Quote:
Originally Posted by AustinSchuh
That is definitely an issue. Though once again, you could do what they did for the Jaguars, and add it in after a year as a firmware upgrade. And who says that the interpreter has to be fancy or anything? Forth, basic, scheme(!)... There has to be a simple interpreter already out there. Scheme would be really easy to write, too. There is very little to no syntax. Or something like Logo, or ...
One of the really valuable parts of having a control language is that you can run things that matter and are custom at very high frequencies (1khz), and it can be sandboxed so that FIRST is always in control. Without having to mess with extra hardware which adds significant development and manufacturing challenges.
|
I'm not saying it can't be done. With enough cooperation between the module development before the language and the people that develop the alternate firmware they add to the interface module later in the lifecycle of the module it could be done. I just encourage you to consider that you'd be linking the life of your additional project to the lifecycle of the interface module you added it to.
For example of what concerns me:
Let's say we have a CAN equipped interface module. It's appoved and we as a community have a supply process to satisfy FIRST as part of the approval. You decide to work with the people that made that CAN equipped interface module to make your custom firmware. Great, no problem yet. Then the next year you help the CAN equipped group offer your extra firmware for the same CAN equipped interface module for FIRST to review and approve. Still no issue.
Let's say the next year the folks making that CAN equipped interface module decide they need to alter that hardware in such a way that it still performs their original specifications, but it tweaks your additional firmware. Well now you'd have to play along with their change. You may have the language stable and working and suddenly you've got to change it because they decided to change.
I propose to fork the project to avoid you dragging each other with restrictions or schedules. You can certainly absorb their module as it already exists. So just make your firmware and make it work then take it for approval. If that module project decides to make hardware changes later you can just keep making the original module with the same community resources. The community shouldn't look at it like being asked to make old hardware for the original project. They should look at it as making the hardware to support your language. Nothing would stop you later from later making the upgrade to match the original interface module again. However, you could each operate freely of each other in the mean time.
It's mostly just an issue of logistics. Not a way to make the language developer stuck to making hardware. I suspect most interface modules will rely on community resources for manufacturing anyway so I'm not sure it's much impact except to change some part numbers.
Outside of those mostly bureaucratic concerns I think it's a valuable idea for the same reasons you've stated.