RE: [beagleboard] Re: Using GPIOs without Using sudo
Followed what this user reported step by step. https://stackoverflow.com/questions/41586162/access-gpio-on-beaglebone-as-non-root-user No matter. ./Blinky still requires sudo as explained in the comments at the start of the program. So after creating the 80-gpio-permissions.rules And creating the udev-gpio-permissions.sh And then going through the udevadm control --reload-rules and reboot What should be done next? Thanks John > -Original Message- > From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On > Behalf Of Dennis Lee Bieber > Sent: May-11-21 5:48 PM > To: Beagleboard > Subject: [beagleboard] Re: Using GPIOs without Using sudo > > On Tue, 11 May 2021 20:29:59 -0400, in gmane.comp.hardware.beagleboard.user > Dennis Lee Bieber > wrote: > > > > > procedure Get_Value (Pin : in String; Value : out Integer) is > > > > Pin_File : File_Type; > > Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin & "/value"; > > In_Value : String := " "; > > Whoops -- artifact from earlier attempts, In_Value is no longer needed. > > > -- > Dennis L Bieber > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/ic9m9g9v70473o3bpfomrtc5f83dngc104%404ax.com. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/098d01d746d5%244b17ac60%24e1470520%24%40autoartisans.com. Blinky.lpr Description: Binary data
RE: [beagleboard] Re: Using GPIOs without Using sudo
Actually I was suggesting the really simple way with apt install but there is
another.
The fpupdeluxe is a windowing install application that allows you to create any
version for any target on your PC. I did install it on my Beagle and yes,
hours later it's done but that's because the beagle is a bit of a pig. Went
much faster on a Pi3 and on both a LinuxCNC PC and WIN-7 PC lightning fast.
And you can install which target you want to compile for.
The key here is that for the most part you write once, compile either anywhere
or on the same machine for anywhere along with an IDE for much faster program
development. The blinky.lpi project that I referred to is a command line
program.
But I'm trying to keep this discussion pointed in the direction of the subject
line. The problem with access to GPIO seems to exist in both the Pi and Beagle
world. One posting mentioned how his software broke when the Pi OS was
upgraded to 4.14.
The issues seem to be the same. Something with udev and creating the correct
scripts and files.
https://stackoverflow.com/questions/41586162/access-gpio-on-beaglebone-as-non-root-user
The problem with the above link is that step 1 running
80-gpio-permissions.rules doesn't work for me because it doesn't exist on my
system and the contents of that file aren't listed.
However they are in the reference but in that reference the revision of the
kernel is 4.4.36
https://github.com/adafruit/adafruit-beaglebone-io-python/issues/137
My experience with changing Beagle versions is fraught with disaster where the
change then breaks all sorts of stuff that was working. This is why I'm
staying on 4.11 which is what the book uses and at least there's 1.25" of paper
all pointing to the same OS.
So. Should I just blindly, in the command line way, type all that stuff with
no idea of why I'm doing it, run it and if it works be happy?
As an example the second link uses:
chown -R nick:digital /sys/devices/gpio
The first link above uses
chown -R debian:root /sys/devices/gpio
I think debian:root is what I want to do but I don't understand why the
nick:digital allows root access. Why not nick:root?
And the second link with nick's /usr/local/bin/udev-gpio-permissions.sh has a
lot more lines in it.
As I said, this appears to have been an ongoing issue for more than 7 years.
And perhaps the latest OS fixes it? But then I have to go through the process
of rebuilding an entire system. Like going from WIN-7 to WIN-10. What a pain.
John
> -Original Message-
> From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On
> Behalf Of Dennis Lee Bieber
> Sent: May-11-21 5:30 PM
> To: Beagleboard
> Subject: [beagleboard] Re: Using GPIOs without Using sudo
>
> On Tue, 11 May 2021 09:43:49 -0700, in gmane.comp.hardware.beagleboard.user
> "John Dammeyer" wrote:
>
>
> >To try this program do sudo apt install lazarus.
> >
> I think not... Not for an experiment at least. No offence intended, but
> it wants to install over 1GB of stuff -- which is a 33% increase in the
> content of my uSD card!, and would require me to attach a keyboard and
> display to work with the GUI.
>
> Now, a simple command line only program would be a different matter
> (does FPC support command line only? -- FPC may be small enough to justify
> installing for testing via SSH, but not Lazarus... *** nope, just FPC is
> most of the load, 900+MB)
>
> An example using GNAT (Ada). There is no (or I don't know of one)
> library for GPIO access in GNAT Ada, so everything is SysFS I/O. I had to
> set the pin number to string as the simple integer'image(pin) was
> generating leading spaces, which resulted in invalid file name. Everything
> is in one (117 line) file -- no nasty forms, etc.
>
> debian@beaglebone:~/BBB_IO$ ls
> main.adb
> debian@beaglebone:~/BBB_IO$ cat main.adb
> with Ada.Text_IO; use Ada.Text_IO;
> with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
>
> procedure Main is
>
>Sysfs_Path : constant String := "/sys/class/gpio";
>GPIO_Pin : constant String := "48";
>Pin_Value : Integer;
>
>procedure Export_Pin (Pin : in String) is
>
> Export_File : File_Type;
> Export_Path : constant String := Sysfs_Path & "/export";
>
>begin
> Put_Line ("Opening " & Export_Path);
> Open (Export_File, Mode => Out_File, Name => Export_Path);
>
> Put_Line ("Writing pin number: " & Pin);
> Put (Export_File, Pin);
>
> Put_Line ("Closing " & Export_Path);
> Close (Export_File);
>
> New_Line;
>
>end Export_Pin;
>
>procedure Set_Direction (Pin : in String; Direction : in String) is
> Pin_File : File_Type;
> Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin &
> "/direction";
>
>begin
> Put_Line ("Opening " & Pin_Path);
> Open (Pin_File, Mode => Out_File, Name => Pin_Path);
>
> Put_Line ("Writing direction: " & Direction);
[beagleboard] Re: Using GPIOs without Using sudo
On Tue, 11 May 2021 20:29:59 -0400, in gmane.comp.hardware.beagleboard.user Dennis Lee Bieber wrote: > procedure Get_Value (Pin : in String; Value : out Integer) is > > Pin_File : File_Type; > Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin & "/value"; > In_Value : String := " "; Whoops -- artifact from earlier attempts, In_Value is no longer needed. -- Dennis L Bieber -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ic9m9g9v70473o3bpfomrtc5f83dngc104%404ax.com.
[beagleboard] Re: Using GPIOs without Using sudo
On Tue, 11 May 2021 09:43:49 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" wrote:
>To try this program do sudo apt install lazarus.
>
I think not... Not for an experiment at least. No offence intended, but
it wants to install over 1GB of stuff -- which is a 33% increase in the
content of my uSD card!, and would require me to attach a keyboard and
display to work with the GUI.
Now, a simple command line only program would be a different matter
(does FPC support command line only? -- FPC may be small enough to justify
installing for testing via SSH, but not Lazarus... *** nope, just FPC is
most of the load, 900+MB)
An example using GNAT (Ada). There is no (or I don't know of one)
library for GPIO access in GNAT Ada, so everything is SysFS I/O. I had to
set the pin number to string as the simple integer'image(pin) was
generating leading spaces, which resulted in invalid file name. Everything
is in one (117 line) file -- no nasty forms, etc.
debian@beaglebone:~/BBB_IO$ ls
main.adb
debian@beaglebone:~/BBB_IO$ cat main.adb
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;
procedure Main is
Sysfs_Path : constant String := "/sys/class/gpio";
GPIO_Pin : constant String := "48";
Pin_Value : Integer;
procedure Export_Pin (Pin : in String) is
Export_File : File_Type;
Export_Path : constant String := Sysfs_Path & "/export";
begin
Put_Line ("Opening " & Export_Path);
Open (Export_File, Mode => Out_File, Name => Export_Path);
Put_Line ("Writing pin number: " & Pin);
Put (Export_File, Pin);
Put_Line ("Closing " & Export_Path);
Close (Export_File);
New_Line;
end Export_Pin;
procedure Set_Direction (Pin : in String; Direction : in String) is
Pin_File : File_Type;
Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin &
"/direction";
begin
Put_Line ("Opening " & Pin_Path);
Open (Pin_File, Mode => Out_File, Name => Pin_Path);
Put_Line ("Writing direction: " & Direction);
Put (Pin_File, Direction);
Put_Line ("Closing " & Pin_Path);
Close (Pin_File);
New_Line;
end Set_Direction;
procedure Set_Value (Pin : in String; Value : in Integer) is
Pin_File : File_Type;
Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin & "/value";
begin
Put_Line ("Opening " & Pin_Path);
Open (Pin_File, Mode => Out_File, Name => Pin_Path);
Put_Line ("Writing value: " & Integer'Image (Value));
Put (Pin_File, Value, Width => 1);
Put_Line ("Closing " & Pin_Path);
Close (Pin_File);
New_Line;
end Set_Value;
procedure Get_Value (Pin : in String; Value : out Integer) is
Pin_File : File_Type;
Pin_Path : constant String := Sysfs_Path & "/gpio" & Pin & "/value";
In_Value : String := " ";
begin
Put_Line ("Opening " & Pin_Path);
Open (Pin_File, Mode => In_File, Name => Pin_Path);
Put_Line ("Reading value");
Get (Pin_File, Value, Width => 0);
Put_Line ("Closing " & Pin_Path);
Close (Pin_File);
New_Line;
end Get_Value;
begin
-- Believe the pins are already exported in Buster
--Export_Pin (Gpio_Pin);
Get_Value (GPIO_Pin, Pin_Value);
Put_Line
("Current value of " & GPIO_Pin & " is " & Integer'Image (Pin_Value));
New_Line;
Set_Direction (GPIO_Pin, "out");
New_Line;
Get_Value (GPIO_Pin, Pin_Value);
Put_Line
("Current value of " & GPIO_Pin & " is " & Integer'Image (Pin_Value));
New_Line;
Set_Value (GPIO_Pin, 0);
Get_Value (GPIO_Pin, Pin_Value);
Put_Line
("Current value of " & GPIO_Pin & " is " & Integer'Image (Pin_Value));
New_Line;
Set_Value (GPIO_Pin, 1);
Get_Value (GPIO_Pin, Pin_Value);
Put_Line
("Current value of " & GPIO_Pin & " is " & Integer'Image (Pin_Value));
end Main;
debian@beaglebone:~/BBB_IO$
debian@beaglebone:~/BBB_IO$ gnatmake main
arm-linux-gnueabihf-gcc-8 -c main.adb
arm-linux-gnueabihf-gnatbind-8 -x main.ali
arm-linux-gnueabihf-gnatlink-8 main.ali
debian@beaglebone:~/BBB_IO$
debian@beaglebone:~/BBB_IO$ ls
main main.adb main.ali main.o
debian@beaglebone:~/BBB_IO$
debian@beaglebone:~/BBB_IO$ ./main
Opening /sys/class/gpio/gpio48/value
Reading value
Closing /sys/class/gpio/gpio48/value
Current value of 48 is 1
Opening /sys/class/gpio/gpio48/direction
Writing direction: out
Closing /sys/class/gpio/gpio48/direction
Opening /sys/class/gpio/gpio48/value
Reading value
Closing /sys/class/gpio/gpio48/value
Current value of 48 is 0
Opening /sys/class/gpio/gpio48/value
Writing value: 0
Closing /sys/class/gpio/gpio48/value
Opening /sys/class/gpio/gpio48/value
Reading value
Closing /sys/class/gpio/gpio48/value
Current value of 48 is 0
Opening /sys/class/gpio/gpio48/value
Writing value: 1
Closing /sys/class/gpio/gpio48/value
Opening /sys/class/gpio/gpio48/value
Reading
Re: [beagleboard] TI PRU_ADC_onChip example
Hello Walter and Cheng I spent 2 hours total doing following 1)Created Ubuntu 16.04 LTS Dev Box using VBOX on Win 72) Created SDK linux SD card using image writer on Windows booted Linux on Beaglebone White 3) Rebuilt kernel sources created images of customized kernel and replaced these on SD card I have a full development environ Now ! Next step add a kernel driver I wrote and understand how use the OCP shared RAM to get large amounts of data from PRU to linux *** _ _ _ _| _ |___ ___ ___ ___ | _ |___ ___ |_|___ ___| |_| | _| .'| . | . | | __| _| . | | | -_| _| _||__|__|_| |__,|_ |___| |__| |_| |___|_| |___|___|_| |___| |___| Arago Project http://arago-project.org am335x-evm ttyS0 Arago 2019.11 am335x-evm ttyS0 am335x-evm login: [ 143.131162] NET: Registered protocol family 15[ 143.545960] Initializing XFRM netlink socket _ _ _ _| _ |___ ___ ___ ___ | _ |___ ___ |_|___ ___| |_| | _| .'| . | . | | __| _| . | | | -_| _| _||__|__|_| |__,|_ |___| |__| |_| |___|_| |___|___|_| |___| |___| Arago Project http://arago-project.org am335x-evm ttyS0 Arago 2019.11 am335x-evm ttyS0 am335x-evm login: On Tuesday, May 11, 2021, 02:39:31 PM CDT, 'Mark Lazarewicz' via BeagleBoard wrote: HI Cheng I have two Beaglebone White and the am335x SK both have JTAG on the board so no soldering. The key is to follow the labs 1 to 3 only dont use any RPMsg examples The other key is the PRU gel script is crucial there is a typo error in the instructions about correct .gel file name and how to execute it I used CCS 6.0 win 7 and CCS 10 on windows 10 Id be glad to help if I can The power of the CCS/JTAG is reading memory locations and finding crashes quickly its worth the learning curve Any issues please ask but tell me your CCS version What I dont like about the PRU tutorials is all use Linux interaction as in interrupts and they assume SDK linux not Debian Its some work but you could use Windows to create a SDK linux SD card for JTAG if problems I have several jtags one is USBV2 and I have yours I also have two BBB but even being EE I dont solder Let me know be glad to help trust me after you master CCS/JTAG you will be very happy and have an awesome tool in your belt Mark On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen wrote: Hi Mark, Thanks a lot for the updates. I went through the SDK documents and I actually got a lot inspiration. Thanks for that. I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is that how you debugged with JTAG ? I feel this approach is a little cumbersome since I need to set up a lot of environments manually. But it worked, so I just put up with it for now. I think both SDK and Beaglebone has a lot of interesting stuffs worth being explored. Appreciate your help! Regards,Cheng在2021年5月8日星期六 UTC-4 下午7:52:41 写道： Hello Cheng I learned a few things this weekend I thought I would share The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK BBB is also supported My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7 The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended ) CCS DOES NOT require linux to load and debug PRU For those that want to learn ARM TI RTOS Win 10 is required to build The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you. I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route. Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost. The approach in this group is wonderful especially for Linux App types that don't care about details they just want a working kernel and
[beagleboard] Re: Using GPIOs without Using sudo
On Mon, 10 May 2021 22:29:01 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" wrote:
>I think you missed the above line in my initial posting where the signals DC
>and RESET are used for controlling the LCD display. They have absolutely
>nothing to do with SPI.
>
Okay... The following will be a bit of a rambling mess as I can't find
a clean way to separate all the file searching I'm doing... I tried to mark
what seem crucial points with
the point
>>
>> >to create the gpio48 folder and as super user the VXP library can do that
>> >but then it fails on the write to SPI.
>
>In fact if I run the program without running it as super user the failure
>messages that occur happen because gpio48 and gpio60 cannot be created due to
>access rights.
>
>The PXL library appears to be designed and tested with a BBB (based on the
>photos and wiring diagram) but because the library is older, the moving target
>(AKA BeagleBone OS) is likely the culprit for it not working.
>
I've downloaded the source https://asphyre.net/products/pxl , and can't
even find a mention of beagles (checked for "eagle", BBB, etc.). Whereas
the R-Pi has a dedicated module. {Side note: The MDI interface of Lazarus
is painful to me -- too many independent windows that have to be pulled
forward after every change from it to some other application}
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern beagle
-Path *
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern eagle
-Path *
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern bone
-Path *
Jedi.Compilers.inc:1315:// Revision 1.30 2005/12/04 10:10:58 obones
Jedi.Compilers.inc:1318:// Revision 1.29 2005/11/01 20:46:20 obones
PS C:\Users\Wulfraed\Desktop\pxl-v110\Source> Select-String -Pattern bbb
-Path *
PXL.Linux.videodev2.pas:212:function V4L2_PIX_FMT_RGB444: Cardinal; inline;
{ 16 }
PXL.Linux.videodev2.pas:289: rrgg
ggbb... }
***
... But since you are specifying lower-level SysFS calls, it should be
generic.
***
>Here's the constructor which shows I'm trying to get to spidev1.0 and the
>PinDC and PinRST are gpio48 and gpio60 respectively.
>
>===
>constructor TApplication.Create;
>begin
> FGPIO := TSysfsGPIO.Create;
> FDataPort := TSysfsSPI.Create('/dev/spidev1.0');
>
> FDisplay := TDisplay.Create(TDisplay.OLED128x128, FGPIO, FDataPort, PinDC,
> PinRST);
>
> FDisplaySize := (FDisplay as TDisplay).ScreenSize;
>
> FDisplay.Initialize;
> FDisplay.Clear;
>
> LoadGraphics;
>end;
>===
>
>And then here's the python code that does work.
>
>
>from PIL import Image
>
>import Adafruit_ILI9341 as TFT
>import Adafruit_GPIO as GPIO
Unfortunately Adafruit_GPIO has been deprecated in favor of
CircuitPython libraries via the BLINKA interface package... Makes
crawling through it problematic.
At the core, if it has to export the pin, it uses
"""
const char gpio_export[] = "/sys/class/gpio/export";
if ((fd = open(gpio_export, O_WRONLY)) < 0) {
syslog(LOG_ERR, "Adafruit_BBIO: gpio_export(): %u couldn't open
\"%s\": %i-%s",
gpio, gpio_export, errno, strerror(errno));
ret = BBIO_SYSFS;
goto exit;
}
len = snprintf(str_gpio, sizeof(str_gpio), "%d", gpio);
if(write(fd, str_gpio, len) < 0) {
syslog(LOG_ERR, "Adafruit_BBIO: gpio_export: %u couldn't write
\"%s\": %i-%s",
gpio, gpio_export, errno, strerror(errno));
ret = BBIO_SYSFS;
goto exit;
}
"""
It looks PXL display doesn't test/export GPIO pins -- it directly
accesses whatever was provided.
"""
constructor TCustomDrivenDisplay.Create(const AGPIO: TCustomGPIO;
const ADataPort: TCustomDataPort; const APinDC: Integer;
const APinRST: Integer);
begin
FGPIO := AGPIO;
FDataPort := ADataPort;
FPinDC := APinDC;
FPinRST := APinRST;
inherited Create;
if FPinRST <> -1 then
FGPIO.PinMode[FPinRST] := TPinMode.Output;
if (FPinDC <> -1) and (FDataPort is TCustomPortSPI) then
FGPIO.PinMode[FPinDC] := TPinMode.Output;
end;
"""
**
If those GPIOs have not been exported on your system, you may have to
manually
Re: [beagleboard] TI PRU_ADC_onChip example
HI Cheng I have two Beaglebone White and the am335x SK both have JTAG on the board so no soldering. The key is to follow the labs 1 to 3 only dont use any RPMsg examples The other key is the PRU gel script is crucial there is a typo error in the instructions about correct .gel file name and how to execute it I used CCS 6.0 win 7 and CCS 10 on windows 10 Id be glad to help if I can The power of the CCS/JTAG is reading memory locations and finding crashes quickly its worth the learning curve Any issues please ask but tell me your CCS version What I dont like about the PRU tutorials is all use Linux interaction as in interrupts and they assume SDK linux not Debian Its some work but you could use Windows to create a SDK linux SD card for JTAG if problems I have several jtags one is USBV2 and I have yours I also have two BBB but even being EE I dont solder Let me know be glad to help trust me after you master CCS/JTAG you will be very happy and have an awesome tool in your belt Mark On Monday, May 10, 2021, 11:51:35 PM CDT, Cheng Chen wrote: Hi Mark, Thanks a lot for the updates. I went through the SDK documents and I actually got a lot inspiration. Thanks for that. I bought an TMDSEMU110-U for debugging. That is recommended from TI tutorials of PRU debugging: PRU is connected with TMDSEMU110-U and then to the laptop. Is that how you debugged with JTAG ? I feel this approach is a little cumbersome since I need to set up a lot of environments manually. But it worked, so I just put up with it for now. I think both SDK and Beaglebone has a lot of interesting stuffs worth being explored. Appreciate your help! Regards,Cheng在2021年5月8日星期六 UTC-4 下午7:52:41 写道： Hello Cheng I learned a few things this weekend I thought I would share The PRU Labs examples 1 to 3 can be loaded with CCS and JTAG from Windows 10 You can even debug both PRU0 and PRU1 at the same time examine memory and use HW uart debug to speed up development The RPMSG example LAB must be loaded by the linux or TI RTOS drivers running on ARM side I have win 7 and Windows 10 CCS/JTAG installations working one a Beaglebone White and the other AM335X SK BBB is also supported My Last step is building the SDK linux kernel from scratch with rproc kernel modules loaded from a VirtualBox Ubuntu VM on Win 7 The Linux SDK has binaries for the ARM side so a Native Linux BOX is NOT REQUIRED(but recommended ) CCS DOES NOT require linux to load and debug PRU For those that want to learn ARM TI RTOS Win 10 is required to build The SDK documents I saved as the wiki is disappearing are awesome I found some very detailed PRU documentation that talks about everything from running TI PRU firmware On PRU ICCS for complex Industrial protocols as well a custom PRU code The facts about clock cycles also were discussed. All of it in can be found by following the documentation tar ball I sent I you. I think too many people panic dont want to run SDK Linux or use CCS /JTAG dont read through all the documents as they dont want to go that route. Thats fine but the basic fundamentals of the whole SOC are then missed leading to confusion The SDK has done an excellent job of documenting this unfortunately unless your actually using the SDK all of this is hidden and I guess they are taking down some wikis so kind of sad this data will be lost. The approach in this group is wonderful especially for Linux App types that don't care about details they just want a working kernel and actually making one script to build linux makes sense as supporting keystroke errors and inability to read docs in a chronological orderly way would be a nightmare. So in summary In my humble Opinion if your goal is writing Linux apps on a open source board the SDK probally is NOT for you. If your goal is barebones, TI RTOS , board bring up, custom hardware , DSP programming Cortex M4 programming , advanced PRU apps or learning or adding Linux Device drivers the SDK is a great asset. Mark On Thursday, May 6, 2021, 05:28:39 PM CDT, Cheng Chen wrote: Hi Walter, Sorry for the late reply. The most important part I modified for TI's makefile is to make sure that the firmware is loaded into remoteproc1. I basically replaced the loading procedure in the shell script with Molly's version which I attached below. I also added the entire include file and modified some of the constants and variable names in the c code because compiler reports errors of unrecognized header file and variables. But except those, it runs pretty well. start: ifneq ($(PRU_DIR),) @echo write_init_pins.sh @$(COMMON)/write_init_pins.sh /lib/firmware/$(CHIP)-pru$(PRUN)-fw @echo "- Starting PRU $(PRUN)" @echo start > $(PRU_DIR)/state else ifeq ($(PROC),tidl) ti-mct-heap-check -c sudo mjpg_streamer -i "input_opencv.so -r 640x480 -d /dev/$(shell fgrep -v vpe /sys/class/video4linux/video*/name | perl -ne '/\/(video\d+)\/name/ && print $$1') \ --filter
Re: [beagleboard] versioning beaglebone images with OSTree
Thanks Robert! What builds the initrd file? One strategy I'm seeing for using OSTree is do some of the filesystem mounting in initrd, but I'm not sure how to modify what is currently used. -John On Tuesday, May 4, 2021 at 5:05:15 PM UTC-6 RobertCNelson wrote: > On Tue, May 4, 2021 at 5:28 PM John Allwine wrote: > > > > Where is the source code for what u-boot runs by default on the > Beaglebone images? I see some references to patches that I assume are > applied to u-boot on the Beaglebone: > > > https://github.com/beagleboard/image-builder/blob/master/target/chroot/beagleboard.org-buster.sh#L276-L291 > > > > Is there somewhere I can see the applied versions of those or do I have > to manually apply them? I'm trying to understand what exactly the > environment variables in uEnv.txt do. > > You can find that tree here: > > https://github.com/beagleboard/u-boot/tree/v2019.04-bbb.io-am335x > > it's built/provided via the debian package: bb-u-boot-am335x-evm > > https://github.com/rcn-ee/repos/tree/master/bb-u-boot-am335x-evm > > Regards, > > -- > Robert Nelson > https://rcn-ee.com/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7862b0a1-3373-470e-965a-0b3d61504be0n%40googlegroups.com.
Re: [beagleboard] Re: Using GPIOs without Using sudo
OK, I am not using a current kernel, so can't really address the issues
with group settings. But, here's one thing that will work:
if you have a user program xyz, do :
sudo chown root:root xyz
sudo chmod u+s xyz
TYhis makes the program owned by rootm, and uses the privileges of root
when that program is run. You DO need root privileges to MAKE these
settings, but then the program will run and be able to access the GPIO
without the user needing the privileges.
Making the user a member of the right group should also make any program
run by that user have the necessary privilege. It depends on what is in
the /etc/group file as to what group you need to be a member of.
Jon
On Tuesday, May 11, 2021 at 12:29:23 AM UTC-5 jo...@autoartisans.com wrote:
> > From: beagl...@googlegroups.com [mailto:beagl...@googlegroups.com] On
> Behalf Of Dennis Lee Bieber
> > "John Dammeyer" wrote:
>
> > >The SPI bus ADAfruit application for a 320x240 display written in
> Python runs properly rendering LENNA.JPG onto the LCD display.
>
> > The key outputs are the DC and RESET which are on gpio48 and gpio60. An
> "ls" of the /sys/class/gpio folder shows on start up those
> > two are not visible.
> > >
> >
> > SPI and I2C rely upon a different PINMUX configuration than GPIO...
> > GPIO is pretty much all "mode 7". SPI0 pins are "mode 0" and SPI1 pins
> are
> > "mode 3".
> > http://www.ofitselfso.com/BeagleNotes/BeagleboneBlackPinMuxModes.php
>
> Hi Dennis,
> I think you missed the above line in my initial posting where the signals
> DC and RESET are used for controlling the LCD display. They have absolutely
> nothing to do with SPI.
>
> >
> > >to create the gpio48 folder and as super user the VXP library can do
> that but then it fails on the write to SPI.
>
> In fact if I run the program without running it as super user the failure
> messages that occur happen because gpio48 and gpio60 cannot be created due
> to access rights.
>
> The PXL library appears to be designed and tested with a BBB (based on the
> photos and wiring diagram) but because the library is older, the moving
> target (AKA BeagleBone OS) is likely the culprit for it not working.
>
> Here's the constructor which shows I'm trying to get to spidev1.0 and the
> PinDC and PinRST are gpio48 and gpio60 respectively.
>
>
> ===
> constructor TApplication.Create;
> begin
> FGPIO := TSysfsGPIO.Create;
> FDataPort := TSysfsSPI.Create('/dev/spidev1.0');
>
> FDisplay := TDisplay.Create(TDisplay.OLED128x128, FGPIO, FDataPort, PinDC,
> PinRST);
>
> FDisplaySize := (FDisplay as TDisplay).ScreenSize;
>
> FDisplay.Initialize;
> FDisplay.Clear;
>
> LoadGraphics;
> end;
>
> ===
>
> And then here's the python code that does work.
>
>
>
> from PIL import Image
>
> import Adafruit_ILI9341 as TFT
> import Adafruit_GPIO as GPIO
> import Adafruit_GPIO.SPI as SPI
>
> # BeagleBone Black configuration.
> DC = 'P9_15'
> RST = 'P9_12'
> SPI_PORT = 1
> SPI_DEVICE = 0
>
> # Create TFT LCD display class.
> disp = TFT.ILI9341(DC, rst=RST, spi=SPI.SpiDev(SPI_PORT, SPI_DEVICE,
> max_speed_hz=6400))
>
>
>
> In both cases SPI device 1.0. All I'm doing is compiling an example from
> the PXL library and the original subject line is still my primary interest.
> Likely this issue will be solved by the Lazarus group since it's likely a
> Linux on BBB problem.
>
> So before we get too far off topic again do you know what to do to for
> setting up GPIO access without sudo?
>
> Thanks
> John
>
>
> > >
> >
> > SPI0 appears on P9_17, _18, _21, and _22 (raw GPIO # 5, 4, 3, 2, aka
> > gpio0_5, ...). SPI1 are on P9_28, _29, _30, _31 (raw GPIO # 113, 111,
> 112,
> > 110, aka gpio3_17, _15, _16, _14).
> >
> > GPIO # 48 (gpio1_16) on P9_15 has no modes for SPI.
> >
> >
>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/12eed06d-2d12-402a-a82f-0ca2603d4a8fn%40googlegroups.com.
