P6 - reset pins (model B)

It's a hard reset and will trigger a reboot.

Gordon

Gordon Henderson in data 13:37, lunedì 09 settembre 2013, nel gruppo comp.sys.raspberry-pi ha scritto:

Thank! Know solution for rapid shutdown using a input pin? Same when you press the on/off button on portable pc with windows.

--
+----------------------------------------------------------------------------+ 
|             Due galli in un pollaio senza galline, diventano gay?          | 
+-----#41--------------------Diamanti di saggezza.---------------------------+

Yes, me too. Graceful shutdown, as if you'd sent "shutdown now -h" from the console.

--
Graham. 

%Profound_observation%

Why not just stick a push button on one of the GPIOs and monitor its status?

Install wiringPi.

Put this in a file and run it at boot time:

#!/bin/bash

pin = 0 # wiringPi numbering scheme = BCM_GPIO 17, Phys 11

/usr/local/bin/gpio mode $pin up # Enable internal pull-up /usr/local/bin/gpio wfi $pin falling # Wait for input level to drop /usr/bin/sudo /sbin/halt

connect a button between the pin and ground and off you go. Just don't push it accidentally.

Gordon

Gordon Henderson in data 10:21, martedì 10 settembre 2013, nel gruppo comp.sys.raspberry-pi ha scritto:

Thank, very, very much!!!

--
+---------------------------------------------------------------------------+ 
|Al termine delle elezioni,la madre superiora fa la conta dei voti:         | 
|DC, DC, DC,... PPP. Chiama subito suor Maddalena per le spiegazioni...     | 
|Si era rotta la punta della matita, ed ho scritto: PORCA PUTTANA LA PUNTA! | 
+-----#8---------------------Campagna contro le pubblicita` idiote.---------+

Or press the button for more than a few milliseconds.

Rob Morley in data 02:27, martedì 10 settembre 2013, nel gruppo comp.sys.raspberry-pi ha scritto:

Only if you know the exact moment that the input will be activated!

No bueno!

--

+---------------------------------------------------------------------------+ |Al termine delle elezioni,la madre superiora fa la conta dei voti: | |DC, DC, DC,... PPP. Chiama subito suor Maddalena per le spiegazioni... | |Si era rotta la punta della matita, ed ho scritto: PORCA PUTTANA LA PUNTA! | +-----#8---------------------Campagna contro le pubblicita` idiote.---------+

or you aren't stuck in Someone Elses Interrupt.

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

Excuse me this is much more important! I've really got to get this done RIGHT NOW

:)

--
W J G

#every_pi_should_have_one

Thanks Gordon.

--
Graham. 

%Profound_observation%

A slight change to this:

If you're not using I2C, then use one of the I2C pins. They have on-board pull-ups, so you don't need the gpio command to enable the pull up.

Same action as before, push the button to halt the Pi - however now, once it's halted, if you push the button again (without an intervening power cycle), then it will reboot the Pi...

In a halt state, the GPU is still running and listening to the I2C pins - and when it detects either going low, then it resets the system and reboots. It's still consuming about 100mA, but that's the difference between a set-top SoC and a mobile phone SoC ...

The I2C Pins are wiringPi pins number 8 and 9, or Physical P1:3 and

1. In BCM_GPIO world they have different numbers between a Rev 1 and Rev 2 board. Stick to wiringPi or P1 numbering schemes...

Gordon

The Pi supports edge-level interrupts and these can be directed to user-land programs, so you don't need to poll the pin, just wait for the interrupt.

It's not quite the same as on a microcontroller as Linux deschedules your process, then when the interrupt happens, Linux has to wake your process up again and make it runnable, however the interrupt will never be missed although it's not as fast to run your process as something directly in the kernel. My tests showed that I could vector an interrupt into a Linux process at a rate of about 66KHz.

Gordon

Er no. If the scheduler stops running or is locked into a higher priority interrupt - and that's when you NEED a reboot button - linux will simply never reschedule your task.

The point about a hardware reset is that t works when all other methods beyond yanking the power cord, have failed.

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

I have experimented with the watchdog, which should cater for that, but I cannot get it configured correctly. See other thread.

NO software reset is ever 100% proof against a poorly written ISR somewhere else in the system that won't let go..

That's why you have hardware resets in the first place. They are guaranteed to be absolutely 100% the top priority interrupt. Hardwired to reset the instruction pointer to a predictable address,

Using software to reset software is about as dumb as my ISPs help page which says ';if you are unable to get a connection, please check our website for reports on current outages'

Duh!

By all means have watchdogs, detectors of 'reset' button software etc., but don't expect it to get you out of trouble when the inevitable finally happens...

I've typed 'reboot' often enough on this computer, and had it lead to a hung machine with no sign of rebooting going on.

Or stick at the bios flash screen, and never actually load the boot loader.

--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

Re. brutal shut-down: I'm using my rPi every day like an 8-bit uProc [or light] -- just unplug the power. The power-off-switch is used as a time-modulated controller, thus: to control a stack of text-to-speech *.wav files, which I periodically lie down and listen to in a location which has no mains-power, so I just have the rPi & USBstik [for *.wav & control script] & 6v [+ diode] accumulator.

IIRC the control allows me to disable a *.wav from replaying by, at the end of the play by: mv $1.wav $1.wax # the main loop plays *.wav from the stack aplay mv $1.wax $1.wav # restore the cancelled wav, to play next time

Now I want to extend/refine that, to be able to cut the power WHILE the TTS is playing, to 'cancell that *.wav from further playing', instead of waiting till it's done.

It's too complex for me without 'tools like Karnaugh-maps or ladder diagram methods' to cover all the combinations.

Can someone advise.

BTW, depending on your personal psychology, lying down and having the complex text read to you can be very efficient/relaxing.

== TIA.

What is the for the ARM? It's often 0 for many systems. Where would you get the bytes-codes, for a minimal routine [without opening the canOworms of installing an assembler] to eg:- = loadImmedite #N to RegI = Store RegI to mem:M = Branch unconditional -1:relatve // for loop-forever.

Perhaps an ARM-group will give it ?

==TIA.

The ARM reset address is unimportant - it's the GPU that is in control.

The GPU loader sets up the memory and hardware while holding the ARM in a reset state. The GPU code then loads the OS image into RAM (at 0x8000 by default) and triggers the ARM to start running from that address.

Don't forget the ARM is really a small slave co-processor to the GPU.