There have been a few times where it would have been handy to have something like the DOIA/DOIAP with custom firmware. Has anyone had any luck prying enough hardware and bootloader detail out of Digi to roll your own firmware?
I was thinking something like ucLinux, eCos, or RTEMS to get multitasking and networking. Obviously you’d lose all the nifty Digi features such as the web interface, Realport, etc.
Thoughts?
Not very easy as the RTOS running is a proprietary ‘SUN streams-like’ system optimized for rapid full-duplex ‘streams’ management (aka Ethernet socket to serial data pumping).
However our newer generation Digi Connect products (lacking a DIN rail product yet - but I’m lobbying) include support for Python, and although I do NOT plan to port the DOIAP code to Python, I am looking into providing a “filter-hook” which would allow a customer to snoop on every data packet & tweak/change/answer them from Python.
So imagine a Modbus/TCP to RTU bridge where a tiny Python filter app gets to preview every request and either allow them to pass verbetum to/from serial, change the req or rsp, or answer them. This would allow creating virtual Modbus slave/servers, doing complex ASCII conversion etc.
Not very easy as the RTOS running is a proprietary ‘SUN streams-like’ system optimized for rapid full-duplex ‘streams’ management (aka Ethernet socket to serial data pumping).
Yeah, but I’m not expecting to run your proprietary RTOS. I just want to use the hardware.
For instance, say I want to poll a bunch of RS-485 slaves from the Digi (communicating with a custom binary protocol) and then serve up a summary webpage over the ethernet port.
So imagine a Modbus/TCP to RTU bridge where a tiny Python filter app gets to preview every request and either allow them to pass verbetum to/from serial, change the req or rsp, or answer them.
That sounds like a good idea. Not sure that I’d ever make use of it, but I’m sure someone will love it. (It’s easier for us to mod our device firmware to fit the Digi than it is to mod the Digi to fit our products.)
We do have a line “embedded” products which include the Digi Connect SP and WiSP (Ethernet to serial and WiFi to serial). It is same form-factor as Digi One SP but using ARM processor instead of Coldfire. I am still lobbying to get an ARM-based DIN rail in DOIA/IAP’s case in this line (would be same as above Digi Connect + Python. The method of loading code is well defined for user-developed code.)
These run Digi NetOS or embedded uLinux:
http://www.digi.com/products/serialservers/digiconnectsp.jsp
http://www.digi.com/products/serialservers/digiconnectwisp.jsp
I am still lobbying to get an ARM-based DIN rail in DOIA/IAP’s case in this line
Would this proposed product have plenty of LEDs, full size easy to use DIP switches, two piece screw terminal connectors, reverse polarity power protection, PoE, conformal coating, un-brickable serial bootloader, and all the other nice features of the DOAIP that I love?
Or would it be more like the Wi-SP that I do not love?
It would be something like the DOIAP in same case but with new PCB to support the NetOS tools, so yes. Real surge protection, real quality term blocks (would be larger 200mil kind for std screw drivers) DC-to-DC isolation, the same LED along the top, etc.
PoE would be a question - it adds (literally) about $16 to the adjusted cost (cost - not price) of a product due to isolation transformers etc … and more critically chews up huge real-estate so even supporting as build-option “costs” PCB space.
It would be something like the DOIAP in same case but with new PCB to support the NetOS tools, so yes. Real surge protection, real quality term blocks (would be larger 200mil kind for std screw drivers) DC-to-DC isolation, the same LED along the top, etc.
Sounds good. Frankly, I’ve been a little scared of messing with the customizable Connect modules. From the outside looking in, my uneducated impression is that the support is spotty, there are module and bootloader variants that are confusing, the tool costs are high, and the documentation could be better.
Remember Digi owns Rabbit/Zworld also, so look at what they offer in “box products”. They support tools OTHER than DyncC if that’s an issue.
Digi modules can be done with GNU tools - that is all Digi gives me. I use Ubuntu Linux as a cross-compiler for the ARM products.
Unfortunately that is common - the problem with any raw platform is you can so easily get stuck debugging code for people who should be legally banned from opening a C/C++ manual or pretending to be a programmer.
For example we just an irrate customer complain my MB/TCP to serial in a semi-programmable module didn’t work. When tech support finally gave me a trace, customer was returning badly formed Modbus/RTU responses which lacked 2 bytes of data. Okay, so why blame me if every Modbus/TCP response is missing two bytes of data if the source message is missing two bytes of data?
Seems kind of a no-brainer to check ones own code before wasting hours “on the phone” yelling at tech support people. The Modbus message was displayed byte-for-byte in the telnet trace, they just never bothered to notice it should be 7 bytes long instead of 5 bytes.
Remember Digi owns Rabbit/Zworld also, so look at what they offer in “box products”. They support tools OTHER than DyncC if that’s an issue.
I’ve done the Z-180/Softools thing, years ago. The Rabbit stuff just doesn’t appeal to me.
Digi modules can be done with GNU tools - that is all Digi gives me
I like the GNU tools, for the most part. (I have toolchains installed for arm, h8, 68k, and ppc.)
Seems kind of a no-brainer to check ones own code before wasting hours “on the phone” yelling at tech support people. The Modbus message was displayed byte-for-byte in the telnet trace, they just never bothered to notice it should be 7 bytes long instead of 5 bytes.
Ouch. I remember one time spending quite a bit of time blaming my own modbus code, and then someone pointed me to a personal web site with the DOIAP modbus write single firmware fix… 
It’s a shame we don’t use enough hardware to justify rolling our own DIN rail mount embedded product. I’ve looked around and can’t seem to find anything I really like (ethernet or wireless, isolated 232/422/485 serial, good connectors, PoE, plenty of ram/flash, linux or open source RTOS, industrial temp rating, etc.). But that’s a whole 'nother can of worms.