Messages

1

µTasker general / uTaskerFileCreate.exe - application error

« on: March 17, 2010, 05:42:45 PM »

Hello,
Having a problem with uTaskerFileCreate.exe generating an application error.
I have put together a test case that shows an example of it crashing.
Run the 'RunMe.bat' file

. The table generated looks like this:
static const USER_FILE user_files[] = {
{"eimg.jpg", (unsigned char *)_eimg, sizeof(_eimg), MIME_JPG, FILE_VISIBLE},
{"fimg.jpg", (unsigned char *)_fimg, sizeof(_fimg), MIME_JPG, FILE_VISIBLE},
{"gimg.jpg", (unsigned char *)_gimg, sizeof(_gimg), MIME_JPG, FILE_VISIBLE},
{"himg.jpg", (unsigned char *)_himg, sizeof(_himg), MIME_JPG, FILE_VISIBLE},
{"iimg.jpg", (unsigned char *)_iimg, sizeof(_iimg), MIME_JPG, FILE_VISIBLE},
{"jimg.jpg", (unsigned char *)_jimg, sizeof(_jimg), MIME_JPG, FILE_VISIBLE},
{"kimg.jpg", (unsigned char *)_kimg, sizeof(_kimg), MIME_JPG, FILE_VISIBLE},
{"limg.jpg", (unsigned char *)_limg, sizeof(_limg), MIME_JPG, FILE_VISIBLE},
{"mimg.jpg", (unsigned char *)_mimg, sizeof(_mimg), MIME_JPG, FILE_VISIBLE},
{"nimg.jpg", (unsigned char *)_nimg, sizeof(_nimg), MIME_JPG, FILE_VISIBLE},
{"oimg.jpg", (unsigned char *)_oimg, sizeof(_oimg), MIME_JPG, FILE_VISIBLE},
{"pimg.jpg", (unsigned char *)_pimg, sizeof(_pimg), MIME_JPG, FILE_VISIBLE},
{"qimg.jpg", (unsigned char *)_qimg, sizeof(_qimg), MIME_JPG, FILE_VISIBLE},
{"rimg.jpgÿØÿà JFIF
  d d  ÿì Ducky
   d  ÿî Adobe dÀ   
ÿÛ „







{0} // end of list
};

If you comment out any one of the jpg files in userfiles.txt, the problem goes away.

Has anyone managed to work around this one or knows what causes the application error?
Thanks.

2

µTasker general / Re: PPP

« on: March 07, 2010, 11:24:37 AM »

About to look at PPP for AT91SAM7S (but working with the AT91SAM7X for the moment)
Has anyone got it working? - or can give some direction on what I need to do - and where.
If its much less work, SLIP is always an option.
Thanks.
Jon.

3

µTasker general / Re: No more answer on Ethernet after HTTP use

« on: March 06, 2010, 09:21:10 AM »

Thanks.. I nearly got there! I was calling fnOpenDefaultHostAdapter earlier on... unconditionally (bad)
fnConfigEthernet() is the obvious place to call it.. Thanks for pointing me to a better solution!

In summary:
When LAN_REPORT_ACTIVITY is commented out, INTERRUPT_TASK_PHY is not defined and WINCAP thread is not started.
To Fix it, I moved fnOpenDefaultHostAdapter(); in SAM7X.c :
#if defined SUPPORT_PORT_INTERRUPTS
    #if defined INTERRUPT_TASK_PHY
    interrupt_setup.int_type = PORT_INTERRUPT;                           // identifier when configuring
    interrupt_setup.int_handler = fnPhyInterrupt;                        // handling function
    interrupt_setup.int_priority = PRIORITY_PIOB;                        // port interrupt priority
    interrupt_setup.int_port = PORT_B;                                   // the port used
    interrupt_setup.int_port_sense = IRQ_FALLING_EDGE;                   // interrupt on this edge
    interrupt_setup.int_port_bits = PHY_INTERRUPT;                       // the input connected
    fnConfigureInterrupt((void *)&interrupt_setup);                      // configure test interrupt

    fnWriteMII(KS8721_INTERRUPT_CONTROL_STATUS_REGISTER,                 // enable various PHY interrupts
//             PHY_REMOTE_FAULT_INT_ENABLE
//             PHY_LINK_PARTNER_ACK_INT_ENABLE
//             PHY_PARALLEL_DETECT_FAULT_INT_ENABLE
//             PHY_PAGE_RECEIVED_INT_ENABLE
//             PHY_RECEIVE_ERROR_INT_ENABLE
//             PHY_JABBER_INT_ENABLE
              (PHY_LINK_UP_INT_ENABLE | PHY_LINK_DOWN_INT_ENABLE)
               );
    #endif
#else
    fnEnterInterrupt(PIOB, PRIORITY_PIOB, PortB_Interrupt);
    PIO_IER_B = PHY_INTERRUPT;                                           // enable interrupt line from PHY
    #ifdef _WINDOWS
    PIO_IMR_B |= PIO_IER_B;
    #endif
    fnWriteMII(KS8721_INTERRUPT_CONTROL_STATUS_REGISTER,                 // enable various PHY interrupts
//             PHY_REMOTE_FAULT_INT_ENABLE
//             PHY_LINK_PARTNER_ACK_INT_ENABLE
//             PHY_PARALLEL_DETECT_FAULT_INT_ENABLE
//             PHY_PAGE_RECEIVED_INT_ENABLE
//             PHY_RECEIVE_ERROR_INT_ENABLE
//             PHY_JABBER_INT_ENABLE
              (PHY_LINK_UP_INT_ENABLE | PHY_LINK_DOWN_INT_ENABLE)
               );
#endif
#ifdef _WINDOWS
   // Moved by JN, fnOpenDefaultHostAdapter should be called at all times, not just when the INTERRUPT_TASK_PHY
   // is defined. Ref: http://www.utasker.com/forum/index.php?topic=542.0
   fnOpenDefaultHostAdapter();                                          // simulate link up
#endif
}

4

µTasker general / Re: No more answer on Ethernet after HTTP use

« on: March 05, 2010, 01:31:39 PM »

I too have had some problems getting the NIC recognised in the simulator. (VS2008, XP)
It worked the first time.. but after that nothing, not even an answer to a ping.
To get it back I did the following:
Closed the simulator -> deleted the NIC.ini file -> restarted the simulator -> reselected the interface from the menu:
Hay presto : it worked again.

So, I investigated what happens in the handler for dropdown NIC selector .v. what happens during the application startup..
This is what happens when the drop down is selected.. - in SetNIC(..)

case IDOK:
  if (iNewSelection != iactive) {
  if (iUserNIC < 0) {
    iactive = iNewSelection;
    fnWinPcapClose();                            // close present adapter
    fnWinPcapSelectLAN(iNewSelection);
    fnWinPcapOpenAdapter();
  }
  iUserNIC = iNewSelection;
}

This is what happens during the application startup.. - in WndProc(..)
 case WM_CREATE:
#ifdef ETH_INTERFACE                                                     // {10}
    iUserNIC = fnGetUserNIC();
    fnWinPcapSelectLAN(iUserNIC);                                // select the NIC according to the user setting        
#endif

__
I noticed when the application is started up, the NIC was selected, but not started up. I added the following lines, and fixed the compile errors and hey presto.. it worked. Green lights flashing again!

case WM_CREATE:
#ifdef ETH_INTERFACE                                                     // {10}
  iUserNIC = fnGetUserNIC();fnWinPcapSelectLAN(iUserNIC);                                // select the NIC according to the user setting
 fnWinPcapOpenAdapter();
  fnWinPcapStartLink(ghWnd);
#endif

I have a number of possible interfaces to select, so it could be getting confused.
Also, I ended up changing the code that checks the selection had changed, this gave more reliable 'switching' between different interfaces while running. The condition: "if (iUserNIC < 0)" was never satisfied, and hence, never changed the interface.
case IDOK:
  if (iNewSelection != iactive) {
    if (iNewSelection >= 0) {
      fnWinPcapClose();                            // close present adapter
      fnWinPcapSelectLAN(iNewSelection);
      fnWinPcapOpenAdapter();
    }
    iactive = iNewSelection;
    iUserNIC = iNewSelection;
  }

This caused the NIC to startup reliably in the sim, and change following a reselection in the drop down.

Not saying I fixed it, its just what got me working.
I'm hoping I have not introduced a new bug in the process!!
These problems could be linked to having a long list of interfaces in the drop down list. In my case 4. I have to select the third of 4.
Post here if this helps..
Jon.

EDIT:
The application sometimes crashes on startup, and the green LEDs dont work too well.. but it is responding ok.
I think there is a threading issue with PCap and the Windows application.
A better solution anybody?

5

µTasker general / Fast task response to an interrupt

« on: February 10, 2010, 08:12:03 PM »

Hi, been playing around with the demo application and like the way it can easily give us all the bells and whistles we need for our project - file system, webserver, usb, tcp, bootloader and so on.. all with a neat little scheduler that fits my preferred programming model of event based state machines.

As an aside, a table driven hierarchical state machine I have used in the past...
http://embedded.com/design/10700829

My past projects tend to run a pre-emptive RTOS - and for most of the 'executing time', they don’t need to. Agreed.
There is one case where I have relied on pre-emption to meet some tight real time constraints - and can't see an obvious solution using the uTasker scheduler. Really I'm looking for some tips/tricks/strategies on if/how I can solve these problems.

It concerns situations, for example,  when external devices give an interrupt to signal they need additional attention - and fairly quickly. A 'hypothetical example' is the SPI CAN driver chip MCP2515. It lets me know a message is waiting in the RX buffer - but I cant read the buffer from within the ISR (SPI comms within an ISR is not good practice!) .. If I leave it too late the buffer gets ovewritten.
So, what I do is have the ISR post an event to a task called 'ReadMCP2515_RxBuf'. The 'ReadMCP2515_RxBuf' task reads out the contents of the buffer over the SPI and places it in a FIFO in RAM for other tasks to consume as and when they can. (Assume CAN messages arrive in bursts)

Most of the time all tasks are waiting on a empty queue, so the real time requirement is met, but there will be conditions where this clashes with a periodic task, such as an ADC read - that in turn will start a flurry of message activity between tasks - status updates, LCD updates.. etc. all the time our 'ReadMCP2515_RxBuf' is not getting any service. (No one said event driven programming was easy!)
Ideally the current SPI operation finishes its chip select - (this could include an LCD update OR and an ADC read..) then the 'ReadMCP2515_RxBuf' should get started as soon as possible.

What are community members thoughts on tacking such an issues?
Multiple entries of 'ReadMCP2515_RxBuf' task in the table of tasks to be run?? That sort of thing??
Thanks,
Jon.