void RF24::read( void* buf, uint8_t len ){
// Fetch the payload
read_payload( buf, len );
read needs read_payload to get the values of buf and len, this should be a utility node?
uint8_t RF24::read_payload(void* buf, uint8_t data_len)
{
uint8_t status;
uint8_t* current = reinterpret_cast<uint8_t*>(buf);
if(data_len > payload_size) data_len = payload_size;
uint8_t blank_len = dynamic_payloads_enabled ? 0 : payload_size - data_len;
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
Ok, I found documentation on utility nodes. I don’t think my tool can make that decision. My tool purposefully does a direct conversion, with the hope that the result is somewhat usable. There is an expectation that it may need some manual fixes, and that a wrapper library may have to be written around it to make it nicer and more understandable. You are discovering some of the things that need to be done! And, we are discovering the process of how to do this.
I would suggest:
RF24 xod library project on https://github.com . You, bradzilla84, others (jh295?), and I can interact more easily with the code there.publish it when it is workingFirst I would have to better understand how to work on github., I do not know how it works in reality, I only have a limited idea.
I am working in a library, and I found constant values that I do not know how you will define your tool.
Here an example, through switch and alias, I have managed to overcome the obstacle.
a pin Number, and select value 0-3
// Display mode argument for setDisplayMode()
enum OLED_Display_Mode {
DISPLAY_OFF = 0, // No pixels on
DISPLAY_ALL_PIXELS_FULL = 1, // All pixels on GS level 63 (ie max brightness)
DISPLAY_NORMAL = 2, // Normal display on
DISPLAY_INVERSE = 3,
};
I wish there was an easier way for people to begin using git & github. It is a problem I have with my students as well. The github app might make it tolerable. I know it is another thing to figure out.
Yes, that is the enum problem. There is a discussion about how do deal with those. So, right now I don’t define them at all (I’m thinking of a node that has the values listed in the description for now).
The patches that need an enum, like set-data-rate in RF24, should take a number. It’s the best we have right now.
I “fixed” RF24, so that inputs that are enums should compile now, the fixes look like:
auto _cspin = static_cast<int> (getValue<input__cspin>(ctx)); // int
And I fixed the pragma that references the arduino library.
rf24-ll.xodball (148.2 KB)
Here, I had a terrible idea for an enum! Each output is one of the values. This terrible idea will only be tolerable if there are not too many enum values.
terrible-enum-idea.xodball (1.2 KB)
This week I was thinking about handling bits and matrix, and it would take a node of graphical interaction type switch, maybe also can be adapted to your node and is a simple way to select a value.
I also thought about a drag & drop, but using switch with default I would not have a problem loading a value outside the enumerator
int intVal = getValue<input_IN>(ctx); //
switch(inVal){
case 1:
pic->setVal(value_1);
break;
case 2:
pic->setVal(value_2);
break;
case 3:
pic->setVal(value_3);
break;
default:
pic->setVal(value_0);
Now I have a problem when there are two values 
pic->setVal(value_0, set_0);
here I am trying with alias
I think you only need to do a cast like I mentioned above:
auto in= static_cast<OLED_Display_Mode> (getValue<input_IN>(ctx));
pic->setVal(in);
This is very advanced for me, I’m learning C ++ as well as using XOD 
I’ll try…
I had not understood, sorry
i would like to know if this is being posted as the last three requests have gone unanswered
Following this work. Any progress?
I haven’t done anything further. I received very few requests to convert libraries, so I’ve considered this to be of low interest to the community. On the other hand, I may not have marketed it well.
Hi there I do have a few that I will submit asap, cesars and wayland helped create a pressure sensor that works great. Something I have been wishing for is a i2C multiplexer and some further displays like ssd1327 and ability to load images to the display so possibly a node you can upload the bitmap to display an image on Oled displays. This may already exist but I am still new to XOD but do love it and thank you to everyone who helps create all the great stuff.
Hi awgrover, Is it possible to create some nodes / library for this display? at present I use the SSD1306 for 128x64 Oled but these are sometimes too small, it wuld be nice to have a larger display.
Let me know your thoughts.
Regards,
Jason
I’ll try to look into this, I haven’t had the code out for a while.
Any chance of getting ILI9431 library working in XOD? Would be very nice to get it working… Thanks in advance!
