rns.recipes

Hello. I built some faketec devices. I want to add support for the board to RNode_Firmware. It seems like to add support for a new device there are many files to edit, and it's not clear if everything is done until building, and then getting errors.

Has anyone successfully ported RNode to a faketec or other new board? Can you give me pointers on what I'm missing?

Details

I added the board to Boards.h, and added an entry to the Makefile. It builds but I get issues with the defines for PRODUCT, MODEL, and BOARD. It seems these are just tags to tell other parts of the code what to do. But it's not clear where in the code needs to be changed to add support for other boards.

If I try to create my own PRODUCT, MODEL, and BOARD, I get invalid eeprom errors.

The provisioning process is dark magic to me. I cannot find documentation on the inner workings of RNode and don't really know what I need to start doing.

Maybe for something better discussed in a seperate thread: Is there a reason why the details for all the boards are in one header file? Would it be possible to seperate the Boards.h file into a seperate header file for each board, so it's easier to add support for new boards?

You're on the right track. You should pick another board id and just search all the code for it. This is pretty easy when the project is open in Arduino IDE or most other editors. If you use something like Arduino IDE, you can build directly in the editor and not mess with the Makefile right away. You will need to add PRODUCT, MODEL and BOARD values that are distinct from the other RNode devices if you want to eventually return the code to one of the upstream repos. Those IDs are also used in rnodeconf.py for provisioning. If they firmware is fully updated and rnodeconf is modified to provision it, the eeprom errors will go away. The second path would be to modify a copy of the web flasher to do the same thing. It also has hardcoded IDs, so must be modified to flash.

I personally think the one header file is easier to work with, since you can compare all the models and take pieces that match your board and copy them in to your own block. There could be multiple files, but that would be quite a lot of smaller files with how many board models are supported now.

Faketec has been working in my fork for a while now. You can flash it here

Thanks Nickie for the link to your fork. Unfortunately the AI generated code assumes the faketec has a display, which I am not making display variants and it is not able to be made to work on your branch easily.

I'll come back when I have something that works for my board and I'll see if I can make a patch for upstream RNode.

anonymoose wrote:

Thanks Nickie for the link to your fork. Unfortunately the AI generated code assumes the faketec has a display, which I am not making display variants and it is not able to be made to work on your branch easily.

I'll come back when I have something that works for my board and I'll see if I can make a patch for upstream RNode.

FakeTec support was integrated a while ago and without any LLM assistance as it was a pretty trivial task, just requiring mostly pin assignments.

The presence (or absense) of a display doesn't affect the RNode functionality at all, RNode_Firmware works fine without an I2C display connected and I have just confirmed it with a display-less faketec_v4 I have laying around.

So, there is no need for a patch. Everything is working just fine and dozens of Faketecs have been successfully flashed with the f/w from my fork.

Oh, and upstream RNode_Firmware hasn't been accepting patches for a long time.