raw said:
adding translations is a nice to have, but it think it will also make things more complicated. there is not much point in translating the configuration menu because then the wiki (at least the configurations page) has to be translated too and should use the same terms as the translation. so the bike-builder that does the configuration needs to work in english now.
translating the home screen would be nice, because the end user may like it in his native language, i.e. if you are building bikes for your friends and families that do not mess with the configuration and just ride the bike.
I like the idea of translating only the main screen, but, it is also to much to translate: main screen strings, all custom fields strings and error strings. Also there is no support for chars like ç á ê , etc, so, I would not translate anything. For friends and family, would be good to make harder to enter configurations and make sure it would leave automatically after some time. Also configuration for 1, 2, or 3 main screens and then set to only 1. The data on that only 1 main screen can be easy to understand, on the 4 fields, choose trip time, trip distance and others that are intuitive to understand.
Are there are many others things to do that I think have higher priority:
- solve SW102 lock issues on configurations menu
- solve lights issue
- automatic shutdown does not work
- Trip (with quick reset): time, distance, Wh
- Short Trip: time, distance, Wh
- kms range estimation, based on Wh used of current short trip, last 5 or 10 minutes
- disable sensors: brake, cadence and torque
raw said:
while working with the Color_LCD firmware i noticed that
- it is pretty inconsistent in its code style, intents are made with tabs and spaces, the opening brace is sometimes on the same line as the if, sometimes on the next and so on. a official coding style would be nice.
- documenting comments are there (and very useful!), but mainly specific to some code lines. what lacks are documentation comments for functions (why are they here, what should they do). i noticed this especially in the screen.c while trying to figure out how the rendering works.
- i was also missing a toplevel developer documentation that explains some principles how everything works to allow a quicker start into the code.
- more important: an documentation for the UART protocol used would be nice (=> what each bit does). when developing for the display, you will currently need to read the motors sourcecode to get an idea what something does, which is also time consuming. this will especially useful for the TSDZ2 wireless project, as it would make maintaining the wireless firmware and android app more easy.
The code for displays, was structured by other developer much more experienced than me. Lately I am not having much time so I am not putting much comments...
raw said:
is there an easy way to get some "debug console" like output on the display? so i.e. i can print some text when a specific part is reached?
If you think you will be able to really develop, then maybe you could buy the cheap as possible 850C because it is easy to open without damage and it is almost the same hardware as 850C - and use the JTAG debug, that is what I do, way faster to develop!!
Benoit said:
I could translate in French as it's my native language, and I could translate the wiki too.
Please don't, instead let's have only 1 version and strong!! you can focus on improving current version.
pgwguk said:
Is it possible to set the crank length as a user adjustable value?
I personally use 145mm unicycle cranks on my TSDZ2 setup, shorter cranks tend to work better on a recumbent.
If we're planning to expose power details via Bluetooth / ANT+, it makes sense to get it as accurate as possible.
Would be nice to have that as configurations. I wish other developers could develop, test and send a pull request.
raw said:
@casainho is it possible to accidentally brick the display by flasing a errorous or incomplete firmware to the point that it is not recoverable by the bootloader method?
I am pretty sure not. Only bootloader should be able to write on bootloader flash section, so, app should not be able to overwrite the bootloader.