Taking experimental requests: to convert Arduino IDE libraries

Yes, I understood that.

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.

I will try to make the missing ones

I just looked for it and I found it, I did not know

If you figure out a pattern we can automate, I’d be interested in putting in the tool.

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

utility

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:

  • 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

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.

Screenshot%20from%202018-12-24%2016-54-31
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 :slightly_frowning_face:

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

This is very advanced for me, I’m learning C ++ as well as using XOD :grinning:
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

other terrible idea :laughing:

enum

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

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.