Got it. Just me being muddled for a while. It all sounds a bit like the apple mac color bus with ROMs on board the cards. A nice idea. Perhaps a URL to the driver should also be in the ROM, to allow dynamic updating without reflashing, but would this need a reboot, or just a insmod?James Adams wrote:Not quite sure I understand the question.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.
As I understand it, clock stretching is a bit buggy.FLYFISH TECHNOLOGIES wrote:Additionally, information if clock stretching is supported would also be valuable.
Thanks & Best wishes, Ivan Zilic.
You can always bit-bang I2C ...jamesh wrote:As I understand it, clock stretching is a bit buggy.FLYFISH TECHNOLOGIES wrote:Additionally, information if clock stretching is supported would also be valuable.
Thanks & Best wishes, Ivan Zilic.
I'd like to be able to say, shift a peripheral block, such as the UART, to one of its alternate sets of pins, and it would be a bl**dy nuisance to have to recompile a kernel to do it.[email protected] wrote: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!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.
Which makes it just a blurb of letters and numbers...EDIT: I suggest a bold
This is an interesting idea. 28 pins plus left-most 2 mounting holes would make for cheaper boards due to board area. You'd lose a lot of functionality provided by the extra set of pins (including i2s) though.jackokring wrote: EDIT2: 28-way mini hats might be quite interesting.
Toupis?mikronauts wrote:caps ?
You can design and produce any board you like, but you can't call it a HAT unless it adheres to the mandatory portions of the specification.recantha2 wrote:Can I ask some really dumb questions?
* If I'm developing a simple add-on board for the B+ that uses the 40 pins as they've been specified, do I _need_ to worry about the EEPROM? i.e. If you don't connect anything to the EEPROM pins, does it really matter?
Same as the last statement - nothing stopping you but you can't call it a HAT. I think we shall support 28-pin HATs but it's not baked into the specification yet.* Presumably if I'm developing a GPIO board that I want to work with the B and the B+, so therefore I just use the first 26 pins, then I don't need to worry about the EEPROM?
As of the current spec yes this is OK (but I'll say again we're still changing the spec but it is 'solidifying'). - as jdb says though we are probably going to mandate that only things that use a 40W connector with the recommended board outline and support EEPROM can officially be called HATs.At the moment, if I understand correctly, we have the option of creating add on boards with or without the EEPROM. Whichever variant we should be using the PCB footprint already published with the camera and screen cable cut outs being optional.
So if someone was to create a board to the defined PCB footprint, with or without cut-outs, with or without EEPROM the foundation would find this acceptable and these boards would not be frowned upon?
Back to the flippant track ... that could be a Top Hatjdb wrote:I think we shall support 28-pin HATs but it's not baked into the specification yet.
Hmm, given that it would be smaller, I think a Pork Pi Hat would be more appropriate...Paul Webster wrote:Back to the flippant track ... that could be a Top Hatjdb wrote:I think we shall support 28-pin HATs but it's not baked into the specification yet.
Yes that device will be suitable.I have some CAT24C256LI-G 32Kx8 devices which I assume will be suitable.
Tools have been posted but are 'alpha' - i.e. under active development.On a related note, when will the EEPROM tools referred to be available? Presumably this will be after the specs are frozen.
Users browsing this forum: No registered users and 5 guests