This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Where to start? TM4C129 based ethernet enabled industrial sensor



Hi Folks,

We are working on an industrial sensor that reports it's values to a MySQL database server via ethernet. We have a prototype on a RasPi with Linux, but for a production version this seems like overkill. 

I am now looking for a Microcontroller and software to achieve the same. Is there a good place to start looking? Might the DevKit actually already provide a software framework? From the documentation I can't tell.

Our "spec":

* ping - able
* http server (simple HTML showing device values)
* DHCP client
* SNMP GET/SET/TRAP 
* NTP client
* TCP/IP communication with MySQL database server (like: https://launchpad.net/mysql-arduino)
* Firmware updates via ethernet
Looking forward to your input!
  • Using something with less power may be a challenge.

    Try the Beaglebone -- it uses a TI processor. 

    I have done sensor networks with TCP/IP and UDP reporting to a PC with a Delphi (EMbarcadero Object Pascal) front end to an Interbase SQL (Embarcadero) server on Linux.

    It's the feed rate for packets that is the issue. If you are collecting more than 1000 - 2000 packets a second then even a multi-core unit may be preferable, Expect lots of dropped packets if you use low clock rate MCUs and a 1K Hz + collection rate.

    If its a reading every few seconds or so you should be OK on lower power MCUs.

    Interrupt driven sensor bring their own problems to the mix (collecting at a fixed rate). Polled sensors -- low volume should not be an issue since you control the collection and the feed rate -- you likely cannot maintain a fixed rate though...

    Clear I hope...

  • Thanks Dave! I originally had the BeagelBone planned but I accidentally blew it up: BeagleBone IOs are not 230V AC tolerant ;-)

    Good point about the speed, let me give some more details:

    * Webserver will be used to configure the sensor and check status. no more than 2 sessions will be open at any time.

    * Sensor reads are asynchron. at most 100 readings per second. normal operation 5 reading per second. Time to database is not critical. if it takes 20 seconds no one will care/notice. Jitter is not an issue either.

    * Sensor read/write and data processing is done on a 16bit MSP430 and right now transmitted via UART. We just want to switch to ethernet and a single MCU design for production.

    * I would like to use the native MySQL connector and avoid writing my own one. I am afraid that setting up the database would become a support nightmare otherwise.

    I feel like the T4C129 would be a nice fit. I am just afraid of starting from scratch and face a skyrocketing the development time. 

  • Hi,

     Much easier would be as already suggested to use Beaglebone Black.

    Running nodejs webserver with websockets will give you a real time web with very low effort and plenty

    of examples available online.

    Good luck.

    Jan

  • ucDude said:
    BeagleBone IOs are not 230V AC tolerant ;-)

    Nor are the I/Os of just about any MCU presently known to man...

    Unfortunately - while your introduction of, "out of spec" input signal was extremely severe - such, "Whoops! Signal introductions" are not especially uncommon.

    A proactive method - which our group long has used - employs a separate, I/O "safety board" which is imposed between the MCU and the external world signals.  This board is voltage/current limited - may even employ isolation or opto-coupling to prevent such, "unfortunate, MCU-killer (& beyond) signal introductions!"

    Yes - there is a cost associated - but such board can be "deleted" from the final/production bom once the safety of each/every input signal - over time - has been well established.  There is also a time/cost/effort penalty caused by such unfortunate signal introductions - which may slay the MCU as well as multiple, other components.  And - if you're especially unlucky - unexpected, elevated voltages may harm expensive test equipment and/or even personnel.  And then - just what have you, "saved?"

    We now always use such, "Safety" boards - and can report the incidence of such "disasters" has near vanished...

    An ounce of prevention...