Need assistance determining number of hardware peripherals

Good day folks

I am working on a project and would appreciate some assistance. I will be as transparent on this platform as possible in asking my question.

The project is a UAV that will have industry (commercial) application, and is definitely not intended for recreational use. I am having issues selecting microcontrollers and I believe this is due to my limited knowledge. I am more of an idea/visionary individual compared to technicals.

The MCU’s that I have come across have had at most 6 SPI, 6 I2C, and 6 UART ports. The issue is, for example, one of the four MCU’s that will be used requires (or I believe requires) up to 18 SPI ports. This led me to question whether I am reading the pin descriptions in the datasheets correctly. An example is the Bosch BMI088.

One of the goals of this project is compartmentalization. Group sensors together via one MCU, group thrusters together via one MCU…and on and on like that. Now the main IMU (BMI088) as I calculate will utilize ‘6 SPI pins’. Here is the problem.

In selecting an MCU, I first need to determine the hardware peripherals and their quantity. This is where I am running into trouble. I would prefer if a discussion on the phone, and a potential in person meeting with someone with above adequate knowledge were to happen. And I am willing to pay. There will be an NDA signed before releasing more information about the project. If anyone is up for the task let me know how we can make contact. There is a preference for a field application engineer.

I would greatly appreciate authenticity as there is and will be a lot of time and money dumped into this project, so I would need to be able to verify your abilities. The components to be used in the craft have been 90% selected. 90% because I anticipate additions/modifications. If we were to determine we can work together, I am open to considering bringing the right individual on board the entire project.

Thanks for the considerations and hope to get moving on this.

Cheers

I’m not sure I have the relevant experience to help you out directly, but I will add some general knowledge to the discussion.

In most cases it’s not required to have a dedicated SPI/I2C port for each slave device.

In the SPI case, almost all slaves will have a CS (Chip Select) pin which allows your controller to select which chip (heh) it’s talking to at any given time. So you can hook them up in parallel sharing the same SPI bus with multiple peripherals and use GPIO (or a GPIO expander) to set the appropriate CS pin to talk to the desired device. This scheme may not work for you if you need to do precisely concurrent reads from multiple devices or if you require very high update rate, but for reading IMUs I imagine it would be fine to multiplex 10 or so sensors on one bus. You don’t want to go too crazy with this because of fanout.

I2C on the other hand is a shared bus by design, and every slave will have an address that is communicated on the bus itself, so you don’t need any extra pins. Most slaves have some way to set 1-3 address bits, so you could have 2-8 similar chips on the same bus and address them directly. Others allow you to program their address via the bus itself. You don’t have to do anything special for this, just size the pull-up resistors appropriately. Again, performance, concurrency, ‘fanout’, and possibly a limited ability to address slaves uniquely, are the limitations that would force you to using multiple peripherals.

Your main criteria for selecting a micro should probably be what you (or your firwmare dev) are familiar with, and only if you can’t make it work within that family, branch out. Unless cost is very critical.

Moved to Commercial Ops category

Hi @ktims thank you for your response. For this project, I require precise concurrency and unique allocations. I did get a private response from an embedded engineer that I will be following up with. Thanks again for your assistance @ktims, and be safe out there!

Cheers

I may be misunderstanding you, but IIUC this is a pretty common design problem, one that smartphones ran into and solved a few years ago–mostly by moving away from discrete sensors and on to IMUs with more and more bundled functionality, including sensor fusion offload. Here’s an example: ICM-20948 | TDK InvenSense

For a UAV, you’d probably want higher sample rates than the stuff that’s in phones and wearables, and you’ll also need to integrate GPS and proximity.

But… Have you looked at the cheap and cheerful world of RC flight controllers yet? You wouldn’t want to trust them to fly BVLOS or around people, but they would get you started. :slight_smile:

For example, I ordered one of these recently, it’s fixed-wing only. There are lots more for similar prices that include 6- or 9-dof IMU, and easy connectivity to GPS modules.

Hi @Arrgh

Due to the intended market I have a strong preference for industry standard components, hence why I avoided sourcing from the cheerful world of RC flight controllers (although I did browse through to get a feel for what the market has to offer).

I have a thorough list of components that will be used, the issue is selecting the appropriate MCU. Thanks for your response though.

Cheers

Makes sense, I’m just saying that you almost certainly need additional sensor fusion hardware between the sensors and the microcontroller, which will cut down on the I/O and compute and code requirements in the microcontroller too. :slight_smile:

1 Like

Hi @Arrgh

I’m starting to realize that might be the case, just like @ktims suggested. I believe my first move is to produce high level schematics and get a clear picture…while still hunting for a more efficient system. See I realize when it comes to computing, operations happen quicker than you can say quick, but I’m the kind of guy that will constantly be searching for the most efficient method to do something. But I won’t let it slow me down. Thanks for the advice, I’ll keep you updated.

Cheers

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.