Quote:
Originally Posted by MPaulHolmes
Maybe there could be a separate microcontroller that does all the non time critical stuff that sends the info to the time critical micro? non super-time critical could compute A/D's of throttle, brake A/D pressure switch thing, temperature A/D, DC voltage monitor, UART communication with outside, etc... All stuff that doesn't HAVE to be right this 0.0001 sec. It could even drive an optional 4th half bridge for the boost option. Then the other micro could do current 1, current 2, encoder or resolver, and that's it. boom. FOC with the focus of a ninja. haha. It would have to receive messages but that could be done quickly and reliably.
|
I am debating (with myself) a system like that to deliver the power to four different wheels. I'm wondering if it would be better to have a microcontroller (something simple like an 18 or 16 series pic) "interpret" the user inputs like throttle, brake, steering angle, etc. The output of this would go as an individual throttle "request" to four independant motor controllers.
Or perhaps a more simple analog solution that also makes these "requests"?
Anyway, I've sort of come to the conclusion that having one computer interpret driver "requests" like throttle is a necessary evil. Two? Hmmm I'm not sure I trust cumpooters that much. I REALLY don't trust the modern systems that use CAN bus for everthing from tire pressure monitoring to infotainment to throttle and ABS brake controls.
Oh, BTW, I'll this previous post
Quote:
|
By "frozen" on the startup, I really meant "I don't give a crap what happens there because I never mess with that part. haha (laughing intentionally in quotes)" So, feel free to adjust that to include delays for things that are needed so no extra delays are there.
|
to mean go ahead with those final "main" mods. I'll put them into a form that can easily be copied into the current code, so your current work won't be affected. I hope this will work out - if not, you'll still have your old code.
*****edit******
regarding the above, for now I'm not going to change anything.
1) I can't see a way to improve the contactor control time, and moving this outside main would not help anything
2) The while(1) loop in main that starts with "ProcessCommand" appears to be only UART stuff, but I'm not sure about the section that looks at the PI values. Since you are debugging PI stuff, I think it's best to leave this alone for now.
***************
I'll just get back to integrating a resolver into the FOC part. I'll see if just the sin or cos can be used so that AN0 doesn't need to be changed.
- Eclipse