next topic »

[Reply #135 on:]

With workarounds I've got my earlier one doing part of what I envisaged it doing (webserver with far less limitations than an arduino with ethernet shield basically).  Too many fudges with all they had to do to make it as cheap as it is.  Its hopeless as a desktop replacement.  With my limited expectations of the platform, I'm battling with the poor USB / ethernet implementation (along with half those posting on the Pi forum it seems).   

@Graynomad

Its one I came across on another of my haunts :   http://www.navitron.org.uk/forum/   , I 'borrowed' it. I love it as well.

[Reply #136 on:]

At least we can say pretty much what we like here, although I think that's because the powers that be totally ignore the forum.

I don't think the two are interconnected.  I believe "we can say pretty much what we like here" for two reasons: 1. The Admins trust the Moderators to keep the conversation civil; 2. Massimo and David C ^# believe very strongly in an individual's right to free speech.


^# This is not meant to imply the other three are opposed to free speech.  Their exclusion is simply a reflection of my ignorance.

[Reply #137 on:]

By the time it arrives I'll have misplaced my marbles.

I've bookmarked this thread - lots of things to remember in another 8 weeks

It arrived today. I promptly have put it on shelf. If I have to wait so long for it, it now it's turn to wait until I have time!   

[Reply #138 on:]

I got a Pi about a week ago. It arrived unexpectedly early -- the Farnell/Element 14 site said there was a 32 day lead time expected. I ordered it Monday and got it on Friday (delivered by Toll from Singapore!)

I'm very impressed so far. I haven't had any real problems getting everything up and running, and after getting the linux distro set-up pretty much how I like things, I thought I'd jump in the deep end and try to see how feasible it was to port an Arduino program that was running at about 5000 lines of code across to Pi linux. This app runs a SPI slave device and also does some GPIO manipulation, as well as providing an ethernet server.

My main motivation for porting the program up to an embedded linux device was because of the port limitations on Wiznet style devices. The W5100 allows only four active ports to be in use at at one time, for example. That greatly limits the usefulness of this particular app.

Another issue that wasn't going to be addressed while staying in the 8 bit world was that SSL would be quite useful. Connecting to many servers these days requires SSL, which is simply never going to be available on an Arduino class device.

So after a couple of days -- it's all working! (It's not supposed to be this easy.) The SPI ioctl interface works just fine. Manipulating GPIO pins works just fine (the pins are memory mapped, you get a pointer to the mapped section of memory and write your bits there).

I was a bit worried about emulating delay(), delayMicroseconds(), and millis(), but Linux usleep() works nicely for this app. Most of my timing is of the sort "delay for _at least_ this long", so if usleep(10) actually takes longer than 10 usecs (within reason), no biggie for this app.

Emulating millis() was done by using one of the many time interfaces that return time in millisecond resolution. (I think time() in unix returns milliseconds since 1-jan-1970, IIRC.)

A bit of futzing to get the socket code to work as I required (non-blocking calls, don't raise signals on broken pipes, etc.), but working on the networking side of it is now playing to a linux box's strengths. Mapping all the Serial lib stuff to standard printf (via macros and a writing a few wrapper functions) was a bit dull and tedious, but straightforward.

So I was aiming after the port to be able to compile the same source code for either an 8-bit Arduino or the 32-bit Pi using just a few simple #define config directives, and that's not been all that difficult at all. Having gcc/g++ as the underlying compiler on both platforms helped this considerably, no doubt. (BTW, I did all the editing and compilation on the Pi itself, logged in via ssh using PuTTY from laptop, rather than using a cross compiler tool chain. Emacs, bash and gcc -- I was in a comfortable place, amongst old friends. )

No doubt in the medium or even short term I will be extending the program on the Pi to places where the Arduino really can't follow, but really, that's the whole point, in practical terms.

So anyway, it's all working, much simpler porting process than I was expecting, and overall I'm pretty impressed with the whole thing. Bang-for-buck, the Pi is a compelling deal. It does full Debian Linux (which is a distro I am already familiar with and like a lot anyway), but it also it does pin-level IO, making it an interesting hybrid. It's got Ethernet, SD card storage, and USB ready to go. Not to mention those graphics!

And, of course, the price point is amazing. Still hard to believe, actually. Honestly, I'm not sure where something like a 32-bit Arduino is going to fit in between the 8 bitters and 32-bit devices of this capability. The Pi has definitely got a place in my toolbox for now. Not sure about the Due (or its inevitable imitators), but we shall see.

[Reply #139 on:]

And, of course, the price point is amazing.

Good but it is a bit like stone soup.

I'm not sure where something like a 32-bit Arduino is going to fit in between the 8 bitters and 32-bit devices of this capability

It fits in because the Pi under Linux is not a real time device at all. Ten to 20mS can go missing at any time. That means it is no good for things like video digitisers, sound synthesisers and the like without having USB plug in hardware with the associated FIFO buffers.
I am still waiting eagerly for the 32-bit Arduino.

[Reply #140 on:]

It fits in because the Pi under Linux is not a real time device at all. Ten to 20mS can go missing at any time. That means it is no good for things like video digitisers, sound synthesisers and the like without having USB plug in hardware with the associated FIFO buffers.
I am still waiting eagerly for the 32-bit Arduino.

Fair enough. If you need to run without an OS, run without an OS. OTOH, if you need an OS, you need an OS. Horses for courses.

I'm just not sure how many apps are going to fit into the 32-bit 'Due' slot. It's a squeeze from below with the cheaper 8 bitters, and from above with the (now) even cheaper embedded Linux devices. My feeling is that it may be a pretty slim niche.

As for "stone soup", well, it's a tool. Some people can turn modest ingredients into a banquest. Others could be provided the finest ingredients, and still end up with, well, stone soup. Perhaps time to look at sharpening those cooking skills.

[Reply #141 on:]

A 256k sam3x chip (due) is cheaper than a 256k avr chip (MEGA).  Total board cost is a separate thing, and retail price is yet another separate thing.  We shall see...

[Reply #142 on:]

As for "stone soup", well, it's a tool. Some people can turn modest ingredients into a banquest.

Yes of course they can. 
http://en.wikipedia.org/wiki/Stone_soup

[Reply #143 on:]

As for "stone soup", well, it's a tool. Some people can turn modest ingredients into a banquest.

Yes of course they can. 
http://en.wikipedia.org/wiki/Stone_soup

OK, now you'll have to explain how/why the RPi is like the "stone soup" in the fable. Cool story, BTW... I've never come across it before.

I thought you were just saying "cheap, but who cares if it's basically inedible."

FWIW, I've always thought the Arduino was a bit like the "stone soup" in the fable. The core hardware and software is actually pretty ordinary, to be generous, but the third party contributions (mostly software) are where the real value is to be found in the platform.

[Reply #144 on:]

No I was saying that the so called low cost of the Pi was not so low when you have to buy a keyboard, mouse, HD TV, SD card and power supply.
Stone soup sounds like soup made from a very low cost ingredient, however in order to be edible you have to add real food. I think the authors of Wikipedia get the motivation wrong. In England it is a tale of how gullible people can be when offered what looks like a low cost bargain but then they have to buy all sorts of extras to make it any good. Another real life example is the low cost airlines like Rayan Air, flights are cheap but you pay for booking in but you can't take the flight without booking in.

[Reply #145 on:]

No I was saying that the so called low cost of the Pi was not so low when you have to buy a keyboard, mouse, HD TV, SD card and power supply.

That's a good point, and it would probably triple the cost at least if you had to go out and buy all the standard peripherals to get them to work.

But you don't always have to. I haven't bought anything for the one I'm using -- I had a spare 8GB SD card, and I'm running it as a network server, so it sits on my LAN and I use ssh or telnet from my laptop or desktop instead of a dedicated keyboard and/or monitor. I'm powering it from a USB hub, so I didn't even have to buy a power supply (although I've ordered one anyway... $5 from China on ebay. I'm such a cheap-ass.)

Other people may well have spare keyboards and mice laying about. I have whole closets downstairs with crap like that in them. I get nervous going down there though, I have dark suspicions about what may have been breeding down there.

The glass half-full view is looking at what you *do* get -- Ethernet port (on the "B" model), 2 x USB host ports, SD card slot, 2 x video, audio, some GPIO breakouts, an ARM 11 with 256MB of RAM -- and a couple of ports I haven't figured out what exactly they might be used for (cameras/video devices?)

How much are you going to have to spend on add-ons to get an Arduino with all of that (even the bits you *can* get)?

In England it is a tale of how gullible people can be when offered what looks like a low cost bargain but then they have to buy all sorts of extras to make it any good.

OK, at least I understand the point you were making now.

Actually, I think embedded Linux devices complement the 8-bit Arduino class devices nicely. While there is some overlap at edges, they really have different strengths and weaknesses. Not every application needs hard real-time, not every application needs to do SSL. I've worked with embedded Linux devices in various situations for quite a few years now, so I have a fairly good idea of what they can do already. What knocks me out about the RPi is the breakthrough price point.

And of course, the thing about real-time (which seems to be your main criticism), is "how much" real-time do you need? 

Garden variety Linux distros do what is sometimes called "soft" real time. It's got micro second timers, and if you program your app carefully, your delays will be _no shorter_ than the timeouts you have requested.

If you need to improve on average time latencies (rather than worst-case), it's easy to bump the priority up.

If you really need "hard" real-time (i.e., genuine guarantees for worst case latencies), you recompile the Linux kernel with something like Xenomai, RTAI, or RT Linux (http://en.wikipedia.org/wiki/Xenomai). Then you get a RTOS with guaranteed latencies in the order of 15 usecs or so.

I would be surprised if Xenomai has been ported to the RPi yet. But I wouldn't be surprised at all if it done in the reasonably near future -- it is running on fairly similar ARM boards already, and the Xenomai team is pretty active.

I personally think the RPi is going to attract *masses* of development interest because of the bang for buck. I'm already planning my next RPi project (which will have an AVR chip on a daughterboard, if that will soften your grumpy heart even a little :-).

[Reply #146 on:]

And of course, the thing about real-time (which seems to be your main criticism), is "how much" real-time do you need?

Well you really miss it when you don't have it. It rules out all sorts of projects that I was hoping to do with the Pi, and I am still hoping to do with the Due.

Then you get a RTOS with guaranteed latencies in the order of 15 usecs or so.

So you jump through all sorts of hoops and only get 15uS. It is not just the latency it is the fact that your thread can be closed down at any time. This rules out projects that involve timing like a lot of A/D functions. Also driving a matrix, generating PWM or servo signals are a no go. Anything that involves digitising audio or data or a soft scope is right out. One project I wanted to do was a simple audio delay with all that memory. Just a A/D, store, then D/A but you can't do that.
You also can't use interrupts like we understand them, that is deliverer direct to your running thread.

So yes the Pi can do some sorts of projects but it is limited. For example it would be a good way to transfer slow data through a web page. It could replace a lap top running Processing for several Arduino type projects, but then that is only replicating what you can do already. What I am looking for is something I can use for projects that at the moment do not have a good solution. The Pi does not seem to be that something.

[Reply #147 on:]

And of course, the thing about real-time (which seems to be your main criticism), is "how much" real-time do you need?

It is not just the latency it is the fact that your thread can be closed down at any time. This rules out projects that involve timing like a lot of A/D functions. Also driving a matrix, generating PWM or servo signals are a no go. Anything that involves digitising audio or data or a soft scope is right out. One project I wanted to do was a simple audio delay with all that memory. Just a A/D, store, then D/A but you can't do that.
You also can't use interrupts like we understand them, that is deliverer direct to your running thread.

Actually, none of this is true.

The thing is, you do a lot of this the hard-real time stuff in device drivers, which run at kernel mode, which you write to have critical sections that are not interruptable.

The interrupts are still there, of course, it's just that they are abstracted away for user space (i.e., ordinary) programs. The kernel handles the raw hardware. You want access to the raw hardware? You got it. You write a driver (which sounds daunting, but is actually not that difficult to do).

As an exercise for the reader, google Linux PWM driver, and see what you come up with.

So yes the Pi can do some sorts of projects but it is limited. For example it would be a good way to transfer slow data through a web page. It could replace a lap top running Processing for several Arduino type projects, but then that is only replicating what you can do already. What I am looking for is something I can use for projects that at the moment do not have a good solution. The Pi does not seem to be that something.

Without meaning to be rude, the limitations you are perceiving here are not really with Linux, but rather with your limited (seriously, almost non-existant) understanding of the Linux architecture. While no single tool is going to be the optimal solution to every project, an RPi running under various flavours of Linux can do a lot -- much, much more than you say. Perhaps it's time to do a bit of reading. Or not. I've pointed you to where the water is, it's up to you to do the drinking.

Let me know when you have SSL running on that Due, LOL.

[Reply #148 on:]

Actually, none of this is true.

Well according to the experts on the Pi forum this is true. These are people with 12 years plus professional usage of Linux.

Yes I am very new to Linux, however I have not got 20 years left in me jumping through hoops to fix something that is just a tangled mess. The problem is that Linux is a great mess, it is better than it was but it is still a mess. The code quality is very poor. Most of the time stuff simply does just not work, and you have to keep upgrading the distribution so that all you configuration is lost and you have to start all over again. This passes for entertainment in Linux land. You can try automatic updaters like RPI-update and that just trashes your SD card, it sould have been called RIP-update.

One problem with the Pi is the USB drivers drop frames, resulting amongst other things repeating keys on some keyboards but not others. They can't solve that so what chance have I in solving that.

Frankly if you get you kicks from writing drivers and installing stuff then Linux is for you. If you actually want to do projects then there are much better solutions.

[Reply #149 on:]

Anything that involves digitising audio or data or a soft scope is right out. One project I wanted to do was a simple audio delay with all that memory. Just a A/D, store, then D/A but you can't do that.

An RPI-class device running linux CHANGES the way you have to do such things, but doesn't make them impossible.  For instance, your audio delay project would probably best be done with a $10 USB "Sound card", rather than a $30 "Audio Codec shield."