Fred's firmware development diary comments thread

[Fred]

Jared, what you can do, is create a branch locally, commit experiments against it and push that branch up to your github repo. I have a repo just for your stuff that i can pull --mirror from, switch to your experimental branch and build it with a different path. Just let me know what you have for me to try :-)

1.5.6 is the version in deb stable on my VPS, I have a newer one locally, and yes, there are differences between them, but I don't know what exactly.

Fred.

[jharvey]

I created a folder with a very simple test set of files. I'm sure that once I can get it to work in a test file, I'll be able to reproduce it in the real version. When I get home tonight, I'll put it in a folder and see about doing a commit/push such that you can give it a look. My guess is that it's not lookin at the right directory, however, the log notes it searched the directory listed in the EXAMPLE_PATH tag. I'm sure it's just some kind of formating, or typo issue, I just can't seem to find it.

[Fred]

why don't you create a git project on github just for your test setup? you can always delete it afterwards :-)

[jharvey]

I remember an article about A/D readings. It explained the difference between ratiometric and non ratiometric readings. It talked in good detail about why rail to rail readings were often inaccurate and how to calibrate them such that they would be correct. Linear corrections based on the datasheet were more accurate, but still not right. The accuracy of the A/D is typically an S curve. Which is often easiest to get by using known good values, and making a look up table. After that there was some calibration based on temperature if I recall it correctly. I wish I could find that article. I believe it was in circuit cellar, but I'm having some trouble finding it. If I find it, I'll post it to the article section.

From what I recall in that article, what you are seeing is probably correct, but will need some calibration to make your readings what you expect. The calibrations will change based on ratiometric or non ratiometric, temperature, and a couple other parameters. The calibration steps and reason for each step, weren't as obvious as one might expect.

[Fred]

Thanks for that, I see you posted a link in the articles section, I'll check it out!

It seems to be linear from 0 - 4.8V which is nice, but it would be nice if we didn't need yet another layer of calibration. I'll have a read of that article and see what I can determine from it.

Fred.

[nitrousnrg]

No idea what has been talked about; but I saw this in your firmware a while ago and always forget to speak up:

Is there a reason for you to use
unsigned short a;
instead of
uint8_t a;
int8_t
uint16_t
uint_32_t, etc

Its quite common, at least in the embedded software I've seen, to use these types. They provide a much compact a clearer way to say what they are, and makes the code more portable between bigger architectures, like 16,32 and 64 bits. (not your case though). For example, I had to google the length of an unsigned short, while uint16_t would be obvious :-)

The types definition are in stdint.h

[Fred]

I personally find "nameOfUserString" almost enough to cause me to vomit. Having an identifier "unsignedInt16Type" which is effectively what uint16_t is, is just the same. I did discuss this with EssEss and he/you are right that my shit is not standard or portable. Perhaps the compromise that is needed is to pull in the header, retypedef to uint16 from uint16_t and call it a day. Or do our own types header with a direct uint16 to unsigned short typedef. Then that file can be changed to suit a new env and the code will be the same between both.

In any case, I HATE C style var naming and hungarian notation and bulk abbreviations. Torvalds hates hungarian too, as does stroustrup. Those typedefs are too much like that for my tastes, but I have to do something as the current way is wrong, as much as I don't want to admit it.

My only other complaint was about eclipse colouring, but that might have been bogus anyway.

Fred.

[nitrousnrg]

haha, fair enough.
I didn't understand the idea, but it was just a suggestion in case you didn't know (is something out there you don't know?!). You are the coder, get comfortable with your code :-)

But beware... I have a friend who would travel all the way to NZ to kick you arse if you keep using those definitions in an embedded system :P.

[sry_not4sale]

Isn't nitrous referring to the var type, as opposed to the var name?

[Fred]

Indeed he is, but the var type is a var name of sorts, its called typedeffing. you could call unsigned short foobar and it would work fine. That's why I don't like it, it's just aliases to the same shit. I'd rather have the shit that is under it at the end of the day, but there is a portability issue with my approach. I acknowledge that it's not done right. I'm just not sure of which way I want to go about making it more right, yet. I don't want old fashioned ugliness if I don't have to have it. I hope that makes some sense.

The reason for using short over int is that short is always 16 bits on this platform, and int can be 8 or 16 depending on compiler flags. Thus int is unacceptable to me in the code. The uint128_t stuff solves that issue by referring to the short underneath on this platform (hopefully!!! Another thing to check before doing it...) and whatever else it needs to on other platforms.

Fred.

PS, good to see you posting, Aaron! :-) Will we see the tuner being bench devved against that board in the near future? I have a mate with a holden V6 that might be the next FreeEMS donk if we can tune it a little more effectively, and keep the tuner working as comms evolve.