Taking experimental requests: to convert Arduino IDE libraries


#10

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?


#11

This is the address of the documentation / application

url git is library.json


#12

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?

For what it’s worth:
geniearduino-ll.xodball (47.8 KB)


#14

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.


#15

I will try to make the missing ones

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


#16

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


#17
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;

#18

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)


#19

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.


#20

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


#21

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


#22

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

#23

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

#24

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)


#25

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)


XEN-F001: Enums
#26

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


#27

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

#28

This is very advanced for me, I’m learning C ++ as well as using XOD :grinning:
I’ll try…

I had not understood, sorry


#29

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


#30

other terrible idea :laughing:

enum

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