Electronics > Projects, Designs, and Technical Stuff

Board to board connections in multi-PCB project

<< < (3/3)

Trotters_Independent2:

--- Quote from: max_torque on July 28, 2024, 08:52:48 pm ---
--- Quote from: Trotters_Independent2 on July 23, 2024, 07:31:51 am ---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.



--- End quote ---

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"!


--- End quote ---

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 electronics 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.

max_torque:

--- Quote from: Trotters_Independent2 on August 01, 2024, 08:24:58 am ---
--- Quote from: max_torque on July 28, 2024, 08:52:48 pm ---
--- Quote from: Trotters_Independent2 on July 23, 2024, 07:31:51 am ---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.



--- End quote ---

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"!


--- End quote ---

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.

--- End quote ---

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.

tooki:
In terms of connectors, you can use d-sub, but if you do, use only top-quality ones with machined contacts. This needn’t even be that expensive; Amplimite housings and mil-spec crimp contacts (M39029/63-368 female and M39029/63-368 male) combined with a good backshell is adequate for many situations that don’t need weatherproofing.

But there’s a reason that one-off cars (like race cars) and aerospace use a lot of circular connectors, despite the high cost: flexibility and reliability. There’s a huge selection of weather-sealed versions, variations on backshells and seals and accessories, as well as interesting contact types that allow you to mix regular pins, coaxial, fiber optic, and even pneumatic connections by inserting different contacts.

Take a look on YouTube for how race car harnesses are made. They’re things of beauty.




As for integration: developing different sections independently can give you some advantages (especially in terms of being able to completely replace a section easily if it doesn’t work), but as others have said, the system integration complexity is at least as large as in doing it as one board, if not larger. IMHO to be successful, you still need to have very clearly defined the system architecture and above all the interfaces between the sections — and you need to do that before you begin designing anything. Otherwise you just end up with individually-functional modules that can’t talk to each other properly, or don’t actually do everything they need to do.

max_torque:

--- Quote from: tooki on August 01, 2024, 05:22:57 pm ---

 developing different sections independently can give you some advantages (especially in terms of being able to completely replace a section easily if it doesn’t work),

--- End quote ---

Honestly, this is also the case with doing it "all on one board" these days!  And honestly again, on a project like this one, you shouldn't even be looking to combine subsections in ANY way until you know they work.  Thanks to circuit simulation, it's unlikely anything you are doing on a car is complex enough to be likely to "not work" (unless you are doing AI driving etc...)  Sure, some component values might need a tweek to say remove some noise, or a bit more analogue filtering added to clean up a signal, but really, most of your work in going to be in the software domain (i'm going to assume you are buying a COTS motor controller, not rolling your own, if you are, good luck, this IS a serious task...)


Take reading some thermistors. It's pretty easy to identify you'll need some ADC peripheral access on the micro to convert the analogue signal to digital, and some I/O circuitry to drive, filter and ideally diagnose the sensor itself, but none of that is very hard.  What you get however is a robust solution, where one failure is much less likely to remove an entire chunk of data (a CAN Bus is a "constriction" in the system, both in terms of throughput, but also in terms of a failure node where one failure can have extremely far reaching impacts.  A single board, or well physically coupled multiple pcbs sending data to one controller is much more robust to failure, and a single failure is likely to be less catastrophic (and you failure matrix becomes a lot simpler)


So you get your "thermistor team member" to start simulating, then designing a proto pcb to plug into the standard devboard you have choosen, so they can quickly get up and running, testing and developing, and not worrying at all about the size or physical constraints of that individual part. They can make their IO test board as big as it needs to be, with test points, and plenty of abillity to "fudge in" say an additional resistor or ferrite bead or whatever.  They can write the software to read / process and respond to their stimuli, and get everything working.  At some way into this process, the team leader can start to look at his team memebers sections, and start to pull together an overall single system design.  The final re-spin to move from the prototype IO pcbs to this new single solution is really pretty simple, and while he waits, the team principal can get started on the power and logic elements to the controller, and the 3d design of it (which is critical to get right in the auto sector)

Navigation

[0] Message Index

[*] Previous page