View Single Post
Old 10-09-2015, 11:34 PM   #2172 (permalink)
Master EcoModder
Join Date: Sep 2010
Location: Saskatoon, canada
Posts: 1,488

Ford Prefect - '18 Ford F150 XLT XTR

Tess - '22 Tesla Y LR
Thanks: 747
Thanked 565 Times in 447 Posts
Originally Posted by MPaulHolmes View Post
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.
.. Long post .. lots of ranting on random topics .. my apologies in advance!

My basic idea is 3 micros. Hopefully the description makes SOME sense ..

A separate co-processor to handle everything else and feed the dsPIC with exactly the information required, no fluff, no waiting, just the latest value of whatever variable the dsPIC 'asks' for. Hmm.

So the co-processor would handle the throttle (single or dual channels, open circuit/short circuit detection, hall effect or potbox, coast or regen), brake (regen level, drive the brake light), select Park or Neutral or Drive, perhaps Eco mode or Sport or .. Ludicrous? Control the boost IGBT (not sure about how to approach that one), Transmit the throttle signal to the dsPIC once every .. 100 ms? If the dsPIC loses the throttle for 250 ms it turns off the motor outputs and coasts.

I don't like that the dsPIC has to 'ask' for info. How about it just receives a broadcast?

Handling the throttle may not require microsecond processing, but it is pretty important compared to selecting Drive or Neutral.

I hesitate to suggest an even MORE complicated structure ... but .. I would feel better if the throttle, brake, Boost .. were on a microprocessor that did not handle communications with a phone, or a web server, and stuff.

web and phones and park and drive and entertainment .. how about I call this one the 'Firewall' communications micro. That micro sends data via something - CANBUS or Serial? - the next Micro. How about 'DMZ' micro, that does throttle and brakes, boost controller, maybe charger, allow change from Drive to Neutral to Park, interlocks so you don't drive the car away while plugged into the charger, sends some data back to the Firewall, sends the rest - CANBUS or Serial - to the dsPIC that does FOC in interrupts. dsPIC receives information required from DMZ in main, non-interrupt process. And takes the latest value of info needed to send back to DMZ.

Somehow, the datalogs from the dsPIC must pass to the DMZ, and that data as well as logs from the DMZ must pass through to the Firewall. Some sort of command/response/verify?

With no IP stack on the DMZ or dsPIC, it should not be complicated. If there are no write commands direct to memory defined, but only exchange of data with the Firewall - that should remove the simple hacks. If the buffers that interface between DMZ and dsPIC are defined at the end of memory so stack overflows get dumped off the end of the memory map, where there is simply no memory left. Not sure how to guard against the stack overflows and other hacking methods .. kinda out of my league there .. but it would be nice to be reasonably sure that the DMZ and the dsPIC can't get *EASILY* hacked.
  Reply With Quote
The Following 2 Users Say Thank You to thingstodo For This Useful Post:
e*clipse (10-10-2015), MPaulHolmes (10-10-2015)