Hi Richard, no problem sharing the code, Others could benefit from it making their own projects or just copying (bits of) this one
I have no idea what a pull request is or what it should do on github
. I'm a hobbyist programmer and I suspect pacificcricket is a programmer by profession.
I do appreciate suggestions. And as for his suggestions, I don't see real valid reasons to change the code. All the suggestions just add more lines of code and do not improve the readability. (in my opinion!)
Here's my view on things:
Using a switch instead of multiple if-statements could be valid but does not add any functionaltity or even clarity from my point of view. The If statements are very clearly for 1 single CANID and broken down byte by byte. Adding case and break lines just clutters the code (again MY opinon). I do agree that after the first if statement the rest would be better off using "else if" instead of a new "if" because then the routine is faster because when it has found the right canID it skips the rest. Maybe a switch case statement does the same, i wouldn't know. I'm just a (novice) hobbyist programmer.
The comment regarding the color definitions would ADD 12 definition lines at the top of the code for the same 12 lines it takes now to define the colors (every colour statement is just use once). I just dont see the point in that. it's adding (lines of) code with no real purpose (for ME).
The same for the grouping of the arithmetic "buf[1] + 256*buf[2] should be buf[1] + (256*Buf[1])". Well that is just basic arithmetic. If that is not clear enough that you must multiply before adding than the brackets are not going to help either. Again, it's more (lines of) code for no clear reason (again for ME)
next would be the macro definitions for the same line. WHY ? is it not clear enough that byte 1 and 256* byte 2 are added ?? Defining a macro "Magic(buf,1,2)" does not really make it any clearer (to ME). and again would just add some lines of code.
The last comment regarding integer arithmetic because of using a long could be valid. I don't know because i don't know what all that means. I have a general idea though. But in this way the displayed value is accurate for all values the parameter can get to in the real world, so.....
I would be very happy to add or change
functionality for this project. But i'm not likely going to change the code to accomodate these (style) changes. I'd like to spend my (limited) time on adding things like :
* compass direction and distance to the nearest EVSE station and display that on the screen as well so i don't have to have my phone app ready all the time. I have ordered a small GPS receiver for this. Any suggestions for searching through a database of EVSE-POIS and selecting the nearest one with direction and distance would be extremely appreciated.
A warning when range minus distance to the nearest EVSE is below a certain threshold is also easy (making the range display in red for example)
* an altitude indicator. That would be an easy one with the addition of a GPS receiver. The higher the altitude the better the range because of the thinner air
(off course climbing to that higher altitude costs more battery, but still nice to know the altitude)
* GPS logging onto the SD card that can be put into the TFT screen. after a long trip it's always nice to have the route on a map inbetween the photo's of the trip
Upon request i shared the code and eveyone is free to use it or bits from it. That benefits us all!!. After all the idea came from someone else on this forum. I expanded his good work with functionality that i liked and all the values are accurate and work well.
Greetz
P.S. This is not meant to be an angry post, not at all and i do think that the comments are meant to improve the code. It is merely my point of view on the proposed changes to be made. They don't add functionality, and that is my main objective.
Author
Topic: Zero SR/F Dashboard on a Zero (D)S(R) using CanBus (Read 5854 times)