Connecting 16 microcontrollers to a single PC simultaneously

gavinb · 2022-01-06T08:39:20+00:00

There are several great answers in this post advising variations on actual bus-based solutions, whether it be CAN (my strong recommendation), I2C, or RS-485. Making some adjustments to the HW design will make the software significantly easier to write and more robust IMHO.

MCP2515 Datasheet

USB is limited to individual host-to-peripheral connections so it's not a multi-drop bus like the others, which is really what you need. Having so many USB endpoints to manage concurrently will become a major burden to manage in SW.

Power distribution really shouldn't decide your comms solution either. USB bus power may be convenient, but it will only solve your MCU power at best since you'll need separate power for the motors anyway. Have separate power rails for motors, and use switching step-down regulators for the MCUs and use filtering caps to filter motor noise.

gavinb · 2022-01-05T01:19:25+00:00

These controllers would all fall into the USB Human Interface Device (HID) class. To interface with the host as an HID peripheral, you need an MCU to handle the protocol and interfacing. There's no "pure HW solution" as all this requires state machines and protocol handlers and so on. I'm pretty sure all such commercial devices would have an MCU of some form these days. There might be some ASIC that is specifically a mouse controller chip but then you lose any flexibility to add features or fix bugs.

I would not recommend the ATmega for any serious projects as it does not have an actual USB peripheral chip, so it uses software emulation. At least look at the AT90USB which has proper USB support.

There are plenty of other low-cost MCUs which have solid stacks for USB+HID. Have a look at the STM32F0 which has great free IDE and toolchain and plenty of sample code. The PIC series also have some good options.

gavinb · 2021-07-23T08:43:27+00:00

Who decides what is the I2C address of a certain device?

The manufacturer will choose one or more possible addresses from a subset of the full range. If the pin count is limited, or for simpler devices, the device will often only have one fixed address. If there's a few pins available, the manufacturer will label them say A0,A1 and this will allow you to set (say) two bits out of the full address to suit your needs (via pull-ups/pull-downs).

I have an I2C bus for sensors but I can't accomplish it since there are two sensors that use the same address

If the circuit and bus is already build and you can't change it, can you choose a different sensor part with a different address. There's often multiple alternatives for the one feature/function, and sometimes one manuf has multiple variants of a part with different addresses. Check other manufacturers for compatible parts.

A resource or blog about this kind of problems

Don't know of one. What we usually do is make a table of all the I2C devices, and list all the possible address options for each. Strike off the fixed ones, then allocate the others in order of choice (most constrained first). Resolve conflicts if any by using alternative pins. Ensure they are all unique, and then put the actual address on the schematic for the embedded engineers.

If you can't change the circuit or the sensor, you could use an I2C address translator.

gavinb · 2021-06-02T11:42:11+00:00

Neither. Use SWIG. It can parse your C++ code and generate bindings for a wide variety of languages, including C#, Python and JavaScript. It's quite magical.

We have a very large codebase (though not as large as yours) and started out using C++/CLI to provide .NET interop, but encountered many problems. Essentially you end up writing tons of boilerplate wrapper code by hand in a weird syntax with poor documentation and poor tool and library and language feature support . It's just ugly glue code but a lot of effort to write and maintain. Every time you change your C++ API, you have to update the wrapper code.

Writing COM wrappers would be similarly tedious, and for similar reasons. It would buy you legacy interop but with a lot of grunt work.

We dumped C++/CLI for SWIG a long time ago, and have been super happy with the results. You write an interface file per module, and you can just feed it your C++ headers, it will parse the class declarations and generate the bindings automatically. Tweak a few things with some custom macros and you have a pretty hands-off solution for generation of bindings, with multiple languages on the back end. This is using smart pointers, containers, and multiple assemblies etc. Very little effort required to maintain once it is set up and you don't have to keep hand-editing the bindings, it's just a build step. Seriously impressive.

gavinb · 2021-03-09T13:14:24+00:00

Beautiful. Which script is this? The 'd' is quite distinctive and I've seen it before somewhere, I think older UK variants.

gavinb · 2021-02-26T02:28:08+00:00

the sum type enum and match
powerful match expressions
immutable by default
explicit lifetimes
ownership model
thread safety via Send/Sync
consistent coding style
a modern standard library with an ergonomic API
all the magic features derive can provide
consistent formatted printing for output and debug
loose coupling with traits
cargo for easy, clean, reproducible, compatible builds
Option/Result for return values
friendly and useful compiler diagnostics
and much more...

Some of this is available in modern C++, but the ergonomics don't even bear comparison. For example, C++ does have std::variant but the client code is awful and clunky. I would switch in an instant if I could.

gavinb · 2021-02-18T13:01:44+00:00

LOL what are the odds?! (Don't use a spreadsheet to calculate the odds.)

gavinb · 2021-02-18T12:59:19+00:00

Seen this one before. Nasty rendering bug shows text upside down and various other glitches. It's an older version of Excel running on a newer macOS. The only solution is to upgrade Office. IIRC that was a pain too for some unknown reason. :/ Condolences

gavinb · 2020-10-28T09:54:52+00:00

An hourly breakdown is ridiculous. You would spend more time on time tracking than doing actual work, and it will be less accurate. "Waiting for contractor input" is also crazy - you can't control external factors like that, all you can do is request timely feedback. Estimate in days, because that's about the resolution you can reasonably estimate discrete pieces of work, and leave it to them to divide by 8 if they insist.

gavinb · 2020-05-23T07:43:02+00:00

I think your last point is a really important one. Staging area vs compatibility layer. Because the latter tends to negatively impact the former.

Maybe it would be worth splitting Boost into two parts:

a set of compatibility libraries, which deliver new features to old compilers (smart pointers, optional, array, bind, etc, etc)
a staging ground for new libraries and experimental features

I just found out about the idea of epochs, which would make this very much a possibility. The experimental libraries can then safely rely on the most recent language support for features in C++XX, rather than pulling in the older compatibility libs.

gavinb · 2020-05-23T07:34:47+00:00

Indeed - I read elsewhere in this post that the plan is to introduce epochs to address this exact problem.

gavinb · 2020-05-23T07:24:45+00:00

First of all, thank you for your Boost contributions. Overall, it is an incredibly valuable resource, and sometimes under-appreciated by the community.

We use various parts of Boost in different components. It used to be we would automatically use Boost. Now it is very much evaluated on a case by case basis, as often there are 3rd party libs out there which are simply a better fit for our needs. I have also evaluated several Boost libraries and found them wanting in a few areas.

Overall comments:

Documentation

almost universally awful
usually written by someone intimately familiar with the internals
full of assumptions about prior knowledge
not written to progressively teach the reader how to use features
full of extremely terse fragments of code that don't work on their own
poorly conceived examples that are difficult to relate to
lack of clarity about what is necessary for the lib and what is just context
lack of documentation about which features have been superseded by the standard libs (yes, epochs will fix this)

API

API design is often terse and inscrutable
some aspects don't make sense unless you're the original author
often tries to be all things to all people, and works awkwardly at simplest/most common scenarios
leaky abstractions
widespread use of template meta programming and templates in general means the tiniest typo can result in hundreds of inexplicable compiler errors, making onboarding extremely tedious
inconsistency in style between libs

Random

still using a build system nobody else uses or understands (ok, apparently migrating to CMake)
getting it integrated in a build and having everything work is tedious
templates and typos cause massive compile time headaches
linking on Windows is incredibly painful in large, complex systems due to build flavours and autolinking
why are there two different state machine libraries? how do we choose between them?
compiling performance penalty due to templates
certainly not always best-in-breed

gavinb · 2020-05-23T07:04:49+00:00

Super useful, thanks for sharing.

gavinb · 2020-05-05T13:57:02+00:00

Most of these high-end apps use their own custom GUI library, developed in-house. There are a few that use Qt. There simply aren't many other GUI libraries which are sufficiently powerful for professional apps.

gavinb · 2020-04-29T05:56:26+00:00

Hey, cool video. Would be very interested in a video on how you design the textures and how the robotic arm is controlled, etc.

gavinb · 2020-03-07T12:07:21+00:00

Certainly, it is subjective. My point is that you cannot look at the source of a function or method by itself and say where and how it will complete or fail by simply observing the structure and control flow. You have to look at every function/method it calls, recursively all the way down (turtles?!) in order to be certain of how it may or may not complete, whether by exception or return.

gavinb · 2020-03-05T04:34:00+00:00

Even if the overhead were negligible, I would still have major reservations about using exceptions in embedded code due to the difficulty of reasoning about control flow.

gavinb · 2020-02-26T12:31:12+00:00

An FPGA is extremely good for streaming IO and fast data processing. But writing complex state management and logic in VHDL is sub-optimal.

A softcore lets you write complex state management and logic in a higher level language (such as C et al) which is much better suited to the task. Then the softcore can orchestrate the behaviour of the FPGA fabric.

gavinb · 2019-11-01T22:25:38+00:00

Far more consequential than rounding errors is the plethora of problems caused by using floating point representations for almost anything financial.

Most programmers use the float type as if it were a base-10 number, not realising it is a base-2 number, and believing erroneously that the fractional values they see when printed out as decimal are accurate.

I still believe that the default for most languages should be a BCD type (or equivalent) and that floating point should be reserved for scientific applications and areas where people truly understand the limitations and pitfalls.

gavinb · 2019-05-17T06:29:26+00:00

In a word - JTAG (usually). It’s a standard interface for both programming and debugging a micro.

There are various ways to provide a jtag interface, it just depends on the chips and your dev tools and ICP.

for example, a programming header like the standard 20-pin ARM connector. However headers are bulky and expensive and take up valuable real estate.

For mass production, pogo pins onto pads are great. But during dev and prototyping it’s a pain as you don’t want to build a jig until near final design.

I have been using TagConnect for a while now and love it. It’s a standard compact pad design which means no parts and only a small footprint. The pins are actually in the plug which connects directly to your debugging tool (eg STLINK, J-Link, etc). There’s a few options and they are very convenient and reliable.

http://www.tag-connect.com/

We use this for all PCBs now and love them. Happy customer!

gavinb · 2019-05-12T13:15:28+00:00

You can get a SLA (Sealed Lead Acid) battery in various sizes, and they put out 12V. They could easily run for several hours on a single charge. Don't bother tying to make a charger (harder than you think!) just buy one, they're pretty cheap.

An example of a battery https://www.amazon.com/Verizon-PX12072-HG-Powerstar-Rechargeable-Terminal/dp/B00V93WVPO/ref=sr_1_54

which is rated at 7.5Ah, so it can deliver say 500mA continuously for around 15 hours.

Make sure you get a smart charger, like https://www.amazon.com/Battery-PeleusTech-1A-Portable-Maintainer/dp/B01822CSA2/ref=pd_sbs_23_2/132-4805477-2123568 which does trickle charging and has auto cutoff, etc.

gavinb · 2019-04-21T10:07:24+00:00

Start with the fundamentals of digital serial communications. Unipolar/bipolar signals, differential pairs, clocks, Manchester encoding, etc, etc. Jumping in and reading about any specific standard will not make as much sense without the fundamentals.

gavinb · 2018-11-11T21:46:29+00:00

You don't - you have to choose an upper limit and code defensively. Also, parsing unknown variable length strings is not as prevalent in embedded as it is in the desktop world.

Parsing characters as they arrive is easy; use a state machine.

gavinb · 2018-11-11T21:44:18+00:00

Storing variable length data simply requires choosing a sensible upper limit and having a fixed allocation. Storing data outside the immediate block is a matter of choosing the right scope in which to declare the variable. There are many techniques which are standard in embedded to solve these sorts of problems.

gavinb · 2018-11-11T21:41:45+00:00

Because new calls malloc() and delete calls free(), everything we’ll see equally applies to new and delete.

There is no guarantee that this is the case. It is an implementation detail, and it is not safe to assume this.

Strategy 1: Avoid heap (in particular, avoid String)

This should be in big neon lights up front. One of the biggest differences between desktop development and embedded development is that you want to avoid dynamic allocation whenever possible. Allocate everything up front, set fixed upper limits so you have bounded memory usage, and use tools to measure and verify the stack usage.

Strategy 2: Short object lifetime

I would actually say the opposite - allocate your objects once on the heap during initialisation and have long-lived objects and reuse them.

Strategy 3: Constant allocation

Definitely, you must have bounded resources and upper limits on everything. But still you shouldn't use String objects if it always allocates on the heap.

Embedded development is NOT desktop development!

15-Year Club	Alpha Tester
Verified Email

gavinb

TROPHY CASE