Taking experimental requests: to convert Arduino IDE libraries

[awgrover]

but to be able to have them all generated quickly would be great

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)

[awgrover]

read needs read_payload to get the values of buf and len , this should be a utility node?

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.

[cesars]

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.

You said there were a lot of methods, the tool made 154 method patches.

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

[jh295]

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

[awgrover]

read needs read_payload to get the values of buf and len , this should be a utility node?

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.
• publish it when it is working

[cesars]

start a RF24 xod library project on https://github.com . You,

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,
};

[awgrover]

First you will have to understand better how to work on github, I do not know how it works in reality, I only have a limited idea.

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.

I am working in a library, and I found constant values that I do not know how you will define your tool .

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)

[awgrover]

Here an example, through switch and alias, I have managed to overcome the obstacle.
a pin Number, and select value 0-3

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)

[cesars]

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);

Now I have a problem when there are two values

pic->setVal(value_0, set_0);

here I am trying with alias

[awgrover]

int intVal = getValue<input_IN>(ctx); // switch(inVal){ case 1: pic->setVal(value_1); break;

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);

[cesars]

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…

auto _cspin = static_cast<int> (getValue<input__cspin>(ctx)); // int

I had not understood, sorry

[strikein]

i would like to know if this is being posted as the last three requests have gone unanswered

[cesars]

other terrible idea

other-terrible-enum-idea.xodball (2.0 KB)

[james-agada]

Following this work. Any progress?

[awgrover]

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.

[skippy2k]

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.

[skippy2k]

ST7735 Library

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

[awgrover]

I’ll try to look into this, I haven’t had the code out for a while.

[edgars-balunovs]

Any chance of getting ILI9431 library working in XOD? Would be very nice to get it working… Thanks in advance!

[awgrover]

Obviously I haven’t done anything about this. I’m not likely to in the
near future.