I’ve started a Github repository for some modified patches and header I’ve needed for my ATTiny-based XOD project. There’s an #include file which should be added at the top of the transpiled XOD code, and then while using the two libraries mentioned in the readme installed from the Arduino IDE repository, and changing the line in the generated XOD source “typedef double Number” to “typedef ATTinyNumber Number” when using the posted patches things should work OK…
Will post new node code as I clean it up and add it. Some of the nodes from the core work OK unmodifed due to compile-time overrides in the fixed-point math library.
Although I consider fixed-point math replacement highly experimental, I wonder how could we help to hook such additions in a more straightforward fashion…
Let’s try to split the problem we’re facing now.
No way to add a board to the list of supported targets for the upload dialog
No way to inject code specific to a particular board into the output
No way to override some code specific to a particular board
The (1) is tricky because it should not only extend the drop-down list of board models but also provide all necessary tools and extra C++ files for (2) and (3). If you have any ideas on what UX (what he clicks, what he sees, where it is grabbed, where it is put) is when he wants to include the support for ATTiny provided by you, it would be interesting to hear.
The (2) is solvable if we’ll let a particular board model to provide its extra C++ files that would be injected near the top of the output.
The (3) could be trivially resolved by using many #ifndef guards to allow overriding, say, Number type in the extra files from (2).
A quick thing I should mention is that it may be possible to make most if not all of the stock nodes function as-is via only changing the “Number” typedef, but it would require doing a significantly more challenging rewrite of inheritance subclasses from the fixed point lib’s types to make their overloads and conversion operators very XOD-specific. Probably using private inheritance and doing a bespoke re-implementation of all the operations the core requires, e.g. like piecing together a “long long” for the clock node’s timer call from a fixed point integer and fractional part.
I’ve been messing with that but that’s not really my strong suit in C++ The lib seems well-constructed otherwise though so I think forking that might prove an easier avenue than doing an XOD-specific fixed-point lib from scratch. I needed a hack and altering a few lines in certain nodes involving timing and I/O seemed the most expedient way to accomplish that
