I followed this answer to enable PWM on my Beaglebone Black, but I wasn't sure if that method is using the PRU to do hardware PWM or if it's toggling the pin in software? I see other references to /sys/class/pwm/ehrpwm (e.g. here) which I'm more confident is hardware PWM, but I'm not sure how to enable that interface.
To summarize how I'm enabling PWM:
echo am33xx_pwm > /sys/devices/bone_capemgr.9/slots
echo cape-universal > /sys/devices/bone_capemgr.9/slots
config-pin P8.13 pwm
echo 6 > /sys/class/pwm/export
echo 1 > /sys/class/pwm/pwm6/run
echo 50000 > /sys/class/pwm/pwm6/period_ns
echo 50000 > /sys/class/pwm/pwm6/duty_ns
Thanks!
Yup, that's using the hardware PWM modules - the am33xx_pwm overlay enables all the different PWM subsystems (eHRPWM, eCAP), then the PWM kernel driver configures the corresponding PWM module for the pin being configured.
Related
I have a bit of a hacky setup on my laptop where I use optimus-manager to configure my screen layout at X startup based on whether an external monitor is connected or not. If it is, I only want to use the external monitor and not the laptop monitor, but because of a limitation of NVIDIA drivers, I need to leave my laptop monitor on, and just lower the backlight brightness. See my /etc/optimus-manager/xsetup-hybrid.sh for how this works (eDP-1 is my laptop screen, and HDMI-1-0 is my external monitor):
#!/bin/sh
# Everything you write here will be executed by the display manager when setting up the login screen in "hybrid" mode.
xrandr --output eDP-1 --mode 1920x1080 --pos 3000x0 --output HDMI-1-0 --primary --mode 2560x1080 --pos 0x0
if [ "$?" -ne "0" ]; then
echo "Not connected to display, don't dim internal monitor"
exit 0
fi
echo 0 | tee /sys/class/backlight/intel_backlight/brightness
Notice that eDP-1 (laptop monitor) is positioned at 3000x0. I've done this to keep the screens far enough apart so that my mouse can't accidentally stray from my external monitor's screen into my laptop monitor's screen.
This works pretty well, but for some reason every time I log into awesome (or anytime I change the screen layout with xrandr for that matter), awesome focuses the laptop monitor screen by default, even though xrandr is specifying the external monitor screen as --primary.
How can I change this behaviour so that my external monitor screen is focused by default if that monitor is connected, falling back to my laptop screen if it isn't?
You could warp the mouse cursor to the primary screen in your config:
mouse.screen = screen.primary
The above can also be tested in an already running awesome session via awesome-client: awesome-client 'mouse.screen = screen.primary'.
If you want to decide the pointer coordinates more precisely (the above uses the upper left corner of the screen), there is mouse.coords({ x = 42, y = 21 }).
It's likely apps are being displayed where the mouse currently resides. You could use xdotool to ensure mouse is on desired display to begin with.
#!/bin/sh
## executed by display manager during login
if [ "$?" -eq "0" ] ; then
xrandr --output eDP-1 --mode 1920x1080 --pos 3000x0 --output HDMI-1-0 --primary --mode 2560x1080 --pos 0x0
echo 0 | tee /sys/class/backlight/intel_backlight/brightness
## sudo apt install xdotool
## x, y coordinates: half of 2560x1080, so middle of main screen
xdotool mousemove 1280 540
else
## external display not plugged in
xrandr --output eDP-1 --mode 1920x1080 --primary --pos 0x0
fi
I was able to flash a micropython binary which I'd cross compiled some 6 months ago, and it was working fine. It was built from master branch at that point of time, and I did not save the code, nor the binary.
Today, when I again compiled, the binary is having problem at a point. So I want to revert back to the old binary, only problem is I'm not sure what commitID/build the master was at at that point of time ~6 months ago when my compiled binary which works fine was created.
I do have an ESP which has that binary flashed into it. So I was thinking if there is a way to retrieve the binary from the ESP?
Please let me know if this can be done somehow via ampy, etc..
Or suggest me some workaround. I'm already trying to find out the approximate commit around that time, and would cross compile again, which I'm not sure if would work as expected.
Regardless of which firmware you loaded onto your ESP8266 module (NodeMCU, MicroPython, Arduino, etc.) you can use esptool.py to dump the flash content to a file like so:
./esptool.py -p PORT -b 460800 read_flash 0 0x200000 flash_contents.bin
read_flash is the command, 0x200000 the argument for the upper memory bound (2MB).
For reading the firmware as a BIN file
For reading the firmware as a BIN file you need FIRST to connect correct the FTDI with the pins on the IR module
FTDI to IR Module as follows
FTDI 3.3 V to IR 3.3 V,
FTDI GND to IR GND,
FTDI GND to IR IO0 (flash mode - IMPORTANT otherwise it will not work),
FTDI RX to IR TXD,
FTDI TX to IR RXD
Then run the command (if the COM port is 5 and the name to extract the bin is flash-contents, otherwise you replace them to match your COM and the name you wish to have) – important the baud rate to be 9600
esptool.py -p COM5 -b 9600 read_flash 0 0x200000 flash_contents.bin
Below is the outcome for me (running under python 3.10.2 on windows 11):
PS F:\> esptool.py -p COM5 -b 9600 read_flash 0 0x200000 flash_contents.bin
esptool.py v3.2
Serial port COM5
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying
again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 10:52:1c:f8:b7:c7
Stub is already running. No upload is necessary.
2097152 (100 %)
2097152 (100 %)
Read 2097152 bytes at 0x0 in 2215.2 seconds (7.6 kbit/s)...
Hard resetting via RTS pin...
PS F:\>
Remember the esptool.py -p COM5 -b 9600 read_flash 0 0x200000 flash_contents.bin is for 2MB memory
but it is well run with esptool.py -p COM5 -b 9600 read_flash 0 0x100000 flash_contents.bin for 1MB memory as it was in my IR Module
I reduced the speed of reading the flash memory of my esp8266
460800 for "46080" I took a zero.
and successful
My system is a windows 10
C:\Users\POSITIVO\Downloads\esptool-master\esptool-master>esptool.py -p COM6 -b 46080 read_flash 0 0x400000 flash_contents3.bin
esptool.py v3.0-dev
Serial port COM6
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 2c:3a:e8:42:b9:f7
Uploading stub...
Running stub...
Stub running...
4194304 (100 %)
4194304 (100 %)
Read 4194304 bytes at 0x0 in 937.7 seconds (35.8 kbit/s)...
Hard resetting via RTS pin...
There is very little information how to configure the Beaglebone for PWM on newer versions of the kernel. Past instructions for interfacing with PWM through the slots file are obsolete, as the slots file and bone_capemgr are disabled in v4.14 of the kernel.
How do I configure PWM for BeagleBone Black with the new kernel? I am using a TI AM335x BeagleBone Black Wireless running kernel version 4.14.37-ti-r46.
As mentioned in the question, the slots file and bone_capemgr are disabled in v4.14 of the kernel in favor of U-Boot overlays.
As explained in a response by the BeagleBone kernel developer, U-Boot now handles the overlays and automatically enables the equivalent of cape_enable=bone_capemgr.enable_partno=univ-all,BB-ADC,BB-PWM0,BB-PWM1,BB-PWM2:
All 5 of those are enabled out of the box with the images now shipping
under:
https://beagleboard.org/latest-images
For the pwm's make sure to reference
https://github.com/beagleboard/bb.org-overlays/blob/master/examples/cape-unversal-pwm.txt
and the config-pin pwm <pin#>..
Therefore, the PWM interface is already configured! Now just export and use the PWM. For example to access pwm0:
root#beaglebone:~# cd /sys/class/pwm/pwmchip0
root#beaglebone:/sys/class/pwm/pwmchip0# ls
device export npwm power subsystem uevent unexport
root#beaglebone:/sys/class/pwm/pwmchip0# echo 0 > export
root#beaglebone:/sys/class/pwm/pwmchip0# ls
device export npwm power pwm-0:0 subsystem uevent unexport
root#beaglebone:/sys/class/pwm/pwmchip0# ls pwm-0:0
capture device duty_cycle enable period polarity power subsystem uevent
Note: you might need to disable HDMI with disable_uboot_overlay_video=1 in /boot/uEnv.txt if the pins are already in use.
To determine the pin mapping for the PWM interfaces, see my follow-up post PWM chip to pin mapping on BeagleBone Black (v4.14).
The last image (Debian 10.3 buster) of debian for the BeagleBone give us the next pin mapping for the pwm outputs:
P8.13 corresponds to folder: /sys/class/pwm/pwm-6:1
P8.19 corresponds to folder: /sys/class/pwm/pwm-6:0
P9.14 corresponds to folder: /sys/class/pwm/pwm-3:0
P9.16 corresponds to folder: /sys/class/pwm/pwm-3:1
P9.21 corresponds to folder: /sys/class/pwm/pwm-1:1
P9.22 corresponds to folder: /sys/class/pwm/pwm-1:0
The default period for P8.13, P8:19, P9.14, and P9.16 is 500000. On the other hand, the default period for P9.21 and P9.22 is 20000.
The key to work with the PWM is the next instruction, which is mentioned in the link posted in the last post about the pin mapping for the PWM interfaces:
config-pin P8.13 pwm
config-pin P8.19 pwm
config-pin P9.14 pwm
config-pin P9.16 pwm
config-pin P9.21 pwm
config-pin P9.22 pwm
After doing that, make this for all desired PWM outputs:
debian#beaglebone:~$ cd /sys/class/pwm/pwm-6:1
debian#beaglebone:~$ echo 250000 > duty_cycle
debian#beaglebone:~$ echo 1 > enable
I can control P8_3, P8_4, but P8_5 stays stuck at 3V3.
I've booted the BB with this configuration to disable HDMI:
# cat /proc/cmdline
optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
Then I enabled GPIO 34+38+39 (P8_{5,3,4}):
# echo 34 > /sys/class/gpio/export
# echo 38 > /sys/class/gpio/export
# echo 39 > /sys/class/gpio/export
And set them as outputs:
# echo out > /sys/class/gpio/gpio34/direction
# echo out > /sys/class/gpio/gpio38/direction
# echo out > /sys/class/gpio/gpio39/direction
Then I'm setting them to alternate between HIGH/LOW at 1Hz using a script which writes as so:
# value is 0/1, pin is 34/38/39
# echo $value > /sys/class/gpio/gpio$pin/value
I measure P8_{3,4} alternating between 0V and 3V3, but P8_5 is stuck at 3V3.
I've tried compiling the devicetree overlay for gpio-P8.5 from here and adding it, but with the same result.
I'm aware that these pins are used by HDMI, but I thought I'd disabled HDMI with that kernel command-line, and I ideally need to use those specific pins due to the board I'm connecting the BBB to.
A colleague using my SD image also had the same issue on a BB green (which I believe doesn't have HDMI).
It seems the device tree files provided with the BBB were trying to configure GPIO#2 instead of GPIO#34 (gpio0_2 instead of gpio1_2).
I generated a new device-tree overlay for P8_5 (gpio1_2 / gpio34) with this and it all works now.
I'm trying to get my receipt printer working on Debian Wheezy.
On being plugged into computer, my USB-serial Receipt Printer (epson tm-t88ii/ii compatible) tics question marks every few seconds, and does not respond to commands.
the output from the printer is:
˥ ?????????????????£???≡█
attempting to print to it by echo fails with error:
/dev/ttyUSB0: Permission denied
even as root.
attempting to open the cash drawer fails with error:
/dev/ttyUSB0: No such device
How do I get it to stop the tic and print?
Here's how I got it working:
after sending:
# echo "test" > /dev/ttyUSB0
returns Permission denied,
# dmesg | tail
returns:
[92780.658576] ftdi_sio 2-3:1.0: FTDI USB Serial Device converter detected
[92780.658624] usb 2-3: Detected FT232BM
[92780.658626] usb 2-3: Number of endpoints 2
[92780.658628] usb 2-3: Endpoint 1 MaxPacketSize 64
[92780.658630] usb 2-3: Endpoint 2 MaxPacketSize 64
[92780.658632] usb 2-3: Setting MaxPacketSize 64
[92780.664556] usb 2-3: FTDI USB Serial Device converter now attached to ttyUSB0
[92782.102904] usb 2-3: usbfs: interface 0 claimed by ftdi_sio while 'brltty' sets config #1
[92782.104874] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[92782.104891] ftdi_sio 2-3:1.0: device disconnected
This indicates there is a conflict with package 'brltty', (braille device), which is installed by default.
# apt-get remove brltty
stops the tic
set baud with
# stty -F /dev/ttyUSB0 9600
try echo
$ echo "test" > /dev/ttyUSB0
it prints!
What about the cash drawer?
$ echo -e "\033\0160\0\031\372" >> /dev/ttyUSB0
it opens!
Problem solved. Unless you need a braille display as well.