Bafang SW102 Bluetooth LCD - OpenSource firmware and mobile app
- Thread starter casainho
- Start date
So for all people who are interested, I lost some words about setting up the development environment on Windows:
https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/wiki/Setup-IDE-(Windows)
If something missing, please give us a hint.
https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/wiki/Setup-IDE-(Windows)
If something missing, please give us a hint.
Nick said:
Do you have a picture of how your lcd is connect to pins on the stlink clone?
I couldn't find it on the wiki's. Do you let the lcd power from the "normal" connection or do you use the 3.3v on the printboard?
Any tips on where to buy the sw102 lcd in Europe (if possible)?
Thanks.
bart1006 said:
I will do some documentation in the next days. But until then the debug pins have some markings which make it quite easy to connect:
Board <-> ST-Link probe
3V3 <-> 3.3V
DIO <-> SWDIO
CLK <-> SWDCLK
GND <-> GND
For your first steps you can power the SW102 from you ST-Link probe, that's what I do and it is convenient. But as soon as you power from battery, you should disconnect the 3V3 from your probe. casainho fried some probes because high current seems to flow through the USB port then.
I live in Germany and bought my first one on Aliepxress. I also found some sources with german stocks on eBay recently!
This SDK is a bitch. Very bad documentation and strange design IMHO 
I had some strange behavior working with IRQ priorities just to realize that nrf51 only has 3 prio levels and if you configure >3 this setting is discarded or the code asserts. I revised the sdk_config.h to reflect this.
Next is the internal switch to newer drivers (nrfx) since SDK 15 and its configurations. They also need the "legacy" configs in sdk_config.h. So don't wonder if there seems to be double entries.
I added some Build Targets to the Eclipse project. You can hit "sdk_config" and a tool pops up where you can change the sdk settings.
For future debugging I added the app_error_fault_handler callback to main.c. If you compile with the DEBUG_NRF (see Makefile) flag, this functions gets called on error (assert f.i.)
I added fonts.h with some custom fonts and an example of battery icons printed in main.c
I had some strange behavior working with IRQ priorities just to realize that nrf51 only has 3 prio levels and if you configure >3 this setting is discarded or the code asserts. I revised the sdk_config.h to reflect this.
Next is the internal switch to newer drivers (nrfx) since SDK 15 and its configurations. They also need the "legacy" configs in sdk_config.h. So don't wonder if there seems to be double entries.
I added some Build Targets to the Eclipse project. You can hit "sdk_config" and a tool pops up where you can change the sdk settings.
For future debugging I added the app_error_fault_handler callback to main.c. If you compile with the DEBUG_NRF (see Makefile) flag, this functions gets called on error (assert f.i.)
I added fonts.h with some custom fonts and an example of battery icons printed in main.c
nieles
10 kW
Just fyi; prio level 0 and 2 are for the softdevice, 1 and three are for application.
At work we do not use different irq prio levels, because this this gets complicated rather quickly! Especially with large projects. Better to keep the same level, this way you know the irq functions won't be interrupted. (At least not from the application in this case, the radio on prio 0 will still interrupt app irq)
At work we do not use different irq prio levels, because this this gets complicated rather quickly! Especially with large projects. Better to keep the same level, this way you know the irq functions won't be interrupted. (At least not from the application in this case, the radio on prio 0 will still interrupt app irq)
neftaly
1 µW
- Joined
- Feb 6, 2019
- Messages
- 1
I'm excited to see this! Both Arduino and Espriuno have build targets for the nRF51 (and SH1107 drivers), which would also make it easy to port to other MCUs. Espriuno already has wireless hot code updates, I'm pretty sure it works with BT but I've only ever used WiFi.
Can someone please measure the position of the programming pads on the case? I'd like to print a template and drill/melt holes for pogo pins without opening it. I thought I could cheat using the CAD files, but they're not board layout.
Can someone please measure the position of the programming pads on the case? I'd like to print a template and drill/melt holes for pogo pins without opening it. I thought I could cheat using the CAD files, but they're not board layout.
Arduino IDE seems quite interesting to me! The sandeepmistry repo looks up-to-date. There is also a bootloader on this older repo based on S130 softdevice and OTA support.
SH1107 is supported by the U8G2 library.
If you don't like the IDE, you can also use Eclipse.
Should we give it a try?
BTW:
I'm struggling integrating Softdevices to the project. I read that S110 support was canceled somwhere prior to SDK v11 and the S130 is supported up to SDK v12.3. So I think I was wrong just to use the latest version which states "all platforms" but rather use some hidden deep links on the homepage to get the right SDK version (did I already mention I don't like the SDK? :wink: ). I think we have to switch from current SDK version back to SDK v12.3.
SH1107 is supported by the U8G2 library.
If you don't like the IDE, you can also use Eclipse.
Should we give it a try?
BTW:
I'm struggling integrating Softdevices to the project. I read that S110 support was canceled somwhere prior to SDK v11 and the S130 is supported up to SDK v12.3. So I think I was wrong just to use the latest version which states "all platforms" but rather use some hidden deep links on the homepage to get the right SDK version (did I already mention I don't like the SDK? :wink: ). I think we have to switch from current SDK version back to SDK v12.3.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
I like a lot the spirit of Arduino and I know it since the begin however, it used to lack good IDE and support for debugging, also C++. It can also be not good for pur limited memory size, I guess.Nick said:Arduino IDE seems quite interesting to me! The sandeepmistry repo looks up-to-date. There is also a bootloader on this older repo based on S130 softdevice and OTA support.
SH1107 is supported by the U8G2 library.
If you don't like the IDE, you can also use Eclipse.
Should we give it a try?
BTW:
I'm struggling integrating Softdevices to the project. I read that S110 support was canceled somwhere prior to SDK v11 and the S130 is supported up to SDK v12.3. So I think I was wrong just to use the latest version which states "all platforms" but rather use some hidden deep links on the homepage to get the right SDK version (did I already mention I don't like the SDK? :wink: ). I think we have to switch from current SDK version back to SDK v12.3.
What would be the strong advantages to change to Arduino?
Because we already did some steps with the official SDK, advantages are maybe not that huge.
On a fresh start, Arduino IDE would have the advantage of easy setup, easy library integration, huge set of libraries (ready to use LCD gfx lib f.i.) and it is also more beginner friendly.
But no problem to stick to nrf5 SDK here.
But imho we really need a working OTA bootloader running on the SW102 before we continue! This means a decision which SDK version and Softdevice version to use!
On a fresh start, Arduino IDE would have the advantage of easy setup, easy library integration, huge set of libraries (ready to use LCD gfx lib f.i.) and it is also more beginner friendly.
But no problem to stick to nrf5 SDK here.
But imho we really need a working OTA bootloader running on the SW102 before we continue! This means a decision which SDK version and Softdevice version to use!
I created a new branch named SDK_12.3.0 with the "new" SW102 example code based on the SDK v12.3.0 and S130 Softdevice.
The Eclipse project inludes:
The Eclipse project inludes:
- New Build Targets among others: flash_softdevice: flash the S130 to the SW102 via openOCD/ST-Link clone, flash_program: flash the example code via openOCD/ST-Link clone (you have to set the path to your local openOCD installation in the Makefile).
- Some examples how to use custom fonts.
- ble example which establishes a UART over BLE. Advertisement is working and I also could trigger RX/TX. You can test with nRF Connect / nrf Toolbox apps under Android. Very basic proof of concept right now.
Nick said:
Nick,
My sw102 is still on his way (hopefully it will arrive next week), so I can't yet use/test your developments :-(
Ble UART implemented (nice!!). Does this mean you can see in the nRF toolbox UART app directly the buffer send from the motor ?
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
I am being traveling with my bike far from home and once I have time I want to test all the changes you did, which seems great!!Nick said:Its just the basic BLE feature. Data transmission has yet to be implemented. I don't know how long this will take. Time is the very limiting factor for me
Nick said:Its just the basic BLE feature. Data transmission has yet to be implemented. I don't know how long this will take. Time is the very limiting factor for me
Nick,
I think time is a limiting factor for a lot of us , same for me => it comes as it comes
some post back Casainho suggested that (at least for the common data structure) the implementation of the 850c was a good starting point.
Maybe I'm over oversimplifying things but I see 4 (relatively independed) parts in the sw102 firmware
MotorHandling : all (UART) communications from and towards the motor
DisplayHandling : all LCD related, GUI + menu handling
BleHandling : Implementation of ble profiles like UART, custom profile, ...
With as glue a common part containing the common data structure & some general fuctions
(and the android app ofcourse)
Like this different developers can also work quite independly on the different parts as long as the common data structures are respected
Casainho,
Do you think the Motorhandling part and the common data structure (L2,L3) are easily portable from the 850c code to the sw102 ?
Any pitfalls you can think about?
Nick said:
If we easiliy can port the port the work done for earlier displays (I mean the part handling the communication with the motor) I would say to stick on the nrf5 SDK (like this we can use the maximum of the nodic toolsets and examples)
Nick said:
If I read the doc corretly the SDK v12.3 & softdevice s130 are supporting DFU (OTA), but no idea what the disavantages would be to stick to that 'older' SDK.
Yes, I too think we should stick to SDK v12.3.0 and S130. As I mentioned, S110/S120 support was canceled with SDK v11 and even if the S130 needs some kb more flash, this seems to be the preferred softdevice.
As I already mentioned, I would keep the software on SW102 simple, stupid. If we need some advanced features this can be done on the Smartphone App which remote controls the SW102 (f.i. heart rate sensor bound to the mobile app which sets assist levels on the SW102).
DFU:
I'm on it and it looks good so far. The platform is the SDK 12.3.0 and S130. There are examples for an secure bootloader supporting the S130 API which compiles ~17kb. So ~19kb with some reserves for the bootloader. If we count everything together (MBR, S130, bootloader + settings), we have 128kb left for the SW102 firmware. We still need a working example for DFU, maybe in the next few days...
- LCD communication & GFX library: feasible
- UART com Motor <-> Display: feasible
- UART over BLE: feasible
- DFU over BLE: open
As I already mentioned, I would keep the software on SW102 simple, stupid. If we need some advanced features this can be done on the Smartphone App which remote controls the SW102 (f.i. heart rate sensor bound to the mobile app which sets assist levels on the SW102).
DFU:
I'm on it and it looks good so far. The platform is the SDK 12.3.0 and S130. There are examples for an secure bootloader supporting the S130 API which compiles ~17kb. So ~19kb with some reserves for the bootloader. If we count everything together (MBR, S130, bootloader + settings), we have 128kb left for the SW102 firmware. We still need a working example for DFU, maybe in the next few days...
I agreeNick said:
Android App
- Display live data (when connected)
- graphs of some live data (when connected)
- Configuration parameters for motor
- ? Configuration parameters for display ?
LCD
- Basic Live data (in a few screens)
- change assistance level
- change mode (street mode / offroad)
- enable walk mode
I (partly) disagreeNick said:
Basic idea should be that during your ride it is not mandatory to have the phone connected
The HRS is ofcource an advanced feature to be implement in second phase, but I would link the heart rate sensor directly to the sw102. => SW102 as HRS client (but also make it again available as HRS server for the Apps)
Ofcourse this would mean that the sw102 has to act as ble client and as ble server (even for muliple ble services) => I don't know if this is possible with the srf51 & s130
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,058
Yes I think.Zelenaar said:
L1 is UART rx tx data processing with UART rx interrupt using max priority (should happen every 100 ms as motor controller sends every 100 ms only).
L2 is 100 ms processing like battery Coulomb SOC and uses a 100 ms interrupt. I think BLE rx tx data processing should be done here.
L3 is display processing and happens at main loop frequency (can be as fast as possible).
Data flows from L1 to L2 and then to L3 and also on the backward direction.
L3 do not access data if L2 data is being processed.
L2 do not accesa dara if L1 data is being processed.
