My team are entering into a competition which involves designing and building of a low speed electric vehicle. We are designing a multitude of different PCBs to implement things like telemetry, sensing of various voltages/currents/temperature etc and they all communicate with the main "CPU" PCB via CAN bus.
ok, hate to be the one to say it, buy why??? There ARE some very valid reasons to have seperate control units, mostly due to physical location constraints or for signals that cannot easily be moved (well less easily moved that a databus + power).
Unless you are doing something EXTREMELY complex, then i see no reason that a modern 32b micro cannot have pretty much everything on-board it needs to have. You can still have teams designing the different sections (i do this all the time) and with modern EDtools co-operative design can occur at all levels (schematic, board layout and 3d mech).
I'v got 30 odd years of direct electronics experience in motorsports (up to and including f1) in OE pass car and in aerospace and defence, and i can tell you right now "avoid every connector you can"!
The reason why is more of a "project management" type reason. Having a single centralised "controller" was the initial preference. But we are a geographically displaced team living in different cities, with limited opportunities to meet in person, and each of us with very limited time and experience - except myself with some design experience but no prior management experience.
Having a single controller with all (or most) of the features combined into one PCB would mean too much work for an individual person (namely me) and I felt it would be difficult to get a whole team of several engineers working on one PCB. I feel the multi-PCB method makes it easier for everyone to work on their own bit in isolation, develop software, debug hardware etc. They can set up a dummy central controller at home to mimic the CAN comms that will be happening when the individual PCBs are installed into the main system and they can validate that their own PCB works exactly as intended. And it clearly sets implicit boundaries between each others' responsibilities, even if overall system complexity is somewhat increased.
That being said, I am autistic and struggle with management and organisation in general so there could easily be another approach that I haven't thought of, but this seemed like the best way to manage the team's work and develop a solution, given our circumstances.
I can see why you might think the "Multi-controller" approach is easier and less work. But, it isn't. What it does is open you up to everyone elses faults/bugs and errors bringing down the show, and your software task is multiple times bigger because everyone has to do all of their own s/w for each node, and some one has to do the "integration" and "network" software. More work, more potential for errors and bugs.
My suggestion, is as follows:
1) choose a decent microcontroller for which you can get a dev kit/devboard. This isn't hard these days, plenty of choice. That controller can be an "overkill" for individual requirements, but it's cost is pretty much irrelevant in the grand scheme of things
2) One person, most familiar/experienced with that micro is responsible for building the "low level code", a standard set of code files that allows the peripherals to work on the dev board as required. These days, thanks to things like STMcubeIDE etc, this task is pretty trivial, ie you can build a low level environment pretty much entirely with "clicks" for most micros. The days of directly manipulating registers and setting up periferals by hand are (mostly) long gone
3) Each person then develops their part of the system for their specific I/O and task using that dev board as the standard logical element. The "team manager" will need to track and allocate microcontroller resource and peripherals to avoid conflicts, but this is pretty easily done. This gets you up and running very quickly indeed, as each team member can get coding and developing pretty much straight away.
4) once you start to see how things are forming, in terms of physical size and uC resource allocation, the team manager can now start to look at issuing each team member with a standard "footprint". The form factor is up to you, but lets say you use 100mm x 100mm square pcbs, linked with stackable ribbons or direct board 2 board connectors. Each team member can take their protoype circuitry they proved with the microcontroller dev board and very easily port it across to the final physical design package.
5) Whilst this is going on, the team manager takes the dev board basic circuitry, and puts it onto the projects "base board". Here you can pretty much copy the dev board, although for auto rating you'll need to look at psu / emc / filtering etc This board should also deal with suitably robust I/O connectors out into the real world, these might need to be on flexpcb or ribbons depending on your mech design
6) Finally, one person can take each team members proven and working code + header files and put them together, so one micro on the base board can do everything.
At a bench test level, you can do an intermediate step, where you run a full or partial system using the devboard itself and a rats nest of wires to each team members I/O circuitry proto boards but don't be tempted to put this in the vehicle, trust me, it won't work and it will introduce so many problems and faults, and consume so much of your time chasing "Ghosts" you'll wish you didn't bother!
I'll guess you are budget limited and have few contraints in terms of space or mass, so there are probably no prises for making everything small and sexy. Get a big box (ideally an COTS automotive rated ECU enclosure with integrated connectors (as linked previously) and just put all your individual pcbs in their.
Home
Help
Search
Login
Register
