Here is a review of the Raspberry Pi from the forum:
This is my “home” forum for embedded stuff, as the community here is good. Though I note Raspberry Pi (here forward R-Pi) has its own forum (I’m teholabs there).
I wonder how many persons here got one? I ordered on day 1 (March) and just got mine this week… Eeppp. But I’m sure they will catch up in not too too long.
So I have some mixed feelings about R-Pi, on the one hand a lot of the fun of doing embedded system stuff for me is to see how much you can do with very little. People laugh at me when I tell them I have 512 bytes of memory for a project.
Read the full review below.
However, simple to use is good and always reinventing the wheel is not needed. While I like to code, implementing some protocol I didn’t design isn’t a lot of fun. Linux is a big big help there. I don’t have to port SSL/TLS for instance it is just there. This makes R-Pi a great way of being on the internet in a secure way. This is possible with my Procyon board as well but it isn’t as easy honestly as having an OS with a huge amount of software to throw at the problem.
I think a lot of people were expecting a lot for their 35 dollars (+ SD card + screen + mouse + keyboard; no so cheap now is it), investment… (though you can always SSH in ;-), but still need an SD card).
I started with Arch Linux, for a console application I think I would use Arch (at this point). At first it didn’t display anything over HDMI (I have it hooked to a TV). After a quick search I learned about the somewhat opaque config file.
R-Pi has a FAT boot partition. This holds the stuff that it needs to read for boot both kernels and configuration details. The configurations are all text files. The Arch image has a config.txt in this FAT partition. The file tells it to use HDMI_MODE=X (I forget the number but it is UK frequency). Thus my TV didn’t show anything, because it doesn’t support that refresh rate. I realized this when I did a quick google and found I should delete this file.
If you don’t have a config.txt it uses whatever mode the TV/Display wants. Okay great, only thing is it didn’t fill up my TV. To fix this you add overscan offsets to fill the rest up (In the troubleshooting eLinux FAQ). There is a post in the beginner section of R-Pi’s forum about HDMI modes (it is a big list). To start with though have no config.txt later you can add one.
After installing X and openBox on Arch (using VESA and fbdev as the video drivers) I decided to give another Distro a try, as it wasn’t all that smooth. I thought the recommendation was Fedora Remix based on some comment on the eLinux wiki. I have to say I did not find the Fedora remix acceptable at all. Performance was far worse than Arch subjectively. I then decided to try Debian’s image. This is what the “alpha” boards used.
It works quite well they were smart and used Midori and not Firefox and lots of other little things. I also note that Debian has a swap partition in the image while I know Arch didn’t and I don’t think Fedora did either. This could be why it runs better or it could be the kernel or maybe it is using a video driver other than VESA. I posted a question about this on the R-Pi forum but no answer as yet.
This might be Linux but a heavy distro full of software you don’t need like the Fedora Remix is currently is totally inappropriate for an embedded system.
I’m sticking with Debian for now using R-Pi and would recommend everyone use it for now at least, though no doubt progress will be rapid. However if I was done with a project that didn’t need a screen I might well go back to Arch for the no frills, configure everything base it has. I like that more for “I’m going to deploy this”.
The full datasheet for the BCM2835 is not public. Boardcom like Marvel is one of these companies that is highly unfriendly to anyone but volume people. I don’t honestly see how that helps them at all… But whatever the case may be a partial datasheet was released for the chip.
If you are used to micros this is the key stuff. Also Gert’s software for the Gertboard is that always helpful programming example to get started.
He nicely made it public domain, so we are free to crib from it. Though the pointers he chooses are a bit odd in places you can see what he does to get to the memory map for GPIO and things. Importantly he has basically handed everyone GPIO both in and output (with pull up/down), SPI, I2C, PWM and UART (though he doesn’t use it it is written down in the code).
The big difference here with R-Pi vs. regular embedded system programming is of course this isn’t embedded system programming by which I mean it is a program running on a OS with lots of processes and that OS is not a RTOS, so timing is not promised. This is a big deal and a big difference. I bet people will piggyback simple micros like AVR for just this reason.
I also think it will be interesting to see if/when someone does a RT-Linux flavor. They do exist.
I found getting started with the hardware not hard though and my first project is already under way.
Via the forum.