James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Preliminary B+ HAT (Hardware Attached on Top) docs/specs

Mon Jul 21, 2014 11:00 am

Preliminary docs are here on Github: https://github.com/raspberrypi/hats

The docs are still changing. We want to lock down the spec by the end of the week. Sensible comments welcome :)

Note we are now working on the software to create and flash the HAT EEPROM, hopefully complete by the end of the week also.

[EDIT - update subject to be more descriptive]
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
gordon@drogon.net
Posts: 1961
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Preliminary docs are up

Mon Jul 21, 2014 11:24 am

Looks good so-far, but am I right in thinking that if I plug a "legacy" (26-pin board, or any board without an ID eeprom) on the Pi then the behaviour of the pins will be as before - I'm mostly thinking about the serial pins here..

Ta,

-Gordon
--
Gordons projects: https://projects.drogon.net/

Gswg
Posts: 57
Joined: Wed Oct 16, 2013 10:30 am
Location: Swindon
Contact: Website

Re: Preliminary docs are up

Mon Jul 21, 2014 12:22 pm

Thanks James, this is very useful.

Is there recommendation on the part numbers to use for "stackable" connectors please?

It would also be useful to have any defined PCB face2face distances etc. I am assuming (maybe incorrectly) that any PCB which contains components > 11mm in height will, by default, be non-stackable?

Gordon, I plugged in our 26way Pi-DAC card into the B+ and the serial lines worked as expected.

Best regards,

Gordon@iqaudio.com

James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Re: Preliminary docs are up

Mon Jul 21, 2014 12:45 pm

The current firmware hasn't moved to the 'new world' yet - but it is very nearly there.

Basically we're moving to doing things 'the right way' using device tree: http://www.devicetree.org/ and a thing a bit like it called gpioman which sets up GPIOs that are used exclusively used by the GPU (e.g. power LED, but also clocks).

So on a B+ you will need to enable hardware using this method (on HATs with EEPROM the EEPROM contains a device tree fragment for the hardware on the board and so Linux will set it all up & load drivers). Otherwise prviding a DT blob to drop onto the /boot partition will do the same job.

For legacy 26 pin GPIO support there will be a config.txt parameter (and raspiconfig menu entry) that will force a default device tree that sets things up in legacy mode (UART and I2C support). HOWEVER on a B+ the EEPROM will still be probed if this legacy option is set, and if detected it will fall back to a safe mode (all pins inputs with pulls) to stop users accidentally setting this option but having a B+ HAT attached.
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
PeterO
Posts: 3616
Joined: Sun Jul 22, 2012 4:14 pm

Re: Preliminary docs are up

Mon Jul 21, 2014 12:59 pm

A couple of comments from a first read through..

I think it would be a good idea for there to be a statement early on that "input" and "output" refer to the view from the PI and that view then needs to be used consistently. Currently there are places where both views are used.

The case of a non-stackable board on top of a stackable board does not seem to be covered. Is it allowed ? If so then the non-stacking board's assumptions on having the default pin states may be wrong.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Re: Preliminary docs are up

Mon Jul 21, 2014 2:30 pm

TBH we've been on the fence over whether the whole stacking boards thing is a good idea due to the added complexity - and as PeterO and Gswg have pointed out there are still holes in the spec (non-stacker on stacker, and we'll need to spec connectors and board spacing).

So after some more internal discussion we've decided to drop this as a supported feature (also we're not sure how often it would actually get used, and if, given the complexity, it would actually be implemented correctly all the time even if we could resolve the remaining issues).

Nothing stops people 'manually' configuring and using unused pins if they know what they are doing.
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
PeterO
Posts: 3616
Joined: Sun Jul 22, 2012 4:14 pm

Re: Preliminary docs are up

Mon Jul 21, 2014 3:15 pm

James Adams wrote:So after some more internal discussion we've decided to drop this as a supported feature (also we're not sure how often it would actually get used, and if, given the complexity, it would actually be implemented correctly all the time even if we could resolve the remaining issues).
That is disappointing to hear. It shouldn't be impossible, after all there are examples of self configuring busses in other machine architectures... Hands up who can remember the last time they had to set IO addressed and Interrupt lines on a PC card ?
Nothing stops people 'manually' configuring and using unused pins if they know what they are doing.
I suppose the issue is to find the correct(ish) balance between flexibility and complexity of implementation. Maybe by imposing some constraints on flexibility the implementation could be made manageable ?

It may only be the hard-core interface builders that would want to stack boards, but with the availability of the extra GPIO pins there may be more use cases which put a new 40 pin board on first and an older 26 pin board stacked on top, who knows ????

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Re: Preliminary docs are up

Mon Jul 21, 2014 3:30 pm

Yes it is a little disappointing - but it was getting complex (we were already thiking this but decided to throw it out there initially anyway). Yes in the past people had to set jumpers for ISA IRQs and whatnot on older hardware, but it was always a source of confusion for the not-too-technical.

It is exactly those people we're trying to make life easier for - so complicating the spec for a feature that may not be often used (and may make implementation more difficult to get right) in the end felt like a bad idea.

Stacking a 26W board on a 40W one would not have worked in our ideal world anyway as there was no way for the B+ to 'see' the 26W board (no EEPROM) so you would still have to set it up manually and know what you were doing.

Nothing stopping people stacking boards on top it is just not officially supported (by officially I mean you need to know what you are doing - and do it at your own risk - which is basically the deal for Pi A and B anyway so nothing has been 'lost').
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
mikronauts
Posts: 2621
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Preliminary docs are up

Mon Jul 21, 2014 3:32 pm

C'est la vie.

A bit disappointed, but it won't stop me from making '+' boards :)

I tried to view the mechanical spec pdf from the link in the first post of this thread, but it was corrupted. Could it be posted to this thread?
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Re: Preliminary docs are up

Mon Jul 21, 2014 3:40 pm

I tried to view the mechanical spec pdf from the link in the first post of this thread, but it was corrupted. Could it be posted to this thread?
Did you clone the Git repository? I don't think you can view directly via Github.
James Adams
Raspberry Pi - COO & Hardware Lead

hippy
Posts: 2180
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Preliminary docs are up

Mon Jul 21, 2014 3:43 pm

James Adams wrote:So after some more internal discussion we've decided to drop this as a supported feature ...
It feel it would be worth delaying that decision until after a more public discussion on the issue.

If people are going to produce stackable boards there is little which can be done to prevent that, so IMO better to accept that and at leas thave some de facto standard to comply with rather than the mess which is likely to arise if everyone goes their own way.

James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Re: Preliminary docs are up

Mon Jul 21, 2014 4:00 pm

It feel it would be worth delaying that decision until after a more public discussion on the issue.
If we wanted to keep the stacking we would have to mandate an ID EEPROM for all B+ HATs, and then still have to spread the word that you could not stack 26W boards on top - so there would still be a 'manual setup' setp. It is easier to spread the message that stacking boards is not (officially) supported and if you do you do it at your own risk.

And again, it complicates the spec for a minority use case.

So currently stackable is still out (but we reserve the right to change our minds in the nex day or so...!).
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
mikronauts
Posts: 2621
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Preliminary docs are up

Mon Jul 21, 2014 4:31 pm

Time for a Homer moment.... "DUH!"

That worked, thanks.

Now I'll go and get more coffee, as I obviously need it..
James Adams wrote:
I tried to view the mechanical spec pdf from the link in the first post of this thread, but it was corrupted. Could it be posted to this thread?
Did you clone the Git repository? I don't think you can view directly via Github.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

bbodin
Posts: 70
Joined: Sat Jun 28, 2014 3:23 pm

Re: Preliminary docs are up

Mon Jul 21, 2014 5:21 pm

Mandating an ID EEPROM on all stackable boards doesn't resolve the issue where more than one board use the same pin for output to the B+. It would also require all boards to use output drivers with current limiting and indefinite short-circuit protection.

The GPIO port has no physical layer for protection against conflicts. Until there is a well thought-out architecture for using the GPIO port as a bus for stackable boards, dropping the official support for these boards is probably a good idea. It potentially avoids finger-pointing and legal issues down the line.
Binh Bui

rotwang
Posts: 221
Joined: Sat Dec 07, 2013 1:12 pm

Re: Preliminary docs are up

Mon Jul 21, 2014 6:42 pm

Just recap for me, is device tree support (which would be a god-send for the compute module) coming, coming real-soon-now(tm), or dead in the water.

User avatar
gordon@drogon.net
Posts: 1961
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Preliminary docs are up

Mon Jul 21, 2014 6:46 pm

rotwang wrote:Just recap for me, is device tree support (which would be a god-send for the compute module) coming, coming real-soon-now(tm), or dead in the water.
As I see it, the CM isn't "general purpose" - it will be built into specific applications with a specific set of drivers compiled into the kernel for that application (and no more - or at least that's the way it would be were I designing it into something). I don't see that having an ID system for the CM would give it anything... But I could be wrong!

-Gordon
--
Gordons projects: https://projects.drogon.net/

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4632
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Preliminary docs are up

Mon Jul 21, 2014 6:50 pm

rotwang wrote:Just recap for me, is device tree support (which would be a god-send for the compute module) coming, coming real-soon-now(tm), or dead in the water.
To some extent, it's already in the firmware. https://github.com/raspberrypi/firmware ... 9e1b1a1eb6
Dom uploaded this dt-blob.bin in another thread:
https://dl.dropboxusercontent.com/u/366 ... t-blob.bin
You can convert it to a dts file, modify it, convert it back to a dtb file and save it under /boot/dt-blob.bin and it will be used to configure the pins automatically, for example.

User avatar
mikronauts
Posts: 2621
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Preliminary docs are up

Mon Jul 21, 2014 7:17 pm

If the i2c bus was scanned for all eight eeprom addresses, up to eight add-ons could be supported at once - each board would need to be able to strap its eeprom's address.

If there was a need for multi-function boards, each eeprom address could allow for say eight 2k blocks in each eeprom, which would then support 8 boards with up to 8 devices each - which I'd suggest is more than plenty.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: Preliminary docs are up

Mon Jul 21, 2014 7:27 pm

How much do we think this board identity eprom circuitry is going to cost to add in?

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1187
Joined: Sat Sep 10, 2011 11:43 am

Re: Preliminary docs are up

Mon Jul 21, 2014 7:33 pm

Just to be clear...

gpioman support and the introduction of the ability at add a dt-blob.bin is not the same as the kernel device tree implementation...

We've recently added gpioman support into the firmware, this takes a dt-blob.bin file from the first partition (/boot) and uses it to configure the initial pin settings (the alternate settings) and the pin configuration.

This way if you are creating a new compute module board you can use this file to move the camera gpio pins around or the LAN_RESET pin or the 25MHz clock output (or to output a special second GPCLK output and configure the clocks for it). Although this file is a dtb file it is not a full device tree implementation for the linux kernel.

The full implementation is coming and we are working on it (mostly by rewriting significant numbers of drivers to enable us to upstream our drivers!) We hope to get this working in the long term but it's still some months away

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

User avatar
jackokring
Posts: 815
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Preliminary docs are up

Mon Jul 21, 2014 8:28 pm

The title is vague, at least from the new posts click link, and the content is/was not apparent. But having read, I see. For most simple people stacking is out, which is good. Being able to override the EEPROM with a stacked user choice is essential although rare, otherwise why buy some boards? Or maybe the EEPROM should be socketed or "power/data offable..."

Input and output have always been defined from the board doing the local or mastering of the IO not the one connected to it. This includes the pi as a slave to the hat master. I think this is a good one on the fizz bang not effect.

If the ID wires are considered for just ID use, then maybe a mini 2 by 6 aux IO for small boards will arise. How many 26-way boards will cover the ID pins?

EDIT: http://skpang.co.uk/blog/archives/575 and do the older boards now have a need to not use I2C address 0, on the bus before the switch around? And there is the obvious omission of a 3V3 within the new pins.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Re: Preliminary B+ HATs docs/specs are here

Tue Jul 22, 2014 9:12 am

EDIT: http://skpang.co.uk/blog/archives/575 and do the older boards now have a need to not use I2C address 0, on the bus before the switch around? And there is the obvious omission of a 3V3 within the new pins.
Not quite sure I understand the question. I2C0 (for rev2 B and now B+, it was I2C1 on rev1 B) is the I2C reserved for GPU use. It has never been recommended or supported to use the GPU's I2C on older models. B+ HATs should not use I2C0. Future things attached to the GPU may make even more use of it (for instance camera already does, new display does too for both control and for touch interface).

We can't stop people using it if they really want to, but we would actively recommend people avoid using boards that did this as they don't follow the spec.
James Adams
Raspberry Pi - COO & Hardware Lead

summers
Posts: 63
Joined: Mon Jan 30, 2012 4:27 pm

Re: Preliminary B+ HATs docs/specs are here

Tue Jul 22, 2014 10:28 am

This is sounding very like the beaglebone and beaglebone black set up with capes.

How things are evolving with the beaglebone is maybe instructive, especially as capes have been part of the landscape for so long.

Now in the past, the beagle bone has used a cape manager, that has handled bringing up the capes. However with the evolution of the device tree, the approach for how to configure the hardware has changed. The problem that you have is that the add on board (capes in beagle bone) are hardware - and effecitvly end up being defined as part of the whole hardware system. In device tree land this is a bit of a mare - it pushes towards havig a different device tree blob for each configuration, e.g. when you change an add on board, you need to change the device tree blob. This is a big hassle.

Now the way the kernel developers see things going, is a device tree with many add ons defined in the tree - but not enabled as default. Now the beagle bone boots via u-boot; and u-boot has the ability to modify the device tree after loading, but before boot. So what is imagined is enabling add on boards in u-boot, before booting to linux.

All this area is currently very active at the moment - its an area of both u-boot and the kernel, that is rapidly evolving. The cape manager approach is having a harder time getting into the mainline kernel - its a less happy fit.

Now fast forward to the RPi B+, it doesn't boot via u-boot, but via a GPU blob. Now if it goes the same way as having add on boards defined in the device tree - how will that be managed? E.g. will you be able to modify the device tree before booting into linux? Does the GPU blob have that functionality? Or is the RPi going in the cpae manager direction, which means a certain amount of forking from the mainline kernel?

James Adams
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 94
Joined: Wed Mar 19, 2014 2:58 pm
Location: Cambridge

Re: Preliminary B+ HATs docs/specs are here

Tue Jul 22, 2014 10:33 am

On BCM2835 (Pi SoC) the GPU boots first, then brings up the ARM and boots the Linux kernel so you kind of have a boot manager right there...

The ID EEPROM (read by the GPU) contains a device tree 'fragment' which is merged (by the GPU) into the main board device tree before being handed to the Linux kernel when it is loaded and control passed to the ARM.
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
FLYFISH TECHNOLOGIES
Posts: 1750
Joined: Thu Oct 03, 2013 7:48 am
Location: Ljubljana, Slovenia
Contact: Website

Re: Preliminary B+ HATs docs/specs are here

Tue Jul 22, 2014 12:04 pm

Hi,

I haven't noticed information about the ID I2C bus speed (alias the speed this ID EEPROM must support).

Recommended CAT24C32 supports 100k, 400k and 1M Hz, but I'm wondering if another EEPROM supporting only slower bus can also be used.

Additionally, information if clock stretching is supported would also be valuable.


Thanks & Best wishes, Ivan Zilic.
Running out of GPIO pins and/or need to read analog values?
Solution: http://www.flyfish-tech.com/FF32

Return to “B+ addons”

Who is online

Users browsing this forum: No registered users and 3 guests