simavr

I'm a huge fan of tcc. I use it on embedded systems -- a good trick is to pre-process any headers you need via cpp preprocessor, 'compress' them in a single file, and add your .c to that. That way you don't need to cart around all the -dev packages etc. The 'hidden gem' of tcc is libtcc (the backend), which you can use as a JIT subsystem in your own code. For example I've written a full JIT translator for simavr [0] like that. The code translates each AVR opcode into it's own little piece of C, then compile the whole 'firmware' and runs it. [0]: https://github.com/buserror/simavr/tree/wip/jit

I tend to agree, up to a point, however I still use the GPL because it at least gives me a leg to stand on for people actually ripping your code and selling it as is... (What I call the packagers) I'm sure that if Linux wasn't GPL, you'd have 'vendors' selling 'HP Linux' and 'Corp Linux' to their locked in customers in no time at all. The only reason Linux grew up to this point is that the vendors are forced to contribute back and cooperate (up to a point). Mind you it might also be the reason Linux is so bloated these days, but at least there is no vendor lock in... As a small example, someone decided a few years back to release a "Arduino UI" over my own simavr[0] as an indigogo project. ie trying to be paid to package a demo I made (for free): he had screenshots, a few promises and no source code. I managed to email the guy telling him

I do use it as interpreter on embedded boards! Preprocess/trim the headers you need, and add #!/bin/tcc -run at the top of your .C file, add a +x to it and it'll run just fine! I love tcc, in fact I added a firmware instruction translator to 'JIT' AVR code to simavr a few weeks ago. Takes a AVR binary, translates it to C, and compiles it on the fly with libtcc to run it :-) https://github.com/buserror/simavr/tree/jit-wip

I'm a huge fan of simulations, I don't think you can develop a 'good' embedded system without it. My way of implementing something embedded is: * Develop a capture program for the input feed/sensors, and capture as much as you can. * Develop a software model to recreate the input for a 'target' embedded system * Write the embedded system against the captured input. That will get you 95% there. * Run it 'live', check anything wrong (you will). Usual debugging & tweaks. * Do a feedback loop if problem input comes in, and keep /that/ preciously for your test unit sequence. * Once software is done, every time you make a change, run your simulator with all the test input you have and check your output for divergence. I very, VERY rarely need to JTAG into a board, I'd rather spend the time on the simulation model and get it accurate as I can th

Yes it's strange, it's one of the reason I stopped using C++ as a matter of fact. Given the innate amount of code required in C++ constructor to initialize objects, you'd think that would be very handy. BTW, shameless plug, but my own simavr uses these C99 features as more or less the whole basic structure on how multiple cores are described, see a sample core declaration [0] for example. The beauty is that there is no code involved in the declaration, it'll be 'const' too. Imagine the boilerplate you'd need to do that in C++! [0]: https://github.com/buserror/simavr/blob/master/simavr/cores/...