Netburner and Embedded Linux Cosultant needed

[pbreed]

We are about to release our MOD54415 hardware to beta.
The Final batch of hardware boards are in hand and the two proto's from this batch are being built as we speak.

After this is complete we will build the first batch of 100 to start shipping kits.

This module is based on the MCF54415 and this has an MMU and a freescale provided Linux port.
While we fully support this Module with the NetBurner NNDK, we would also like to offer
a Linux solution tailored to our specific hardware module, as well.

To do this we are looking for a consultant that has both Netburner and Embedded Linux porting experience.

If you have this set of skills and are interested in a consulting job please contact me.
Please put the works MOD54415 Linux in the subject.

P B R E E D at NetBurner.com

[fanat9]

Can you tell us any details on MOD54415?

Frequency - 250MHz ? RAM amount and type?
Both Ethernet will be available ?
Module form factor?

Best regards!

[Ridgeglider]

also please provide info on:
flash / ram setup
usb otg or host support???
number of serial ports and driver type (232/422/485 full or half duplex)
spi dedicated in additon to what's dedicated to sd/mmc?

[pbreed]

250Mhz
64MBytes of DDR2 RAM
16MBytes of Flash.
Separate Serial boot flash so its unbrickable, boot monitor can do autoupdate and ipsetup if
a recovery jumper is placed on the board before reset.

Up to 4 SPI, up to 8 serial ports. (They share pins)
8 x A/D (Two can be D/A)
On Module SD Card.
Same physical size as MOD5234.

On this module the USB pins do not come out.
We currently only expose one Ethernet port.

At the last minute we changed the physical form factor of the flash memory chip from
TSOP to BGA so we can have variants with much bigger flash memory if needed.
I expect these BGA prototypes to be back from assembly and on my desk this week.
I it looks like general beta could be 6 to 8 wks after I approve these.

All system and network software has been ported and is running.
I still have to port the debug mode Ethernet driver.
Pins class stuff done.
Flash file system support is working.
Serial drivers are done.
Generic SPI and I2C drivers will be very different than our stock stuff as the underlying hardware is very different.
Based on our testing network performance is very close to wire speed.

In addition we have a lower cost 54415 module in a different form factor.
(think PCI express card form factor) Hardware specs roughly similar, but
base flash is only 8Mbytes.

We are not ready to discuss this module in detail yet... (I'll wait until we have it running at least)
The Low cost module does not expose the external memory bus.
This module has options to bring out USB host and USB device (pick one, but not both)

[fanat9]

I got a couple more questions :)

Why MCF54415 ? I mean - it have so called motor control PWM module or mcPWM. I read ref. manual on it and looks like it quite capable module, but not like MCF5234 eTPU. Did you take it into account? And that new MOD54415 - a replacement for MOD5234 in a future? Do you aware of Freescale plans to discontinue MCF5234 (I'm not really follow Freescale press releases)?

I can't find any Freescale AppNote's (similar to eTPU AppNotes) for mcPWM yet - do you plan to support/give us a tools/examples in System software ?

[BBAdmin]

Hello,

Thank you for your questions. The intent is not to replace the MOD5234, and if you need advanced timing the eTPU is still the way to go, there are no plans to discontinue it, and it is still recommended for new designs.

The advantage of the MOD54415 is for applications other than eTPU, with lower cost, higher performance, more resources with DDR2 memory controller, multiple serial SPI ports, etc.

[Ridgeglider]

It would really be great to have USB support as a way to allow both add'l serial ports and higher throughput thumb/flash/hard-drive support to say nothing of cameras and microphones.

The SD/MMC interface is a bottleneck if you are trying to log data in parallel from 5+ serial ports...

[pbreed]

A 115.5K baud serial port at full speed is about 11.5K chars per second.

The present MMC/SD system will log at about at 1Mbyte per second.

So with proper buffering the existing system will do 86 serial channels....

If you write to the raw flash frames instead of full file system its at least 2X faster.

Testing the new module shows its even faster....

Something does not compute in your comment?

>The SD/MMC interface is a bottleneck if you are trying to log data in parallel from 5+ serial ports...

[thomastaranowski]

I think what ridgeglider is referring to is using the serial ports as higher speed interfaces to external hardware running at 1Mb/s per. 115.5k would be at the low end of that scale. I didn't find the baud rate limit in the freescale docs, but I believe it was pretty high. In that case saving to on-chip flash, or piping the data out over the network to a network-based logged is the only option.

[Ridgeglider]

Well, thanks for both of your comments. I don't mean to recruit you both into a design review of our system, but, for better or worse we have run into what seem like some bottlenecks associated w/ SD. Briefly, we have ~7 serial ports on a 5234, each feeding into a series of discreet tasks. These ports operate from 115K baud down to 9600 baud to send and receive motor, gps, altimeter, pressure, iridium and similar data streams. We tend to log these streams to SD as raw data. Although in principal, the transfer rate for SD can be fast, in practice we find there are lots of things that slow it down. In our case, incoming raw serial data is timestamped to 1/100th of a sec, written to the log w/ that timestamp, and then parsed for use in various mission planning and control loops as part of a robotic instrument. The raw outbound data to each device is also logged, as well various files documenting ongoing system status including summaries of both the parsed sensor values, and resultant data calculated from them. Each device, and several of the control loops have their own tasks running and logging. Most of the tasks access a log file, sometimes several, that are opened on the hour, written continuously during the hour, and then closed and then incremented with a new file name at the end of the hour. We do this because we've found that opening and closing files after each write is very time consuming. A downside to this approach (keeping the files open) means that data is not flushed after each f_write(). If we flush, either by closing or flushing, speed drops dramatically. So instead, we f_write(), and pray that no mishap causes us to lose buffered, but not fully written data. At any one time, we have close to the max. number of allowed files open (10 I think?). Another issue is that we f_write() data to the log files as it's rec'd in relatively small chunks (say a NMEA sentence). We know it would be far more efficient to buffer this data and to write it less often in larger blocks, but we are short on RAM too and so to date, we haven't pre-buffered it. These tasks create LOTS of files over an ~2week period. We've found that the speed of directory searches to the SD file system associated with finding, opening, flushing and closing files bogs down as the number of files increase. If there are just a few files, things run OK, but with lots of files, things get really slow. I know there are things we could do: we could combine the streams of data and write them into fewer files using larger blocks. We could buffer the data and write it less often. We could write binary files. Those things might be warranted, but they reduce the modularity and independence of the various pieces. Plus, it's pretty convenient to have one ASCII log file per device per hour with a descriptive, timestamped file name. Somehow, we felt that access to USB drives might be a solution for the SD which seems to be a congested place.... maybe not?