1. Home
  2. Embedded Programming
  3. Hardware/software suggestions for collecting data from legacy serial and Ethernet devices

Hardware/software suggestions for collecting data from legacy serial and Ethernet devices

I'm planning an interesting project that requires data collection from up to 16 legacy devices (simultaneously) via serial (RS-232) and Ethernet links (each using proprietary protocols.) The total bandwidth is quite low (well under 1Mb/s) and the system need only process the data once every 10 seconds or so, so processor performance needs are also low. The system will display a message based on the data collected and provide for simple input via touchscreen LCD.

Since performance is not a major concern and minimal development time is the main goal, I'm leaning toward using National Instruments' LabView for development, prototyping on a PC, and eventually moving to an ADI BlackFin-based embedded system (or similar) for production. LabView's ability to target multiple platforms (FPGA, embedded CPU, PC, etc.) is a nice bonus, and development/IDE cost is not a concern. My main focus is getting a prototype up and running asap, then moving to relatively low-cost (~$1k or less) production system asap.

Based on my research there are numerous potential solutions for this application and it's non-trivial to compare all the options without trying each. I'm wondering what platforms and development environments you would recommended to minimize development time and simplify implementation of this system for someone with more hardware design experience than embedded system programming experience. Am I perhaps overestimating LabView's potiential as a solution for this application? What would you suggest I evaluate as potential hardware and software solutions for this system?

Thank you in advance for any suggestions or recommendations

Reply to
randyest
Loading thread data ...

I would recommend Exar for multi-UART components. A simple ethernet

10BASE-T port controller can be demonstrated with a SiLabs (Silicon Laboratories) part. They would also have a dev kit that would have one of their micros control the ethernet controller (MAC + PHY) and supporting software to implement TCP/IP stack if needed. Newer SiLabs micros have very attractive mips and power consumption numbers. If you require 10/100, take a look at SmSC, they would have non-PCI 10/100 EN controllers. Micrel bought out Kendin; they would have embedded EN hubs and routers for EN port expansion. Thanks, Sch sym
Reply to
schsym

Sounds like you are going to need a lot of serial ports? Or are they bussed onto one via some arbitration scheme?

Ugh. Well, I mean if you like labview, then that's the way to go. If you like traditional programming languages you may well hate labview... I can type a lot faster that I can draw with silly mouse tools, and anything that's available as a labview vi should be available as a function call in a development environment supported by the proper libraries (in fact, most labview vi's probably have c / vb / etc library equivelents available from NI). The big win though is for things that aren't available as a pre-written vi. Programming langauges are much better for low-level manipulation when you have to get creative - to deal with bit/register oriented hardware, to parse strings, service interrupts, etc...

Personally, I'm starting to think in terms of

a) the little microcontroller b) the big microcontroller c) x86 PC...

I have some projects where the same basic C program can be compiled for all three targets, because I wrote my code with the ability to do that in mind. With PC-104 boards, the PC is potentially available as an embedded platform, though we haven't gone there yet.

Reply to
cs_posting

Minimizing the workload here depends a bit on these proprietary protocols. Do you have to implement those protocols yourself, or do you have known-good precompiled libraries? If the latter, you're in a bit of a corner regarding OS support.

My gut instinct for your project description has two forks:

  1. Unless you intend to ship a LabView-based product, I think time spent getting the application running in that environment is probably not going to speed up development of the final product very much.
  2. I would probably want to separate the user interface from the "collect and process data" block and make the connection between the two a TCP/IP link, even if both sides are physically resident in the same hardware. I would most likely write the UI side in Java, because that would allow a broad spectrum of hardware for the UI module.
Reply to
larwe

You should look into sampling 16 inputs from a CPLD, and pulling the data out of the samples.

That should give you the fancy interfaces for the bean counters. Not sure if it helps with the product developments.

I am currently involved in a project with fancy packagings (interfaces), but the core is rotten. They spent tens of thousands before realizing that the core design is faulted, but sometimes it's necessary to get a project through the visualization phase (for the managments, of course).

Reply to
linnix

I'm considering a multi-port serial-to-ethernet, or 1-port serial-to- ethernet converters (such as

formatting link
for prototyping. In the end, I'm hoping to use SPI to bus the serial connections together.

I'm a hardware designer, not a programmer. I do know C fairly well, especially for embedded apps (i.e., not MSFT windows GUI stuff) but others who will necessarily be involved in implementing the data flow and user interface are not programmers at all.

This is an >

I intend to ship a LabView-based product.

The UI module and data collection module will always necessarily be in the same physical unit. And remote-monitoring/control via LAN will be a part of the system.

l>

Interesting idea, thanks. Sounds like it would be cheaper than standard serial->ethernet parts, but maybe more work and take longer to make perfect.

The fancy interfaces are actually for the end users. The system will be used by very non-technical people. I need to make both the core and the UI good and robust.

Reply to
randyest

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.