I am currently working with the G30 TH module. My task is to create a general-purpose* firmware that will allow our customers a lot of freedom in the use of our device.
*by general purpose I mean the user will have the ability to program what the device that our board controls does and when it does it.
I am prepared to set out on a journey of creating a sort of command interpreter that will reside on the board as well as a PC tool for creating lists of commands. And of course the communication paths that will get those commands loaded into RAM (or non-volatile storage if possible).
However, I have come across the notion of a GHI original tool called RLP. I am looking for advice here. Is RLP a better method of producing the desired firmware? Perhaps producing a PC program to generate and compile source code that can be invoked by the managed code already on the board is an easier path? Perhaps large arrays of commands will not be processed quickly enough by managed code?
The latter question above leads me to a large source of confusion: are the ELF files and what not of RLP something that can be created and loaded by my PC tool once the customer has the board or is it just a tool to incorporate faster executing native procedures at the point when we flash the boards before shipment?
Obviously I’m a bit green here but I would appreciate any advice pointing me in the right direction.
@ jwizard93 - So backup a second. Why not just let them program it with c# just like you did? Provide them a COMPILED Api that abstracts whatever the device does in an easy and safe way, and let them use that. So long as your IP isn’t that API you’re fine. Otherwise you’re going to have to write an interpreter for python or javascript.
@ Mr. John Smith - Thanks for the suggestion. I’m not 100% sure if I see the whole picture of what you are talking about. Are you referring to having users reference DLLs that I provide to create new programs? I like the idea a lot but I’m afraid things stand in the way of how I think that would work.
The biggest obstacle being the fact that one would have to take apart the product to reflash the board.
I have a feeling that, software wise, you’re idea would be the easiest route to achieve the goal and achieve it well but I’m not sure how much easier. The command interpreter I’m talking about is not a JavaScript or Python or anything existing language interpreter. I mean something more like:
CODE "05 73 FF DC A4" means do ACTION_3 at a rate of int(A4) or something like that. And I would have a unique code for every possible action and parameter.
The PC tool would load these in memory over a wireless connection.
I’m still wondering what the existing alternatives are if any. Interops?, RLP?, (is CodeDOM a netmf thing?) or even if you think I’m wrong about not being able to achieve what you suggested please let me know.
Thanks again for offering assistance. Much appreciated.
How so? How far is the usb connector from the outside world?
What wireless solution are you using? If it’s WIFI, then you may be able to use an ESP8266 to connect to COM1 of the G30 for remote debugging (and a virtual com port software or hardware since visual studio also needs to be fooled).
@ Mr. John Smith - [quote]
How so? How far is the usb connector from the outside world?
[/quote]
My employer has informed me that the USB port will be made available in the next product revision, but that it will not be used to flash the boards in any method other than official updates. I don’t know if we will be able to stop people from doing so but it will be entirely unsupported.
XBee radios.
[quote]If it’s that simple then 1) spec out your language definition (write the Backus-Naur form), 2) Implement a parser and evaluator
[/quote]
I believe it is simple enough for such an approach. It’s been suggested that I check out the way the Vive controllers are configured using jSON. And thanks a lot for pointing me towards some theory on what I need to accomplish if that is the route.
One of the oceanographic profilers I work on has to be programmed with a “mission” defined by the user and we need to change the mission while the profiler is out at sea. The mission defines such things as how deep to dive, how fast to descend and ascend, how long to park, when to sample the attached instruments and so on. My approach is to write a desktop GUI that allows the user to define the mission. The GUI basically fills in the properties in my mission class. Then I serialize the mission class with the standard .Net Micro serializer and send it via Bluetooth or Iridium satellite to the system embedded on my platform and the embedded software deserializes the class. I haven’t written the GUI yet, just the serializer. When I do get time to write the GUI, my plan is to use desktop C# since I’m already using it for my .Net Micro embedded system and the full desktop .NET is great for developing GUIs.
I’ve been down the path of writing my own command interpreter for user interaction. By the time we got it close to working we had basically written a crappy custom programming language. Eventually we trained our users in Ruby and that worked better but I wouldn’t do it that way again unless the user really needed to write a pretty sophisticated program to control our system.
@ Gene - Thank you for sharing your experience and insight. If I may ask you more about your system, does this happen without the device needing to reboot? I mean are the serialized and then deserialized objects instantiated by already running firmware that doesn’t need to stop and reload itself to begin executing the new assembly?
In Gene’s case, it doesn’t sound like it’s a new assembly being read, but simply a new set of instructions.
Your application idea is a complex one. I’d suggest you search out posts here from skewworks and Thom’s great application framework work he’s done.
@ jwizard93 - No reboot required. I use a state machine architecture. When bytes show up on either the serial port connected to the bluetooth module or the Iridium modem, the standard .Net micro serial port event handler gets the message which includes the serialized byte array with the new mission parameters and sticks it on my queue. When my state machine sees the message in the queue, it fires the method in my mission class that deserializes the byte array from the queue and replaces the old mission parameters with the new ones.
We have developped something similar using Excell file as primary input for final application. This file is serialized into xml and define a set of variables, a set of communication ports, a set of protocol to fill up data variables using the corresponding protocol. There’s also a set of function (mission) made of instructions, each instruction is composed of a set of conditions on the variables and if these conditions are met then actions (relays, data send to port…)are taken.
This way our firmware can target a wide range of functionnal applications as can be done using a PLC.