casainho said:
For next steps, I would make the UART custom profile of Nordic working between the SW102 and Android app.
Casainho,
I agree and disagree
I really think the one is not excluding the other
But as you mentioned "think big, start small"
The Nordic UART Service (NUS) looks to be ideal for a quick implemetation and very usefull for debug reason
=> very same tx/rx buffers used between motor & LCD can be exposed via this NUS
=> the nordic nRF Toolbox app "UART" or a screen in our own Android app can be used to display the raw buffer data
=> we can/should indeed start with this one.
In a second phase we can use the same data to be exposed thru other services
Do I interpret correctly that struct _motor_controller_data is containing all data that need to be displayed on LCD and/or App
and that struct _configuration_variables is containing all data that should be editable in App to be send back to Motor ?
Best BLE practice would still be to create a custom service with defined charasteristics for each element in those structures
=> like this you can even view the data in a less raw format with standard tools like the nRF connect
https://www.novelbits.io/bluetooth-gatt-services-characteristics/
https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gap
How can we split the work ?
I could take the AndroidApp part
and eventual try to do the bleHandling in the nrf51 (in the assumption that all data is exchanged thru the 2 defined structures)
- struct _motor_controller_data -> ble (NUS) -> App
- App -> ble (NUS) -> struct _configuration_variables
Nordic SDK example :
https://infocenter.nordicsemi.com/t...0/ble_sdk_app_nus_eval.html?cp=5_4_0_4_1_2_24
Who can do the Motor -> struct _motor_controller_data
& struct _configuration_variables -> Motor part ?
casainho said:
I think it is also very important to define the design of mobile app and his structure in terms of menus or options. At least, I see a minimum like on 850C LCD: main screen showing real time data like wheel speed, motor power, etc (in numeric fields only for a start) and a configuration screen.
Do you agree that this would be done in 2 steps ?
first implement the NUS (and maybe the custom profile) with 2 simple screens corresponding to the fields in the structures
In a second step we can make it fancy with Graphical representaions of the real time data and a more userfriendly configuration screen.
I would do the UI en menu design of the "fancy" one once we have the NUS version ready
Some Practical questions
- what IDE do you use ? the Segger Embedded Studio or other ?
- what programmer do you use for the sw102 ? SEGGER J-Link, STlink v2 ?