Then we’ve effectively recreated the two-language problem. It also directly contradicts the title “C codegen considered unnecessary: go directly to binary, do not pass C”
C codegen isn’t necessary but it is an option (and may be the best option for some users)
2 Likes
Absolutely. If I look at the projects at my place of work that run on embedded hardware, they have 100K+ LOC written in C already. And that’s on top of an already existing RTOS like zephyr or threadx. My current work flow consists of generating C code and passing that off to the dev team. That way everything is checked into version control, and easily maintainable and compilable because it just more C code.
I think calling that c code from Julia is an acceptable way to have a digital twining environment as there may be other reliability and safety concerns that Julia is not able to tackle right now.
I like the initiatives some people are taking to realize PID and other controllers written in Julia directly to hardware, especially for academic and prototyping settings.
Some of the systems I’d be interested in modeling are complicated systems of systems with not only a control loop, but also kalman filtering and state estimators, perhaps machine learning elements, and other arbitrary state machines, sensor fusion, yada yada yada. A concise way to tackle this in a Julia Environment would be golden.
2 Likes
Hi @Allan_Baker
and …
Only two yada, yadas but what you just said was what I did in Julia. This was just over three years ago now and I was only a one-man-band but the door was always open for the deep learning (DL) stuff. Actually, my biggest problem was getting to grips with multi-threading races.
I really like the way @ChrisRackauckas suggests the uncertainty can be handled by embedding DL into classical code using MTK.jl but I didn’t have the time.
State estimators can be made to reject bad data by using re-weighting techniques as well as smooth out Gaussian stuff. I am still somewhat biased against the use of machine learning for on-line, real-time use.
BTW: I ran the Julia-only code on a (I think it was) 48 virtual-core Concurrent Machines computer running a deterministic real-time OS, RedHawk Linux. Julia was perfect for this as the OS allowed one to choose which cores were 100% available and Julia made it a snap to run code specifically on those dedicated cores. Julia and an RTOS is a match made in heaven.
The dimension (i.e. order) of the MIMO system TF was way to big/unstable/interacting for PID although I did investigate using a diagonalising precompensator, which potentially would have exposed the TF matrix diagonal elements as suitable for individual PIDs. But, too complicated and long-winded to explain why I didn’t! 
3 Likes
That sounds pretty cool. For the applications I’m talking about they could be on severely limited SWAP hardware like DSPs or FPGA based socs. Many times without an OS and running bare metal in a deterministic fashion.
1 Like