Is there a way to write to a pin on the mcp23017 chip in Shell / bash without having to change/ update the other pins
This is what I found
sudo i2cset -y 1 0x20 0x14 0x01 # Sets bus 0x20 port A to 00000001
In python i can specify a pin :
bus_0 = IOPi(0x20) # Choose Chip
bus_0.set_port_direction(0, 0x00) #Set port A/0 to Output(For all pins)
bus_0.write_port(0, 0xFF) # Can write all pins
bus_0.write_pin(1, 1) # can write specific pin
Is the only option to write a script that takes the input from shell_exec and does the job?
Related
I already have a working config for a compute module 3+. As I need the same setup on a raspberry Pi Model 3 B I tried bringing the config over.
Everything is compiled in a buildroot environment. U-Boot v2020.10 is used.
After some small changes regarding the device tree and dtoverlays I managed to get U-Boot to print on the serial console(as expected), but it ignores all keyboard input.
The following output is produced by U-Boot on serial console.
EDIT
I used the term serial very loosely here. I'm connected to the serial console with a serial-USB adapter and picocom. I applied the miniuart-bt overlay to restore /dev/ttyAMA0 respectively UART0 on gpio pins 14/15.
Lastely I configured U-Boot with PL011.
I left out support for mini-uart as this would break the output too.
This configuration works just fine on the compute module, but doen't register input on the model 3B.
EDIT
I moved the working u-boot.bin from the cm 3 to the model B to see what happens. It seemingly works as both are close enough. But the same problem occurs. The other way around though it does not work. So it is potential not a problem with U-Boot but with the Model B configuration.
1 Isa-Boot>·
2
3 U-Boot 2020.10 (Mar 24 2022 - 12:18:38 +0000)
4
5 DRAM: 924 MiB
6 RPI 3 Model B (0xa02082)
7 MMC: mmc#7e202000: 0, sdhci#7e300000: 1
8 In: serial
9 Out: vidconsole
10 Err: vidconsole
11 Hit any key to stop autoboot: 0·
Neither can I stop autoboot nor can I use the shell to complete the boot script.
I tried what feels like a million configurations and I'm out of ideas what could be the reason for this behavior. I also never experienced this with the cm module.
RPi setup config.txt:
enable_uart=1
start_file=start.elf
fixup_file=fixup.dat
kernel=u-boot.bin
gpu_mem=100
dtoverlay=miniuart-bt
dtparam=spi=on
device_tree=bcm2710-rpi-3-b.dtb
dtoverlay=sc16is750-spi0-ce0
U-Boot defconfig:
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_ARCH_BCM283X=y
CONFIG_SYS_TEXT_BASE=0x00008000
CONFIG_TARGET_RPI_3_32B=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x4000
CONFIG_DEFAULT_DEVICE_TREE="bcm2837-rpi-3-b"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_SYS_STDIO_DEREGISTER=y
CONFIG_MISC_INIT_R=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_SYS_PROMPT="Isa-Boot> "
CONFIG_CMD_GPIO=y
CONFIG_CMD_MMC=y
CONFIG_CMD_USB=y
CONFIG_CMD_FS_UUID=y
CONFIG_OF_EMBED=y
# CONFIG_ENV_IS_IN_FAT is not set
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
# CONFIG_NET is not set
CONFIG_DM_MMC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_BCM2835=y
CONFIG_DM_ETH=y
CONFIG_PINCTRL=y
# CONFIG_PINCTRL_GENERIC is not set
# CONFIG_REQUIRE_SERIAL_CONSOLE is not set
# CONFIG_BCM283X_MU_SERIAL is not set
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_DM_VIDEO=y
# CONFIG_VIDEO_BPP8 is not set
# CONFIG_VIDEO_BPP16 is not set
CONFIG_SYS_WHITE_ON_BLACK=y
CONFIG_CONSOLE_SCROLL_LINES=10
CONFIG_PHYS_TO_BUS=y
CONFIG_OF_LIBFDT_OVERLAY=y
From U-boot documentation, "U-boot Environment Variables":
bootdelay: After reset, U-Boot will wait this number of seconds before it executes the contents of the bootcmd variable. During this time a countdown is printed, which can be interrupted by pressing any key.
Set this variable to 0 boot without delay. Be careful: depending on the contents of your bootcmd variable, this can prevent you from entering interactive commands again forever!
Is this value 0 in your case?
I have a raspberry pi 3 model b (Raspbian GNU/Linux 10 (buster)) and I want to disable the Bluetooth module connected to UART0 (pins 8 and 10) to make use of UART0. When I add the dtoverlay=disable-bt to the end of /boot/config.txt and connect a UART device, the raspberry pi freezes or signs me out.
Does anyone have an idea as to why this may be happening?
I have uninstalled the application that uses Bluetooth as well.
I've ran the following commands:
sudo systemctl disable hciuart.service
sudo systemctl disable bluealsa.service
sudo systemctl disable bluetooth.service
My /boot/config.txtb file looks like this:
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on
# Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
#dtoverlay=vc4-fkms-v3d
# Enable UART
enable_uart=1
Any help is appreciated.
I figured out that adding unnecessary spaces in the /boot/config.txt was causing my error.
I had written:
dtoverlay = disable-bt
instead of:
dtoverlay=disable-bt
Also, it helped to go to Pi > Preferences > RPi Configurations > Interfaces to make sure that the serial ports were enabled.
I am new to yocto and i have generated a linux image for my raspberrypi-cm3 and i want to connect an mcp2515 to my cm3 to test the can driver.
the mcp251x.ko , can_dev.ko , spidev.ko spi_bcm2835.ko and spi_2835aux.ko modules are loaded and when i write ' dmesg | grep can' i get messages that mcp251x is finely there but when i write ' dmesg | grep spi' nothing shows up.
also in my 'config.txt' file the spi is set to 'off' by default.
Can someone please help me to enable the spi so i can test the mcp251x of the can?
Open .dts file in your kernel and enable spi and set STATUS="okay"
and write platform data for spidev
&spi0 {
pinctrl-names = "default";
pinctrl-0 = <&spi0_pins_a>,
<&spi0_cs0_pins_a>;
status = "okay";
spidev#0x00 {
compatible = "spidev";
spi-max-frequency = <1200000>;
reg = <0>;
};
and open bitbake -c menuconfig virtual/kernel. then enable spidev present in devicer/drivers.
As per my understanding chosen node is used to send boot arguments to the kernel.
The following is the chosen node of the existing device code (am335x-bone-common.dtsi).
chosen {
stdout-path = &uart0;
};
So, I have modified chosen node to pass kernel arguments.
chosen {
bootargs = "console=ttyO0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rw rootwait";
stdout-path = &uart0;
};
While bringing up the board I encountered KERNEL PANIC,
Here is the log {https://pastebin.com/XHyrsmfG}
FYI: These are the u-boot commands issued on serial console(minicom) inorder to port kernel and devicetree using SDcard.
fatload mmc 0:1 0x81000000 zImage
fatload mmc 0:1 0x82000000 am335x-boneblack.dtb
bootz 0x81000000 - 0x82000000
As per my understanding chosen node is used to send boot arguments to the kernel.
Your understanding is incomplete.
As already mentioned in another answer, the kernel command line provided by the bootloader (i.e. U-Boot) is the actual list of parameters currently used when you boot the board.
For ARM Linux the default kernel configuration gives precedence to the bootloader's command line over the default kernel command string and the bootargs in the chosen node in the Device Tree.
The rationale according to U-Boot author/maintainer Wolfgang Denk seems to be that any hardcoded, built-in bootargs are inferior to bootargs that can be easily customized and supplied by a bootloader.
This is exactly what you are seeing.
There are actually three possible ARM kernel boot configuration choices:
Kernel command line type:
(X) Use bootloader kernel arguments if available
( ) Extend bootloader kernel arguments
( ) Always use the default kernel command string
If you want to always ignore the command line in U-Boot's bootargs variable (and the command line from the DT), but exclusively use the default kernel command string as defined in CONFIG_CMDLINE, then the kernel should be configured for the third choice (CONFIG_CMDLINE_FORCE) on that list.
Note that this list of choices is only available when CONFIG_ATAGS is enabled ("Support for the traditional ATAGS boot data passing").
The scheme that selects the DT bootargs is to use the existing kernel configuration, but simply delete that U-Boot environment variable (i.e. setenv bootargs).
If you change U-Boot's bootargs variable to an empty string as mentioned in another answer, the kernel will use its default kernel command string (CONFIG_CMDLINE) rather than the DT.
Also see How to set Linux kernel command line on ARM?
As per my understanding chosen node is used to send boot arguments to
the kernel. The following is the chosen node of the existing device
code (am335x-bone-common.dtsi).
chosen {
bootargs = "console=ttyO0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rw rootwait";
stdout-path = &uart0;
};
Looking at your pastie, the boot log says the command line is the following:
Kernel command line: console=ttyO0,115200
ip=10.0.0.111:10.0.0.4::255.255. 255.0 rw root=/dev/nfs
nfsroot=10.0.0.4:/home/dileep/beaglebone/rootfs,
And since you have also set the bootargs "bootargs = "console=ttyO0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rw rootwait";" in the devicetree wouldnt affect as uboot has already set those parameters, ie if same parameter is set in the device tree and in the tags (uboot), the one from the uboot tags will be chosen.
So you will have to clear up the bootargs set by u-boot.
1] setenv bootargs "";
2] saveenv
3] fatload mmc 0:1 0x81000000 zImage
4] fatload mmc 0:1 0x82000000 am335x-boneblack.dtb
5 bootz 0x81000000 - 0x82000000
For fresh building uboot, where the board is not programmed yet make sure in the u-boot configs you don’t have bootargs variable defined.
I have connected 2 raspberry pi using GPIO :
The first one is the master, and use GPIO2 (and GND...)
The second one is a slave, and use GPIO0 and GPIO1
All are switch on a relay card
I put GPIO1 and GPIO0 on direction "IN" and GPI02 on direction "out" :
echo in > /sys/class/gpio/gpioXX/direction
On my master, (GPIO2, direction = OUT), when i put the pin GPIO2 to 1, the 2 pins on my slave turn to 1 too. So, no probleme here
I add a shell script, using inotifywait on one folder (for example /sys/class/gpio/gpio18/ (18 for GPIO1)).
When I'm on my SLAVE, and i try to modify the value of /sys/class/gpio/gpio18/ with an echo 1 > .../value , inotifywait catch a modification, but the value didn't change ( -bash: echo: write error: Operation not permitted , it's normal because direction is on "IN" ).
When I'm on my MASTER, and i modify the value of gpio27 (corresponding to GPI02), both value file (GPIO0, GPIO1 and GPIO2) change, but my inotifywait didn't catch the modification on gpio/gpio18/value (the containt of the file change from 0 to 1 or inversely)
I can't say for sure what is wrong. But I would try running a simple script like this and see what happens:
while inotifywait -e modify /sys/class/gpio/gpio18/; do echo "Hello"; done