Design Advice

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Design Advice
Quoted text here. Click to load it
I would look around for a better development environment than
Codewarrior.  Maybe check with IAR.

Re: Design Advice
That's exactly, what I am doing with NUT/OS and Ethernut board. But if you
choose it - start from Ethernut-2 and consider using external WDT.
Regards, Alex.
Quoted text here. Click to load it
listed?
Quoted text here. Click to load it



Re: Design Advice
Quoted text here. Click to load it

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 ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Design Advice
Quoted text here. Click to load it

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

Re: Design Advice



Quoted text here. Click to load it

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



Site Timeline