Make it easier to support more arduino-compatible boards (like Wemos D1)

[tigert]

Looking at the Wemos D1 for example, and pretty much other arduino-compatible boards, that might work, it would be nice to have some kind of board definition file that you could write to add support for a board.

The Wemos D1 mini is very affordable, has 1 or 4MB of flash, and kind of similar to the Pro Micro in terms of IO and use cases.

[tigert]

What we discovered so far, there are some AVR architecture specific things that need more digging:

• eeprom.h has a different library on esp8266, this might be a case on other architectures too. This seems not a drop-in replacement because on esp the functionality is supported by a reseved part of the flash memory, as there is no real eeprom.
• interrupts in the TicksPerSecond library also are avr specific, this also can likely be ported to other architetures as most cpu's do have interrupts, but needs investigation.

[elral]

Hello all,

if the platform developer did a good job there should be only less topics which require adaptions. Normally even interrupts and eeprom library should work without any modifications. This is the advantage of the Arduino framework. E.g. if an eeprom is not available, the library for this platform uses the internal flash by using the same functions.

I "tried"it for a Teensy3.5 board, only some board specifications had to be adapted:

• what inputs and outputs should be used
• what are the numbers of inputs and outputs
• what are the numbers of pins
• the name
• and the size of the eeprom
  Means only this where the Mega/Micro/Uno differ. All used libraries worked without any changes/adaptions.

I used the teensy3.5 due to its native USB support. So I was able to add joystick device. Four analog inputs (which can not be used as binary inputs) are shown up as x/y/SliderL/SliderR axis within Windows and can be used as any other joystick (could be extended to joystick buttons).

Even for other boards there is a high chance that the firmware will run only with a new board definition. I didn't checked it for the Wemos boards, but I can give it a try as I have restructed the source to put all board specific data in seperate files (beside some other adaptions (button with repeat function) which also reduces the required RAM).

Regards

Ralf

/edit: eeprom read/write seems to be indeed a little bit differnet for the esp8266 compared to the standard lib

[MobiFlight-Admin]

... if the platform developer did a good job there should be only less topics which require adaptions ...

Thanks for the feedback! You're welcome to share your wisdom with me.

[elral]

It seems that I got misunderstood. I did NOT mean the Mobiflight software or you. The software is really good espacially how it gives one the flexibility to define different functions to each pin. I am far away to blame someone on a forum or somewhere else.

I just wanted to say, that you have to be aware that modifications are required even if using standard Arduino functions when porting software from the Arduino platform e.g. to ESP8266 platform (or ESP32, nrf52, STM32, ...). The number of modifications depends on the "quality" of the implemented platform library (STM32 has no standard EEPROM functions, ESP32 needs an additional Servo library, nrf52 has "only" it's own flash storage functions, BLE functions differ heavily, ...).

[MobiFlight-Admin]

All good! I was being sarcastic.

Let me know if you see anything that can be improved. I currently have no ambitions to support more boards because it turned out to be quite difficult.

[tigert]

Yeah, I looked like the eeprom implementation was quite different for the esp8266, different functions etc. I am not super knowledgeable of that stuff, but I agree, the arduino framework seems like a good common denominator here that might make it easier to support other devices.

Splitting the board definitions to different files is a good idea in my opinion - its a bit what comes to mind from drones and flight controller software called BetaFlight that has something similar, like this board as an example - they define IO pin mapping and supported features in boardname.h and some other files.

I think it would be good to have easier support for more devices, but there is an additional challenge to maintain builds of all the firmware versions (and flashing procedures that might be required, currently mobiflight knows to use avrdude to flash to atmel microcontrollers, other boards likely have their own methods, so that should also be handled somehow. There is a balance between utility and maintaining the extra "infrastructure".

[elral]

I fully agree that that extra boards should have a "benefit" when adding them. And for the Wemos D1 I don't see any big advantage.

However, I didn't understand why the EEPROMex lib is used. As I understand the "advantages" of this library are not used here, so you can break down the functions to the high level eeprom lib. And then it compiles with less changes also for the ESP8266 family.