tubular
Posts: 9
Joined: Wed Jul 23, 2014 9:44 am

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

Sat Jul 26, 2014 10:27 am

Sorry what I mean by "can" is that it is _able_ to be solved in the software domain (GPIO mapping). However the stack does separate out the GPIO on a board by board basis

By way of example say you have an SPI ADC (requires 1 chip enable, + the SPI already on the 26way connector), and a stepper motor driver (that needs 3 gpio for enable, step, direction).

The SPI ADC is first in the stack, its "chip enable" takes GPIO5, and the remaining 8 GPIO shuffle down the stack while maintaining formation, so GPIO6 connects to the "new GPIO5" on the main male header ready to connect to the next board in the stack.

The stepper driver is next in the stack. It takes 3 GPIO off the bottom - which map to GPIO6, 12, 13 because of the shuffling action of the ADC board.

Each board in the stack takes the GPIO it needs from the bottom of the stack, and the rest shuffle down accordingly. How much they shuffle down depends on how many GPIO each board needs.

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 10490
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

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

Sat Jul 26, 2014 11:24 am

There is no practical mechanical way to do the "shuffling down". The stacked header solution only supports simply connecting through every pin.

tubular
Posts: 9
Joined: Wed Jul 23, 2014 9:44 am

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

Sat Jul 26, 2014 11:38 am

Let me get some mock-ups together of how to do it

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1758
Joined: Thu Jul 11, 2013 2:37 pm

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

Sat Jul 26, 2014 12:26 pm

This is precisely the reason why stackable HATs weren't baked into the specification. Even between two PCB designers there's confusion about implementation detail - a problem that would only be compounded by the HAT spec defining all the requirements for PCB designers in order to support stacking.

There's nothing stopping you designing a board that is inherently stackable (indeed some of our prototypes can be mechanically stacked already) and also compliant with the HAT specification, but the use case for a HAT is a single board on top of a single Pi B+.
Rockets are loud.
https://astro-pi.org

User avatar
panik
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

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

Sun Jul 27, 2014 1:24 am

I'm working on an STM32 (ARM Cortex-M3) addon board, called "ARMinARM". It's breaking out all Raspberry Pi B+ GPIO pins, as well as all STM32 pins. They could possibly be all connected or disconnected, depending on the usecase of the end user. Originally for the "old" model B, but I'm reworking it for the B+, see topic here: http://www.raspberrypi.org/forums/viewt ... 45&t=80726

I'm planning on breaking out the eeprom I2C pins to a seperate header on the board. Playing with the idea that the enduser (or myself) could design an addon board for the ARMinARM that would contain the eeprom that identifies the "addon board for the addon board" to the Raspberry Pi. In fact, identifies the two together as one entity. First I simply pass them through. Save them for later. Leaving them floating.

A distinction is made in the spec between "New add-on boards basic requirements" and "B+ HAT requirements". The ARMinARM board is not going to meet the requirements to be called a HAT (no eeprom, no camera slot, no display slot) and I'm perfectly comfortable with that. However,
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:

1. The header must cover the ID_SD and ID_SC pins and either a valid ID EEPROM must be used on these pins, OR the ID_SD pin must be shorted to GND (so the Pi can detect at least that a board is plugged in) and the ID_SC pin must be left unconnected. Do not use ID_SC and ID_SD pins for anything except an ID_EEPROM, or shorting ID_SD to GND on non-EEPROM boards.
A general question, why must the Pi be able to "detect at least that a board is plugged in"? What's it going to do without further info from a missing eeprom?

And specifically, would RPF be at least open to the idea of supporting beforementioned "addon board for addon board that contain an eeprom"? Because also:
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.
And only for the sake of discussion (nitpicking maybe), would an addon board that contains an eeprom for the ARMinARM board (still without camera and display slot) suddenly make the two boards together a 'proper' HAT? No conflicts?

Basically I'm asking: What happens if I initially do leave those pins floating, against all instructions?
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")
http://www.onandoffables.com

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

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

Sun Jul 27, 2014 2:03 am

Hi,
panik wrote:I'm planning on breaking out the eeprom I2C pins to a seperate header on the board. Playing with the idea that the enduser (or myself) could design an addon board for the ARMinARM that would contain the eeprom that identifies the "addon board for the addon board" to the Raspberry Pi. In fact, identifies the two together as one entity. First I simply pass them through. Save them for later. Leaving them floating.
I'm not sure if "HAT compliant" label will help selling new boards, but what you could do (at least leave placeholders on the PCB) is to have EEPROM also on your base board, containing info about it. In case of additional add-on board presence, you could design/request that this add-on for add-on board also contains EEPROM (as you've already described), but the inserted board disables the EEPROM on your base board.

This feature of disabling your base board's EEPROM is simple - have a pull-down resistor on one EEPROM address pin. When there is just your base board present, all EEPROM address lines are low and it is queried by the RasPi. By adding the on-board, the mentioned EEPROM address pin with pull-down resistor becomes shorted to 3.3V, thus, the EEPROM on your base board becomes "disabled" (= never addressed by RasPi) and the second EEPROM is queried instead.
panik wrote:What happens if I initially do leave those pins floating, against all instructions?
"Undefined state" ? ;-)


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

User avatar
panik
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

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

Sun Jul 27, 2014 2:51 am

I'm honestly not looking to be 'HAT compliant'. I'm confident about my product. It's not a HAT. It's an ARMinARM board. You can plug it on a Raspberry Pi. Or use stand-alone. It's awesome. Period. :D

I need the Raspberry Pi to do nothing. And "do nothing" seems to be very little to put on an eeprom. Too little to even bother. Maybe that's why the spec now states that ID_SD needs to be connected to ground, in stead of 'leave floating' as it did in the beginning (and still does in picture 'bplus-gpio.png', posted on the blog and elsewhere).

The pins are on a 1x2 header now (just the pins). It's probably simpler to make that a 1x3 header with ground added next to ID_SD, and instruct the end user to put a jumper there (and remove it when plugging in an addon board that contains an eeprom). Or something.

But I'm not really worried. It already works great on a Model B without an eeprom. It's just that I feel connecting ID_SD to ground is too permanent for my use case, but I also don't want to break stuff.
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")
http://www.onandoffables.com

tubular
Posts: 9
Joined: Wed Jul 23, 2014 9:44 am

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

Sun Jul 27, 2014 10:42 am

Here's one way to implement the stack, with the ability to easily carry signals straight through (for the original 26 pins), or stagger GPIO so they don't conflict (for the new 14 pins).
https://www.dropbox.com/s/frsr0y6ver7hq ... .55.46.jpg

The female header is a 'passthrough' type, that splays the connections so they're 0.3" rather than 0.1" apart. They are available from multiple vendors, such as samtec, 4ucon...

The male connector is the usual ~11mm long. There's an insulating spacer (not shown in photo) so they can't short out.

PCB routing is straightforward, and its possible to make on perfboard, or homebrewed using single sided Kinsten or toner transfer (about 11 mil track and space), with all trackwork on the underside of the pcb as is conventional for through hole components on top.

Capacitance would be fairly minimal this way, and there is no need to alternate direction as the boards stack.

User avatar
rpdom
Posts: 12415
Joined: Sun May 06, 2012 5:17 am
Location: Essex, UK

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

Sun Jul 27, 2014 11:49 am

As I see it, your "stack" method would only work if all the GPIOs had identical functionality or were only used as simple inputs or outputs.

What happens if board N in the stack needs GPIO Z because it wants to use it in ALT-Y mode and that is the only GPIO that provides this function?

(apart from any software headaches with the boards GPIOs changing depending where on the stack the board is).

Or am I misunderstanding your logic?

tubular
Posts: 9
Joined: Wed Jul 23, 2014 9:44 am

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

Sun Jul 27, 2014 12:58 pm

rpdom, yes, if its critical to use a particular gpio pin for its alt function, then the stack order also matters. Keep in mind I'm only 'stacking' the extended 9 gpio pins, the original 26 pins carry through as usual.

If your board is the first in the stack, there may be away to grab your desired (critical) gpio, rather than the (usual) bottom one of the stack, and still shuffle the rest down, with the device tree in the corresponding eeprom updated to reflect whats going on. Need to investigate this further.

Punisher
Posts: 9
Joined: Thu Jan 03, 2013 8:57 pm

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

Sun Jul 27, 2014 10:18 pm

Hi,
I have read the FAQ but am not 100% sure, so:
if I need a bigger PCB than specified in the HAT board specs, then I can't call it a HAT anymore? Regardless in which direction it is bigger, and even if it has all holes etc.?

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

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

Mon Jul 28, 2014 12:39 am

panik wrote:
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:

1. The header must cover the ID_SD and ID_SC pins and either a valid ID EEPROM must be used on these pins, OR the ID_SD pin must be shorted to GND (so the Pi can detect at least that a board is plugged in) and the ID_SC pin must be left unconnected. Do not use ID_SC and ID_SD pins for anything except an ID_EEPROM, or shorting ID_SD to GND on non-EEPROM boards.
A general question, why must the Pi be able to "detect at least that a board is plugged in"? What's it going to do without further info from a missing eeprom?
Having read the docs, I'm also curious about this. It seems to imply that if you're only using the first 26 pins, then you should leave ID_SD floating, but if you're using any of the last 12 pins you have to connect ID_SD to GND.
Does this mean that if people are 'prototyping' and connecting jumper leads directly to the J8 header, then if they want to use any of GPIOs 5, 6, 13, 19, 26, 12, 16, 20 or 21 there's also some requirement to ground ID_SD ? :?

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

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

Mon Jul 28, 2014 1:02 am

AndrewS wrote: Having read the docs, I'm also curious about this. It seems to imply that if you're only using the first 26 pins, then you should leave ID_SD floating, but if you're using any of the last 12 pins you have to connect ID_SD to GND.
Does this mean that if people are 'prototyping' and connecting jumper leads directly to the J8 header, then if they want to use any of GPIOs 5, 6, 13, 19, 26, 12, 16, 20 or 21 there's also some requirement to ground ID_SD ? :?
Ummm, prototyping would imply doing it if your prototyping a HAT. If not then it would be free to do as you wanted. What edge is the I2C clocked on, as you may be lucky enough to jumper ID_SD to ID_SC, and hope there is no hold time violation, allowing a synthetic GND. :?

Another simple botch maybe to bridge pin 25 to 27 using a selector jumper (and maybe a 24 way socket). The ground being on the clock side on pin 30 is a bit of a F*** Nibblet.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

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

Mon Jul 28, 2014 2:07 am

Couple of other questions:
  • designguide.md says "Address pins where present on a device should be set to zero." and eepflash.sh says "This will attempt to write to i2c address 0x50. Make sure there is an eeprom at this address.". Looking at the datasheet for the recommended CAT24C32 chip I can see it says "For the CAT24C32, the first four bits of the Slave address are set to 1010 (Ah); the next three bits, A2, A1 and A0, must match the logic state of the similarly named input pins." which then matches the specified 0x50 address when A2, A1 and A0 are all zero. Should designguide.md be updated to explicitly say that the EEPROM should be configured at I2C address 0x50? Or do all 24Cxx type I2C EEPROM chips always share the same addressing scheme?
  • Should the "Back Powering the Pi via the J8 GPIO Header" part of designguide.md specify what minimum/recommended current (over and above the current needed by the addon board) should be supplied to power the Raspberry Pi (and optional camera board, etc.) ?
  • In the "Vendor info atom data" part of eeprom-format.md it's not clear whether "UUID (must be unique for every manufactured board)" means all instances of "manufacturer X, board Y, revision Z" should all have the same UUID, or whether it still needs to be different even for otherwise-identical boards? If it's the latter, then maybe a small tool which could take an existing .eep file, simply change the GUID, and write out a new .eep file would be useful?

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+ HAT (Hardware Attached on Top) docs/specs

Mon Jul 28, 2014 12:41 pm

Some comments on previous posts:
I'm planning on breaking out the eeprom I2C pins to a seperate header on the board. Playing with the idea that the enduser (or myself) could design an addon board for the ARMinARM that would contain the eeprom that identifies the "addon board for the addon board" to the Raspberry Pi. In fact, identifies the two together as one entity. First I simply pass them through. Save them for later. Leaving them floating.
The EEPROM reading is baked into the GPU boot loader and will (deliberately) not be 'user hackable' to do stuff like this as it's breaking the spec considerably and may cause user confusion. EEPROM or not don't make these pins available for hacking onto as it is not conforming to the spec.
And specifically, would RPF be at least open to the idea of supporting beforementioned "addon board for addon board that contain an eeprom"?
No, see above comments.
And only for the sake of discussion (nitpicking maybe), would an addon board that contains an eeprom for the ARMinARM board (still without camera and display slot) suddenly make the two boards together a 'proper' HAT? No conflicts?
No, because it won't be a single board. Really, don't do that.
designguide.md says "Address pins where present on a device should be set to zero." and eepflash.sh says "This will attempt to write to i2c address 0x50. Make sure there is an eeprom at this address.". Looking at the datasheet for the recommended CAT24C32 chip I can see it says "For the CAT24C32, the first four bits of the Slave address are set to 1010 (Ah); the next three bits, A2, A1 and A0, must match the logic state of the similarly named input pins." which then matches the specified 0x50 address when A2, A1 and A0 are all zero. Should designguide.md be updated to explicitly say that the EEPROM should be configured at I2C address 0x50? Or do all 24Cxx type I2C EEPROM chips always share the same addressing scheme?
I believe all specified EEPROMs would end up at 0x50 but I'll change the docs to be explicit.
Should the "Back Powering the Pi via the J8 GPIO Header" part of designguide.md specify what minimum/recommended current (over and above the current needed by the addon board) should be supplied to power the Raspberry Pi (and optional camera board, etc.) ?
Good idea I'll add to the spec.
In the "Vendor info atom data" part of eeprom-format.md it's not clear whether "UUID (must be unique for every manufactured board)" means all instances of "manufacturer X, board Y, revision Z" should all have the same UUID, or whether it still needs to be different even for otherwise-identical boards? If it's the latter, then maybe a small tool which could take an existing .eep file, simply change the GUID, and write out a new .eep file would be useful?
Yes the idea is that each and every board, even ones of the same manufacturer, revision and type should have a unique UUID. Think of it as a unique board serial number across all boards ever made. Also the eepmake tool will automatically fill in the UUID for you if it is left as zero.
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

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

Mon Jul 28, 2014 1:17 pm

Thanks James. Still curious about the requirement to ground ID_SC though if you're using any of the last 12 pins?

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+ HAT (Hardware Attached on Top) docs/specs

Mon Jul 28, 2014 1:53 pm

Still curious about the requirement to ground ID_SC though if you're using any of the last 12 pins?
After some internal debate we've scratched this requirement (docs now updated) and we're back to using those pins for an EEPROM only, or leaving them unconnected for boards that don't have an EEPROM.
James Adams
Raspberry Pi - COO & Hardware Lead

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+ HAT (Hardware Attached on Top) docs/specs

Mon Jul 28, 2014 4:40 pm

OK thanks to all for the good discussion over the past week and a bit.

The docs are now considered complete so people are free to create (or complete!) their B+ add on board / HAT designs.

For questions or clarifications please continue to post to this thread.
James Adams
Raspberry Pi - COO & Hardware Lead

User avatar
panik
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

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

Mon Jul 28, 2014 10:10 pm

James Adams wrote:EEPROM or not don't make these pins available for hacking onto as it is not conforming to the spec.
Thanks for clarification on this. Without 'proper' support from RPF, I can't think of a worthy use case for these pins. If they do more harm than good I might as well leave them off.

Some more questions. From: https://github.com/raspberrypi/hats/blo ... gnguide.md
Note: For newer firmware, a config.txt option exists to enable the UART on GPIO14/GPIO15 prior to booting the ARM. The EEPROM probe routine will override this behaviour if an EEPROM is found.
Does that imply that whenever there is a HAT plugged in, the EEPROM probe routine will always do what the EEPROM is telling it to do? No matter what changes are made to either config.txt or cmdline.txt? So the user is not able to decide that on a per-boot basis without either removing the HAT or reprogramming its EEPROM?

And does that also imply that editing config.txt is now the new way of telling the RasPi to boot with UART enabled or disabled? That editing cmdline.txt to do this is now deprecated? Or one overrides the other? Or this has been the case earlier and I simply missed it?

From http://elinux.org/RPi_config.txt
cmdline (string) command line parameters. Can be used instead of cmdline.txt file
Is this the one to use now?

Thanks again!
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")
http://www.onandoffables.com

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1758
Joined: Thu Jul 11, 2013 2:37 pm

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

Mon Jul 28, 2014 11:00 pm

panik wrote: Some more questions. From: https://github.com/raspberrypi/hats/blo ... gnguide.md
Note: For newer firmware, a config.txt option exists to enable the UART on GPIO14/GPIO15 prior to booting the ARM. The EEPROM probe routine will override this behaviour if an EEPROM is found.
Does that imply that whenever there is a HAT plugged in, the EEPROM probe routine will always do what the EEPROM is telling it to do? No matter what changes are made to either config.txt or cmdline.txt? So the user is not able to decide that on a per-boot basis without either removing the HAT or reprogramming its EEPROM?

And does that also imply that editing config.txt is now the new way of telling the RasPi to boot with UART enabled or disabled? That editing cmdline.txt to do this is now deprecated? Or one overrides the other? Or this has been the case earlier and I simply missed it?

From http://elinux.org/RPi_config.txt
cmdline (string) command line parameters. Can be used instead of cmdline.txt file
Is this the one to use now?

Thanks again!
To answer this question:

Shortly the default for the B+ (and probably the model A and model B as well) will be to not set any of the alt settings on the GPIO header, i.e. leave everything as input with default pull.

The UART is a bit of a special case because it is often the first device that the kernel talks to when it's alive and doing things.

It's part of the ARM Linux booting specification to optionally enable a board UART and configure it such that early printk's from the loaded kernel make it out of the system: this is essential for low-level debugging of early Linux bring-up, messing around with custom embedded kernel compiles, etc.

For this reason an exception will be made to the "everything on the B+ header is an input" doctrine: a config.txt option will be implemented that instructs Videocore to set up the UART on GPIO14/15. This will likely be a retrospective change: firmware will no longer drive the UART on any model of Raspberry Pi after this firmware version unless the opt-in is given in config.txt.

There are no /boot/cmdline.txt options that can influence the setting of the GPIO pins associated to the UART. Deleting the serial console lines means that there is merely no data put out on the UART TXD pin (but it is still driven high).

The EEPROM will by default override this opt-in parameter. Currently the thinking is that if the EEPROM is detected and there's a valid GPIO map, the UART will be disabled as the GPIO map will take precedence.
Rockets are loud.
https://astro-pi.org

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

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

Mon Jul 28, 2014 11:37 pm

panik wrote:Some more questions. From: https://github.com/raspberrypi/hats/blo ... gnguide.md
Note: For newer firmware, a config.txt option exists to enable the UART on GPIO14/GPIO15 prior to booting the ARM. The EEPROM probe routine will override this behaviour if an EEPROM is found.
Does that imply that whenever there is a HAT plugged in, the EEPROM probe routine will always do what the EEPROM is telling it to do? No matter what changes are made to either config.txt or cmdline.txt? So the user is not able to decide that on a per-boot basis without either removing the HAT or reprogramming its EEPROM?
That's what it sounds like to me. Isn't that exactly the behaviour you'd expect from an easy-to-use HAT system?
(Of course I suspect that post-bootup you / your driver will still be able to manually force the GPIOs into whatever state(s) you want)
And does that also imply that editing config.txt is now the new way of telling the RasPi to boot with UART enabled or disabled?
I'm guessing this means this "new option" will be used to tell the GPU firmware on the B+ to put the GPIOs 14 and 15 into ALT0 mode by default, same as is done currently for the firmware on the A and B.
That editing cmdline.txt to do this is now deprecated? Or one overrides the other? Or this has been the case earlier and I simply missed it?
Nope, you'll still need the options in cmdline.txt to tell the Linux kernel to communicate with ttyAMA0. Without the "enable UART" option in config.txt, messages will still be printed to ttyAMA0, but TXD0 and RXD0 wont be routed to pins 8 and 10 on the header.
From http://elinux.org/RPi_config.txt
cmdline (string) command line parameters. Can be used instead of cmdline.txt file
Is this the one to use now?
Nope, that documentation is wrong. The correct documentation is at http://www.raspberrypi.org/documentatio ... fig-txt.md

This is all merely AIUI of course! :?

EDIT: Ooops, wrote all this at the same time jdb was writing his reply.

User avatar
panik
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

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

Mon Jul 28, 2014 11:40 pm

I see. I'm asking because of a possible use case for the ARMinARM board. Admittedly probably not very common, but possible nonetheless.

I'm using UART pins 14 and 15 to upload firmware to the STM32 using the built-in ST bootlader. And two other GPIOs, 4 and 17 (which are by default the state I need them in) to control the "bootmode" after STM32 reset. This is done with python scripts using RPi.GPIO.

So most of the time I want the UART pins "disabled" (= available for the user and scripts to talk to the STM32 and/or its bootloader). I'm relying on "/boot/cmdline.txt" at the moment to boot the Raspberry Pi with UART enabled or disabled. There's a menu option in the software for it, which edits that file. I understand that needs to change to editing config.txt.

With the right firmware for the STM32, the ARMinARM board could act as a "virtual USB serial device", relaying kernel messages and tty console from the RasPi UART pins to the USB port on the ARMinARM board. Emulating a "Serial to USB FTDI device" or similar. Giving the user the option of logging in on the Raspberry Pi over UART by connecting a USB cable from the ARMinARM to a PC or laptop. Or possibly do that low level debugging and messing around with the kernel you mention.

That's when the user will want UART "enabled" if I may call it that. But that'll only work if there's no EEPROM in the way that thinks it knows better.

All in theory, but I like to keep all options open.
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")
http://www.onandoffables.com

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

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

Mon Jul 28, 2014 11:45 pm

jdb wrote:For this reason an exception will be made to the "everything on the B+ header is an input" doctrine: a config.txt option will be implemented that instructs Videocore to set up the UART on GPIO14/15. This will likely be a retrospective change: firmware will no longer drive the UART on any model of Raspberry Pi after this firmware version unless the opt-in is given in config.txt.
I can see that makes sense for the B+ (since the whole thing is still kinda in flux), but I'm not so sure it makes sense (by default) for the Models A and B. Wouldn't it mean that all the developers of add-on boards for the A and B suddenly need to either provide updated drivers, and/or update their setup instructions? Or they might start telling people not to update the firmware because it'll 'break' their addon board... :cry:

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

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

Mon Jul 28, 2014 11:57 pm

panik wrote:I'm using UART pins 14 and 15 to upload firmware to the STM32 using the built-in ST bootlader. And two other GPIOs, 4 and 17 (which are by default the state I need them in) to control the "bootmode" after STM32 reset. This is done with python scripts using RPi.GPIO.

So most of the time I want the UART pins "disabled" (= available for the user and scripts to talk to the STM32 and/or its bootloader). I'm relying on "/boot/cmdline.txt" at the moment to boot the Raspberry Pi with UART enabled or disabled. There's a menu option in the software for it, which edits that file. I understand that needs to change to editing config.txt.
...snip...
Nope, you'll still want to only edit /boot/cmdline.txt to enable / disable Linux from talking to the serial console. And leave the config.txt option (assuming you're not using an EEPROM, as you already said) to enable GPIOs 14 and 15 to act as the UART.

Basically there's multiple levels of "enablement" - config.txt merely controls (at the hardware level) whether GPIOs 14 and 15 are setup in ALT0 mode, i.e. whether the UART signals are routed to pins 8 and 10.
/boot/cmdline.txt (and /etc/inittab - see https://github.com/lurch/rpi-serial-console ) will determine whether Linux (at the software level) outputs bootup messages and runs a getty on the UART (the same as happens with the A and B currently), or whether it can be used by a user-process to talk to other devices.

User avatar
panik
Posts: 369
Joined: Fri Sep 23, 2011 12:29 pm
Location: Netherlands

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

Tue Jul 29, 2014 12:11 am

That would mean I don't have to change anything.

Cool! :)
Microcontroller addon boards and software for Raspberry Pi A+/B+/Pi2:
- ARMinARM: ARM Cortex-M3 (STM32)
- AVRPi: ATmega32U4 & ATmega328 ("Arduino")
http://www.onandoffables.com

Return to “B+ addons”

Who is online

Users browsing this forum: No registered users and 3 guests