Thanks for the answers. For sure it is possible to buy an ATmega and even a full-featured debugger would be acceptable compared to the effort of porting. But still, I am very biased towards the PIC without logical or economical arguments.
I did not yet work with the mysensors libraries and only browsed quickly through the github repo. Maybe someone can give me a few hints to estimate the effort deeper than just claiming it as "much workload"?
What I see so far is:
make the C++ code compile (translate to C with clang/llvm and compile with the XC8 compiler)
create a new HAL (in hal/architecture) which seems not too much effort for making it initially working
Questions:
Do I see it right, that there is a linux-port available? -> I would expect much more effort to port from AVR to linux than to port it to a different MCU
What about the licensing? It looks like the code is GPLv2, but in the CLA it seem that contributors need to give away their rights on the contributions and that mysensors can even redistribute the code under another license - which seems completely against the principles of the GPL. Can someone explain that in more detail?
@NeverDie said:
Can it be programmed through the Arduino IDE?
I had briefly looked into it back in 2011 and was able to get an Arduino sketch for blinking a LED to work. I had to upload it using the external dfu program since at the time the Arduino IDE did not allow specifying an external programmer device. I'm not familiar with what may currently be possible with the Arduino IDE since that time however.
Plain C using gcc and uploading using dfu-programmer works fine though.
@NeverDie Thx for appreciating the work done. There will also be an open source part in the future. When and how extensive the open source part will be, remains to be seen. The release of certain information (block diagram, ..., in this post) is related to those open source parts.
There are some OBD solutions, however most of them (in my experience) give back low frequency data put by the car manufacturer on the OBD-bus (CAN, ...). Therefore transients evolving directly from the battery could only be recorded if the manufacturer sends those data accordingly on the bus. Due to the small bandwidth(also because of other car data that have to be sent, ...), such battery data are sent more often once per second or less. Fast battery events (i.e. cranking events, ...) are therefore imperceptible. Unless the manufacturer processes the fast events and then sends them (once per second or less), which is very unlikely if the manufacturer does not market this feature itself. Third parties devices for high frequency sensing costs several hundreds dollars.
In my experience, important battery states (especially the fast ones) are recorded by measuring and processing corresponding data directly on the battery.
I agree with you about the limits related to the communication over Bluetooth. But i think Bluetooth 5.0 will improve a lot. However, WiFi will always remain an important option due to the high data throughput. The combination of both (BLE & WiFi), especially with regard to energy consumption, will gain in importance.
