They provide an Arduino IDE library that allows one to use to programmed touchscreen displays - with Arduino-to-screen-widget communication through a serial port. It would be a huge boost if one could use XOD nodes to communicate with screen-based switches, gauges, knobs, etc. (https://github.com/4dsystems/ViSi-Genie-Arduino-Library)
I was just about to ask about this library lol.
maybe start with the serial controll libary
As it is a simple library to implement but a LOT of nodes to create i have started with some of the basic ones but to be able to have them all generated quickly would be great
looking at the ViSi-Genie library it may have to be done by hand or at least altered after conversion(due to the callback, but i think i have a way around that).
I grabbed one of the smaller versions yesterday to start just this so i can test and tweak if you like?
These display’s are amazingly easy to use i want to get one of the bigger ones later.
jh295 how would i go about requesting one of these?
First attempt is probably disappointing (check the readme patch for many skipped methods):
Failed to generated patches for many methods because there were argument types of void*. e.g.:
void read( void* buf, uint8_t len );
That looks like bad style, should be something like byte* or byte. But, it is a old common idiom, especially for C programmers.
Not sure what to do here. At minimum, it seems like a custom type like xod/byte_buffer for these? However, there is a question of responsibility for memory management, which is a long-standing problem with “foreign-function-interface” with C code: who allocates the space and who reclaims it? Could maybe signal part of this (byte buf implies passing in an allocated buffer). In Arduino land, malloc() and free() is rare, and we can usually assume static allocation. Should I just do that? Which may imply a “make-buffer” patch?
Failed to generate patches for some methods with usage like whatHappened(bool& tx_ok.... I think, for scalars, things like bool& tx_ok just means “emit that argument(s)” (i.e. a return value). I can work on that.
I can at least open this as a project, so the project.xod and .xodp aren’t completely messed up. rf24-ll.xodball (147.8 KB)
Interesting. I used the url value from the library.properties file:
sentence=A library for NRF24L01(+) communication.
paragraph=Optimized library for nRF24L01(+) that is simple to use for beginners, but yet offers a lot for advanced users. It also has a lot of good examples how to use the library.
Apparently the value is really “the website”, not necessarily where the code is.
This is why we should make at least 1 example! And, demonstrates that some manual work is often required.
My tool does have provision for overriding this value. How can I do a sanity check on the library.properties url, to validate that it points to an Arduino IDE library .git?
You said there were a lot of methods, the tool made 154 method patches.
But, all of the patches have an error, because we failed to make the constructor, because the only constructor takes a pointer, so I skipped it.
This class has public instance variables! Error4D, etc. I turned off that code in my tool because I don’t know what patch(s) to produce. What should I generate? A getter (pulse to trigger)? A setter (like any other state-change-patch: pulse to trigger, output pulse?)?
Should probably figure out a mapping of XOD’s string to some useful type (const char seems hard)? It’s not clear which/what we should do: const char, String &.
It occurs to me that we are doing a trivial wrapping of the “native” method. I’ve forgotten if there is a way to have c++ inline the actual method (and avoid the second call)? picaso-serial-arduino-library-ll.xodball (566.0 KB)