1. Home
  2. Embedded Programming
  3. Design Advice

Design Advice

Hi All:

I would like some design advice from those that have 'been there / done that'.

We are designing a fairly simple data logger. In essence, this device will connect via serial to an industrial machine and log the data to a database via a standard ethernet port.

We are currently evaluating two different paths to accomplish this:

(1) ATMega128 controller and use the Nut/OS suite as the software development platform

(2) Use the Motorola (freescale) MC9S12NE64 controller and use the TCP/IP stack from Motorola and development environment from CodeWarrior

My basic questions are;

(a) Does anyone know of any immediate pros/cons of the above MC's listed?

(b) Can anyone comment on having used the Nut/OS (Ethernut) suite?

(c) In practical uses for small projects - is using an embedded OS better than just coding direct to the chip?

I appreciate all comments and pointers....

Thanks, Barry

Reply to
BarryS
Loading thread data ...

I would look around for a better development environment than Codewarrior. Maybe check with IAR.

Reply to
cmplx80

listed?

Reply to
Alexander Baranov

I suspect once anything supplies you the TCP/IP stack 90% of the work is done. You should be worrying more about how to handle the situation when the database system or network is down, and thus how much buffering your system contains, and what it does when those buffers overflow. You should also worry about metering out the buffered data when the DB system comes on line, as an immediate dump of all the buffers may overload it or the network.

Similarly you have to worry about guarding against bad or partial incoming data on the serial lines, and how to handle these.

Offhand it doesn't sound like anything that needs an OS.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer

Good points.

For the record, the approach I'm taking for these items is as follows:

(a) Each poll of the idustrial machine will result in about 60 bytes of data collected. We are going to equip each device with 2MB Flash - so that should be enough to buffer more than a day based upon a poll interval of once every 4 seconds.

(b) For the transport, we are going to use UDP - obviously I understand that it is connectionless, but thats the point in a way. I want the devices on the floor to continue sending out data no matter if the DB is up or not. There will be a listener port on each device which the master server can connect to in order to request a re-send of data.

This should simplify development since I want to push the "intelligence" to the master server and let it be responsible to ensuring that it has all the data packets it needs.

In the case of a DB / Master Server going off-line, the devices on the floor will happily be sending updates over the ether. Once the DB gets back up, the Master Server can re-request the last X number of packets to ensure all data is collected.

This is a situation where it is not critical that the data arrive by a certain time, just that the data is eventually accounted for. So, there are no hard-limits regarding time of data collection (other than common sense).

Anyway, thanks for your comments...

-B

Reply to
BarryS

UDP also mean no guarantee the packet arrived at the Master. You need to take care of retries.

Reply to
Neil Kurzman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.