BCM2835 datasheet


190 posts   Page 4 of 8   1, 2, 3, 4, 5, 6, 7, 8
by jamesh » Wed Dec 21, 2011 3:33 pm
Just remember that a BRCM2835 datasheet isn't much use, whereas a Raspberry Pi datasheet is, since the Raspi doesn't expose all the capabilities of the 2835.

And a full datasheet of the 2835 isn't really a sheet, more of an encyclopaedia. Just printing out the instruction set for the Vector core is 150 pages (sorry the rainforest). And that doesn't cover how to use them. The you have all the pinout descriptions and block diagrams - that's about 50 pages of nonsense. Then you have the 800 pages of registers, then you would need another 800 pages of how to use those registers. Then probably another 500 pages on the libraries of code there already. Those last 1300 pages don't yet exist. That's just the GPU BTW, the Arm has it's own docs.

That lot would would make a VERY tedious read (I know, I've been there for the docs that do exist!).

Roll on a Raspberry Specific datasheet, all you need to know in 20 (prediction) easy to read pages.
Raspberry Pi Engineer
Raspberry Pi Engineer
Posts: 10595
Joined: Sat Jul 30, 2011 7:41 pm
by Burngate » Wed Dec 21, 2011 3:34 pm
Quote from jamesh on December 21, 2011, 12:28
There are a couple of closed source libraries - OpenVG and OpenGLES.

Hmm. You can see my confusion.

Clears up for me where the boundary actually is. Thankyou. I'm just going to learn how to drive them. No problem (apart from slow & erratic brain cells)

Side Question - Would those closed libraries be usable from another OS? Any idea how the RiscOs fraternity are dealing with that?
Hardware ace - level: Cowboy
User avatar
Posts: 2351
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by Burngate » Wed Dec 21, 2011 3:37 pm
Quote from jamesh on December 21, 2011, 14:45
I think you are right - he is a tool.

I'm off to the venting thread ... oh you weren't talking about me
Hardware ace - level: Cowboy
User avatar
Posts: 2351
Joined: Thu Sep 29, 2011 4:34 pm
Location: Berkshire UK
by johnbeetem » Wed Dec 21, 2011 3:53 pm
Quote from jamesh on December 21, 2011, 15:33
And a full datasheet of the 2835 isn't really a sheet, more of an encyclopaedia.

That lot would would make a VERY tedious read (I know, I've been there for the docs that do exist!).


"Throw me into that briar-patch."

Yes, I know it's a data book and not a data sheet, but "datasheet" works better with the song. I'm quite familiar with databooks' getting increasingly large as they get distributed only as .pdf. I read and print the parts I need at the time I need them. At some point I hope to have a reasonable-size tablet for browsing them.

I once worked at a place where one of the software engineers didn't like to read the Motorola 68360 tome because it was "boring". My buddy and I were flabbergasted by the comment, and felt that if you found data books boring you probably shouldn't be a software engineer, at least not at the embedded level.

That said, some data books are a lot better written than others.
User avatar
Posts: 938
Joined: Mon Oct 17, 2011 11:18 pm
Location: The Coast
by bradburts » Wed Dec 21, 2011 3:58 pm
Just remember that a BRCM2835 datasheet isn't much use, whereas a Raspberry Pi datasheet is, since the Raspi doesn't expose all the capabilities of the 2835.


It will be like the layers of an onion. Start with the Pi datasheet and lets go from there.
I will paddle a little into the 'need too' debate again. 'Want too' is an essential part of learning as well, not as important perhaps (ref. Manfred Max-Neef) but a need all the same.
You have nicely taken the base 'need too' away, so don't be suprised by the number of 'want toos' you are left with :)
See, its your fault for being to nice really :)

Which leaves me to say .......
Posts: 341
Joined: Sun Oct 02, 2011 7:07 am
by JeToMad » Wed Dec 21, 2011 4:00 pm
Quote from johnbeetem on December 21, 2011, 15:53
Yes, I know it's a data book and not a data sheet, but "datasheet" works better with the song. I'm quite familiar with databooks' getting increasingly large as they get distributed only as .pdf. I read and print the parts I need at the time I need them. At some point I hope to have a reasonable-size tablet for browsing them.


Nowadays, the datasheet for something like an 8bit PIC is 800 pages long, so...

In fact, the last time I readed a 32bit TI uC, it was like 1500 pages without the ARM core part.

But I do not see the problem at all: the more info you get, the less you need to ask :) Even when a big part of that info can be repeated if you work with some members of the same processor family.
Greetings from Spain!
User avatar
Posts: 14
Joined: Mon Dec 19, 2011 11:13 am
by jamesh » Wed Dec 21, 2011 4:25 pm
Quote from Burngate on December 21, 2011, 15:34
Quote from jamesh on December 21, 2011, 12:28
There are a couple of closed source libraries - OpenVG and OpenGLES.

Hmm. You can see my confusion.

Clears up for me where the boundary actually is. Thankyou. I'm just going to learn how to drive them. No problem (apart from slow & erratic brain cells)

Side Question - Would those closed libraries be usable from another OS? Any idea how the RiscOs fraternity are dealing with that?


OpenVG and OpenGL are the names of the libraries as defined by the Khronos group. The Open in their names refers to the open and standard API used, not the implementation. Because of the standard API any Open GLES libraries on a platform can be easily replicated by another OpenGLES library on another platform.

In addition the Khronos group provides a set of standard tests for a library to ensure it meets their standard. The Broadcom implementation of the API meets all the required standards.

So your side question should be answered. It's your application that makes API calls to the OpenGLES libraries. As long as you have an OpenGLES compatible library on another machine your code (when recompiled if necessary) should still work. The OpenGL etc libraries for the Pi will NOT work on another machine (unless by chance it has a Videocore 4 in it, and even then...). However, OpenGL libraries are available for Linux, Windows etc, either accelerated or not.

The RiscOS people have a Broadcom engineer on their team, which should help!
Raspberry Pi Engineer
Raspberry Pi Engineer
Posts: 10595
Joined: Sat Jul 30, 2011 7:41 pm
by tufty » Wed Dec 21, 2011 7:05 pm
Quote from jamesh on December 21, 2011, 16:25
Quote from Burngate on December 21, 2011, 15:34
Side Question - Would those closed libraries be usable from another OS?

So your side question should be answered. It's your application that makes API calls to the OpenGLES libraries. As long as you have an OpenGLES compatible library on another machine your code (when recompiled if necessary) should still work. The OpenGL etc libraries for the Pi will NOT work on another machine (unless by chance it has a Videocore 4 in it, and even then...). However, OpenGL libraries are available for Linux, Windows etc, either accelerated or not.

I don't think that's quite what Burngate was asking, James. My interpretation is "if I were to run <x> on my Pi, would I be able to use the Linux OpenGL/OpenVG libraries?", where <x> is something like NetBSD.

The answer to that is highly likely to be "no, you're not - you may get OpenGL/VG through a non-hardware-accelerated library, but not via the GPU". The FreeBSD does have (or did have) a Linux compatibility layer, you might be able to shoehorn that into working, but I doubt it would be easy. As far as I know it's only x86 and lagged behind the cutting edge kerels by a long way.

Simon

As for iwantmypi, I personally would have referred him/her/it to Arkell vs Pressdram. I'm very impressed by your continuing cool-headedness.
Posts: 1330
Joined: Sun Sep 11, 2011 2:32 pm
by obarthelemy » Wed Dec 21, 2011 8:07 pm
Had to look for Arkell.. here it is: http://en.wikipedia.org/wiki/P.....Litigation
Posts: 1399
Joined: Tue Aug 09, 2011 10:53 pm
by bradburts » Wed Dec 21, 2011 8:09 pm
lol.
Its a good quote.
Posts: 341
Joined: Sun Oct 02, 2011 7:07 am
by jackb » Wed Dec 21, 2011 8:20 pm
Quote from JeToMad on December 21, 2011, 12:20
As I understand it, with Broadcom (and many others, such as TI with the OMAP chips) is exactly like you say: You know how to write and read the Christmas cards, but know nothing about how the delivery goes.

That was a very bad example, becase there is a excessive 3000+pg technical reference manual for the omap chips that are comercially available, there is a special omap kernel tree, and I am currenty using the DSP in one of those omap chips in my cellphone to do some SDR stuff. For Broadcom stuff there is nothing like that, because you can not even buy the chips.
Posts: 6
Joined: Mon Dec 05, 2011 11:59 pm
by Lance Constable Carrot » Wed Dec 21, 2011 8:30 pm
Quote from scep on December 21, 2011, 14:48
Quote from bradburts on December 21, 2011, 14:33
wantmypiandeatit is not real.

Are you suggesting that people actually register under an assumed name and post a troll-rant just to get a reaction?! Nah - that wouId be too sad and desperate :D


In my opinion people like bradburts are the ones who say what the most think, but the most know the answer.

I think the people behind the RPI had to work very hard to learn all the stuff necessary to build a RPI, sometimes asking for the necesary documentation to computer publications or the manufacturers, and I'm sure that sometimes getting the necesary documentation is a hard task, and even the most common answer is NO. I think we all know this.

But also we all know that without being perseverant in getting documentation we would never get the technical skills we have and we want children be able to have. Have somebody thought what a children would be able do if he were taught to use the PI DSP? We all do things in the standard-robotic way but children may find other ways and other uses, and I think we are not thinking about that.

Also I think if some today's chidren were taught to take a step beyond in programming they would be in the future as well skilled as any of the RPI's team.
Posts: 19
Joined: Fri Jul 29, 2011 6:37 pm
by Wooloomooloo » Wed Dec 21, 2011 10:10 pm
I always find it amusing when people cite the number of pages of a datasheet or other spec - be it in the hundreds or thousands - as a valid reason why no-one in their right mind would want to look at them, ever, heaven forbid. Actually, only laymen could possibly think that those documents should be read page by page in their entirety before being of any use. In fact, far from it. It's true that prolonged use of a particular chip will slowly get you acquainted with much of such a document, but datasheets / user manuals / etc. are much more like a reference - a phone book you open in a specific spot, when needing to scratch a specific itch. It doesn't matter how many hundreds or thousands of registers a chip has documented, when one usually is only directly interested in about a dozen of them at a time (unless _all of them_ have to be set up correctly before any use - that's a specific and rare case). For instance, I know my way around PIC datasheets with a blindfold on, yet I have never read the I2C multi-master part, nor do I expect to ever do it. So could we please agree to stop citing numbers of pages (or registers) as any sort of valid argument for anything?

Also, by now I think absolutely everybody save the newest of the newbies here understood what the deal with the GPU is, and (even if possibly begrudgingly) accepted it. I believe nobody is asking for that spec anymore, so "we" might consider stop being scandalized again and again about that too. What some people would still like (and I think have expected) to see at some point (="faster would be better", and yes that's really a quote) is the lowest possible (register level) spec of the allegedly non-secret, trivial GPIO parts of the SoC, which seem to have been declared anywhere between "forget it", "supported with driver, just use that", "hopefully going to be supported, if someone writes a driver" and "you'll get to reverse engineer it from the driver source" at some point in time. Of course, nobody is obliged to produce such a spec, it just seems to be the belief of some that at some point it was understood it would become available. Perhaps they were all wrong all along, it's quite possible frankly.

However, as someone coming from a hardware background to this project, I too am one of those who are accustomed to work with the silicon directly whenever we see fit, and have all specification - global architectural, part and register specific, electric, thermal, physical and everything else you can possibly think of up to and including SMD tape an reel positioning - at our disposal; a condition generally met for the vast majority of MCUs up to and including ARM class. Not being complete idiots (surprise) we do understand this is not really going to work in this specific case (and in many similar cases where GPUs are involved), but we - I at least - were definitely hoping for more than a software API and access to the sources of the drivers.

Frankly, after all the discussion on this I'm still very much confused about if and how much of a more specific spec is about to become available, but I'm not writing this trying to demand anything - I'm way past that. Just trying to clarify what I (and a few others I think) were saying / asking for all that time. I came here looking for a step-up from the standard 8/16/32-bit MCU (Arduino class if you will), looking for the same just with more oomph at less than daylight robbery prices (like a certain canine-related board et al.), and it starts to slowly dawn on me this might not be it - entirely not for architectural, but for mere legal reasons. I need hardware that I'm allowed to control. And honestly, I still have no idea how much of that I'll get to have here. That's all, thanks for reading.
Posts: 92
Joined: Fri Nov 25, 2011 10:52 am
by Neil » Wed Dec 21, 2011 10:36 pm
Quote from jamesh on December 21, 2011, 12:28
All the code running on the GPU itself is private, but without the custom compilers etc, you can't do anything with it anyway, and it's complexity means most people coming to it would throw up their hands in complete bewilderment.


Yep I'd agree with that :)
Posts: 88
Joined: Thu Sep 29, 2011 7:10 am
by Jessie » Wed Dec 21, 2011 10:56 pm
This is not a microcontroler it is a SOC. If you want a MCU then the R-Pi and it's Chip are not it. Nor were either designed to be. It does have some functionality that is similar to one but it is not one. Look into a STM32 F4 for a capable ARM based MCU with a full manual, they were giving eval boards for free for some time and even if you buy one they are very inexpensive.

I would like to see full documentation for this chip myself, but it isn't going to happen. Everyone needs to stop dwelling on what isn't there and focus on what is. No product will be all things to all people.
User avatar
Forum Moderator
Forum Moderator
Posts: 1168
Joined: Fri Nov 04, 2011 7:40 pm
by bradburts » Thu Dec 22, 2011 12:08 am
Quote from Wooloomooloo on December 21, 2011, 22:10
I always find it amusing when people cite the number of pages of a datasheet or other spec - be it in the hundreds or thousands - as a valid reason why no-one in their right mind would want to look at them, ever, heaven forbid.


Sounds like a good reason to understand them to me :)
Posts: 341
Joined: Sun Oct 02, 2011 7:07 am
by cruzzer » Thu Dec 22, 2011 12:11 am
Many things have been said and surly everyone has their point, but I think people are looking at R-Pi and believe it's the eternal solution to any need associated with a small computer. Think about it, this is a 25 dollar PC! Life is a compromise and obviously some have been made when creating this device.

So here is the question, what do you want? I don't know about you guys, but i want a little computer that allows me to wright some cool code to display some logs and do live monitoring on a screen mounted to my wall.
I don't need the GPU source for that. I'm all for open source, but if you start rejecting every devices that use any type of closed-source code, then why are you using your keyboard or screen?

The team wanted to do something cool with an amazing amount of power (considering) for a small price. I think with this compromise they meet the demand of the majority of people that will be handling it. You also don't walk in to a shop and ask the owner how he may dare sell you something that doesn't meet every single demand you have. You just buy it or you don't.

I wish to thank the R-Pi team for their efforts and hope they don't get burned from these kind of reactions.

cheers
Posts: 3
Joined: Wed Dec 21, 2011 11:42 pm
by kme » Thu Dec 22, 2011 12:42 am
@cruzzer - well put, I totally agree. I too have my personal wish list, but so do all of us. No one is forcing me to buy a R-Pi, and I could just pick up something else - with other compromises.
Posts: 448
Joined: Sun Sep 04, 2011 9:37 am
by bradburts » Thu Dec 22, 2011 1:32 am
There was a very naughty boy here today. I can assure you that Santa will not be visiting.
Other than that I think that discussion have been fairly polite, no-one is demanding or ranting.

I think that the discussions are usually quite open. Other than Mr Naught I do not recognise the picture painted.
People have not demanded. Wandered and wished for maybe.
I have no doubt that our views and opinions have influence. I am sure that all but the rudest are listened too and that there is reflection.
We are talking within a community lead by excellent engineers & scientists after all.
Posts: 341
Joined: Sun Oct 02, 2011 7:07 am
by Neil » Thu Dec 22, 2011 5:31 am
I think perhaps a visit from ALLCAPS..?

http://redwing.hutman.net/~mre.....llcaps.htm
Posts: 88
Joined: Thu Sep 29, 2011 7:10 am
by DavidS » Thu Dec 22, 2011 6:44 am
There is no need for an open video architecture so long as the GPU binary exports a well documented OS independent API for accessing the important stuff. Why do we need to know the details so long as we can use it from any OS and even on otherwise Bare HW.

If you want a truly open video device put together 16 ARMs with DSP and SIMD instructions each running at 266MHz plus and do some creative multiprocessor programming and synchronization, then bit bang the pixels (it is possible and would only cost about 16*4=64USD for the ARMS plus all the other needed HW. :) . The Pi is the best board I have yet seen (and I have only seen it function on youtube).
ARM Assembly Language: For those that want: Simple, Powerful, Easy to learn, and Easy to debug.
User avatar
Posts: 1251
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
by bradburts » Thu Dec 22, 2011 11:03 am
Quote from Neil on December 22, 2011, 05:31
I think perhaps a visit from ALLCAPS..?

http://redwing.hutman.net/~mre.....llcaps.htm



lol.
Nice site.
Posts: 341
Joined: Sun Oct 02, 2011 7:07 am
by jamesh » Thu Dec 22, 2011 11:23 am
In answer to a massive post above which I cannot be arsed to quote, re: documentation on the GPIO. I believe there will, eventually, be some low level register information for the these.
Raspberry Pi Engineer
Raspberry Pi Engineer
Posts: 10595
Joined: Sat Jul 30, 2011 7:41 pm
by bradburts » Thu Dec 22, 2011 12:48 pm
Quote from jamesh on December 22, 2011, 11:23
In answer to a massive post above which I cannot be arsed to quote, re: documentation on the GPIO. I believe there will, eventually, be some low level register information for the these


Awwww, you spoiled it!
You're not supposed to tell us until Xmas morning!

Hope that PWM is in there as I have a robotic itch to scratch & am not sure if a PWM driver is included.

Thanks.
Posts: 341
Joined: Sun Oct 02, 2011 7:07 am
by RealTimeGraphics » Tue Dec 27, 2011 10:05 am
As an embedded software engineer , i am interested in the hardware platform

of the BCM2835 .

On a limited pin device there must be internal multiplexing to readjust the pin usage.

wil we be able to get ar least  the registers  spec for the following.

1) number and functions  of  timer control blocks and associated timers  available on the SOC

2) details of pin multiplexing .

3) no of uarts available in soc.

4) PWM setup .

5) ADC capabilities  and setup.

I find it hard to believe that this level of detail compromises Broadcoms IP.

Without  this simple level of documentation,designing new applications for the board

is a a matter of reveres engineering the current drivers and guess work.
Posts: 1
Joined: Sat Dec 03, 2011 8:30 am