View Single Post
Old 10-09-2015, 03:25 PM   #2159 (permalink)
Permanent Apprentice
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 312 Times in 214 Posts
I'm going to split this into two parts; 1st the memory issue, then the AtoD conversion issue.

Originally Posted by MPaulHolmes View Post
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
  Reply With Quote