I'm going to split this into two parts; 1st the memory issue, then the AtoD conversion issue.
Quote:
Originally Posted by MPaulHolmes
The used up data memory isn't actually as used up as it seems. A lot of it is tied up in some debugging arrays that I'm using. I just made them as big as possible so that all the memory was used up. It's in a UNION in sensorless.h. As for MOSTLY frozen things, that's a good question. A couple functions in UART are constantly changing as new commands are added and taken away. Also, I keep changing the commands to really short stuff so I don't have to type so much while testing.
In the rest of the code, initialization code is pretty frozen. startup sequence is frozen. I need to automate the PI loop tuning (for all motor types) and finding of rotor time constant for case of ACIM.
|
Regarding memory - that's really good news.
I was mostly bringing up memory to illustrate the reality of having limited resources on microcontrollers. I think it's an interesting challenge.
If it ever does get close, one suggestion is to carefully choose whether memory is defined in a function or the main part of the program. The memory defined in functions is only used when the functions are operating, so there can be some overlap.
Regarding frozen code, I would like to adjust some things a little bit in the startup (top of main) code and initialization code.
I wasn't quite done, but I wanted you to get this ASAP.
It's really NBD, just moving the contactor code and read/writes stuff to EEprom to separate functions. After that point the main is just a manager - it doesn't really
do stufff.
If that seems ok, then a subtle " order of things " might be possible: The precharge relay has a number of time delays to ensure there is the correct voltage before moving on with the code. This is only done once, so it's really nbd. - - How about using the dead time spent reading from EEprom and initializing values as precharge time?
I can just send the new functions and main - the rest won't change.
A bit of initialization stuff may need to be altered, depending on the postion feedback the user wants - that's the next post. Also - the constantly changing uart.c is a good illustration of how a separate bit of code can be used for customization. I think it's a good thing!
Something like that may be a way of addressing different motor types, etc. For example InductionMotorSetup.c or BLDCMotorSetup.c . Just food for thought. :-)
- E*clipse