Is it always necessary to free a GPIO pin after you have requested it? What does freeing a GPIO pin do and what happens if you don't call gpio_free()?
Calling gpio_free() means to disconnect it from power (GND or 3V3) if it is set to output type. I have written a c program which needs a ctrl+c keyboard interrupt to quit, so it cannot free the used pins, this means there is still voltage on the pins when te program quits, but when I restart it it resets the pins, so not calling gpio free does not stop any code from working, but the pins stay connected to power after quit.
Related
I have an (Adafruit Feather Huzzah) ESP2866 WiFi module which has an (EN) pin to disable the 3v3 output on the chip. This pin is pulled up by default and normally you would just connect it to GND in order to switch off the 3v3 regulator (and disable the peripherals).
What I am trying to achieve is that when the ESP2866 is in "Deep Sleep" mode that the 3v3 output is disabled. Ideally if there was a pin that was pulled down by default when the device is asleep then I could just hook that into (EN) pin but I don't think this exists. However, there are pins that are pulled high by default when the device is fully awake.
What I was considering doing was using a high value resistor to create a weak pull down on this pin by using this to join GND to (EN). Then I would also directly join another pin that is pulled up when the module is on to "cancel out" the pull down. I have a feeling that I might need to end up using a transistor (or a few components) to toggle this low.
Reading the Adafruit forums I have since discovered that pulling the EN pin also switches off the ESP2866 internal circuitry so it will never come back out of deep sleep. On this basis there is no solution to this specific question as there will never be a high pin (without some form of external circuitry).
Thanks to those who bothered to read.
I am trying to enable DDR in sd (spec above 2.0) the procedure in the specifications is as follows
Execute CMD0 to make the card idle
Execute CMD8 to enable ask about the voltage requirements
Execute ACMD41 with S18 bit enabled and log for S18 in the reply to see if the card has voltage switch functionality: checked and the card has the functionality
Now execute CMD11, if the card replies with a response the voltage switching sequence is started, the cmd and data line should go low: checked and yes they do
Stop the clock,
Program the voltage switch reg (with 1.8V) and wait 5 ms
Start the clock: the card should start at speed SDR12 with 1.8V: cmd and data lines should go high, a cmd_done interrupt should be received: NOT RECEIVED
Any pointers regarding this would be helpful...the card status registers shows that there is a data transfer in progress and the card is not present. After this I cannot execute any CMD (the cmd_done interrupts are not received)
For the sake of helping others, the process explained above is correct. The problem was on the board side i.e. there were no 1.8v regulators connected on the board. So first make sure that the SOC or the board has those connectors available. In case of mmc, ddr mode can be enabled with 3V so the above case is only valid for sd.....
I would like to know if it would be somehow possible to handle a Serial.println() on an Arduino uno without holding up the main program.
Basically, I'm using the arduino to charge a 400V capacitor and the main program is opening and closing the gate on a MOSFET transistor for 15 and 20 microseconds respectively. I also have a voltage divider connected to the capacitor which I use to measure the voltage on the capacitor when its being charged with the Arduino. I use analogRead() to get the raw value on the pin, multiply the value by the required ratio and try to print that value to the serial console at the end of each cycle. The problem is, though, that in order for the capacitor to charge quickly, the delays need to be very small (in the range of microseconds) and the serial print command takes much longer than that to execute and therefore holds up the entire program.
My question therefore is wherther it would somehow be possible to get the command to execute on something like a different "thread" without holding up the main cycle. Is the 8bit AVR capable of doing something like this?
Thanks
Arduino does not support multithreading, but there are a few libraries that allow you to do the equivalent:
Arduino Multi-Threading Library
ArduinoThread
For more information, you can also visit this question: Does Arduino support threading?
The basic Arduino serial print functions are blocking, They watch the TX Ready flag then load the next byte to transmit. This means if you send "Hello World" the print function will block for as long as it take to load the UART to send 10 characters at your selected baud rate.
One way to deal with this is using high baud rate so you don't wait long.
The better way is to use interrupt driven transmit. This way your string of data to send is buffered with each character sent when the UART can accept the character. The call to send data just loads the TX buffer, loads the first character into the UART to start the process then returns.
This bufferd approach will still block if you fill the TX buffer. The send method would have to wait to load more into the buffer. A good serial lib might give you an easy way to check the buffer status so you could implement your own extra buffering.
Here is a library that claims to be interrupt driven. I've not used it myself. Let us know if it works for you.
https://code.google.com/p/arduino-buffered-serial/
I found this post: Serial output is now interrupt driven. Serial.print() just stuffs the data in a buffer. Interrupts have to happen for that data to actually be shifted out. posted: Nov 11, 2012. I have found that to be true BUT if you try to print more then the internal serial buffer will hold it will lock up until the buffer is at least partially emptied.
I'm working on a project with Android and Arduino and am trying to figure out how on the Arduino side to tell if the Bluetooth is connected or not.
I'm using one of these Bluetooth Modules to connect. I know I can send a command through Android, but I'm trying to have an action happen automatically when they connect and not have to run a background application on the Android if possible.
Using the module supplied and nothing else you cannot: notice the module has four connectors:
Power (Vcc)
Ground
Tx (send)
Rx (receive)
Given this interface the only way to determine whether the bluetooth module is paired is to send something to the paired device and have it respond in such as way that your Arduino knows that it is connected. For instance, if your Android program always responds with "Hi there!" when it receives a string "Hello?", then by seingin "Hello?" your Arduino will know that it is paired with your Android phone/tablet. Your Arduino could poll (send the interrogation string) every minute (or every five seconds) to see if it is paired with your device.
There is a better way, but it will require some soldering on your part. If your module is HC-03/HC-05-based, then the PIO9 pin is the "paired indicator LED" (see datasheet here). You could connect that pin to an Arduino input pin and read the level: reading digital 1 will indicate that the device is paired, while reading digital 0 will indicate that it is not. It is possible, though not certain, that the pin on your module labeled STATE is exactly this kind of a pin, i.e. it indicates the paired status. Unfortunately. this pin it isn't connected to the header, so you'll have to solder a wire to the correctponding pad to connect it to your Arduino. You should test it first by connecting a multimeter in voltage mode to that pad and measure the potential between that pad and ground in paired and non-paired state. If this is the pin that responds to the paired state then you are golden. It might be that it indicates power (like the HC-03/05 PIO8 whilc blinks when on). If it turns out that the STATE pin is not the pairing status, then you should request a datasheet from your supplier, and use that to find the status LED connection: one is likely to exist. Once you found the correct pad, verify its function using the voltmeter again. Then solder a wire to that connection and read it from your Arduino.
IMPORTANT: Make sure that your Arduino never puts out a digital 1 on the Arduino pin connected to the bluetooth module status pin: these bluetooth modules run on 3.3V, and connecting any unprotected pins to 5V will be damaging. The Vcc and Txd pins are voltage shifted in the module you bought, but the LED/Status lines are likely not to be. So if the Arduino pin connected to "status" on your Bluetooth module is configured as output and you digitalWrite(HIGH) to it, you will likely damage the Bluetooth module.
Unfortuntaely, the HC-05 will switch states when paired, but won't output a 1 until it's actually connected to something.
For instance, I can unpair my phone from the HC-05, pair again, and then the LED will change state, but the output of the STATE pin is still 0. If I open up an app, and connect to the device manually then the LED, and STATE pin will change state. The LED will periodically blink twice, and the STATE pin outputs a 1 to the Arduino.
If you would like to read the the value of the STATE pin, connect a wire to any of the inputs to the arduino, and code Serial.println(digitalRead(inputPin)); inputPin being the wire to the input of the Arduino.
I've been fighting this thing for months, and have yet to find a way to make this thing automatically connect to my phone. It won't even allow for me to connect to it from my phone to the HC-05 unless I download an app onto my Android. It's possible to bind the HC-05 to a certain address, but even this did not work for me. I want to mess with the "AT+CLASS" command, but the documentation behind the instruction has hindered me thus far.
From the HC-05 datasheet we see that the connection status depends on the output from PI09. Apparently sending "AT+BIND?" to the module will return the status of PI08 & PI09 in the form,
"+ POLAR=PI08,PI09" however this makes no sense to me because in order to get this you must enter AT mode and entering AT mode will disrupt the paired connection, hence it will always send PI09 marked as "not connected".
THUS in order to see if the connection is still live from the arduinos POV I can only see 2 feasible ways:
Program arduino to, every so often, send a "hello?" and if it doesn't receive the expected "Hi back" response, then it is to assume that it isn't connected.
Connect PI09 to an arduino input pin and read it's value whenever you want to check if the connection is live or not
AT+STATE? will return the current state of the connection. Yes you will need to enter at mode, that is done by bringing up pin 11 HIGH on the HC05 module. It does require soldering but it's kinda worth it. It then allows full AT control of the device, then set it LOW to return it to normal working mode.
Another option, which I don't fully understand, is the AT+MPIO? command, which returns the state of all the pins in some strange masked format I don't understand yet.
I use the first option above so that I can terminal (Bluetooth) from my phone to the HC05 and switch on a led/relay etc (ie bring up pin 2 to HIGH) on the HC05. This required entering AT mode (pin 11 HIGH), sending the command AT+PIO=2,1 and then setting pin 11 to LOW to return to normal working mode.
Note: I noticed I had to put a 200ms delay in between high and AT and LOW commands. Angela's solution is nice - I use a cheap XBEE Bluetooth module (HC-05 Bluetooth Bee Master & Slave Module with Bluetooth XBee for Arduino uk2015) 2 units(HC05/6) for 5Stg which are laid out in XBEE format - handy for the 3.3v.
When I press a keyboard's key on some GTK application under Linux, what happens exactly? How does a key get received (from which device), interpreted, passed to the program, and then handled?
It's actually rather a complex process...
The keyboard has a 2D matrix of key connections and its own microprocessor or gate array containing a microprocessor. It is constantly scanning the matrix to find out if any keys are pressed. (To save pins, the keys are not individually tested.) The keyboard micro speaks a protocol with the keyboard controller in your CPU and transmits a message indicating a keypress.
The keyboard controller notes the code and interrupts the CPU.
The keyboard driver receives an interrupt, reads the keycode out of a controller register, and places the keycode in a buffer that links the interrupt side of the kernel to the per-process threads. It marks the thread waiting for keyboard input as "runnable"
This thread wakes up. It turns out, this is the X server. The X server reads the keycode from the kernel.
The server will will check to see which window has keyboard focus. The window will be connected to one of various clients.
The server sends an event to the client that displayed that specific window. (Note that to the server, every textbox and such is a "window", not just entire applications.)
The event loop in the client is waiting for the next server event message. This connection could be via TCP or it could be a local Unix feature. It uses read(2) or a socket op to actually get the next event message.
The low-level xlib routine passes the keypress up to higher level widgets, eventually getting to a GTK function of some kind.
The GTK API element hands the character to your program.
I glossed over language mappings, console multiplexing, and a few other things...
Update: So, /dev/input/* and in fact all of the /dev/* things are things called block or character special files. The important thing is that they have no stored data in the filesystem, just a major and minor device number that serve to look up a driver in the kernel in a table. It's almost that simple. If you ls -l /dev/input you will see a major and minor device number instead of a file size. The major number identifies the device driver and the minor number is a sort of instance-number that is passed (within the kernel) as a parameter to the driver.