Go Down

Topic: Iron Library (Read 4652 times) previous topic - next topic


I agree that documentation can often serve as a useul blueprint. In terms of process I tend to start with small unit tests that describe the core functionality, documenting once the interfaces are settled. I will likely use both Doxygen and a wiki to offer usage and examples.

As an update, I've been looking into the graph IDE lately, finding some good open-source options for the GUI. Attached is a snapshot of a quick layout. The idea would be to represent various functions as nodes, allowing you to plug together a graph that describes your device's logic. I'm planning on compiling the graph and uploading to the MCU, similar to the official IDE.



Why should anyone bother with the complex template syntax, when digitalWriteFast() provides the exact same optimization using the same familiar syntax as Arduino?



There is much more functionality planned for Iron than the set/get pin functions, much of which will be seen once the graphing interface is complete. Here is a list of features intended for the IDE:

 -Node-based sketch design, allowing functions to be plugged together to form larger, reusable components.
-Node API allowing user-defined functions to be loaded and shared.
-Compilation and upload of translated graph to MCU. Option to export graph to code, ready for use in other IDEs.
-MCU pin diagram, allowing graphical selection of pins to read/write, mode setup.
-Bus interface diagram, with drag and drop operations for serial/I2C/SPI interfaces.

The main focus of the library, and IDE, is to promote an object-based approach to system design. I'm hoping this will offer an exciting alternative to designers.




I really like your object-oriented approach to defining system parts. However, it would be even better to make the syntax similar to that of the Arduino IDE. That way, it will be easier to learn and more enjoyable for newcomers. Just to let you know, though, you are headed in the right direction with the approach.



Great stuff! Have you looked at handling variability for a larger number of boards and what happens when scaling to larger systems?

I have recently been playing around with a dependency driven execution model inspired by UML Capsules and Connectors. You can find it in Cosa; https://github.com/mikaelpatel/Cosa/tree/master/cores/cosa/Cosa/UML. There are some example sketches with advanced timing, probing, etc, just to show how easy this becomes in a data dependency driven OOP in C++. https://github.com/mikaelpatel/Cosa/tree/master/examples/UML

Keep up the great work!




Thanks for the feedback. I'll have a look at the core library to see where I can better mirror the calls in the standard library. I realize that templates can be a barrier to entry, with some gnarly usage (and compiler warnings).

On the IDE side, I've been working on the graph quite a bit lately, adding a tabbed node browser, drag and drop editing and loads of UI adjustments (see attached). It is possible to load user-defined nodes now, which are the smallest unit within the framework. For example, a "Delay" node might be defined as:

// Define node

    ( Delay, "Example node", "Utility", 0x58, 0x98, 0x1C, 0x2B ),
    (( Internal, milliseconds, uint32_t, 1000, None ))

// Define node class

    void setup()

    void loop()
        // Get 'milliseconds' attribute's value
        delay( get< 0 >() );

Once the graph IDE supports attributes it will be possible to build complete sketches. From this stage you will be able to compile and upload the graph to your board.

In terms of board support, I'm planning on offering an XML-based format to allow custom board types to be defined. From the IDE you will select your board before designing your graph.



From the IDE you will select your board before designing your graph.
One of the nice things about the Arduino system is that you can (in most cases) choose the board AFTER you have written your program, and run the same code on different boards.

Two or three hours spent thinking and reading documentation solves most programming problems.


The graph IDE will have the same behavior. Apart from references to pin numbers, graphs will be portable between board types.


Go Up