52233 Demo, NicheLite and RTOS porting

[jes]

Hi,

I'm perusing the demo board code CodeFire_Lite.mcp which came with the board.  It has it's own OS that does some yielding of tasks, blocking, etc - ie cooperative multi-tasking.  It looks to make some possible accommodations to port to a different OS via the osporttk.c  which shows definitions of macros TK_APP_BLOCK, TK_NETRX_BLOCK, etc. (and possibly elsewhere?).  Has anyone tried to port their own RTOS in place of the existing one or is the existing one too inextricably entwined within that code?

We'd prefer to port an application currently run on the 5213x ColdFire over to 52235 in order to replace an existing Lantronix XPort IP device interface and use the capabilities of 52235.  But we'd like to minimize impact on existing code base using our existing pre-emptive time-sliced RTOS.  Note that our existing RTOS is only 5K or so in size so it's not a behemoth in terms of sucking resources.

Can anyone advise whether this adventure is possible or would it be ill-advised for reasons that aren't readily apparent in short study of that code?  Is the arrival rate of Ethernet packets possibly too high to allow much time for other processing w/o dropping packets?  Judicious filtering of packets a possible remedy?

Thanks.

[mccPaul]

If you port your existing OS you may have to fiddle with interrupt priorities to make sure that the FEC RX interrupt can be serviced reasonably promptly if your OS is using a timer ISR for pre-empting tasks. That shouldn't be hard to arrange as there are so many interrupt levels/priorities available.

The 52xxx FEC does a lot of the work for you in terms of dropping unwanted frames and even if you need to allow broadcast frames through (for ARP, etc.) then the frame is flagged as a broadcast to the driver. You can then peek into the frame to see if it is a protocol you want (ICMP say) or a protocol aimed at you (ARP request say). Uninteresting packets can be filtered and dropped with a very few lines of C or even assembler. Interesting packets just need to be queued and signalled to your network stack.

Because the FEC has its own DMA engine packets are transferred from the FEC FIFO into RAM without any CPU intervention so you can have a reasonably big ring of frame buffers if neccessary (memory constraints aside). On the TX side, we have an application where we need to shovel UDP packets out as fast as possible and we have achieved a data rate (payload) of >90Mbps. This is with a 5282, but we are using the 5282's SRAM for this and the FEC is the same as the 522xx. We believe that the CPU usage to service this is <5% leaving us plenty of CPU time for stack and task management (the data bus can get a little crowded at this rate though).

The InterNiche stack that comes with the 522xx is just fine, but you shouldn't find it too hard to port your existing OS because the FEC design makes life simple (easy to say once you've done it I know!).

Paul.

[jes]

Thanks Paul, I appreciate the response.  I suspected it was possible and posed the same questions via a Freescale Technical request.  After a couple of go-rounds with tech support there they finally responded "Why would you want to do that?" and "Just not enough horsepower".  I pressed them for some specifics other than those replies but was rebuffed with "We already told you no", "Why don't you believe in us" and "Read the disclaimer which say we don't SUPPORT this".

Happily this forum has always provided more technical info than Freescale Tech Support has.  It's hard to drill down thru Freescale layers of support to get an engineer intimately familiar with details such as this.

At least I can proceed now with more confidence knowing it's a path already travelled.

Do you know of any possible 'gotchas' beyond what you already mentioned that I should be on the look-out for when porting?

Thanks again.