pyControl H7 Breakout

[alustig3]

Hi Everyone,

I have designed a new breakout board and would like to share it with the community for feedback. You can find source files here: https://github.com/Karpova-Lab/pycontrol-h7-breakout.

Hopefully we can make some improvements and refinements, and if there is a desire, we can work towards getting devices manufactured and available for everyone in case they don't want to build their own.

The motivation for this new design was to solve some long-standing pyBoard sourcing problems while also improving performance.

This topic has been discussed several times in the past:

• Micropython shortage — November 2022
• Hardware availability — May 2023
• The future of Micropython and Pyboard — May 2023
• Porting to other hardware — January 2024
• Extending pycontrol for compatibility with 28V hardware — November 2024
• Using pyControl on a Teensy or without a breakout board — July 2025

Sourcing

The new design directly interfaces with the microcontroller, in contrast to the previous design which was a breakout board for a pyBoard (which itself is a breakout board for the STM32F405RG microcontroller).

This change is significant as we will no longer be dependent on the availability of pyBoards in the MicroPython Store, we only need to source the STM32H743VIT6 itself which has several suppliers. For the external flash memory (another component with a history of supply issues), the board includes two footprints to maximize sourcing options.

Features

• 480 MHz Cortex-M7, 800 KB SRAM, 32 MB QSPI flash
• 12 pyControl RJ45 behavior ports with ESD protection on all DIO_A, DIO_B, and DIO_C pins
• 4 SMA connectors (2 with DAC outputs)
• USB-B connector with ESD protection
• On/off switch, user button, reset button, and boot button for easily entering DFU mode for firmware updates
• Power indicator LED, controllable RGB LED for status indication
• Easy to manufacture 3d printed/lasercut case design
• Mounting hole spacing compatible with DIN adapters that securely mount onto DIN rail

Specifications

	pyControl Breakout 1.2	H7 Breakout 0.3	Improvement
Microcontroller	STM32F405RG	STM32H743VIT6
CPU	168 MHz Cortex-M4F	480 MHz Cortex-M7	2.9x
Heap (available RAM)	101 KB	753 KB	7.5x
Filesystem space (available Flash)	88 KB	32,707 KB	370x
Input / Output
RJ45 Behavior Ports	6	12	+6
Coaxial Connectors	4 BNC	4 SMA
Power Driver Pins	14	24	+10
Digital I/O Pins	15	38	+23
DAC pins	2	2
UART buses	3	7	+4
I2C buses	2	2
*SPI buses	0	2	+2
*CAN buses	0	1	+1
Dimensions	1.8 x 7.6 in	2 x 10 in

*hardware.py will need to be updated to support SPI and CAN buses.

size comparison

Performance

benchmarking details: https://github.com/Karpova-Lab/pyControl-D-Series-Breakout/blob/master/benchmarking/readme.md

Note on the error offset: There is a known bug in the current pyControl firmware where the timer rounds down to the nearest ms tick, introducing a ~500 µs offset. A fix (rounding up or down to the nearest tick) can be included in the next release, which will center the error distribution around 0 µs

Breaking changes

new peripherals

Below is the standard pinouts for some peripherals on pyControl behavior ports.

	DIO_A (pin 1)	DIO_B (pin 4)	DIO_C (pin 5)
I2C	SCL	SDA
UART	TX	RX
DAC			DAC

This new board would introduce two new standard pinouts for hardware SPI and CAN peripherals.

	DIO_A (pin 1)	DIO_B (pin 4)	DIO_C (pin 5)
SPI	MOSI	MISO	SCK
CAN	RX	TX

Timers

The new board uses different timers, so we will need to rethink how available timers are implemented since right now they are hard-coded. There are still 14 available timers, but the old board uses timers 1-15 while the new board uses timers 1-8 and 12-17.

Questions for you all

1. POW_C pin: None of the behavior ports in this design have a POW_C pin like ports 1 and 2 did in the previous design. Does this break compatibility with any existing devices that you use? If you want the POW_C pin, how many of the ports would you want it on?

2. BNC vs. SMA: Are SMA connectors an acceptable alternative to BNC? I chose them because they take up less board space. BNC-to-SMA adapter cables and inline adapters are available if you need BNC compatibility.

3. Right-angle (horizontal) vs. vertical connectors: The prototype uses right-angle RJ45 and SMA connectors, which work well for our lab setup. Do people have strong preference for vertical connectors instead? I think it would be best to avoid offering/maintaining two board variants, but open to hearing opinions.

4. Extra pins: There are 4 extra pins not currently being used. Would you want to use them for more buttons or indicator LEDs or something else? Or connect them to screw terminal or some other type of connector?

5. Anything else you can think of? Questions? Concerns? Ideas? Suggestions?

Pretty pictures

Hope to hear from you all!
-Andy

Tagging people who may be interested: @jonahpearl @McMuppet @ThomasAkam @theonlydvr @AtMostafa @jonnew @filcarv @marinopagan @ngarcia-font @lauralgrima @FlaviaRicciardi @bdudok @guykoy123 @horsto @msoheib @amchagas @sbtnRey @HMC123-puxel @juan-cobos @margo-tje @wanghgogo @peterpolidoro @sawtelles

[jonahpearl]

Hi Andy — thanks for the ping. New designs are always exciting! This one looks great.

To directly answer your questions:

• POW_C pin: we use POW_C occasionally. For example, I have a very simple home-made olfactometer with three solenoids (odor A, odor B, final valve) for some of our rigs. Having 3 power lines per port means I can use one port as the "olfactometer port" and not have to split it across ports. So yes, in general, I can see the utility of giving the user at least 2 ports with 3 power lines each, as a nice compromise to not have to resort to a port expander or split across ports for homemade peripherals.

• BNC vs. SMA: we use BNC almost exclusively, but I suspect that for what we're doing (mostly sending TTLs) having an adapter won't interfere very much with the signal.

• Right-angle (horizontal) vs. vertical connectors: No strong preference.

• Extra pins: I'm always in favor of having a few debugging pins available, either as screw terminals or 0.1" headers. Maybe also a few spots for GND (so that they can send TTLs). Or a second user button!

Anything else you can think of?

A few thoughts:

• Our lab now has ~8 pyControl rigs running simple 2AFC tasks. The v1.2 board with its six ports has been more than sufficient for running those rigs (I think each rig is using 3 behavior ports + 1 port for controlling odors). As a corollary, I worry about the price for this new one — if these got made by Open Ephys, eg, would the price per board be 2x what it is now, because it's twice as much materials / soldering?
• Will the pyControl backend codebase have to change at all? (Other than the timers issue.)
• Hurrah to having all the connections face the same way — the front/back design of the v1.2 has been annoying during rig set-up / troubleshooting.

[alustig3]

Thank you for the great feedback!

if these got made by Open Ephys, eg, would the price per board be 2x what it is now, because it's twice as much materials / soldering?

I'm not sure how much of the price is a function of components/materials vs. assembly/labor/testing/QC vs. overhead of running an online store etc.

As far as BOM costs, looking at the old BOM I think the cost is roughly ~$75, and for the new design I am getting a rough estimate of ~$50. This was just a quick glance, please take these numbers with a grain of salt! This seems to make sense as buying the bare MCU + components is ~$15 vs. buying pyboard to plug in is ~$30

for labor, I think the assembly of the old board required OEPS to manually desolder some resistors and plug the pyboard into the breakout board (https://github.com/pyControl/hardware/blob/master/Breakout_board/Breakout_board_1_2/assembly_notes.txt). That manual work shouldn't be required with this design.

I'm not sure about the PCB manufacturing and assembly costs. I suspect this new design may be similar. The old design had through hole parts on both sides of the board which I think can be expensive. There may be opportunities for me to change some more of the components to surface mount it that is a significant cost driver. I won't be able to get rid of all through hole parts, and I'm not sure if you have to have a couple of through hole parts anyway, if there is a major difference between say 12 through hole parts vs. 16 etc.

Overall, I would guess that the price should be similar if not less expensive, but that is just an educated guess.

If there is interest for a breakout with less features at a lower cost, we could brainstorm where the cost saving could be and whether the resulting board would be interesting to people. Maybe something like a smaller dev board with just rows of of through holes, no RJ45 or SMA connectors.

Will the pyControl backend codebase have to change at all? (Other than the timers issue.)

It does not appear that there will need to be any other changes, but I am still testing. That is the beauty of the pyControl framework being built on top of MicroPython, in principle we should be able to swap in different STM32 microcontrollers as long as we can build the MicroPython firmware for the new target MCU. Getting this new firmware built was a challenge, but I was able to get something working which has been exciting

From the user's perspective, the only changes they will need to make is importing a different board and maybe changing a couple of port numbers if the devices are using UART or I2C since they aren't all the same port numbers as before.

In this example hardware definition

# This hardware definition specifies that 3 pokes are plugged into ports 1-3 and a speaker into
# port 4 of breakout board version 1.2.  The houselight is plugged into the center pokes solenoid socket.

from devices import *

board = Breakout_1_2()

# Instantiate Devices.
left_poke = Poke(board.port_1, rising_event="left_poke", falling_event="left_poke_out")
center_poke = Poke(board.port_2, rising_event="center_poke", falling_event="center_poke_out")
right_poke = Poke(board.port_3, rising_event="right_poke", falling_event="right_poke_out")

speaker = Audio_board(board.port_4)

# Aliases
houselight = center_poke.SOL

you would just need to update these lines

board = Breakout_H7()
speaker = Audio_board(board.port_8)

[jonahpearl]

Ok, great! I was actually asking about the firmware. The reason is, I'm curious if the changes you've made will make it easier to port to other MicroPython builds like for the Teensy (i.MXRT). IIRC the main roadblock in getting something like pyControl to work on Teensy is that Teensy doesn't really support opening a separate (virtual) serial connection to upload files, the way the old pyC code would; basically it's not designed to have a file system on it. So is that something you also had to overcome for this chip, or is this chip close enough that you could still use the pyb library?

[alustig3]

yes Teensy's lack of the virtual com port that is in the pyb library continues to be a roadblock.

It turns out the pyb library is for all stm32 ports, not just the pyboards (v1.1 and d-series boards). So any board from https://github.com/micropython/micropython/tree/master/ports/stm32/boards can be used as a starting point for creating our own custom firwmare. I started with the WeACtStudio board and firmware.

[horsto]

This looks really cool - thanks for tagging me and sharing your progress @alustig3 !!
I was mainly wondering about costs and software integration: How much more will it cost, what changes ?

[alustig3]

thanks! please see https://github.com/orgs/pyControl/discussions/171#discussioncomment-16329031

[jonnew]

Nice. Is it a two layer board? Given the amount of digital crisscross and the speed of the MCU, I would consider using 4 layer board with 1 or 2 dedicated ground planes. It adds basically zero cost at the scale these will be produced.

[jonnew]

Additionally, if you can use USB-C that would be much preferred IMO. All other USB connectors are becoming defacto deprecated, especially for younger people.

[jonahpearl]

I didn't even notice the USB — I agree that USB-B is annoying. A or C would be fine by me, most desktops in labs will still have A ports.

[bdudok]

Looks like a nice upgrade, thanks for sharing! Supply chain issues can be such a headache, I'm glad you are able to design the board keeping part availability in mind. Re: your questions, I don't have any strong opinions. We don't use POW_C (just A and B). We use a lot of BNCs, but getting a bag of SMA adapters is certainly not a dealbreaker.
One point that comes to mind (that may not even be related to hardware, so I'm just throwing it in): rotary encoder integration has some limitations that are inconvenient for us on the current board. That is, the task script needs to poll the position variable using a timer, whenever we want to do something that depends on distance traveled or reaching a specific treadmill location. Instead, it would be so much better to get an interrupt at a pre-set position value.

[alustig3]

thanks for the feedback!

That is, the task script needs to poll the position variable using a timer, whenever we want to do something that depends on distance traveled or reaching a specific treadmill location. Instead, it would be so much better to get an interrupt at a pre-set position value.

you should be able to get an interrupt based on a "trigger" instead of polling the position. Take a look at the running wheel example task.

Feel free to start another post in the discussions/forum if you can't get it working and we can help you debug.

[ThomasAkam]

Hi @alustig3,

The new board looks fantastic, many thanks for your work on this. Moving to having the MCU integrated directly onto the board should greatly simply both supply chain issues and manufacturing, and having a more modern processer with more memory, and more IO, will be great.

Re questions:

POW_C pin: The only hardware device that I think uses POW_C is the 5 poke board. I think it would be nice to have e.g. 2 ports that support POW_C but not essential.

BNC vs. SMA: I don't feel strongly about this given that adapters are available but probably have a slight preference for having some BNC connectors given that a lot of laboratory hardware still uses BNC and the cables and adapters are substantially cheaper than SMA equivalents.

Right-angle (horizontal) vs. vertical connectors: I really like the form factor of your design. My only question is whether it would be desirable for the power and USB to come off the same side as the other connectors but not sure whether this would be preferable.

Extra pins: Again I don't feel strongly about this. A screw terminal could be useful, particularly if we broke out power and some POW lines to it, but definitely not essential.

Anything else you can think of?

• The STM32H743VI appears to have some built in graphics capabilities (LCD-TFT controller & graphical hardware Accelerator). It could be interesting to have graphics port for connecting a monitor to allow for visual tasks, and it we are thinking about this we might also want to look into touchscreen support.

• We could consider having a 3.5mm audio jack AC coupled to one of the DAC outputs, to facilitate audio stimulus output without using the Audio_board.

• Re USB: We definitely don't want to use the same micro-USB as the original board as these are very fragile. I think Andy has probably chosen the big USB-B connector because it is very robust. I would also be happy with USB-C - Andy what is the rationale for not going with that?

• Do we really need 12 ports? We could consider dropping down to e.g. 10 which would free up 2 driver lines for POW_C on two ports. I don't feel strongly about this but can't think of many situations where we would use 12.

• It could be interesting to have a QWIIC / Stemma-QT / Modulino connector or two as there are many modules from Sparkfun/Adafruit/Arduino that use this connector system (they appear to be compatible between the 3 systems.