I'm using Asus Tinker board and trying to use GPIO to control leds.
I'm very limmeted in what I can install so I'm using shell commends to do this.
like this:
echo 223 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio223/direction
echo 1 > /sys/class/gpio/gpio223/value
It's working fine but what I'm struggle to find is how can I proferm fade in/out (Breathing effect)
and I'm must stick to shell commands. so no Python or C
you need to implement PWM. In short: switching LED on and off very quickly and changing proportion of time when LED is on and off.
You can probably reach desired Breathing effect, but it's very CPU consuming. There are packages like gpio using hw timers, but installation is needed.
Related
I'm working on communicating embedded device via serial port for debug. The device supports only 1843200 bps for baud rate.
But, my usual terminal softwares (minicom, Teraterm) don't look like supporting such high baud rate as they are.
What I want to do using such terminal software is:
sending command string interactively
transporting file to the device
Thank you.
As I commented, I solved the problem myself and post it again.
Teraterm ... high baudrate can be set from CUI (command line), not GUI (926100, max).
teratermpro.exe /BAUD=1843200 /C=1
PuTTy ... Using "plink.exe" works with options like below:
plink.exe -serial \.\COM1 -sercfg 1843200,8,n,1,N
But, you could have to stop "plink" once by Ctrl-c and type like below:
plink.exe -serial com1 -sercfg 1843200,8,n,1,N < [file path]
Regarding Linux, I didn't find the way. It could be that the proper driver should be installed.
#thebusybee Thank you for your kind advice!
What baudrate that is supported by a certain UART device depends on hardware:
How high the clock source for the UART clock go.
What prescalers/divisors the UART hardware support when translating the clock source to it's own hardware peripheral clock.
Some general rule of thumb is that divisors should not give more than 3% inaccuracy from the requested baudrate. More than that and you risk spurious data corruption, framing errors and similar.
Therefore software might limit the number of supported baudrates, not to correct higher ones that will be wildly inaccurate anyway.
Needless to say your embedded device also needs good clock accuracy, so if you are clocking it from something like an internal RC oscillator while running UART at 1.8MHz, you are very likely doing it wrong.
In ttermpro you can manually set the desired baudrate even if it does not show up in the drop-down list. Just type it into the field.
I have an linux embedded system. I can manage I/Os with shell commands. This commands change out status of GPIO #48 :
/sys/class/gpio# echo 48 > /sys/class/gpio/export
/sys/class/gpio# echo out > /sys/class/gpio/gpio48/direction
/sys/class/gpio# echo high > /sys/class/gpio/gpio48/direction
/sys/class/gpio# echo low > /sys/class/gpio/gpio48/direction
How can I manage I/Os with Goland efficiently ? Is it possible to manage them without going through the shell commands ?
On Linux GPIO interface is exported via sys filesystem in /sys/class/gpio hierarchy so as in your shell example you just need to write data into these files, something like:
// To export pin 48 (same as echo 48 > /sys/class/gpio/export)
ioutil.WriteFile("/sys/class/gpio/export", []byte("48"), 0666)
...
Depending on your platform and needs you may want to consider some pre-existing package (e.g. go-rpio for Raspberry Pi or periph which is more general and supports much more than GPIO).
If you want more efficient/faster solution than writing sysfs files you might also consider memory-mapped GPIO access where you basically directly access GPIO periphery via memory range given to it by the kernel. This requires somewhat deeper knowledge of your target platform (understanding its GPIO registers and their mapping). You can read about that approach in detail in this blogpost.
EDIT: As #0andriy pointed out in his comment gpio syssfs is deprecated. That applies for both your Bash example above and my answer how to do same thing in Go. Instead a new ABI was introduced and libgpiod to interact with it. Go port is available here https://github.com/warthog618/gpiod.
I just started with microchip world.
I'm about to buy a PicKit3 and i've seen it can outputs from 1.8V to 14V MCLR.
The pic i will use is the PIC16F1829 and it should work with MCLR # 5V.
In the datasheet it seems i would need a zener/shunt to limit the voltage.
First of all isn't there a board ready to play with?
Can i use LVP? If so using MPLab 8 IDE how do i change in LVP?
Is the pin connection the same?
Since i haven't bought it yet i would rather avoid burning a pic
Regards,
Notes at the bottom of page 345 in the PIC16F1829 data sheet (DS40001440E) recommends using a voltage limit circuit when using the ICD2 device programmer.
According to Microchip this is "not required" when using the PICkit3.
Get a few extra PIC16F1829 just in case.
You ask about boards ready to use, take a look at the Curisotiy Nano boards
https://www.microforum.cc/topic/9-microchip-xpress-evaluation-boards
These are ready to use and do not need any programmer. You can simply send a file to these devices over USB. They are also have debugging capability.
In terms of the 14V on MCLR, the device is designed to handle whatever pulse will be generated by the PICkit3, so you do not need any protection for the PIC against that. In fact limiting the voltage on that pin will prevent the device from programming so you definitely do not want to do that. If you are however using this pin to connect to other parts on your board the other parts probably will need protection.
You can most definitely use LVP, just be careful, it is possible to use LVP to disable LVP, and then the only way to get it back on is to use HVP!
Lastly in the IDE under programming options you can change the mode there (Use low voltage programming mode entry)
In the IDE i've set the voltage appropriately and everything went ok on its own.
I didn't have to enable anything fancy
Currently I'm trying to check the booting time of an Tixi board using systemd on a 2.6.39 linux kernel. To do so I created a service file that calls a bash script which sets and uses a gpio. The problem is that my systems is not allowing me to change the value of the gpio. I can sucessfully export it, change its direction, but NOT the value. I have connected an oscilloscope to check if the value had changed in the hardware but not updated in the file as suggested in some forums, but it was the same: the value just doesn't change!
I should also point out that the same script is working if I use system V, with exactly the same coonfiguration for the kernel, busybox and filesystem.
It is very ironic because I'm already the root of the systems, nevertheless even changing the permissions of the file, would not allow me to change its value. There is also no feedback from the kernel saying that the operation was not possible, but rather it looks as if it was possible but when I check the value, it was the same as before.
I also tried to run that in the Raspbian with a 3.12 (which I changed to systemd) and it was in fact possible to do it, just in the normal way from userspace.
I would appreciate if you have any idea oh what might be the problem since I already run out of ideas.
Thanks
PS: This is the code that should work on the bash line:
echo 0 > /sys/class/gpio/gpio104/value
more /sys/class/gpio/gpio104/value
// I get 1 not 0 as I requested
Nevertheless the same lines of code in the same board work if I use systemV but not if I use systemd
Probably cause by the lack of udev in your new setup which change the permission for those gpio in /sys/class. You might want to just put back udev to see if it fixes your problem.
I don't know your image setting, but each gpio pins needs to be exported prior to usage. Are you doing it or it's done automatically? If you have omap mux kernel switch, you do something like :
echo 0x104 > /sys/kernel/debug/omap_mux/cam_d5 (set mode 4 as stipulate in TI Sitara TRM)
echo 104 > /sys/class/gpio/export (export the pin)
echo out > /sys/class/gpio/gpio104/direction (set the pin as output)
Also do a dmesg | grep gpio and see if there's any initializing problem with the gpio mux.
Actually I've faced an issue similar to your's , ie was not able to change the value of set of gpio pin manually
Finally the result obtained was even though the name of that pin is gpio it can only be used for input only (DM3730 gpiO_114 and gpio_115).
So please refer to the datasheet and confirm it can be used for I/O operations..
I am trying to use the expansion header to control a couple motors and auxiliary task mechanism. For this I am using the appropriate pins as GPIO and merely attempting to send high or low signals as needed by the robot. (For instance, I might need the robot to move forward and so I'd send high signals on both sets of pins, whereas if I needed the robot to turn I'd send a high signal to one pin and a low to the other.)
However, the problem is that the pins will only stay high! I've followed the conventions for sysfs just via the terminal, and, although I'm able to set the "values", "active_lows", etc. to 0 or 1, I can't actually get the pins to send 0V. After checking the beagle.h file I used for u-boot it looks like the multiplexer mode is configured correctly. This is also reflected when I get the info from sys/class/gpio/gpio%/% and sys/kernel/debug/gpio. Furthermore I don't get any errors or indication from anywhere that there is something wrong...it just doesn't work!
What should I do? For the first time in my life I have seemingly exhausted the internet...
details:
Beagleboard xm rev c1
ubuntu 12.04
kernel 3.6.8-x4
Im pretty new to the beagle board and I have recently been trying to configure the GPIO pins on my classic beagleboard c4, which i believe should be fairly similar.
Half of my GPIO pins seemed to work fine and the other half seemed to remain high or low no matter what i did. Even though they were configured the same way as the working pins in /sys/class/gpio/
have you tried to use other gpio pins?
I ended up following http://labs.isee.biz/index.php/Mux_instructions
to configure the mux to 4 and now i can control the pins that were not working.
I basically used the command:
sudo echo 0x004 > /sys/kernel/debug/omap_mux/(mux 0 name)
where (mux 0 name) was the name of the subsystem for the mux 0 setting for the gpio pin you wish to configure
ie. for gpio 183 on beagleboard c4
sudo echo 0x004 > /sys/kernel/debug/omap_mux/i2c2_sda
Though I had to change permissions to modify these files
As I said I am pretty new to the beagleboard and ubuntu but this worked for me so I thought I would share it with you, I hope it is of some help.
Regards;
Paul;
It seems that the beagleboard expansion pins are numbered in alternating fashion, as clearly and professionally depicted here.
Thanks to everyone for your help. I now know way more than I should about GPIO on OMAP systems (and so do you). Good luck on finals/life!**
tl;dr I'm an idiot!