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

[James Adams]

In short with a 128 bit number and good hashing algorithm the probability of collision is miniscule.

Here's a fun web generator for the interested: http://www.guidgenerator.com/

Wikipedia: http://en.wikipedia.org/wiki/Globally_Unique_Identifier

[SteveSpencer]

In terms of uniqueness, it isn't so much the guid that is the problem, as the other ids.
In the USB world, vendors are assigned an ID, and then there is a product id "grouped" by vendor.

I guess in the wild it won't really matter, since the idea is that the configuration is done early on in the boot cycle, so the product ID is less useful than the blob in the EEPROM.

Is the idea that the HAT (or at least the presence/absence) will be visible via some sort of sysfs interface, or enumerable in some other way? I can see that being able to read the guid, and other IDs from the HAT would be useful in some situations.

[James Adams]

The idea of the devicetree blob in the EEPROM is then the board is 'standalone' - i.e. we don't have to add understanding of each and every board to the software (hence no realy requirement for a VID/PID in the traditional sense).

Yes we did consider unique vendor IDs, however that means someone has to allocate them and police the allocation. And then software has to have intelligence to understand the VIDs. And really what would we want VIDs for (considering we have EEPROM DT blob so not for drivers)? To match against the vendor name...

So the vendor string is really the VID in a sense - as these should be unique.

EDIT: yes some sort of sysfs interface will be created so userland software can get details of the attached HAT.

[Greg Erskine]

I think the camera flex slot should extend to the edge of the board. This has two benefits.
1. It allows installing the HAT without unplugging the camera cable
2. The "slot" will become part of the PCB outline therefore reducing cost by eliminating one process during the PCB manufacture. For small run PCBs and hobbyist, the slot cost may be an issue.

What about adding the run port to the HAT spec? ATM it the only port that is not assessable under the existing HAT spec.

regards

[AndrewS]

I think the camera flex slot should extend to the edge of the board.

Wouldn't that also reduce the mechanical strength of the HATs though, and possibly cause extra flexing stress in the middle of the HAT?
(I don't really know, I'm not a PCB designer!)

[Greg Erskine]

I think the camera flex slot should extend to the edge of the board.

Wouldn't that also reduce the mechanical strength of the HATs though, and possibly cause extra flexing stress in the middle of the HAT?
(I don't really know, I'm not a PCB designer!)

Yes and yes, but these PCBs are small and there is not much leverage. I can't imagine it would be a problem and thicker PCBs are available at a small incremental cost. A slot will also look nicer. I do get PCBs made and slots are not part of the generic process. As soon as you deviate from the standard process costs increase. Anyway, I thought I'd throw it out there.

[AndrewS]

I do get PCBs made and slots are not part of the generic process.

Lots of drill-holes, close together?

[James Adams]

OK firstly thanks to everyone for comments / suggestions etc. I think it has been a useful discussion.

The docs got a major update today to be more explicit on what and what isn't a HAT and various other tweaks and improvements.

We're trying to make HATs a spcifically identifiable and easy-to-use (for end users) thing. If you follow the HAT spec is up to you- we're not forcing anyone and if you don't no problem but you can't call your board a HAT.

Please have a read over the weekend - we think we're basically there with the spec now, we'll be freezing this at the end of Monday 28/7 (Cambridge UK time).

Thanks again.

[jackokring]

Looks good, just in the last FAQ, should quantity be quality? The rest is very readable.

[panik]

@James Adams; Can I ask that you take a second look at the rounding of the corners of the display flex cutout in the hat-board-mechanical.pdf?

The text says R=2mm, but the drawing doesn't reflect that. The corners in the drawing seem too small. They look more like the radius of the corners of the camera slot (where R=1mm).

Please compare the drawing in the hat-board-mechanical.pdf with @Flyfish Technologies' CAD template here: http://www.raspberrypi.org/forums/viewt ... 00&t=82618

[jdb]

@James Adams; Can I ask that you take a second look at the rounding of the corners of the display flex cutout in the hat-board-mechanical.pdf?

The text says R=2mm, but the drawing doesn't reflect that. The corners in the drawing seem too small. They look more like the radius of the corners of the camera slot (where R=1mm).

Please compare the drawing in the hat-board-mechanical.pdf with @Flyfish Technologies' CAD template here: http://www.raspberrypi.org/forums/viewt ... 00&t=82618

The cutouts are optional - in fact the HAT spec does not preclude additional cutouts/slots/slats/doilies but rather the ones on the example drawing are recommended placements to ensure the camera/display flexes are not overstretched.

Common sense should prevail if/when cutouts are integrated into a design: rounded corners are required simply to prevent "sharp edges". Either 1mm or 2mm radius bends would satisfy that requirement.

[James Adams]

@James Adams; Can I ask that you take a second look at the rounding of the corners of the display flex cutout in the hat-board-mechanical.pdf?

The text says R=2mm, but the drawing doesn't reflect that. The corners in the drawing seem too small. They look more like the radius of the corners of the camera slot (where R=1mm).

You are indeed correct - the board outline is designed for routing using a 2mm route bit (very common size) so yes the radius is 1mm not 2mm.

It's on the fix list.

[mikronauts]

Unfortunately most fabs charge more for PCB's with rounded corners and internal cutouts.

I thought perhaps y'all rounded the corners to fit an Altoids tin!

@James Adams; Can I ask that you take a second look at the rounding of the corners of the display flex cutout in the hat-board-mechanical.pdf?

The text says R=2mm, but the drawing doesn't reflect that. The corners in the drawing seem too small. They look more like the radius of the corners of the camera slot (where R=1mm).

Please compare the drawing in the hat-board-mechanical.pdf with @Flyfish Technologies' CAD template here: http://www.raspberrypi.org/forums/viewt ... 00&t=82618

The cutouts are optional - in fact the HAT spec does not preclude additional cutouts/slots/slats/doilies but rather the ones on the example drawing are recommended placements to ensure the camera/display flexes are not overstretched.

Common sense should prevail if/when cutouts are integrated into a design: rounded corners are required simply to prevent "sharp edges". Either 1mm or 2mm radius bends would satisfy that requirement.

[tubular]

Hi James

I've been working on a solution to the "stack" problem - photo at this link
https://www.dropbox.com/s/myyuq34h4ew1q ... .07.32.jpg

It works by using the new extra 9 gpio as a "stack" - plug in boards take one or more pins from the stack and the rest shuffle down in numerical gpio order. This way every board takes the gpio it needs from the bottom of the stack.

There is also a similar arrangement for the eeprom addressing that rotates a bit mask past the eeprom address pins. This means the first board plugged in has an eeprom address 0, the next has address 1, then address 3, and finally (or thereafter) address 7.

The original 26 pins are carried through as normal, so legacy boards can be attached. The gpio stack is useful for SPI chip enables.

It be good to discuss the merit and problems with this approach. We have our Melbourne Pi Jam tomorrow and I look forward to getting feedback from those guys too

regards
Lachlan

[Paul Webster]

Tiny spelling correction - two instances of "unlikeley" should be "unlikely".

[James Adams]

It works by using the new extra 9 gpio as a "stack" - plug in boards take one or more pins from the stack and the rest shuffle down in numerical gpio order. This way every board takes the gpio it needs from the bottom of the stack.

Neat idea however it does rely on routing all the GPIOs across the board to another connector every time (which takes up routing resources and adds net capacitance and long stubs), plus I don't see how each board knows exactly which [of the extra] BCM2835 GPIO(s) it uses. Finally as the first 26 pins are run through unchanged you'll still have the same potential issues that made us think stacking in the end was a bad idea for HATs - namely we couldn't think of a good way (apart from mandating extra hardware) to make them idiot proof - i.e. two stacked boards driving the same pin. The idea with HATs is to make them simple for less technical users (and technical users wanting an easy life) and a 'known quantity'.

[tubular]

The eeproms contain the information about the gpio used. From the Pi point of view, it can determine what (extended) gpio routes to which board, up to 4 deep.

Capacitance wise there is another way to do it without long routes and alternating direction. However I'll duck into work and get some capacitance measurements on the stack as-is.

[mahjongg]

Neat idea however it does rely on routing all the GPIOs across the board to another connector every time (which takes up routing resources and adds net capacitance and long stubs), plus I don't see how each board knows exactly which [of the extra] BCM2835 GPIO(s) it uses. Finally as the first 26 pins are run through unchanged you'll still have the same potential issues that made us think stacking in the end was a bad idea for HATs - namely we couldn't think of a good way (apart from mandating extra hardware) to make them idiot proof - i.e. two stacked boards driving the same pin. The idea with HATs is to make them simple for less technical users (and technical users wanting an easy life) and a 'known quantity'.

It would be better to put a second 40 pin connector directly next to the first one, but this also causes all kinds of problems.
simply paralleling every signal seems the only universal solution. using headers with long square posts, something like samtek ssq headers with a standardized but long square posts, so one can be stacked on another.

http://www.farnell.com/datasheets/1680445.pdf

[James Adams]

paralleling every signal seems the only universal solution. using headers with long pins,

Indeed, and we had/have a connector solution to do this that works well- but it's a solution that we couldn't/can't make bullet-proof electically by simple means hence no (official) support for stacking in the HAT spec.

[tubular]

we couldn't/can't make bullet-proof electically by simple means

What were the main issues you struck, James? Too much capacitance caused by more boards in the stack? Electrical loading? Other aspects?

What sort of max data rate can the SPI interface run to currently?

[James Adams]

What were the main issues you struck, James?

Main issue was how to completely safely stack 'incompatible' boards - i.e. boards that want to drive the same GPIO. While it is technically possible to solve this it adds quite a bit of complexity and extra components required on boards. It is also not really solvable for existing 26W boards. We also feel that most people don't want or need stacking so rather not create a complex spec with high 'cost' (in terms of engineering resource and components). Also higher complexity leads to higher probability of people not quite following the spec in some fashion even if not deliberately, again goes against the misson of having something smiple for end users.

KISS rules here.

[mahjongg]

yeah, if you have multiple stacked boards, inevitably the will try to use the same resources, SPI, UART etc. even it was only general purpose GPIO's then it would need a whole array of jumpers to resolve any conflicts, that would become very unwieldy.

I suppose one of the first HAT would be one that is gertduino like, perhaps replicating the arduino headers, or doesn't it fit?
Arduino's are 68x53 mm, but the part that has headers is smaller than 68mm, maybe 50mm.

Only a bus system would be suitable for stacking!
So why not use a sub-set of signals, like only I2C and power and perhaps one "interrupt input" for a more limited "top-hat" system, on top of the normal non stackable hat. Of course such a top-hat board must also carry the EEPROM signals, so it can still be added to the device tree.

Add a new small header with these signals to the hat spec, for top-hats.

[mahjongg]

I think the camera flex slot should extend to the edge of the board.

Wouldn't that also reduce the mechanical strength of the HATs though, and possibly cause extra flexing stress in the middle of the HAT?
(I don't really know, I'm not a PCB designer!)

Actually I am a PCB designer, and IMHO it would be wise to extend the slit to the edge, if only so you can mount the camera flex cable before needing to mount the hat, that would be some much more comfortable than needing to mount/unmount the camera each time, let alone imagine how fiddle it would become if you had to do that. a 1.6mm thick board is plenty of rigid enough that the slit doesn't matter!
it would also be much cheaper
make the slit at least 3mm wide (larger than the standard width for PCB milling cutters).

[tubular]

There's no doubt the HAT spec will be a big step forward. Its good to understand some of the logic behind what you've already looked at, so thanks for that.

I realise its important to maintain compatibility with existing 26 way boards. What I'm proposing is just to use the new 9 GPIO pins in a 'stack', rather than parallel formation. A single "enable / strobe" from this stack of 9 is super useful because, combined with the original 26way, it can give you a new SPI peripheral, or redirect serial (both TX and RX muxed, ie an additional COM port).

Taken alone, yes the 'stack' complicates things, but since you also have an eeprom on each board, with its address staggered, you can completely remove the complication from the end user. From the pi point of view you know what of the (new) GPIO belong to what board, and what their use it. The end user can achieve the elusive dream of stacked boards that don't clash.

Yes the designer has some basic rules to follow with regard to implementing the stack, however the components involved are essentially what you're already proposing.

There are other physical forms of connectors that keep it simpler - I'll post some examples tomorrow.

regards
Lachlan

[mahjongg]

Taken alone, yes the 'stack' complicates things, but since you also have an eeprom on each board, with its address staggered, you can completely remove the complication from the end user. From the pi point of view you know what of the (new) GPIO belong to what board, and what their use it. The end user can achieve the elusive dream of stacked boards that don't clash.

that does not resolve hardware clashes caused by using boards that try to use the same GPIO's! so no you can not "completely remove the complication from the end user." that way, without reverting to massive jumper configuration, or adding a smart "GPIO SWAPPER DEVICE".

thats why I say that only a bus system supports stacking/paralleling.