Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - aaronlawrence

Pages: 1 2 [3] 4 5
We were previously using broadcast UDP packets to discover devices (destination = Now we changed to subnet broadcasts ( a.b.255.255 where a and b are for example 192 and 168).
uTasker does not seem to receive them though from Wireshark we are sure they are getting to the device. No UDP data is received.
Is this expected? Can we fix it?

NXPTM LPC2XXX and LPC17XX / Exception handler
« on: February 22, 2010, 11:51:40 PM »
Hi all, I have made myself a small loop to jump to, if my code crashes. It basically flashes some LEDs at the moment, and I suppose will do more later. I'm currently using it for Asserts and the like.

I would like to change the default exception handlers so if something else goes wrong, it also jumps to this loop.

I see that currently in jumps to default_code: label in startup_gnu.s. How would I change this? Is there some kind of API, or do I just overwrite the exception handler addresses, or ... ?

Just a wild guess, are you sure your MAC addresses are unique? I had some peculiar problems when I forget to program separate MAC addresses :)

NXPTM LPC2XXX and LPC17XX / Re: Hang assigning EMAC_RxStatus
« on: February 19, 2010, 01:37:39 PM »
Still have not had any definitive result here, but the workaround delay fixes debug mode and have never seen it under release. So I'm going to consider it closed. ...

NXPTM LPC2XXX and LPC17XX / Re: LPC17XX Preliminary Information
« on: February 19, 2010, 01:36:35 PM »
Yes, for some cases the "well known supported brand" approach could be useful.
However that sort of negates the benefit of USB memory support, since people expect to be able to use any ubiquitous stick ...
We are trying again at USB mass storage host, but not depending on it. We are now on an x86 platform for our main board, so the USB host  is more standardised (OHCI?) and seems to work so far...

Any custom USB driver with mass storage = run away :)

µTasker general / Re: Polling task goes to UTASKER_STOP
« on: February 19, 2010, 01:29:30 PM »
Oh well ... I did the check in fnApplication to set itself back to polling mode... hope I got all cases.

µTasker general / Re: IPCONFIG default zero ?
« on: February 19, 2010, 01:27:08 PM »
OK, all clear, thanks. I thought that was the implication, but just the way the comment is written isn't too clear.

I already read that other thread. I still haev yet to settle on a MAC address programming scheme...

µTasker general / Success
« on: February 17, 2010, 10:31:16 AM »
We are nearing completion on our new board using uTasker for OS and TCP/IP stack. We are using ARP, DHCP, UDP, unbuffered TCP, ICMP. So far have not found any problems (maybe a few quirks) with the stack; I have found the RTOS a bit fussy to work with, but does the job.

Thanks for the rapid start and good code, Mark :)

µTasker general / IPCONFIG default zero ?
« on: February 17, 2010, 09:01:54 AM »
In Config.h there is:

Code: [Select]
#define USE_DHCP                                             // enable DHCP  - needs UDP - IPCONFIG default zero. Needs 1k Ethernet RX Buffers!! (set random number also)
What does "IPCONFIG default zero" mean??

µTasker general / Re: Polling task goes to UTASKER_STOP
« on: February 17, 2010, 08:49:57 AM »

Thanks for the tips. I understand how to solve the problem, but I find this to be a big bunch of hacks for something that is really claimed to be supported out of the box (polling mode).

I think if you are going to claim there is a polling mode, it should be something you can enable or disable independently, and not depend on a large number of caveats.

As it stands I think polling mode is too fragile to rely on.

I might try and implement a proper polling mode myself in the uTasker loop ie. a separate flag in the task table. I'm kind of committed to this approach now and need something to rely on.

µTasker general / Re: Polling task goes to UTASKER_STOP
« on: February 08, 2010, 06:10:21 AM »
OK, so now I see the problem:

Code: [Select]
extern void fnRtmkSystemTick( void )
                ptTaskTable->ucTaskState = UTASKER_ACTIVATE;             // release task

This code unconditionally sets UTASKER_ACTIVATE... even though it is a polling task... though I suppose the bigger question is why does it think the timer is active? I suppose that really startup delay cannot be combined with polling mode at the moment :(

µTasker general / Re: Polling task goes to UTASKER_STOP
« on: February 08, 2010, 05:57:54 AM »
Well, it seems OK to me. I'm now looking at the code that sets UTASKER_ACTIVATE without checking, e.g.
 uTaskerStateChange(NewWakeTask, UTASKER_ACTIVATE);
if the task being sent to is a polling one, won't this cause it to stop polling??
I'm uncomfortable with the way polling tasks work, it seems like it shouldn't be dependent on a single fragile state variable that is used all over the place. ...

µTasker general / Polling task goes to UTASKER_STOP
« on: February 08, 2010, 03:30:36 AM »
I have set my application to run in polling mode. It is declared like this:

Code: [Select]
{ "app", fnApplication,  MEDIUM_QUE,  (DELAY_LIMIT)((0.10 * SEC) + (PHY_POWERUP_DELAY)),
0, UTASKER_STOP}, // Application - start after Ethernet to be sure we have Ethernet handle

but the application sets itself to polling mode during init:

Code: [Select]
extern void fnApplication(TTASKTABLE *ptrTaskTable)
if ( g_AppState == STATE_INIT )
// set ourselves to uTasker "polling" mode, that is continuous

Is this correct? Can I combine the startup delay with polling mode like this?
It seemed to work fine but now for some reason, the task has stopped running and is waiting for an event. How can that happen?

NXPTM LPC2XXX and LPC17XX / Re: Hang assigning EMAC_RxStatus
« on: January 26, 2010, 01:18:36 AM »
It appears to happen only when debugging (should have checked that before!) and I suspect something to do with resetting ...

NXPTM LPC2XXX and LPC17XX / Re: LPC17XX Preliminary Information
« on: January 26, 2010, 01:17:20 AM »
Comment: in my experience USB host is a nightmare to get working. For one thing there are a squillion possible device types, but perhaps the biggest problem seems to be:

creators of devices (e.g. memory sticks) generally only test them against Windows. Windows has a huge number of sophisticated capabilities, including many workarounds for bad device behaviour. Thus, when you take random "mass storage compliant" memory stick and try to use it according to the specs, it doesn't quite work.

we tried to get USB host for memory sticks working with Windows CE, and neither microsoft nor our BSP developer could get them working reliably across even a decent percentage of consumer memory sticks. They either didn't work at all or worked so slowly (16kB/sec!) as to be useless. One other vendor I saw spent ages working on the microsoft stack and fixed many bugs/workarounds; he went from 50% of his sample sticks working to near 90%...

Pages: 1 2 [3] 4 5