There are so many APIs already, why should we develop a new one ?
To us, the key of democratizing access to this world crucial technology is to make it simple to understand and simple to hack !
Breaking down the complexity barrier implies :
- Simple ergonomics
- No complex installation process
- Having a graphical interface
- Adapting to existing practices
- Some people working on the field to use C to program
- Most people use vendors API to address registers
- Some users are familiar with real time OS such as FreeRTOS
- Other develop algorithm on Matlab
We found out that adapting to different practices while ensuring great ergonomics is really hard. Below is a bit of history of what we've tried !
#1 Attempt as using Arduino to make power converters
We always wanted to have an Arduino like example for our power converters. So, of course, we first tried using arduinos for our power boards.
It appeared that Arduino was having quite some trouble with fast PWM and signals measurement.
The resolution of the signal was low, while the ADC were imprecise. Altogether it was kinda working but the program itself became quite complex to develop with not so intuitive calls to ATMEL registers.
Our return of experience was that Arduino board and API were unable to
- To configure the peripherals to generate all kind of PWM that could be useful for power conversion and synchronizing measurements without using precious processor time.
- To be able to deploy complex control algorithm at a time critical pace. Without spending a TON of time in the search of reducing the computational effort.
The pros were :
- It was a cheap
- The Arduino IDE is super easy to install and well documented
- It was open source friendly
#2 Attempt at using a 16 bit DSP together with Matlab code generation
We also wanted to try using a quite cheap yet plenty powerful 16bit DSP to compare it with the Arduino attempt, and also tried to generate the code directly using a Matlab Simulink blockset. We ended up choosing the dsPIC33EP256MC202.
The board was definitely better at generating PWMs and adressing the measurement challenges, but understanding its register was tough. We were mostly relying on the vendor APIs and tools.
The toolchain was not so easy to install, and we were kinda tied to use the vendor IDE as well. The 16bit DSP was hard to master, as most of the fast computation were relying on understanding fixed point calculation. - I still do nightmares at night about it -
We choosed this chip for its capabilities, but also because it was supporting code generation from Matlab Simulink. We thought it could be cool to try it out.
The block-set was well thought, dedicated blocks permitted to control the dsPIC peripherals. Yet, some functionality were missing and back then it was quite buggy. We took ages to find the workarounds for "simple" things that were not working properly. Moreover, the Matlab ecosystem support was a great feature, but could not cover the users who were used to C code programming with a simple ergonomics.
The last thing that was making us unhappy is that we were kinda tied to proprietary and vendor specific solutions to develop our software which was prone to obsolescence and not really compatible with the BIG GOAL of gathering a vibrant community.
Our return of experience was that the dsPIC board and the Matlab Simulink were unable to
- Provide simple - bug free - ergonomics for begginers.
- Provide an open source friendly pathway
- It was lacking Floating Point Unit (FPU) support
The pros were :
- It was a cheap chip
- It was fast
- The Matlab support was still a really nice feature
That's why we started this journey of developing our own intuitive API for power conversion.