Extending pycontrol for compatibility with 28V hardware

[theonlydvr]

I previously worked on a project to control Coulbourn Instruments chambers using an Arduino and recently had some needs to revamp the project and make it somewhat more flexible. In working on this update, I figured it could potentially be a good idea to make the new version fully compatible with pycontrol and all its modules. I haven't ordered boards yet so I wanted to share the designs here first in case any of the community members had thoughts for improvements or general suggestions/interest.

The main design approach for this board is to use the same breakout as the standard pycontrol boards but using a raw STM32H7 which also breaks out to a large array of header pins. The whole board would be powered off of a high voltage supply which would be stepped down by a buck converter to the standard 12 V used by pycontrol. The array of header pins could be interfaced with a variety of breakout boards for compatibility with different hardware e.g. Coulbourn Instruments, Lafayette Instruments, Med Associates, etc.

Top:

Bottom:

Coulbourn Breakout:

Lafayette Breakout:

I've attached Kicad files for all three boards here as well.

OSCARV2.zip
CoulbournStack.zip
LafayetteStack.zip

[ThomasAkam]

Hi @theonlydvr, this does look like an interesting and useful idea, it would be fantastic to have a pycontrol interface for 28V commercial operant hardware. A couple of questions:

• What is the rationale for using a raw STM32H7 soldered directly to the board, rather than a Pyboard D series connected using the WBUS connector on the underside which has lots of IO lines (as done on @alustig3's 12 port pyControl breakout board). I can see the cost advantage of using a raw microcontroller IC, but it can be useful to have the microcontroller connectorised so it can be replaced easily if if gets damaged, and using pyboards would save the work of having to program the IC with micropython (I have never done this so don't know how straightforward it is).
• Do you plan to have any mounting holes on the PCB so it can be securely mounted on seteps or in a case? Would it be compatible with the case you designed for the original OSCAR system which looks very nice.
• Could you post the schematics as PDFs? I have never used Kicad..

[theonlydvr]

I didn't know about the d-series boards so I will give those a deeper look now! I mainly chose the raw STM32 for cost reasons but I can see about making a Pyboard D series version because it would probably simplify development. I was also somewhat concerned about part availability since it seemed like there were issues with ordering Pyboards in the past but you probably have a better understanding of that concern.

I forgot about mounting holes... I did originally design this to be more similar to the layout for the current pycontrol boards but I can probably make a version that's laid out like OSCAR so it could have a nice box.

I've attached PDFs of the schematics now:
OSCARV2.pdf
CoulbournStack.pdf
LafayetteStack.pdf

[alustig3]

Very cool @theonlydvr, this is a great idea! If I understand correctly, you don't plan on running pyControl firmware on the microcontroller necessarily, but would like the flexibility/option to interface with existing pyControl devices as well as other hardware from Coulbourn Instruments, Lafayette Instruments, Med Associates.

Thank you for sharing, I definitely have interest in this and will be following along with your progress. Making adapters/interfaces to 28V hardware could be very useful to a lot of potential users that would want to use hardware that they already have. I know @amchagas has done some work on making adapters for Med Associates hardware (https://github.com/Sussex-Neuroscience/med-associates-bits/tree/master). It would be great if we all could work together to compile the relevant information of the pinouts for different hardware so adapters could be made.

some quick notes/suggestions for your OSCARV2 PCB:

• J1 and J5 have power pins going to the pin5 of the RJ45 connectors, I would avoid this and leave the pins unconnected or replace with DIOs, as having a POW connedtion deviates from the standard pinout where the 5th pin is unconnected or an extra DIO or DACs (like how you correctly added DACs to J8 and J9).
• It may be useful to route some UARTs and I2C busses to some of the ports if you can. The standard is to have SCL on pin1 (DIOA) and SDA on pin 4 (DIOB) and UART-TX on pin1 and UART-RX on pin4. Some of the documentation from my d-series breakout may be helpful to you. @ThomasAkam I suggest we also define a standard for potential hardware SPI pin locations. I suggest MISO-DIOA, MOSI-DIOB, SCK-DIOC.
• Personally I would prefer either USB-C or USB-B for the usb connection. Adding a TVS diode for ESD protection might be a nice touch as well.

As far as the MCU selection, if you would like it to be compatible with pyControl firmware, it would be best to use one of the STF7's that is also used in the d-series boards. Although in principle the pyControl firmware could be ported to a variety of micropython compatible MCUs, the use of the pyb module (https://github.com/orgs/pyControl/discussions/120) has kept us from deviating from the official pyboard/pyboard-d-series MCUs

[theonlydvr]

@alustig3 At the moment I don't plan on using the pyControl firmware but I could feasibly see myself using it in some capacity in the future and I think it would be good to design a system that would be compatible with it for other users. The ability to use pyControl compatible devices alongside other hardware is definitely the main priority.

I had some time to finish up a new version of the PCB that uses the d-series pyboard. Since the d-series has a lot fewer DIO lines than the prior microcontroller I was using, I had to share some lines between the RJ connectors and the 28 V stacking interface. I figured it would be best to maintain compatibility/layout with your prior design so I've essentially just split all of those lines out to the stacking connector (except for the left-most RJ connectors which are fully independent). This new version will also now fit nicely in a box like the original OSCAR design.

Let me know if you have any further feedback! Otherwise, I'll mockup a new stacking board and probably order a version soon. I've also attached design files in case they're useful.

OSCARV2.zip

[alustig3]

@theonlydvr, the only thing I worry about is pyboard-d-series availability, they are currently and have been out of stock for many months. The bare STM32F723 seems to be available. I don't have experience working directly with STM32 chips, so I'm not sure how difficult it is to get a bare chip up and running, but in principle if you could get the prebuilt micropython firmware (that includes the pyb module) onto the bare chip, then pyControl would be immediately compatible.

The only other feedback I have is maybe to change S1 and S2 to right angle tactile switches so they can be accessed/pressed from the the rear of the board where the USB and power connections are. The current design leaves then inaccessible if you were to have the stacking board on top and/or have the board inside of a case.

[theonlydvr]

Sounds good! It should be pretty easy to modify the design for the bare chip. I have some experience working with the chips themselves, only concern I might have (mostly because of my lack of experience) is whether the internal oscillators would be sufficient or if I'd need to add the external ones.

I will also adjust the switch placement.

[alustig3]

great! I'm excited to hear how it goes.

[theonlydvr]

I decided to go with an STM32F767 since they're available on JLCPCB and have enough DIO lines for both the backpack and the full RJ array. This chip does require external oscillators for the USB to work so I did have to add those as well. Let me know if you have any further recommendations!

OSCARV2.zip

[alustig3]

Very nice! The only other considerations I can think of is the shape. I'm not sure what your dimensional desires/constraints are, but I do slightly regret using the dual row 12-port connector for my board, because:

• I wasn't actually space constrained
• The part is 3-4X more expensive that using 12 individual RJ45 ports
• It is kind of annoying to plug/unplug cables if you are filling up both rows because the tab is on the bottom for the bottom row and cables from the top row get in the way.

These are super minor complaints, because it is very rare that I would actually need to plug/unplug cables, but thought I'd mention anyway. But if you are wanting to fit in a particularly sized case, the dual row connector might be perfect.

If you did move away from that dual row connector, you could potentially go wider and shorter, using a long single row of 12 ports in the front (or 13? 14? as it looks like from your schematic that you have a couple leftover GPIOs that you aren't using?), and then to compensate for the increased width, you could make the expansion board shorter by using dual row headers on the sides (i.e. each side would use a 2x14 header instead of the current 1x28).

I'm not sure what the right answer is, but may be something to think about. Maybe the expansion board has a lot of wasted space right now and you want to make it smaller, or maybe keeping it larger is a good idea to allow for more complex expansion boards in the future.

Thanks for sharing, and please keep us updated! It would be super cool if you could get F767Z micropython running on it and then we could work on porting the pyControl framework to it.