Hi Awgrover,
4D Systems produce a series of touchscreen displays, including Arduino compatible interfaces and a free programming environment that allows direct coding, or wysiwyg drag-and-drop programming of sophisticated customised user interfaces. (https://www.4dsystems.com.au/product/4D_Workshop_4_IDE/downloads)
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)
If you or others are interested in this - we can provide some hardware, as part of the Biomaker Challenge, based in Cambridge (https://www.biomaker.org/information/)
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:
name=RF24
version=1.3.1
author=TMRh20
maintainer=TMRh20
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.
category=Communication
url=http://tmrh20.github.io/RF24/
architectures=*
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?
Well, that shows the limitations of this simple mechanical conversion. Lots of methods have pointers, lots of methods have long ints. So, lots of methods got skipped (see the readme patch).
Is it useful as a starting place to do this mechanical conversion even when so incomplete? Is there a pattern that I could implement to deal with those pointers?
I was completely unaware of library.json. I see it is part of the platform.io world. I’ll try to have my tool use that file.
Of course, I expect you to edit the files for RF24 to fix/add things that my converter can’t do (or does wrong). And, if you see a pattern that the converter should do, I’ll see if I can add it.
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)
How should we handle void * in general? I’m not sure what a utility node is, I see the patch xod/patches/utility (is that what you mean?), but I don’t know what it does.
To the patches that do not use the xoders, they are added Utility, when downloading the library they are hidden
In the project edition, UT will be added to the name
Hardware might be helpful - send me an email at jh295”at”cam.ac.uk, and we can sort out the details. I’ll reach out to engineers at 4D Systems too.
Jim Haseloff
