Go Down

Topic: Raspberry Pi launch farce (Read 22069 times) previous topic - next topic

Grumpy_Mike

The latest disappointment is that the Pi can't do real interrupts.

Quote
The poll() system call waits for an event on a file descriptor. Your program stops running and the kernel takes over, allowing other "stuff" to run until the kernel itself sees the event, then it un-stalls your program and lets it run.


in this thread:-
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33&t=10377

As I said, I don't call that real interrupts but apparently Linux people do.  :~

Coding Badly

As I said, I don't call that real interrupts but apparently Linux people do.  :~


The Linux people need to buy a dictionary.

Nick Gammon

The underlying processor must support interrupts, surely. Even if the kernel doesn't make them available to you.

The more I read about this the more I think the Arduino is the better teaching tool, if you just want to learn microprocessors, interrupts, timers, etc.
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Jack Christensen

C'mon, guys. Surely a basic principle of any OS worth its salt is insulating the hardware from the user and vice-versa. This means we don't get to do our own I/O, fiddle with interrupts, etc., instead we have to ask the OS to do it for us. MCUs are cool because we don't have an OS and can have our way with the hardware. Apples and oranges (or, as we used to say, Apples and IBMs). Completely different mindset between the two platforms. Now, most OS allow the user to write tasks that run as part of the OS one way or another. Of course this requires some knowledge of the OS' conventions for good behaviour, lack of which results in a system crash.
MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Graynomad

I get what a couple of the blokes are saying on that thread, ie you can achieve a similar affect by running a separate task etc. But the bottom line is this

Quote
Your program stops running and the kernel takes over,


That ain't no interrupt, at least not as it's been known ever since God was a boy, maybe they should be using different terminology.

It certainly looks to me that good as it may be in many areas the RPi is not suitable for bare-metal people.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Nick Gammon


Surely a basic principle of any OS worth its salt is insulating the hardware from the user and vice-versa.


Yes, OK. Maybe they mean select(). A quick search indicates select() and poll() are similar, if not identical on some systems.

That's OK, you set up file descriptors that you are interested, and then do a select() call, waiting for an event, or a timeout.

However that's still not quite the same thing as asynchronously getting an interrupt. Eg. calculating some big thing, but getting promptly interrupted if a switch is closed.

I suppose my question is: If this is a small Unix box, running Linux, why bother putting little pins down the side to connect hardware to? Using your model, Jack, we should be connecting things via USB, with an appropriate device driver, and use high-level abstraction to hide the implementation details from the program.

But if it is more like a "high powered Arduino", which not get interrupts directly?
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Chagrin

In Unix parlance an interrupt would be called a "signal". Assuming the GPIO driver supports it you would use an ioctl system call with I_SETSIG for the file descriptor in question.

Demo on how to use Unix signals:
http://www.csl.mtu.edu/cs4411.ck/www/NOTES/signal/install.html

lesto


The latest disappointment is that the Pi can't do real interrupts.

Quote
The poll() system call waits for an event on a file descriptor. Your program stops running and the kernel takes over, allowing other "stuff" to run until the kernel itself sees the event, then it un-stalls your program and lets it run.


in this thread:-
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=33&t=10377

As I said, I don't call that real interrupts but apparently Linux people do.  :~


IMHO it say that it IS interrupt, but it also put your thread/process in wait state and go on processing other process/thread
sei nuovo? non sai da dove partire? leggi qui: http://playground.arduino.cc/Italiano/Newbie

Jack Christensen


I suppose my question is: If this is a small Unix box, running Linux, why bother putting little pins down the side to connect hardware to? Using your model, Jack, we should be connecting things via USB, with an appropriate device driver, and use high-level abstraction to hide the implementation details from the program.


Yes, exactly. I think that's a quick nod to the MCU crowd, but perhaps not entirely thought out. I'd think the best model would be to define a device (call it a port ;)) that consists of some number of pins that are controlled through OS calls and that could also generate callbacks to application code to implement interrupt-like functionality. Some OS latency would be unavoidable, but could be minimized with proper tuning and prioritization schemes. For example, maybe the "port" device, when configured to generate an "interrupt" based on an input signal, really does interrupt the CPU, which then could dispatch the proper task with minimal delay. Given that we have a CPU that is 40 or 50 times faster than the MCUs we're familiar with, one would think that perhaps similar responsiveness could be achieved.
MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

pluggy

Here you go GM, a Pi with real interrupts :



Whadaya mean, sticking an Atmega 328 on top is cheating ?  ;)

http://pluggy.is-a-geek.com/index.html

BenF


IMHO it say that it IS interrupt, but it also put your thread/process in wait state and go on processing other process/thread

I would say no.

Linux, is what it is (very different form hardcore bare bones MCU programming), but that is not what we want an OS for in the first place. It does however excel in other areas and has become pretty popular over the past three decades or so with its model of abstracting hardware from applications and not least its abundance of open source libraries.

This doesn't mean that hardware interrupts are not supported. On the contrary you can have interrupts galore and low level direct port IO with it (whatever is supported by the hardware you run it on - and ARM is pretty impressive in this respect). This however is only supported for kernel mode drivers (OS extensions) and I can't really see qualified arguments for wanting it differently.

Also don't forget that this is a multithreaded OS with all sorts of thread synchronization mechanisms. Typically you will have a main application thread waiting for multiple events. Then you have additional threads that block for single events such as keyboard, mouse, Ethernet, timers and what not. When they wake up, they signal the main thread and go back to waiting for more.

If you need the likes of interrupt driven port IO, you must extend your kernel with a suitable driver. Learning to write such a driver from scratch is not trivial and possibly out of reach for most casual developers. Adding a driver form public sources however is and then availability will depend on community contributions. Judging from the initial interest related to the launch, this seems to be happening for a lot of hardware.

cyclegadget


Sparkfun has added a tutorial page for the Pi. http://www.sparkfun.com/tutorials/372
Good links: Eagle tutorial= http://www.youtube.com/playlist?list=PLDE1858BD83D19C70
General Arduion tutorials = http://tronixstuff.wordpress.com
http://www.gammon.com.au/forum/bbshowpost.php?bbtopic_id=123

pluggy

#132
Jul 26, 2012, 11:52 am Last Edit: Jul 26, 2012, 11:56 am by pluggy Reason: 1
I'll just park a copy of this here for safekeeping :

Quote
by pluggy ยป Thu Jul 26, 2012 10:31 am
I complained about RS a while back and had the thread deleted for my trouble. They've had my money for a month with a delivery date in October. Ring up and they fob you off with "you have to email the Raspberry Pi team", needless to say I'm still waiting for a reply 3 weeks later. No doubt this thread will be going the way of the Dodo bird as well. Their justification being if you read the sticky at the top it says:

It is not the place to air general moans or complaints about RS or Farnell (or anyone else for that matter)


Since its pretty obvious RS don't give a ****, the foundations unholy alliance with said company is next in line. Already had one warning, no doubt I'll be down the road after this.

If they can't fulfil the order in a reasonable time frame, they have no justification whatever for taking your money when you place the order.

Dear Mod, I didn't start this thread, another disgruntled RS customer did, Since the foundation formed the alliance with them, the foundation have a responsibility. Of course, you can take a leaf out of RS's book and hide behind your terms and conditions..........



It is/was here :

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=23&t=12462

All rumours to the effect that the Ras Pi mods are heavy handed is totally unfounded......    
http://pluggy.is-a-geek.com/index.html

Graynomad

Quote
All rumours to the effect that the Ras Pi mods are heavy handed is totally unfounded

Looks like it.



(Sorry I had to use that emoticon, it's great.)

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.

______
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Nick Gammon

I've got a Pi. Not sure what's it good for though. ;)
Please post technical questions on the forum, not by personal message. Thanks!

More info:
http://www.gammon.com.au/electronics

Go Up