I’d like to suggest being able to change the code running on the imp either in squirrel code using a new API call (so I can change it via an input port command) or though the HTTP API directly (or both).
I have an application where I need to support two distinct hardware interfaces (Modbus RTU on RS-485 and an RS-232 terminal using UART) in a single imp but the two applications never need to run at the same time. I’m running into some memory limitations so running code to support both in the same firmware is likely not an option. I’d like to build a custom website for a UI and not need to come to the planner and change the imp’s firmware when I want to select which interface I’m using.
I presuming this feature must be on the list, as a vendor your not going to want to go to the planner to push out code to every customers imp. Presumably vendors will have access to APIs/service to manage customer imps, debug issues, deal with subscription/service issues, monitor etc. One would assume with this service/API you could selectively push different code versions out based on what a customers subscription level/location/paid function etc is.
The idea is that the RS-485 port and RS-232 port would both be permanently hardwired to the impee and use two different serial channels on the imp.
In my application RS-485 will be used 99% of the time to poll Modbus registers. The RS-232 port is only used for a few configuration options that normally don’t need to be reset (and aren’t exposed via the Modbus interface), but are useful for troubleshooting errors.
My code is currently 1489 lines. It is full of comments and hasn’t been particularly optimized so your mileage may vary. I was able to get the code to a point where uncommenting a single server.log() would crash the imp and cause a reboot to occur!
On code size: deldrid1 is not near the imp code size limit (we’ve had discussions offl-forum), but is near the ram usage limit… we’ve seen bigger programs, several thousand lines, but obviously they run using less RAM.
We’re continuously improving RAM footprint and we have options to double code density should that ever become an issue. Also, the server-side imps (which we now call Agents) have less restrictions and can be used to augment the functionality pretty seamlessly.