phelum
Posts: 72
Joined: Thu Jul 17, 2014 7:05 am
Location: Sydney, AUS

Re: Schematics for B+

Sat Jul 19, 2014 12:26 pm

jamesh wrote: Rubbish. The Foundation has no desire to tell you want you need to know. They are also not 'hiding' anything. What I want to know is why you have a need to know? Like I said, albeit tongue in cheek, my Pi works fine without the schematics...! And tbh, you're not going to be able to diagnose a faulty Pi even with the schematics in most cases. And fixing it even if you find a fault will be nigh on impossible! I wonder how many 'broken' B were fixable and fixed due to schematics? Few. Faults on these sorts of boards tend to be bad solder points on the BGA's - not generally fixable.

They will be released at some point of course, I expect, once James has the time to sort it all out and make them suitable for publication.
Hi,
My reason fo wanting the schematics is that when I received my B+ none of the USB ports had power. That was a software issue which people here told me about. But since the model B had power directly from the 5V supply I assumed the B+ would be the same. So I was trying to verify that this was the case and also get some details so I could trace the path through the card.

I agree that there isn't much on the card that I could fix. But without schematics and/or documentation the only thing that stopped me regarding the card as broken was the help I got in this thread.

Cheers,
Steven

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

Re: Schematics for B+

Sat Jul 19, 2014 12:30 pm

Grumpy Mike wrote: Sorry to here you talk like this. It is to do something with the Raspberry Pi. That is what I do. I also write about it, but if you think that money is the motive then I assume you have never had anything published.
Sorry to say but you're coming over as whining and moaning just because the foundation has spoilt the plans for your new book by producing a better product and not telling you about it !

I would imagine most B+ owners are just getting on and learning about it by using it....
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25422
Joined: Sat Jul 30, 2011 7:41 pm

Re: Schematics for B+

Sat Jul 19, 2014 1:10 pm

PeterO wrote:
Grumpy Mike wrote: Sorry to here you talk like this. It is to do something with the Raspberry Pi. That is what I do. I also write about it, but if you think that money is the motive then I assume you have never had anything published.
Sorry to say but you're coming over as whining and moaning just because the foundation has spoilt the plans for your new book by producing a better product and not telling you about it !

I would imagine most B+ owners are just getting on and learning about it by using it....
PeterO
I have to say it does concern me when new products are announced with no warning that a lot of people might be put out, for reasons similar to the above. But I simply cannot think of a better way of doing it. The Foundation clearly cannot keep a massive list of interested parties - there would be thousands, and its bad enough with the amount of leaks that appear anyway! A few people do get told for long leadtime products (cases etc), but you really cannot tell everyone.

Just for completeness, yes, I have had stuff published, not books, just magazine articles etc. Did think about a Pi book, but the cost/benefits analysis didn't add up (it rarely does with books), so my volunteer time goes on the forum and the camera.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25422
Joined: Sat Jul 30, 2011 7:41 pm

Re: Schematics for B+

Sat Jul 19, 2014 1:14 pm

phelum wrote:
jamesh wrote: Rubbish. The Foundation has no desire to tell you want you need to know. They are also not 'hiding' anything. What I want to know is why you have a need to know? Like I said, albeit tongue in cheek, my Pi works fine without the schematics...! And tbh, you're not going to be able to diagnose a faulty Pi even with the schematics in most cases. And fixing it even if you find a fault will be nigh on impossible! I wonder how many 'broken' B were fixable and fixed due to schematics? Few. Faults on these sorts of boards tend to be bad solder points on the BGA's - not generally fixable.

They will be released at some point of course, I expect, once James has the time to sort it all out and make them suitable for publication.
Hi,
My reason fo wanting the schematics is that when I received my B+ none of the USB ports had power. That was a software issue which people here told me about. But since the model B had power directly from the 5V supply I assumed the B+ would be the same. So I was trying to verify that this was the case and also get some details so I could trace the path through the card.

I agree that there isn't much on the card that I could fix. But without schematics and/or documentation the only thing that stopped me regarding the card as broken was the help I got in this thread.

Cheers,
Steven
I always suspect software first (I'm am a software engineer...), and your first port of call should always be here or Google. If nothing, then you might want to suspect HW, but at a failure rate of 0.001% or something (I think Eben said Sony had had 8 returns in 6 months or something), the Raspi is pretty reliable HW wise.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

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

Re: Schematics for B+

Sat Jul 19, 2014 1:42 pm

What's needed in addition to the schematics is a few simple helpful notes - such as DO NOT USE GPIO16 as an input. It will be driven as an output during boot-up and shutdown, behaviour which is not documented anywhere, but is sort of important to know. This is the sort of documentation that takes zero effort to produce, and saves hours of everyone else's time.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: Schematics for B+

Sat Jul 19, 2014 1:46 pm

PeterO wrote: Sorry to say but you're coming over as whining and moaning just because the foundation has spoilt the plans for your new book by producing a better product and not telling you about it !
PeterO
I have known about the B+ for the best part of 8 months now so you can not say that. Have you known about it that long?
It is not a new book it is a second edition of an existing book. The whole point about the second addition is to cover the new model.

I am not moaning about about anything except the attitude of jamesh . Which you would know if you would have bothered to have read the thread. Please get your facts correct before attacking someone.

All I asked is when they would be published. I did not express any displeasure in the resulting answer. Which seems to be "at some point in the future"

User avatar
joan
Posts: 14755
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Schematics for B+

Sat Jul 19, 2014 2:01 pm

rotwang wrote:What's needed in addition to the schematics is a few simple helpful notes - such as DO NOT USE GPIO16 as an input. It will be driven as an output during boot-up and shutdown, behaviour which is not documented anywhere, but is sort of important to know. This is the sort of documentation that takes zero effort to produce, and saves hours of everyone else's time.
I haven't noticed that mentioned anywhere else. Is it a consequence of an incomplete change in activity LED from gpio16 to gpio47?

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

Re: Schematics for B+

Sat Jul 19, 2014 2:09 pm

phelum wrote:Hi,
My reason fo wanting the schematics is that when I received my B+ none of the USB ports had power. That was a software issue which people here told me about. But since the model B had power directly from the 5V supply I assumed the B+ would be the same. So I was trying to verify that this was the case and also get some details so I could trace the path through the card.

I agree that there isn't much on the card that I could fix. But without schematics and/or documentation the only thing that stopped me regarding the card as broken was the help I got in this thread.

Cheers,
Steven
Even with the schematics, you probably would be none the wiser regarding this problem, as it isn't about the USB's getting power at all!
Its just that older firmware does not know about model B+ at all, and so do not know that when it is a B+ it has to program one of the high speed generators to put out a 25.000 MHz signal, so the LAN9514 chip gets the clock signal it needs, and that in the older B versions was generated by its own 25MHZ crystal.
It would have been a miracle if you would have made this conclusion from simply studying the schematic!

But if you simply asked in the troubleshooting forum "whats up with this" you would probably have had your answer almost immediately, also their are several threads about it, here and in the blog that warns you that you will need a very recently updated version of the software, with a description what happens when you don't.

I'm guessing more information is better, but so quickly after the lunch having a partial schematic is already very good, after previous revisions it took weeks before we got updated schematics, as such things take time if you want to publish professional looking documents.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25422
Joined: Sat Jul 30, 2011 7:41 pm

Re: Schematics for B+

Sat Jul 19, 2014 3:11 pm

OK, no more ad-hominem attacks on mods or peoples attitude please. If you don't like my attitude (or indeed any others), which is my own and their own respectively, then please don't engage in conversation that ends up with attacks. Everyone is entitled to an opinion, but posters are not entitled to attack other posters.

I've deleted one post, I don't want to have to delete any more.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

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

Re: Schematics for B+

Sat Jul 19, 2014 4:35 pm

joan wrote:
rotwang wrote:What's needed in addition to the schematics is a few simple helpful notes - such as DO NOT USE GPIO16 as an input. It will be driven as an output during boot-up and shutdown, behaviour which is not documented anywhere, but is sort of important to know. This is the sort of documentation that takes zero effort to produce, and saves hours of everyone else's time.
I haven't noticed that mentioned anywhere else. Is it a consequence of an incomplete change in activity LED from gpio16 to gpio47?
Could well be, it's common to the Compute Module and the B+, just confirmed that with a brand-new B+. Connect an LED between GPIO16 and GND (obviously via a series resistor). On boot-up you get 1 flash, on shutdown you get 10, but curiously enough, on reboot you get nothing. If I is just an oversight on changing the binary blob, then it needs fixing, or at least documenting before it starts blowing up things. Also the blob adds things to the kernel command line (as present in /boot) and thats not documented either.

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

Re: Schematics for B+

Sat Jul 19, 2014 4:41 pm

start.elf has some functions to detect the exact platform it's running on and configure the pins accordingly.
Bootcode.bin does not, so it tries its best.

I don't know if that'll be fixed, or if it is indeed something that needs fixing rather than a mention in the documentation. When I was at uni, one of the things always hammered into us was to never assume any particular hardware or sotware state unless you have configured it and the documentation guarantees nothing else will touch it. That's probably the right way to treat it for now.

User avatar
FTrevorGowen
Forum Moderator
Forum Moderator
Posts: 5458
Joined: Mon Mar 04, 2013 6:12 pm
Location: Bristol, U.K.
Contact: Website

Re: Schematics for B+

Sat Jul 19, 2014 4:51 pm

ShiftPlusOne wrote:start.elf has some functions to detect the exact platform it's running on and configure the pins accordingly.
Bootcode.bin does not, so it tries its best.
I don't know if that'll be fixed, or if it is indeed something that needs fixing rather than a mention in the documentation. When I was at uni, one of the things always hammered into us was to never assume any particular hardware or sotware state unless you have configured it and the documentation guarantees nothing else will touch it. That's probably the right way to treat it for now.
+1
Likewise, 'though several decades ago now - "always initialise your variables" (you can't escape from GIGO ;) )
Trev.
Still running Raspbian Jessie or Stretch on some older Pi's (an A, B1, 2xB2, B+, P2B, 3xP0, P0W, 2xP3A+, P3B+, P3B, B+, and a A+) but Buster on the P4B's. See: https://www.cpmspectrepi.uk/raspberry_pi/raspiidx.htm

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

Re: Schematics for B+

Sat Jul 19, 2014 5:27 pm

ShiftPlusOne wrote:start.elf has some functions to detect the exact platform it's running on and configure the pins accordingly.
Bootcode.bin does not, so it tries its best.

I don't know if that'll be fixed, or if it is indeed something that needs fixing rather than a mention in the documentation. When I was at uni, one of the things always hammered into us was to never assume any particular hardware or sotware state unless you have configured it and the documentation guarantees nothing else will touch it. That's probably the right way to treat it for now.
Documentation? What Documentation?
Could just be a typo, 16 for 46, or maybe someone didn't find all occurences when making the change, in any case it's the sort of thing that wastes hours of time, since by the time any user code gets to run, GPIO16 has been configured as an input.
These pulses are the sort of thing that drive chips into non-destructive latch-up states which reset when power is removed. So complicated interface chip with obscure data sheet, connect it up, doesn't work, power down, test chip on different system, all o.k. Waste hours checking code, checking chips etc. etc.

Been there, done that, got the t-shirt, the sweatshirt, the embroidered tour jacket and the limited edition picture vinyl disc.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: Schematics for B+

Sat Jul 19, 2014 5:28 pm

ShiftPlusOne wrote:start.elf has some functions to detect the exact platform it's running on and configure the pins accordingly.
Bootcode.bin does not, so it tries its best.

I don't know if that'll be fixed, or if it is indeed something that needs fixing rather than a mention in the documentation. When I was at uni, one of the things always hammered into us was to never assume any particular hardware or sotware state unless you have configured it and the documentation guarantees nothing else will touch it. That's probably the right way to treat it for now.
So following that logic you should never plug anything into the GPIO pins until it has booted up. This somewhat conflicts with the advice your Hardware Engineers will give you, about never plugging anything into the GPIO pins when there is power on the board.

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

Re: Schematics for B+

Sat Jul 19, 2014 5:42 pm

Grumpy Mike wrote: So following that logic you should never plug anything into the GPIO pins until it has booted up.
Not sure how you got that from what I said.

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

Re: Schematics for B+

Sat Jul 19, 2014 6:13 pm

rotwang wrote: Documentation? What Documentation?
There's a documentation section on the website.
http://www.raspberrypi.org/documentatio ... /README.md
http://www.raspberrypi.org/documentatio ... /README.md
http://www.raspberrypi.org/documentatio ... herals.pdf

I understand that your complaint is probably the it currently DOESN'T mention anything about GPIO16. That's probably because it's not clear if it will continue to function as it currently does or if bootcode.bin will change to make sure that doesn't happen. In any case, the documentation is on github and sending pull requests is easy.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: Schematics for B+

Sat Jul 19, 2014 6:37 pm

ShiftPlusOne wrote:
Grumpy Mike wrote: So following that logic you should never plug anything into the GPIO pins until it has booted up.
Not sure how you got that from what I said.
Not sure how you can reach any other conclusion when you say:-
never assume any particular hardware or sotware state unless you have configured it
If if have put, say an output, on that pin, or any other pin for that matter, to be read with an input and your software will cope with it, but the OS goes and makes it into an output and pulses it before your software can get a look in then according to your philosophy you should only connect that pin after your software has started running to avoid damaging either your hardware or your Pi, possibly both.

This is not the way the rest of the computing world handles hardware I/O. If it is not fixed / can not be fixed, then you cut off the possibility of using that pin as an input. If that is the case then it better be make crystal clear.

Do you know of any other "nasties" hiding like this?

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

Re: Schematics for B+

Sat Jul 19, 2014 6:47 pm

I believe this is what the ID EEPROM is supposed to address.

Presumably all manufactured add-on boards will be expected to have an EEPROM that will give a board ID (string/number) and the default state (In/Out/ALTn) and default level of outputs of all GPIOs the board uses. Plus some driver information, I guess.

For home built stuff you just need to be careful and don't assume anything until documentation is finalised. Things are still settling in the firmware.

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

Re: Schematics for B+

Sat Jul 19, 2014 7:19 pm

Grumpy Mike wrote:
ShiftPlusOne wrote:
Grumpy Mike wrote: So following that logic you should never plug anything into the GPIO pins until it has booted up.
Not sure how you got that from what I said.
Not sure how you can reach any other conclusion when you say:-
never assume any particular hardware or sotware state unless you have configured it
If if have put, say an output, on that pin, or any other pin for that matter, to be read with an input and your software will cope with it, but the OS goes and makes it into an output and pulses it before your software can get a look in then according to your philosophy you should only connect that pin after your software has started running to avoid damaging either your hardware or your Pi, possibly both.

This is not the way the rest of the computing world handles hardware I/O. If it is not fixed / can not be fixed, then you cut off the possibility of using that pin as an input. If that is the case then it better be make crystal clear.

Do you know of any other "nasties" hiding like this?

I...what?

Let's examine the line of discussion here.

ShiftPlusOne makes the assertion " never assume any particular hardware or sotware state unless you have configured it and the documentation guarantees nothing else will touch it. "

This is true for all cases where auto-discovery and/or enumeration is not possible. PCI, PCIe, USB and other popular, modular interconnects all have defined methods for initial attachment and configuration of devices attached to a host bus. For a 40-way connector full of a random smattering (well, not random but may as well be for the purposes of discussion) GPIOs from a proprietary SoC there are no assumptions about bus state (other than the hardware-defined GND/3v3/5v/logic parameters) therefore we are completely free to define a cooperative probing and enumeration method.

Then you appear to conflate two issues:
So following that logic you should never plug anything into the GPIO pins until it has booted up. This somewhat conflicts with the advice your Hardware Engineers will give you, about never plugging anything into the GPIO pins when there is power on the board.
The inference is that the existence of preconfigured states, intentional or unintentional, should somehow preclude attaching hardware until after the boot process has completed and the apparent contradiction of "hotplug" on a non-hotplug connector creates a conflict.

No such conflict exists. The toggling of random GPIOs during the boot process is a bug in the bootloader. A holdover from the previous assumption of a fixed platform that will take literally five minutes of my time to fix (if Dom hasn't already done so) when I am next back in the office.

The larger perspective is the handling of the ID_SC and ID_SD pins. These were left reserved for a specific reason: such that the bootloader can probe for any attached boards and perform the duty of autoconfig such that said compliant boards "just work" (tm). There is also a reason that this specification is not yet defined: there are three (3) engineers actively involved in this design. To presume that we know all the answers is folly: we will almost certainly miss something in our analysis and therefore bake-in something inherently broken that hobbles some arbitrary use-case further down the line. The "B+ addons" forum was created with this in mind, and when we release the EEPROM specification for public comment the iterative process of deciding on a method for autoconfig of an entirely new, arbitrary interface should end up with a sane specification that avoids most of the pitfalls.
Rockets are loud.
https://astro-pi.org

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

Re: Schematics for B+

Sat Jul 19, 2014 7:55 pm

Grumpy Mike wrote: If if have put, say an output, on that pin, or any other pin for that matter, to be read with an input and your software will cope with it, but the OS goes and makes it into an output and pulses it before your software can get a look in then according to your philosophy you should only connect that pin after your software has started running to avoid damaging either your hardware or your Pi, possibly both.
It seems to me that you have everything from resistors to buffers to optocouplers to prevent any damage in such a case.

I have no such 'philosophy', it's just a general rule of thumb. It's useful to consider what will happen if something you expect to be an input is actually an output. What happens if someone not familiar with electronics runs a script that twiddles GPIO when your hardware is attached? There are ways to override the default pin configuration, so if you release hardware which assumes a certain pin configuration without using an ID eeprom, Murphy's law can and will get you.

I think everything else has been addressed by rpdom and jdb quite thoroughly.

User avatar
Grumpy Mike
Posts: 931
Joined: Sat Sep 10, 2011 7:49 pm
Location: Manchester (England England)
Contact: Website

Re: Schematics for B+

Sat Jul 19, 2014 7:58 pm

The toggling of random GPIOs during the boot process is a bug in the bootloader. A holdover from the previous assumption of a fixed platform that will take literally five minutes of my time to fix
Good.
It is just that ShiftPlusOne wrote:-
I don't know if that'll be fixed, or if it is indeed something that needs fixing rather than a mention in the documentation.
I was trying to point out the flaw in his argument.

This forum is not covering itself with glory today is it?
It seems to me that you have everything from resistors to buffers to optocouplers to prevent any damage in such a case.
Don't you just love it when software Linux types think they know about hardware.

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

Re: Schematics for B+

Sat Jul 19, 2014 8:05 pm

Grumpy Mike wrote: It is just that ShiftPlusOne wrote:-
I don't know if that'll be fixed, or if it is indeed something that needs fixing rather than a mention in the documentation.
I was trying to point out the flaw in his argument.
I don't see an argument being made in that snippet you pasted. For future reference, if I say I don't know something, I'm not making an argument.
Grumpy Mike wrote: Don't you just love it when software Linux types think they know about hardware.
Not sure where you got that characterisation of me from. You don't know my education background or the projects I've worked on.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25422
Joined: Sat Jul 30, 2011 7:41 pm

Re: Schematics for B+

Sat Jul 19, 2014 8:10 pm

Grumpy Mike wrote:
The toggling of random GPIOs during the boot process is a bug in the bootloader. A holdover from the previous assumption of a fixed platform that will take literally five minutes of my time to fix
Good.
It is just that ShiftPlusOne wrote:-
I don't know if that'll be fixed, or if it is indeed something that needs fixing rather than a mention in the documentation.
I was trying to point out the flaw in his argument.

This forum is not covering itself with glory today is it?
It seems to me that you have everything from resistors to buffers to optocouplers to prevent any damage in such a case.
Don't you just love it when software Linux types think they know about hardware.
Whilst I am always up for a lively discussion, as soon as you start to insult people you are likely get banned (and you've also lost). That was an insult, so don't do it. No further comment on this please. That last post was within a hair breadth of deletion, and I really dislike deleting posts.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

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

Re: Schematics for B+

Sat Jul 19, 2014 8:20 pm

jamesh wrote:
Whilst I am always up for a lively discussion, as soon as you start to insult people you are likely get banned (and you've also lost). That was an insult, so don't do it. No further comment on this please. That last post was within a hair breadth of deletion, and I really dislike deleting posts.
I'm willing to waive the usual mod constraints on personal insults if the actual discussion progresses to a measurable degree. I have been called many things during my career and I couldn't care less about almost all of them.
Rockets are loud.
https://astro-pi.org

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 25422
Joined: Sat Jul 30, 2011 7:41 pm

Re: Schematics for B+

Sat Jul 19, 2014 8:26 pm

jdb wrote:
jamesh wrote:
Whilst I am always up for a lively discussion, as soon as you start to insult people you are likely get banned (and you've also lost). That was an insult, so don't do it. No further comment on this please. That last post was within a hair breadth of deletion, and I really dislike deleting posts.
I'm willing to waive the usual mod constraints on personal insults if the actual discussion progresses to a measurable degree. I have been called many things during my career and I couldn't care less about almost all of them.
Fair enough! I'm off to Bedfordshire, been a hot and bothered day.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
“I own the world’s worst thesaurus. Not only is it awful, it’s awful."

Return to “Troubleshooting”