Raspberry HAT <-> Pyboard adapter

[marfis]

I'm working on a small interface PCB that allows to connect a raspberry HAT (40pin) to be connected to the pyboard.

The physical outline is such that a pyboard and a HAT can be mounted to the interface board, side by side (see

Screen Shot 2015-12-30 at 00.27.07.png (83.95 KiB) Viewed 10677 times

for the general idea. It uses more PCB space this way but it will allow access to the pyboard while the HAT is mounted. That should be convinient while developing.

Update: See https://github.com/hoihu/projects/tree/master/raspi-hat for latest schematic/layouts

Goal is to readout the ID EEPROM from the pyboard (will be connected to a separate I2C bus) and to interpret the data (e.g. dynamically reconfigure the GPIO port of the pyboard based on the data in the ID EEPROM).

Of course UART,SPI etc is also wired. I'll probably put a switch for the BOOT and RST pin on it too.

Anyone interested or has suggestions? I'm going to order some batches maybe by mid of January.

Martin

[dhylands]

If you can, it would be good to wire things up to just the X or Y half of the pyboard. Then the pyboard can use a shield on the other half.

The pyboard doesn't have any EEPROM, so are you planning on adding an EEPROM to your board?

Since the Pi only has one serial port, and that can be used as a console, I think it would be worthwhile to have some jumpers which allow the UART to be disconnected from the pyboard, and expose the UART signal from the RPi using something like the standard FTDI 6-pin header.

Having the option to populate an extra set of headers next to the pyboard would be useful. That gives easy access to all of the pyboard signals for prototyping.

I'm planning on using an Espruino Pico running MicroPython plugged into one of the USB ports on the Pi, but having extra options is always good.

I'd probably connect a few GPIOs up between the pyboard and the RPi. These could be used for signalling. The RPi doesn't have any ADCs so I'd try to leave the ADCs on the pyboard free.

Some of what I've suggested above will conflict with itself (looking at the pinout on the pyboard), but you'll need to decide which is most important, or perhaps allow jumpers so that you can wire things up the way that suits a particular project.

[marfis]

The pyboard doesn't have any EEPROM, so are you planning on adding an EEPROM to your board?

Well I was not precise - My intention is to readout the ID EEPROM of a HAT (it's part of the HAT spec) by one of the Pyboard's I2C buses. So the pyboard acts as master and the HAT's EEPROM as slave.

The ID EEPROM of a HAT contains information of how the raspi's GPIO's must be configured. It is normally readout at early boot time of the raspberry so that it can reconfigure the GPIO based on the HAT's EEPROM data. I liked that idea and maybe it can be reused for the pyboard as well.

I think it would be worthwhile to have some jumpers which allow the UART to be disconnected from the pyboard, and expose the UART signal from the RPi using something like the standard FTDI 6-pin header.

good point - will try to implement that.

Then the pyboard can use a shield on the other half.

yeah I was thinking this first as well, but I'd like to have access to the ID EEPROM and the normal I2C interface in parallel. Means 2 I2C buses (the HAT specifications explicitly recommends that, not sure if this is really required though..).

I'm planning on using an Espruino Pico running MicroPython plugged into one of the USB ports on the Pi

Nice. My goal was to use use existing (cheap) HW from the raspberry environement for the pyboard (I have them laying around everywhere at home...). So maybe a lot of more "shields" can be used togehter with the pyboards.

[dhylands]

So this shield is to allow an RPi Hat to be used with a pyboard?

I was thinking it was to allow a pyboard to be used as co-processor with the RPi.

So some of my earlier comments are probably not really valid. Let me ponder this some more.

[marfis]

So this shield is to allow an RPi Hat to be used with a pyboard?

Yes.

I was thinking it was to allow a pyboard to be used as co-processor with the RPi.

That makes sense to me - especially now where the Rpi2's DMA transfer to the SPI bus is not yet working/ported and hence the neopixel support a question mark.

Who knows if the raspberry communicty may include a uPy coprozessor as part of a next generation raspi to offload those GPIO/I2C/SPI work? After all "Pi" stands for Python!

[marfis]

almost ready to send for production:
https://github.com/hoihu/projects/tree/master/raspi-hat

it ended up with heaps of more stuff:
- selectable HAT/raspberry option (you can configure your pyboard to be a HAT or to access a HAT)
- RST/DFU switches
- UART jumpers / I2C access
- Neopixels
- EEPROM for HAT (just in case you want to get real with a raspi hat)
..

[dhylands]

When you use your board with an RPi connected to HAT-Conn, then you should probably not connect the 3.3v from JP1 to the 3.3v from the pyboard. When using JP1 with an RPi HAT, then the way you've got it wired makes sense.

I also noticed you don't have anything connected to Y12, X6, X7, X11, X12 and X18 thru X22 on the pyboard (and that you have unconnected GPIOs on the HAT-connector.

This looks like an interesting board.

[marfis]

should probably not connect the 3.3v from JP1 to the 3.3v from the pyboard

thanks for pointing that out. You're right. That would certainly caused some damage...

Even the other case with a HAT connected to the board wouldn't work I believe. The only pins that should be used for powering the board in either direction is VIn.

If both Vin of the raspi and the pyboard (5V) are fed from independant PSUs that may also call for trouble. Perhaps a safety diode in beteeen the 2 supplys makes sense. There is an example on the raspi hats specification site of such a circuit. https://github.com/raspberrypi/hats/blo ... gnguide.md at the end

[dhylands]

The pyboard already as a diode to prevent VIN from backpowering USB.

When attaching a HAT, you'd want to provide both 5v and 3.3v, but when connecting as a HAT, you wouldn't want to provide the 3.3v.

I forgot about the back-powering (which is allowed, but maybe not always desired). so it seems like jumpering both 3.3v and 5v would be prudent. Then you could have either voltage come from either source depending on how you decide to hook things up.

[marfis]

Right I see.

Your idea about jumpering 3v3 and 5v makes sense. Good to know that in case both pyboard and raspi are accidentally connected to (different) USB supplies there isn't any cross current flowing.

That doesn't apply to the external 5V pads that I have included and may be used in case there is more power needed. But then again with the jumpers you'll have the freedom to select whatever voltage source you like so thats ok.

I'll update the board files by end of this week. I'll let them produce at OSH park, haven't tries it up to now but I heard some good comments about their service.