猶記當初最早接觸帽子 HATs ，是想玩『計算模組』
Compute Module
The Compute Module is a Raspberry Pi in a more flexible form factor, intended for industrial application.
The compute module contains the guts of a Raspberry Pi (the BCM2835 processor and 512Mbyte of RAM) as well as a 4Gbyte eMMC Flash device (which is the equivalent of the SD card in the Pi). This is all integrated on to a small 67.6x30mm board which fits into a standard DDR2 SODIMM connector (the same type of connector as used for laptop memory). The Flash memory is connected directly to the processor on the board, but the remaining processor interfaces are available to the user via the connector pins. You get the full flexibility of the BCM2835 SoC (which means that many more GPIOs and interfaces are available as compared to the Raspberry Pi), and designing the module into a custom system should be relatively straightforward as we’ve put all the tricky bits onto the module itself.
The compute module is available for purchase in single units, or in batches of hundreds or thousands. To get started designing a PCB to use the module, we provide an open-source breakout board with a single module in an affordable development kit.
上的『立體視覺』︰
Real-time depth perception with the Compute Module
Liz: We’ve got a number of good friends at Argon Design, a tech consultancy in Cambridge. (James Adams, our Director of Hardware, used to work there; as did my friend from the time of Noah, @eyebrowsofpower; the disgustingly clever Peter de Rivaz, who wrote Penguins Puzzle, is an Argon employee; and Steve Barlow, who heads Argon up, used to run AlphaMosaic, which became Broadcom’s Cambridge arm, and employed several of the people who work at Pi Towers back in the day.)
We gave the Argon team a Compute Module to play with this summer, and they set David Barker, one of their interns, to work with it. Here’s what he came up with: thanks David, and thanks Argon!
This summer I spent 11 weeks interning at a local tech company called Argon Design, working with the new Raspberry Pi Compute Module. “Local” in this case means Cambridge, UK, where I am currently studying for a mathematics degree. I found the experience extremely valuable and a lot of fun, and I have learnt a great deal about the hardware side of the Raspberry Pi. And here I would like to share a bit of what I did.
My assignment was to develop an example of real-time video processing on the Raspberry Pi. Argon know a lot about the Pi and its capabilities and are experts in real-time video processing, and we wanted to create something which would demonstrate both. The problem we settled on was depth perception using the two cameras on the Compute Module. The CTO, Steve Barlow, who has a good knowledge of stereo depth algorithms gave me a Python implementation of a suitable one.
The algorithm we used is a variant of one which is widely used in video compression. The basic idea is to divide each frame into small blocks and to find the best match with blocks from other frames – this tells us how far the block has moved between the two images. The video version is designed to detect motion, so it tries to match against the previous few frames. Meanwhile, the depth perception version tries to match the left and right camera images against each other, allowing it to measure the parallax between the two images.
所以閱讀了
B+ ADD-ON BOARDS AND HATs
NOTE All references to GPIO numbers within this document are referring to the BCM2835 GPIOs (NOT pin numbers on the Pi GPIO header).
Introduction
The Raspberry Pi B+ has been designed specifically with add-on boards in mind. For B+ we are introducing ‘HATs’ (Hardware Attached on Top). A HAT is an add-on board for B+ that conforms to the HAT specifications. HATs are not backward compatible with models A and B.
There are obviously a lot of add-on boards designed for the original model A and B boards (which interface to the original 26 way GPIO header). The first 26 pins of the B+ GPIO header are identical to those of the original models, so most existing boards will still work.
As well as now being a 40W GPIO header (originals on B and A are 26W) the biggest change with B+ add-on boards versus older boards designed for models A and B is that the B+’s header has 2 special pins (ID_SC and ID_SD) that are reserved exclusively for attaching an ‘ID EEPROM’. The ID EEPROM contains data that identifies the board, tells the B+ how the GPIOs need to be set up and what hardware is on the board. This allows the add-on board to be automatically identified and set up by the Pi software at boot time including loading all the necessary drivers.
While we cannot force anyone to follow our minimum requirements or HAT specification, doing so will make users lives easier, safer, and will make us more likely to recommend a product. Likewise if one of the minimum requirements is ignored we are unlikely to look on a product very favourably.
So why are we bothering with all this? Basically we want to ensure consistency and compatibility with future add-on boards, and to allow a much better end-user experience, especially for the less technically aware users.
Finally if you have any questions please head over to the forums to ask them.
New add-on boards basic requirements
If you are designing a new add-on board that takes advantage of the pins on the B+ GPIO header other than the original 26 then you must follow the basic requirements:
- The ID_SC and ID_SD pins must only be used for attaching a compatible ID EEPROM. Do not use ID_SC and ID_SD pins for anything except connecting an ID EEPROM, if unused these pins must be left unconnected
- If back-powering via the 5V GPIO header pins you must make sure that it is safe to do so even if the Pi 5V supply is also connected. Adding an ideal ‘safety’ diode identical to the one on B+ as per the relevant section of the design guide is the recommended way to do this.
- The board must protect against old firmware accidentally driving GPIO6,14,16 at boot time if any of those pins are also driven by the board itself.
Note that for new designs that only use the original 26 way GPIO header pins it is still recommended to follow requirement 2. if the board supports back-powering a Pi.
B+ HAT requirements
A board can only be called a HAT if:
- It conforms to the basic add-on board requirements
- It has a valid ID EEPROM (including vendor info, GPIO map and valid device tree information).
- It has a full size 40W GPIO connector.
- It follows the HAT mechanical specification
- It uses a GPIO connector that spaces the HAT between 10mm and 12mm from the Pi (i.e. uses spacers between 10mm and 12mm).
- If back powering via the GPIO connector the HAT must be able to supply a minimum of 1.3A continuously to the Pi (but ability to supply 2A continuously recommended).
Of course users are free to put an ID EEPROM on boards that don’t otherwise conform to the remainder of the specifications – in fact we strongly encourage this; we just want things called HATs to be a known and well-specified entity to make life easier for customers, particularly the less technical ones.
Design Resources
Before designing any new add-on board (HAT compliant or not) please read the design guide carefully.
For what to flash into the ID EEPROM see the ID EEPROM data format spec.
There are tools and documentation on how to flash ID EEPROMs here.
自然也知道
Preliminary B+ HAT (Hardware Attached on Top) docs/specs
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]
……
Any news on the Kernel development for HAT support? Auto-loading the right kernel modules would really help users and this should be possible with the data from the HAT EEPROM.
Best regards
Daniel
……
Excellent work so far, but I am eager to start testing. Does anyone have a timeline for when the next/final step will come?
……
Device tree data can be accessed through /proc. I don’t know if there’s currently a way to read the vendor data and the other atoms, but there should be eventually.
Things are a bit busy with Astro-Pi and all that, so I think pulling a timeline out of nowhere would just disappoint people.
───
議論紛紛的觀點。祇不過是奇怪天下真有『一勞永逸』之事耶？？假使只能 Case by Case 豈非玩家的『天堂』乎！！