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:
start a RF24 xod library project on https://github.com . You, bradzilla84, others (jh295?), and I can interact more easily with the code there.
make substantial changes to the library and keep the github updated.
First 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.
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);
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.
