[AmpeROSE] – Pining for a PCB

Hello, everyone!

We’ve been really focused on making sure the physical circuit for AmpeROSE is the best it can be, as it is, in many ways, the most delicate part of our project. In this post, I’d like to talk about how our microcontroller will interact with the rest of our custom printed circuit board, some preliminary planning we’ve done on the firmware, and some interesting interactions between these two tasks.

The Firmware

We have decided to use the ChibiOS real-time operating system to support our embedded code, as we are already familiar with it, and it offers what we need in terms of device drivers and RTOS features (threads, synchronization primitives, etc.) . Our application code will be organized around three main threads, corresponding to the three main tasks performed by AmpeROSE:

  • A data acquisition thread which receives measurements through an interrupt-driven process, detailed further along in this post, applies any necessary signal processing and logical decisions (such as discarding the measurement immediately after a change in measurement) and passes it along to the transmission thread.
  • A transmission thread responsible for sending the measurements to the user interface through Ethernet or USB, or to the SD card through SDIO.
  • A command reception thread responsible for receiving commands from the user interface and controlling the whole program to follow them.

AmpeROSE’s Microcontroller

As you may remember from a previous post, we’ll now be using a STM32F767VIT6 as our microcontroller (or μC). It comes in a low-profile quad flat packaging (LQFP), with 100 pins to interface with the rest of the circuit. You can see its dimensions in milimeters on this image from page 54 of the datasheet.

Of the 100 pins, 16 are reserved for connecting the μC to various voltages (VSS, VDD, VDDA, VCAP…), one is a reset pin and one is used to tell the μC which boot address to use between two programmed options. The 82 other pins may either be used as general-purpose input/output or set to perform a number of alternate functions, the particular subset of alternate functions available being specific to each pin. These pins represent our “budget” for connecting the STM32F767 to the different peripherals on the board, including the current measurement circuit.

Below, the impact of the different peripherals we plan to include in AmpeROSE on this “budget” is discussed:


The STM32F767 includes a 10/100 MAC controller, which must be connected to an external ethernet transceiver (which implements the physical layer of communications). We’ll be using a LAN8742A connected to the μC through a Reduced Media-Independent Interface (RMII). Compared to the standard MII, RMII uses 9 signals instead of 18, but works at a clock frequency of 50MHz instead of 25MHz, which means we have to be particularly careful with the signal integrity of these connections. For each of the 9 RMII signals, only one pin of our μC is capable of performing its function, so we did not have much choice on this matter.

SD Card

The STM32F767 includes two interfaces for exchanging data with SD cards, but one of them conflicts (= needs some of the same pins) with the Ethernet, so we’ll be using the other one on a 4-data pins configuration (which means 6 pins are used, 4 for data + one for clock and one for commands).


The STM32F767 includes two USB interfaces: one for Full-Speed usb connections, for which a transceiver is also included in the packaging, and one for High-Speed connections. In order to use the High-Speed connection, it would be necessary to have an external transceiver, but some of the 12 (!) pins that must be used for connecting the transceiver to the μC are already taken by the Ethernet, so we’ll be working at Full Speed. As AmpeROSE will only ever operate as a USB device, there’s no need to use the ID usb signal, so only two pins (for the DM and DP signals) are needed.


We’ll be using a 32.7Hz quartz and a 20MHz quartz to provide clock sources for the μC, so the 4 pins that may be configured as connections for such oscillators will be used for this.

Context Bits

Six pins will be inputs for receiving context signals from the device under test, through a connector.


After performing a set of SPICE simulations, we have finally settled on an automatic calibration scheme, which will be detailed on another post (spoiler for those following at home: it will be a modified version of the circuit with RS latches). The simulations have also led us to reduce the number of measurement ranges we’ll be working with from 4 to 3, which means that we’ll have only two switches determining which resistors the current from the device under test will go through.

To survey the state of the control signals going from the automatic calibration circuit to these two switches (and thus, the state of the calibration), two pins will be used as inputs. It would be desirable that the μC keeps track of the state of the calibration whenever it changes, rather than just sampling it when a new measurement is made, to avoid the risk of doing this sampling right during a transition and ending with a spurious value.

Our strategy for doing so is to configure the two pins as interrupt sources, which will be activated at rising or falling edges of their input signals. In our μC, the GPIO pins with names ending with numbers from 5 to 9 all activate the same IRQ, as do the pins with names ending with numbers 10 to 15 . We will connect the calibration outputs to two pins in the first group (5 to 9), and use the common IRQ callback for the group to read the state of the pins and update a variable in memory with them.

Additionally, a mechanism for the processor to preempt the automatic calibration and assume direct control of the switches is also needed for our initial calibration process. The schema below, which ties up another 3 pins, appears to be the best solution:

The initial calibration also makes it necessary to have an output pin for controlling whether the shunt resistance receives current from the device under test or from our current mirror.

Finally, as we’ll have a mechanism for the processor to control the switches directly, our supervisors have instructed us the leave open the possibility of doing the calibration through software. This implies that the processor must have a way of knowing when the voltage on the shunt has reached a lower or upper limit and must be changed. Two options for doing so are using the internal adc for reading the voltage output by our amplification stage (needs 1 pin) and reading the outputs from the two comparators of the calibration circuit (needs 2 pins). We have enough free pins for doing either, or even both, strategies.


In order to control the potentiometers present in the circuit, a 2-wire I2C interface will be used.

Analog-to-Digital Converter

We’ve chosen the AD7766 as our external ADC. The protocol for reading data from it is identical to SPI, so one of the SPI interfaces from μC will be connected to it. As this connection will only ever transmit data from the slave (the ADC) to the master (the μC), and contains a single slave, only two SPI signals are needed: CLK and MISO.

Two further signals are needed: one is a GPIO input configured as an interrupt source, connected to the DREADY pin of the ADC, which goes low when there is a new measurement to be read. The other is a 1.024 MHz clock output from a channel of one of the μC timers, which will serve as the master clock for the ADC, determining its sampling rate. In conclusion, 4 pins will be used for this interface.

In the firmware, two callbacks will be used to take care of communications with the ADC:

  • One called for the interrupt launched when the DRDY pin goes low. It will start the reading of the measurements through SPI. It will also read the current state of the context inputs from the DUT, and of the calibration from memory, and place them on a chibiOS mailbox.
  • One called when the SPI transmission ends: it will concatenate the 24-bit measurement bits with the 6 bits received from the previous callback through the mailbox, and send them through another mailbox to the data acquisition thread.

In Conclusion

Taking all the interfaces discussed in this post, we have 44 pins left unassigned.


Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>




This site uses Akismet to reduce spam. Learn how your comment data is processed.