[beagleboard] Re: Is it possible to change boot device 'programmatically'?

[Dennis Lee Bieber]

On Wed, 1 Sep 2021 20:06:49 +0100, in gmane.comp.hardware.beagleboard.user
Chris Green  wrote:

>Dennis Lee Bieber  
>wrote:
>> 
>> I'm surprised this post even came through. The beagleboard forum
>> /moved/ to a new web-based-only system (which I have refused to fight with
>
>I suspect this will carry on working. :-)   Good!
>
But you and I may be the only ones still monitoring it 


>OK, thanks, I suspect it may be rather more difficult than I had hoped.
>
>What I'm aiming for is a Pi/BBB type system that can clone itself
>automatically every day or so.  That would allow me to have a fairly
>quick to implement backup for my Pi (could justas well be a BBB) that
>provides DHCP/DNS on my LAN.

Mostly I think folks do that with rsync
https://man7.org/linux/man-pages/man1/rsync.1.html


-- 
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/23nvigpjgvll4lpkfm1cfak9uk053okbkp%404ax.com.

[beagleboard] Re: Is it possible to change boot device 'programmatically'?

[Dennis Lee Bieber]

I'm surprised this post even came through. The beagleboard forum
/moved/ to a new web-based-only system (which I have refused to fight with
-- I tried but found it cryptic and unusable for someone accustomed to
newsreader clients which fetch all messages in a batch and permit later
responses to be made; I abhor web-based "fetch one message, make a reply,
send, fetch next message")

The Google Groups forum has been abandoned.

On Wed, 1 Sep 2021 16:50:11 +0100, in gmane.comp.hardware.beagleboard.user
Chris Green  wrote:

>If one has a BBB which normally boots from eMMC is it possible to
>write a script that will reboot from the microSD card?
>

On current Beagle systems, it is u-Boot which determines the boot
device dynamically.

That is: 

By default the u-Boot in the eMMC starts processing

It then scans for a bootable uSD card

If a valid uSD card is found, it toggles the boot device to be 
the
uSD card, and proceeds to load the configuration from the uSD card;
otherwise it continues to load the configuration from the eMMC

If there is no u-Boot (and maybe other files) found on the eMMC, the
SoC [hardware] boot sequence is to look for a valid uSD card and load
u-Boot from that card.

The end state: if a bootable uSD card exists, it automatically becomes
the booted image, skipping the rest of the eMMC (u-Boot comes from the
first version found: eMMC then uSD).

Prior to this form of u-Boot, one was required to hold down the
boot-select button on the BBB to force uSD card load. But that form of
u-Boot vanished near the end of the Wheezy era (Debian 7). This was also
the days of kernel loaded device tree overlays -- u-Boot loaded overlays
came in during the Jessie (Debian 8) era. The two u-Boots are totally
INCOMPATIBLE with Debian versions of the other style (Wheezy u-Boot does
not load DTOs, but Jessie and later Debian kernels expect to find the DTOs
already loaded).

I don't know enough about u-Boot and uEnv.txt to know if there is some
way to modify uEnv.txt to /not/ transfer control to the uSD card except
when you want to do you back-up stuff.


-- 
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/i2cvigt822989kf4gbfu2ob6a5p62osu6v%404ax.com.

[beagleboard] Re: Beagle forum has MOVED!

[Dennis Lee Bieber]

On Tue, 6 Jul 2021 22:18:39 -0400, in gmane.comp.hardware.beagleboard.user
Jason Kridner  wrote:


>
>Anyone know how to get Gmane setup with Discourse? gmaine.org doesn't
>respond for me--I got a Cloudflare 522 error.

Well, two matters:

1   gmaine.org is not gmane.org

2   After something happened a few years back, gmane essentially 
lost
"gmane.org" and was recreated as "gmane.io"  https://gmane.io/ (even if it
keeps mangling users with a gmane.org header)

https://admin.gmane.io/ Add new list--- though they have this
preference listed
"""
Please request only lists that are public and open to everybody. If you
have any doubt that the people on the mailing list wouldn't appreciate
having the mailing list on Gmane, ask the mailing list admin first.
"""
The page comes up with no login, I don't know what a gmane login grants...


-- 
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/rtbaegtg68s8gf056526dtmmji7hub3kh3%404ax.com.

[beagleboard] Re: Beagle forum has MOVED!

[Dennis Lee Bieber]

On Tue, 6 Jul 2021 16:07:46 -0400, in gmane.comp.hardware.beagleboard.user
Jason Kridner  wrote:

>You can get forum.beagleboard.org content in your Inbox as well.
>

I've been reading via gmane's NNTP gateway (though I will admit that
for some reason sending via it had worked for a few months, after that I
had to use the GoogleGroups email address [and remember to reply as email])

Unfortunately my preferred email client doesn't seem to have a option
to burst digests into individual messages, which means a lot of overhead to
ensure subject line reflects actual post (and probably will break threading
anyway as the message-ID is for the digest, not the post). My newsreader
does have burst capability -- but to avoid conflicts I'd have to create a
new email account just for the list...


-- 
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/o3u9eg5env1mnkddsumvvvqkerh5kg0hrd%404ax.com.

[beagleboard] Re: Debug serial console not working

[Dennis Lee Bieber]

On Mon, 5 Jul 2021 13:34:17 +0530, in gmane.comp.hardware.beagleboard.user
Vinayakumar Chikkadi 
wrote:

>The pin positions for 5v, gnd, Rx, Tx on cable are not matching with J1
>header on bbb.
>

5V is a danger already... A Raspberry-Pi serial<>USB (came with a
Sparkfun Pi-Wedge) runs
DTR Rx  Tx  3.3VCTS GND
Which is NOT compatible with BBB (the Rx and Tx are swapped).

https://elinux.org/Beagleboard:BeagleBone_Black_Serial
"The debug cable is a standard FTDI to TTL cable. Make sure you get the
3.3V version."

Personally, the AdaFruit cable is probably more flexible as the four pins
are free to connect anywhere, not tied to a specific sequence in one
header.



-- 
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/7de6egl8q3n7cc5h8ej7mtsnafm6dmvutt%404ax.com.

[beagleboard] Re: Debug serial console not working

[Dennis Lee Bieber]

On Sat, 3 Jul 2021 11:05:35 +0530, in gmane.comp.hardware.beagleboard.user
Vinayakumar Chikkadi 
wrote:

>I have given permission by running
>
>sudo chmod 0777 /dev/ttyUSB0
>
That is not the preferred way to do it. The preferred way is by adding
your user account to the /group/ that owns tty* devices. On the systems I
checked, that is the Dialout group.

>Now I am able to open in putty but not receiving any data from bbb. Seems
>the issue with usb to serial cable.
>
Personally, I'd first connect an oscilloscope to the TxD and RxD pins,
and see what, if anything, is on those pins. You likely won't be able to
"read" the traffic, but should be able to recognize start/data/stop bits on
the scope.

Make sure you have the correct pins connected, and in the correct
direction...


-- 
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/hd11egtr128p0bcja207cfe2lcemqubsu4%404ax.com.

[beagleboard] Re: Debug serial console not working

[Dennis Lee Bieber]

On Fri, 2 Jul 2021 15:44:12 +0530, in gmane.comp.hardware.beagleboard.user
Vinayakumar Chikkadi 
wrote:


>I am using the prolific usb to serial connector. After I connect the usb

WHICH "prolific usb to serial"?  They have a whole slew of different
models. And that doesn't count the packagers using a Prolific chip in their
products (cf:
https://www.amazon.com/prolific-usb-serial/s?k=prolific+usb+to+serial )
I'm guessing something similar to
https://www.amazon.com/Serial-Adapter-Signal-Prolific-Windows/dp/B07R8BQYW1/ref=sr_1_8?dchild=1=prolific+usb+to+serial=1625245702=8-8

I can't really help with Prolific -- most of my USB<>serial devices are
FTDI chips. I think the Adafruit 4-pin cable is the only Prolific chip
device I have.

>cable & When I check on Ubuntu with dmesg | tail
>I could see it’s getting enumerated as ttyUSB0
>When I open with putty on the path
>/dev/ttyUSB0 with 115200 8N1
>I am not able to open the com port using putty.

Do you have privileges for the device? May not be relevant, but
connecting a USB<>Serial to the USB side of my BBB (I don't have a native
Linux desktop computer, and Windows won't be helpful to you) shows up like

crw-rw 1 root dialout 188,  0 Jul  2 13:21 /dev/ttyUSB0

the default user for the machine does belong to the dialout group.

I got the same thing for Debian running inside VirtualBox /after/
manually selecting the USB device from the VB0x menu...

BUT... unlike the BBB, my user account under VBox does NOT belong to
the dialout group, so I would have not permission to use it without making
changes...

crw-rw 1 root dialout 188,  0 Jul  2 13:31 /dev/ttyUSB0
wulfraed@debian:~$ groups
wulfraed cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin
scanner vboxsf
wulfraed@debian:~$ sudo usermod -a -G dialout wulfraed
[sudo] password for wulfraed: 



wulfraed@debian:~$ groups
wulfraed dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth
lpadmin scanner vboxsf
wulfraed@debian:~$ 



-- 
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/rqhudg5e0ekfsmaetfe966socu9l1telkn%404ax.com.

[beagleboard] Re: GPIO JAVA library for Beaglebone Black

[Dennis Lee Bieber]

On Tue, 29 Jun 2021 07:02:06 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Radovan Chovan
 wrote:

>Thanks for all your comments.
>
>Is there any mapping between /sys/class/gpio and schematic diagram of 
>Beaglebone Black board?
>
Does
https://vadl.github.io/beagleboneblack/2016/07/29/setting-up-bbb-gpio
provide any help.

>I want to use pin P9_24 (UART1_TXD) and P9_26 (UART1_RXD).
>https://beagleboard.org/static/beaglebone/BEAGLEBONE_SCHEM_A3.pdf (page 
>11/11)
>
P9_24 equates to GPIO15, but in raw pin numbering appears to be 97. As
I recall, there are 32 GPIOs per "CHIP", so that might be the 4th CHIP
(counting from 0), and the second GPIO (again, counting from 0)

>>> divmod(97, 32)
(3, 1)

P9_26 -> GPIO14, raw 96...

>>> divmod(96, 32)
(3, 0)
>>> 

HOWEVER, 
debian@beaglebone:~$ gpioinfo
gpiochip0 - 32 lines:
line   0:  "MDIO_DATA"   unused   input  active-high

line  12: "UART1_CTSN"  "P9_20"   input  active-high [used]
line  13: "UART1_RTSN"  "P9_19"   input  active-high [used]
line  14:  "UART1_RXD"  "P9_26"   input  active-high [used]
line  15:  "UART1_TXD"  "P9_24"   input  active-high [used]
line  16: "GMII1_TXD3"   unused   input  active-high

indicates that it is CHIP0, and the "line" 14/15 map to the GPIOxx (so for,
say, GPIO45 it becomes chip 1, line 13)

The gpioinfo command is provided by installing the gpiod package.


debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -i
p9_26
Pin name: P9_26
Function if no cape loaded: gpio
Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input uart can
i2c pru_uart pruin
Function information: gpio0_14 default gpio0_14 gpio0_14 gpio0_14 gpio0_14
uart1_rxd dcan1_tx i2c1_sda pru_uart pru1_in16
Kernel GPIO id: 14
PRU GPIO id: 46
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -i
p9_24
Pin name: P9_24
Function if no cape loaded: gpio
Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input uart can
i2c pru_uart pruin
Function information: gpio0_15 default gpio0_15 gpio0_15 gpio0_15 gpio0_15
uart1_txd dcan1_rx i2c1_scl pru_uart pru0_in16
Kernel GPIO id: 15
PRU GPIO id: 47
debian@beaglebone:~$


(Unfortunately, that script doesn't tell one what "default" mode IS for the
pin, but does have more capability than the compiled config-pin that
replaces it)


-- 
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/vfamdgl62j1dvk417rb59nf514fba0o9ug%404ax.com.

[beagleboard] Re: GPIO JAVA library for Beaglebone Black

[Dennis Lee Bieber]

On Thu, 24 Jun 2021 07:17:59 -0400 (EDT), in
gmane.comp.hardware.beagleboard.user Robert Heller
 wrote:

>At Thu, 24 Jun 2021 03:47:49 -0700 (PDT) 
>beagleboard-/jypxa39uh5tlh3mboc...@public.gmane.org wrote:
>
>> 
>> I have complex Java application where using GPIO is only part of it.
>
>OK, probably the "easiest" (and Linux-only) way to add GPIO access is use the 
>sysfs interface.
>
At least until the Linux developers remove it... My understanding is
that sysfs is currently "deprecated", the replacement being libgpiod -- a
"character" device driver.

Unfortunately, for libgpiod, JAVA probably needs an interface library
to be created -- quick search finds
https://github.com/mattjlewis/diozero (though there are some mentions of
sysfs in the commentary, but perusing
https://github.com/mattjlewis/diozero/blob/main/system-utils-native/src/main/c/com_diozero_internal_provider_builtin_gpio_NativeGpioDevice.c
appears to be the libgpiod chip devices).

There is also this one https://github.com/sgjava/java-periphery


-- 
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/kpa9dg90iu6vofoq834flucro3cvee0jqi%404ax.com.

[beagleboard] Re: Beaglebone Black libraries for GPIO access in C/C++?

[Dennis Lee Bieber]

On Wed, 16 Jun 2021 09:58:08 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Mohammad Walihullah
 wrote:

>what is the process to access gpio for Jetson nano using qt creator
>

That board is not Beaglebone compatible, so this is not an appropriate
forum for questions on that board.

That said, the first hit on Google for "jetson nano gpio" is
https://maker.pro/nvidia-jetson/tutorial/how-to-use-gpio-pins-on-jetson-nano-developer-kit

As for QT Creator -- if you can't figure out how to link the above
access methods to QT Creator, you'll have to ask the maintainers of QT
Creator... https://forum.qt.io/topic/93213/accessing-gpio-s (most are
Raspberry Pi related, but reading enough of them might show what needs to
be changed for the Nano).
https://www.google.com/search?q=qt+creator+gpio+jetson+nano=inLKYNqjNtK3tAb7sr-YBA=qt+creator+gpio+jetson+nano_lcp=Cgdnd3Mtd2l6EAMyBQgAEM0COgcIABBHELADOgYIABAWEB46BQghEKABOgcIIRAKEKABOgUIIRCrAlCpOljCSGCkS2gBcAJ4AIABgAGIAdYJkgEEMTEuMpgBAKABAaoBB2d3cy13aXrIAQjAAQE=gws-wiz=0ahUKEwjakJ_SkZ3xAhXSG80KHXvZD0MQ4dUDCA0=5



-- 
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/meskcg1kj3uf3lvr434r0lp9055m2u2mf8%404ax.com.

[beagleboard] Re: How to copy BeagleBoard image to a windows PC

[Dennis Lee Bieber]

On Wed, 16 Jun 2021 09:37:05 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Nigel Beckles
 wrote:


>Thanks for responding to me. I have an emmc image on a SD card, I want to 
>copy the image from the SD card to my PC.
>When I put the SD card in the Pc, windows says it needs to format the 
>drive, What am I doing wrong?
>
Windows has no idea of how to access EXTn (Linux) file systems. As far
as Windows is concerned, inserting an SD card with EXT4 is the same as
inserting a never formatted SD card. Windows only reads FAT and NTFS cards.

Win32DiskImager https://sourceforge.net/projects/win32diskimager/ has
the ability to read a raw SD card. One problem is that it tends to require
an identical card for writing the image because it copies the entire card
layout, and a similar card may have reserved more blocks, meaning the image
won't fit the card. (Balena Etcher is write-only, but may be better for
that operation)


-- 
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/k6skcghugaoj39a2td5ulr3a6qao4qs425%404ax.com.

[beagleboard] Re: Reading ADC with both PRUs

[Dennis Lee Bieber]

On Fri, 11 Jun 2021 09:44:27 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

>I can have PRU1 do all the ADC configuration including setting up steps 1, 
>2 and 3 to read three analog lines in one-shot mode while steps 4 & are set 
>up to read the other two analog lines in continous mode.  I'll write data 
>from steps 1, 2 and 3 into FIFO0 and 4 & 5 into FIFO1.  
>
>The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
>the same time?  

Given that each PRU is capable of accessing the other's data RAM (as I
recall, each PRU sees its RAM at address 0, and sees the other's RAM at
some fixed offset), I'd probably use a few words of PRU0's RAM and have
PRU1 write into that space, along with a timestamp value -- PRU0 would look
for a change in the timestamp, then grab the ADC values (allowing PRU1 to
write new values while PRU0 processes the previous set -- Or PRU0 clears
the timestamp [which is no longer a timestamp] which PRU1 sees as "okay to
write new values", PRU1 then sets the timestamp byte to tell PRU0 "okay to
read". Closest I can come to a shared semaphore/mutex (are there any
synchronization primitives in the PRU runtime?).


-- 
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/s377cghljsjo1uhfmsn4sbj7bi1206lcnq%404ax.com.

[beagleboard] Re: Pocketbeagle Wifi Dongle Problems

[Dennis Lee Bieber]

On Tue, 1 Jun 2021 09:33:31 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Patrick Bolton
 wrote:

>This morning,  I setup a brand spanking new pocketbeagle straight out of 
>the package and have very concerning errors on installation of the most 
>recent image.  Nothing whatsoever is connected other than the USB cable to 
>my PC. And the device is sitting on a grounded anti-static pad.
>

Do you have standoffs on that board...Sitting on an anti-static pad
could be making contact with some underside circuitry, causing unexpected
voltages on some pins.


-- 
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/s3efbgt3mlajr2sfg186aij9ud3pdmro1h%404ax.com.

[beagleboard] Re: Pocketbeagle Wifi Dongle Problems

[Dennis Lee Bieber]

On Mon, 31 May 2021 08:09:54 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Patrick Bolton
 wrote:

>I am having problems with wifi dongles with the pocketbeagle.

You've pasted a novel of logs, but nowhere do you state exactly what
"problems" means?

>
>I have two dongles:
>1) Edimax EW-7811Un:  
>EDIMAX - Wireless Adapters - N150 - N150 Wi-Fi Nano USB Adapter, Ideal for 
>Raspberry Pi 
>
>
>2) tp-link  TL-WN725N V3
>TL-WN725N | 150Mbps Wireless N Nano USB Adapter | TP-Link 
>

Have you read
https://static.tp-link.com/2018/201812/20181207/Installation%20Guide%20for%20Linux.pdf
(Granted, the OS/kernel specified in the R-Pi section is antique, but the
rest /might/ apply).

>
>I have tried them in two configurations:
>1)   I cut a usb-a female cable and wired it to the PB in accordance with:
>https://i1.wp.com/www.teachmemicro.com/wp-content/uploads/2018/03/pocketbeagle-usb-type-a.jpg?w=590=1
>2)  2-port usb hub from tindie
>2/4-port USB 2.0 HUB Cape for PocketBeagle from microwavemont on Tindie 
>
>
>Voltage Readings
>Pin  Function  USB Power  5V 0.8A HUB  5V 
>8A power supply

How are you powering the Beagle and hub? Note that USB 2.0 standard is
that only 0.5A is available (and often needs a powered hub to get that). If
the beagle is being powered from a USB connection, you will have much less
current available for any devices connected to it, as the Beagle itself
requires some fraction of the available power (it's why Beagle Bone Black
is recommended to use a barrel connector rather than USB when flashing the
eMMC). A 5V 8A supply is not doing much unless you've wired directly to the
hub 5V source (or P1-1

Since the WiFi adapter runs a micro-radio, you likely need a higher
current just for it, so powering from the USB into the Beagle may not be
viable. I know R-Pi boards with WiFi operate off a USB connection, but that
is not a data connection -- just a specialized power mode which modern hubs
can recognize and provide a touch more current.

>Image:  
>https://debian.beagleboard.org/images/bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz
>2) apt update
>3) apt upgrade
>4) init 6

Pardon, but why the "init 6" (especially as Debian has adopted the
systemd start up, deprecating "init" mode). 


>2) tp-link driver update
>Download for TL-WN725N | TP-Link 
>
>

Okay -- you've probably read the referenced PDF then, as the downloads
are source needing to be compiled. But I note 
"4. This is a beta version; unknown bugs may still exist. The formal
version is coming soon." 
and that was three years ago... Only the Mac version has seen updates newer
than the Linux beta. The beta is also only "tested" up to kernel 4.4.3, and
recent Beagle images are on what, 4.19.x

https://wiki.debian.org/WiFi (possibly a bit dated)
"""
Currently there are only a few modern wifi chipsets readily available that
work with free software systems. For USB wifi devices this list includes
the Realtek RTL8187B chipset (802.11G) and the Atheros AR9170 chipset
(802.11N). For Mini PCIe all cards with an Atheros chipset are supported. 
"""
"""
Edimax EW-7811Un

USB adapter

1 (9,[nPP],[B]), 1 (NOOBS,2015,[B]), 1 (2013,[B]), 1 (2016,[B]), 1 (2014),
1 (ARMv6,[B])

For a guide see multiple in the Amazon reviews. There seems to be a problem
with this dongle's range.
"""
"""
Device

Confirmed

Drawbacks/Comments

Guide

TP-Link TL WN821N

(./)

- The original code of the driver is copyrighted and later contributors
don't know by whom.
The driver download does not contain license information.
(Most C files are licensed under GNU General Public License (GPL), version
2.)
- Only works when disabling random MAC addresses.

1. Update: sudo apt-get update && apt-get upgrade && && apt-get
dist-upgrade and reboot if you updated the kernel
2. Connect the device. lsusb should show 2357:0107
3. Install required packages: sudo apt-get install gcc-6 git
build-essential
4. Get the latest driver from ?GitHub and install it:
git clone https://github.com/jeremyb31/rtl8192eu-linux-driver.git
cd rtl8192eu-linux-driver
sudo make
sudo make install
5. Reboot and check that the kernel module is loaded by running: lsmod
6. Use your network-interface to connect to the WLAN. You could use the
pre-installed NetworkManager for that.
(7.) Edit NetworkManager.conf as root: sudo kate
/etc/NetworkManager/NetworkManager.conf
Append the following:
[device]
wifi.scan-rand-mac-address=no
Save and run: /etc/init.d/network-manager restart
"""


>root@beaglebone:/var/lib/cloud9# lsusb
>Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>Bus 001 Device 001: ID 

[beagleboard] Re: BeagleBone Black (C) USB based touch not working

[Dennis Lee Bieber]

On Sun, 30 May 2021 16:13:00 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Kasimir
 wrote:

>But I'm hanging with touch. 
>Installed is: Linux beaglebone 4.19.94-ti-r64 #1buster SMP PREEMPT Fri May 
>21 23:57:28 UTC 2021 armv7l GNU/Linux
>Plan is to write directly into the framebuffer, no X no desktop.
>That works also fine, very fast.
>But with touch  I'm running out of ideas.
>Was expecting a conflict with USB Network, is now deactivated, no change.
>/dev/input/event0 is existing. But no events .

Could you be having a conflict with the native LCD system (which is
active in parallel with the HDMI). The native LCD system expects a
capacitive touchscreen on the P9 (I think) pins.

Might help if you identified WHICH product you are using. This one
https://www.amazon.com/GeeekPi-1024x600-Capacitive-Monitor-Raspberry/dp/B075QCXLPF/ref=asc_df_B075QCXLPF/?tag=hyprod-20=df0=309707619534==g=5324710204179150785c===9017241=pla-570706414713=1
mentions a "free driver" (I would hope so -- I doubt they'd sell many if
they said the driver was extra cost; though the best documentation I find
for it says "driver-free" -- meaning no driver needed).

I would note that the compatibility list on

does NOT mention beagle bone, though the body text does.

"""
Power Supply 5V/1A via USB port
"""
OUCH! Beagle USB maxes out at 500mA (which is the spec for USB2); you'll
need a powered USB hub with high-power ports.

"""
Please make sure the FPC cable is fastened and please connect the
MicroUSB cable to your device so that it can communicate with the touch
panel.
Please make sure the USB power cable is connected properly.
"""

Implies one needs to use a separate USB power supply

One port is power, the other is data.


-- 
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/e8c8bg9plf21qab86ff5tpjak2acbem7gb%404ax.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Sun, 30 May 2021 11:51:27 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Karishma Jaiswal
 wrote:


>Can u suggest any way to change my application as currently my application 
>is getting call from .bashrc file and now it's taking around 35 sec to get 
>execute.
>Some how can I call the .bashrc file bit faster?  
>this will really help to reduce the boot time.

Since .bashrc is a SHELL CONFIGURATION file, it gets run when a BASH
shell is opened. So how are you getting to a bash shell? (It is vaguely
possible you have some script being started by systemd, or a @reboot
crontab entry, which specifies that the bash shell is to be used).

Bash shell/command interpreter won't be available until most of the OS
has booted.


-- 
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/kiq7bg9bp9d6r1q8olssa7vg41a05ant9j%404ax.com.

[beagleboard] Re: PRU Assumptions - True or False

[Dennis Lee Bieber]

On Fri, 28 May 2021 13:15:20 -0400 (EDT), in
gmane.comp.hardware.beagleboard.user Robert Heller
 wrote:


>
>YES.  5.x kernels only support UIO.  You need a 4.x TI kernel for RemoteProc.
>

Ouch -- a reversion...

>
>I think the mainline kernels don't have the RemoteProc kernel code.  At least 
>by default.
>
Going to impact the day when Beagle images get Debian 11 I suspect --
since I think Debian 11 is a 5.x kernel.


-- 
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/hhn2bghq9pdbv65busub3s32fs58do7ibs%404ax.com.

[beagleboard] Re: PRU Assumptions - True or False

[Dennis Lee Bieber]

On Fri, 28 May 2021 10:11:46 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester
 wrote:

>Dennis,
>
>Thanks for your response. 
>
>When developing with the UIO architecture, they use the term "interrupt", 
>so I assume they meant it somehow, but not willing to die on that hill. I 
>could not get any form of "what they called interrupt" to work the remote 
>proc architecture. I tried, and tried, and tried. If that solution exists I 
>would greatly appreciate it.

I'd need to study much more to find out how a PRU passes an interrupt
to the ARM core, but a comment in
https://www.google.com/url?sa=t=j==s=web==2ahUKEwiW0qzomO3wAhUSV80KHdPiBj8QFnoECAgQAA=https%3A%2F%2Fwww.ti.com%2Flit%2Fpdf%2Fsprace9=AOvVaw1D0FgDrMcykHqZsXm5UPdq
(getting started guide from TI: SPRACE9A)
"""
The PRU_ICSSG adds a Task Manager, which can preempt currently running
code. The Task Manager allows firmware to meet timing requirements for high
priority tasks by interrupting lower priority tasks.
"""
reinforces that the non-enhanced PRUs on the BBB (PRU_ICSS vs PRU_ICSSG) do
not have preemptive interrupts.

That document also implies that interrupts are viable, but have to be
defined in the resource tables of the firmware
"""
User applications can require communication between the PRUs and the Arm
core. Linux provides a method for this communication called RemoteProc
Messaging (RPMsg). RPMsg fits into the RemoteProc framework. TI provides a
RPMsg library and getting started examples to demonstrate how to use RPMsg.
These examples showcase the PRU firmware using its resource table to
request specific interrupt mappings and shared memory to implement the
communication channel.
"""

Strangely, section 3.6.2.2 of
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Overview.html
describes TI's PRU as Ethernet port mode, supposedly using RProc/RPMsg. But
when you get to the Linux side (section 3.6.4.1) they are suddenly back to
using UIO.

https://elinux.org/PRUSSv2_Interrupt_Controller (linking to
https://elinux.org/PRUSSv2_Interrupts ) indicates that PRU interrupt #60 is
the one that "sets" when a message has been left in the PRU0 mailbox.

SPRUHF8A (am335x Pru Reference) has
"""
6.1 Introduction
The PRU-ICSS interrupt controller (INTC) is an interface between interrupts
coming from different parts of the system (referred to as system events)
and the PRU-ICSS interrupt interface.

The PRU-ICSS INTC has the following features:
• Capturing up to 64 System Events
• Supports up to 10 interrupt channels.
• Generation of 10 Host Interrupts
– 2 Host Interrupts for the PRUs.
– 8 Host Interrupts exported from the PRU-ICSS for signaling the
ARM interrupt controllers.
• Each system event can be enabled and disabled.
• Each host event can be enabled and disabled.
• Hardware prioritization of events.
"""
• Host Interrupt 0 is connected to bit 30 in register 31 of PRU0 and
PRU1.
• Host Interrupt 1 is connected to bit 31 in register 31 for PRU0 and
PRU1.
• Host Interrupts 2 through 9 exported from PRU-ICSS for signaling ARM
interrupt controllers or other machines like EDMA.
"""

Unfortunately, I've never found any documents for either RPMsg or UIO
APIs... Or, at least, not something I'd consider API documentation (I was
spoiled decades ago by the documentation for VAX/VMS, which filled two
shelves of a bookcase with 3" 3-ring binders).


-- 
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/12k2bg9phsh8ui18fqpibktrgj0n12ql6r%404ax.com.

[beagleboard] Re: PRU Assumptions - True or False

[Dennis Lee Bieber]

On Fri, 28 May 2021 08:13:05 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester
 wrote:

>I am using BBB Revision C
>
>Please help me get clarity on my assumptions that I believe I have learned 
>so far and tell me where I am incorrect:

Can't confirm for everything, but...
>
>1. There are 2 architectures to interact with the PRU's. They are *UIO* and 
>*RemoteProc*. And they can easily be selected in the /boot/uEnv.txt file. 
>You cannot run both at the same time.

TRUE -- but maybe not "easily"; there are some dependencies upon the
kernel version loaded.

TI has deprecated UIO and considers RemoteProc to be the route for
future usage (it is not tied to just the PRUs, it should work with the DSP
chips on the BB AI, et al.).

>
>2. When using RemoteProc you can *send* a remote message to the PRU and 
>this solution *does not work* with UIO.

RPMsg supports sending message in both directions
https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html
"""
There are two vrings provided per PRU core, one vring is used for messages
passed to the ARM and the other vring is used for messages received from
the ARM. System level mailboxes are used to notify cores (ARM or PRU) when
new messages are waiting in the shared buffers.
"""

>
>3. When using UIO the PRU can *send* an Interrupt to the host code but 
>RemoteProc *cannot*.
>
>4. When using UIO, you *cannot* send an interrupt to the PRU, you need to 
>create some other solution maybe through shared memory.
>

As the PRUs do not have what I would call true interrupts (they have a
set of "interrupt bits" but do NOT interrupt the processor, the bits have
to be polled, and appropriate handlers called) any talk of interrupts is
vague.

However, for RPMsg, the "mailbox" provides, I believe, some form of
blocked wait or maybe use of a select() call to test for mailbox data. I
don't really know what a "Kick" entails in:
"""
ARM Host Steps
Step 1a: Allocate a new buffer -or-
Step 1b: Get a Used buffer from the slave Vring
Step 2: Copy data to be transferred into the buffer from Step 1
Step 3: Add the newly filled buffer to the Available list in the
slave Vring
Step 4: Kick the slave Vring by writing its index (1) into a
message in Mailbox 2
PRU Steps
Step 5: A Kick is discovered in Mailbox 2 with the index of the
Kicked Vring (1). This indicates to the PRU that data is available for
receive
Step 6: Get the Available buffer from the slave Vring
Step 7: Copy data to be received out of the buffer from Step 2
Step 8: Add the now empty buffer to the Used list in the slave
Vring
Step 9: Kick the slave Vring by writing its index (1) into a
message in Mailbox 3
"""
Step five appears to be a polling loop on the mailbox.




-- 
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/ls52bghfoffdbk52e1fjtlggc7l8qvq4e0%404ax.com.

[beagleboard] Re: ioctl messages to Beagle SPI port.

[Dennis Lee Bieber]

On Tue, 25 May 2021 19:44:55 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


>
>OK.  Hadn't noticed until I tried it on the Beagle that it uses 
>PXL.Boards.RPi.pas which has the definitions for the high speed I/O.  The 
>Beagle doesn't appear to have that feature as there is no PXL.Boards.BBB.pas 
>file.  Looks like Beagle I/O has to go through the file system.

Well -- it might be possible to clone the R-Pi version and redefine all
the memory and bitmap addresses to match the BBB , and then modify
whatever code detects the platform...

>
>So this particular SPI program is _not_ portable from the Pi to the Beagle and 
>therefore I will stop talking about it on this Beagleboard forum.

Technically, I think the "program" source is portable, but not binaries
-- the device access is different between the two, but the end result
should be the same.

See my previous response regarding the R-Pi kmem group membership.


-- 
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/inhragtohjhreqsamsv53959akqnkvn7kn%404ax.com.

[beagleboard] Re: ioctl messages to Beagle SPI port.

[Dennis Lee Bieber]

On Tue, 25 May 2021 19:16:51 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>Hi Dennis,
>I tried on the groups site to edit this post and change what I wrote.

While the master copy appears to be a Google Groups entry, it seems to
be propagated outward since gmane is able to copy it and provide NNTP
access (which is how I'm reading -- but about a year ago submitted replies
via gmane were getting rejects from the main group, so I've had to email
replies to Google...).

NNTP spec does offer a CANCEL command to delete posts... BUT most
servers have disabled that (too easy to spoof a user and delete posts one
objects to, perhaps).

Since the messages are on distributed servers, they are essentially
"fire and forget" -- there is nothing one can do once they've hit send...

>It's a good point you make there.  However then the SizeOf function might well 
>return something different in size to make everything fit.  I've also heard of 
>systems re-arranging the members of a record to suit.  In pascal to make that 
>happen you defined it as packed.  
>

My concern was that the C code might be packing things differently from
FreePascal, which could mean some of the arguments will not be where the
kernel expects to find them.

OTOH: I believe ARM Cortex architecture is defined to use byte
alignment (even if word/longword alignment is how the memory bus operates),
so both C and Pascal should be generating packed structures.

>Because this example program uses the high speed gpio the fault happens much 
>sooner on the Pi without the sudo.
>
>pi@raspberrypi:~/projects/lazarus/TC $ ./TC
>An unhandled exception occurred at $00084EE4:
> ERPiOpenFile: Cannot not open 
> file  for memory mapping.
>$00084EE4  TFASTSYSTEMCORE__CREATE,  line 451 
> of /home/pi/projects/lazarus/pxl/Source/PXL.Boards.RPi.pas
>  $00010410  main,  
> line 95 of TC.lpr
>

That may be devolving to the similar timing problem as earlier -- if it
is doing memory mapping to get to GPIO rather than using the sysfs access,
it may take time to get memory privileges set up.

https://man7.org/linux/man-pages/man4/mem.4.html

Hmmm, it appears that /dev/mem is a udev victim. Freshly booted a BBB gave

crw-r- 1 root root  1,   1 Dec 31  1999 mem

but repeating the command a few seconds later shows

crw-r- 1 root kmem   1,  1 May 25 23:45 /dev/mem

(note that the first is using the system default date, while the second is
after the system synched clocks).

Making the R-Pi user a member of group kmem might improve things; the
Beagle already has kmem for user

debian@beaglebone:~$ groups debian
debian : debian adm kmem dialout cdrom floppy audio dip video plugdev users
systemd-journal input bluetooth netdev i2c gpio admin spi iio docker tisdk
weston-launch xenomai cloud9ide pwm eqep remoteproc
debian@beaglebone:~$


-- 
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/fagrag9ss0tg8q0vovkcsum29okdgm4k2j%404ax.com.

[beagleboard] Re: ioctl messages to Beagle SPI port.

[Dennis Lee Bieber]

On Tue, 25 May 2021 12:55:32 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


>My understanding is both systems place the variables on the heap.  Only the 
>small micro-controllers with limited stack space (recall some of the PIC16 
>series had a 2 word call stack).  Other systems in the micro-controller area 
>might limit the stack to 256  bytes due to paging schema.

Unless things have changed in the last decade or two, the normal
behavior of variables defined within a C function is that they were
allocated on the stack. I believe to get them into the heap or BSS space
required them to be declared "static"... Or to use malloc() (and kin) to
allocate the structure space from the heap (I think C++ "new" is equivalent
to a heap allocation).

https://www.google.com/url?sa=t=j==s=web==2ahUKEwi_n8HplubwAhUEH80KHTvaDnMQFnoECCgQAA=https%3A%2F%2Fwww.seas.upenn.edu%2F~cit593%2Fcit593f09%2Flectures%2Fstructs.pdf=AOvVaw1TWuW67QkVCNXBNHnhbVan
"""
We define a variable using our new data type as follows:

struct w_type day;

Memory is now allocated (on stack), and we can access
individual fields of this variable
"""

Or http://www.avabodh.com/cin/structure.html which has a sample of assembly
output, which sure looks like stack-relative access to me...

> 
>The record (struct) is essentially the same in C or Pascal.
>  spi_ioc_transfer = record
>tx_buf: UInt64;
>rx_buf: UInt64;
>len: LongWord;
>speed_hz: LongWord;
>delay_usecs: Word;
>bits_per_word: Byte;
>cs_change: Byte;
>pad: LongWord;
>  end;

Something else to consider -- alignment. C compilers may add padding
between elements to match some architecture idea of ease-of-access (on a
four-byte alignment, a single byte/char field will have three bytes of
padding added to put following data on a 4-byte increment). cf the avabodh
page.


>BTW.  For the Pi to make this work I have to either run it with sudo from the 
>command line or run Lazarus with sudo.  The help everyone provided on the 
>Beagle  to make my user part of the gpio group means the code can run and be 
>debugged from within the IDE.

Sounds like the R-Pi may not have set the same group memberships.
Though mine seems to have gpio and spi set...

pi@rpi3bplus-1:~$ groups
pi adm dialout cdrom sudo audio video plugdev games users input netdev
lpadmin gpio i2c spi
pi@rpi3bplus-1:~$



-- 
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/ra9rag5p83r4p3kgl8bmt19u9asiipd5b9%404ax.com.

[beagleboard] Re: ioctl messages to Beagle SPI port.

[Dennis Lee Bieber]

On Tue, 25 May 2021 09:45:39 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


> 
>Here's the BBB version from and you can see the code is identical for both the 
>Pi and the Beagle.
>https://github.com/derekmolloy/exploringBB/blob/version2/chp08/spi/spidev_test/spidev_test.c
>==
>uint8_t rx[ARRAY_SIZE(tx)] = {0, };
>struct spi_ioc_transfer tr = {
>.tx_buf = (unsigned long)tx,
>.rx_buf = (unsigned long)rx,

Somewhat confusing code -- one has to track upwards in the code... C
arrays are a synonym for pointers, so he's using unsigned long to store a
pointer to the array.

I'm not downloading the source again to see how the buffers are
defined...
> 
>  Data.tx_buf := PtrUInt(WriteBuffer);
>  Data.rx_buf := PtrUInt(ReadBuffer);

... just notice this explicitly asks for a pointer (given my stale C
history, I'd tend to read that as a pointer to an unsigned integer of some
size... But the C version has the buffers defined as uint8_t (new in
C99/C++11) with is an 8-bit unsigned (equivalent to old unsigned char).

Does FreePascal have size differentiation?



>It's likely the C compiler clears this structure when it's declared or extends 
>0's out on an assignment that isn't done by the FreePascal compiler.  And that 
>it was required in that Pi forum posting for C code suggests it's perhaps even 
>somewhat random.  Compiler flags maybe?

"""
-fno-zero-initialized-in-bss

If the target supports a BSS section, GCC by default puts variables
that are initialized to zero into BSS. This can save space in the resulting
code. 
"""

is the closest GCC option I saw. The OS may do zeroing when it allocates a
block of memory to the application, but that wouldn't affect stack usage --
and the C code is allocating the structure on the stack. I presume Pascal
is doing the same (since it allows recursion). Not seeing the declaration
of "Data" means I can't be certain -- FreePascal may have keywords to force
allocation on heap..



-- 
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/r4cqagp6uljj4n53p65c3j4tl6ds3078uj%404ax.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Mon, 24 May 2021 20:47:42 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Karishma Jaiswal
 wrote:


> not getting the exact reason why * 51.048s dev-mmcblk1p1.device *this is 
>taking too much time and is there any way that we can reduce it?
>

Part of that may be tied to the flash memory device itself. Booting
from eMMC, my BBB came up with:

debian@beaglebone:~$ systemd-analyze blame
 48.972s generic-board-startup.service
 48.587s dev-mmcblk1p1.device
  3.739s nginx.service

But booting from a uSD card (my normal mode to avoid "wearout" of the eMMC)
showed:

debian@beaglebone:~$ systemd-analyze blame
 49.889s generic-board-startup.service
 39.657s dev-mmcblk0p1.device
  4.126s nginx.service

... The uSD was 10 seconds faster, even though that is an 8GB uSD card vs
the 4GB eMMC.

I couldn't find anything confirming if there is some sort of boot time
fsck being run.

debian@beaglebone:~$ sudo tune2fs -l /dev/mmcblk0p1
tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name:   rootfs
Last mounted on:  /

Last mount time:  Tue May 25 12:34:35 2021
Last write time:  Tue May 25 12:34:31 2021
Mount count:  132
Maximum mount count:  -1
Last checked: Wed Aug 19 21:34:49 2020
Check interval:   0 ()

debian@beaglebone:~$

Those seem to imply that no fsck is run at boot time.



-- 
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/giaqagl01530vpudgp1iunc51c0h6aoah9%404ax.com.

[beagleboard] Re: PRU Messaging

[Dennis Lee Bieber]

On Tue, 25 May 2021 07:40:20 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester
 wrote:

>*It is asking you to confirm which Beagle you are using.:*
>I am using Beaglebone Black Revision C
>
>
>*It will be much quicker to do an apt update/aptupgrade.:*
>I performed the update/upgrade and /etc/dogtag still reports the same info.
>Should I get a newer image? Is the issue my distro?
>

I don't think the "dogtag" gets updated from repositories. It likely
just identifies the original image burned to the memory.

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux
debian@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Buster IoT Image 2020-08-19
debian@beaglebone:~$

I've been doing apt update/apt upgrade at least monthly since writing that
image.




-- 
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/0b8qagp2svu58m5dnahd5racivt550rmmk%404ax.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Mon, 24 May 2021 15:36:54 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


>I will state that waiting over two minutes for a Beagle to boot into Linux 
>desktop mouse/keyboard/screen is unacceptable.  Windows with a 640K 8088 or a 
>Pentium-33MHz  could create a graphical desktop way faster than a 1GHz Beagle 
>with super fast SD card and 512MB of ram.  From an end user perspective 
>anything longer than 10 to 15 seconds just means it's not done right.

WfW barely qualified as a desktop. It was more of an application
manager running on top of MS-DOS.

My current desktop machine: 3.4GHz Intel i7-3770 with 12GB of RAM and
Windows 10, from a shutdown state took:

1:15 to reach the blue four-windows logo
2:00 to reach the Windows boot chime
2:25 to get to the login screen (and since my default user doesn't have a
password...)
2:55 to get to user desktop -- it was still loading various services for a
few more minutes after that

>
>So I'd like to pose the question back to the original poster of this thread 
>karry.jaiswal-Re5JQEeQqe9fmgfxC/sS/w...@public.gmane.org  Why are you using a 
>Beagle if you need fast boot times?  What is it that the Beagle Green has that 
>you need compared to something with an RTOS (Free RTOS for example).  Why 
>Linux?
>
>
>And with respect to University days I'll deny I ever took Fortran or Cobal 
>courses.
>
It shows... 

COBOL COmmon Business Oriented Language
COBAL Generic Name: cyanocobalamin (vitamin b-12)


-- 
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/jh7qagtbnnusf9aet6khtpo7aqarjqug94%404ax.com.

[beagleboard] Re: PRU Messaging

[Dennis Lee Bieber]

On Mon, 24 May 2021 21:16:32 + (UTC), in
gmane.comp.hardware.beagleboard.user "'Mark Lazarewicz' via BeagleBoard"
 wrote:


>I don't own an AI and expecting someone to get your code and run it I can't do 
>it  is all I'm going to say. I can help guide you and MAYBE try it on BBWhite 
>if I have time. In theory the AM 5729 should work the same. 

If adjusting for the fact that there are 4 PRUs (two modules each with
two PRU cores) -- along with two C66x DSPs (and theoretically a pair of ARM
Cortex M-4 processors -- but I think those were taken up by SoC control
logic), and 4x Embedded Vision Engines (Used, I expect, by the TIDL
projects). However, as the headers are the same as the Beaglebone Black, I
have no idea of what pins are available for the added PRU cores.



-- 
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/vcaoag1j8f8ss8n33650d1hjp1gm6uf156%404ax.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Mon, 24 May 2021 09:26:44 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"robert.sty...-re5jqeeqqe8avxtiumw...@public.gmane.org"
 wrote:

>
>For a screen based turnkey app, you can only display a splash screen for a 
>few seconds, before the user thinks it is broken, a bit longer for an 
>animated splash screen. Imagine a car radio, something has happen 
>immediately after power on (speaker click or LED indicator or screen 
>backlight), then less than half a second "Tuning..." before music appears.
>
Probably not the best example. At best the "car radio" is running a
microcontroller -- not a microcomputer -- with maybe an RTOS at best. The
"radio application" is burned into the microcontroller flash memory, AND
RUNS out of that flash memory. There is no setting up RAM (virtual memory
mapping) as "RAM" in most microcontrollers is the general purpose register
bank. There may be secondary flash or EEPROM used to store user settings
(current volume/tone encoder position, stored station listing). A bigger
unit may include a spinning disk or "user flash" for storing MP3s, but the
core system doesn't have real "boot" phase.

Think Arduino Due, TIVA TM4C123 or TM4C1294, STM chips. ARM "M" cores,
not "A" cores.

On power-on, they start running the code burnt into the on-board flash
(and the first thing said code likely does is read the saved configuration
and command displays/output encoders to those values).

{Heck, most of the car is running off of microcontrollers with the single
application for each burned into flash. Can you imagine having to wait 60+
seconds for a Linux type OS to boot before you can turn the switch from ON
to START?}



-- 
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/o12oag1s6rh38toqsgpknisuv63nmuvp7c%404ax.com.

[beagleboard] Re: PRU Messaging

[Dennis Lee Bieber]

On Mon, 24 May 2021 10:25:57 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester
 wrote:


>*2 This is the BB AI correct?*
>I do not know what this question means..please clarify. 
>

It is asking you to confirm which Beagle you are using.

> 
>*4 What is your ARM OS and version. Compiler host  details*
>BeagleBoard.org Debian Buster IoT Image 2020-04-06,  4.19.94-ti-r42.  A 
>fresh release from https://beagleboard.org/latest-images
>
Unfortunately, that is a year out of date... It's basically the image
that was shipped on new boards (to my knowledge the "testing" images don't
get shipped). Doing an apt update/apt upgrade will take lots of space
staging the files, and quite some time (it is Debian 10.3, and Debian is
now at 10.9)

You might want to grab one of the images at
https://rcn-ee.net/rootfs/bb.org/testing/2021-04-27/ (buster is Debian 10,
stretch is prior Debian 9). It will be much quicker to do an apt update/apt
upgrade.

Unfortunately you trimmed the description so that the question of board
is still open.

AM3358 (now seen as "bone-debian..." in "testing") is for Beaglebone
BLACK/GREEN and other clones. AM57829 (seen as am57xx in testing) are for
the BB-AI (Beaglebone Artifical Intelligence) and X-15 boards.


-- 
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/vt0oag16eu9rbdj1f43s72ulb72ppcn9km%404ax.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Mon, 24 May 2021 11:34:41 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


>But the side effect is that 16 to 18 seconds appears to be the fastest it can 
>wake up which means it's not always the best solution for a product.  But in 
>this world of Python and web based programming, embedded systems have taken a 
>back seat.
>

https://www.adafruit.com/product/4064
Native system runs the CircuitPython interpreter in chip, with Python
application code files on the external flash (if you want base Arduino
behavior, you replace the in-chip CircuitPython with your Arduino sketch,
and use the external flash for data storage).

There are smaller Metro M4 Express (out of stock) and Metro M4 Express
AirLift (with on-board WiFi)

>If you were a new grad from what now tends to be called "Computer Engineering" 
>would you take a job that offered $100K per year as a web designer or $60K 
>developing embedded systems that required assembler knowledge?

Considering my ancient degree was "Computer Science" with an emphasis
on "systems" software rather than "business" software*... I'd probably have
qualified for the latter (at the time, as a new-hire at Lockheed Sunnyvale,
I got only $21K -- which had grown to $125K after 30 years) {And had a
defined benefit retirement plan, vs defined contribution... After layoff
moved to MI and manage a few years at GE Aviation -- my ("early
retirement") from Lockheed was nearly as much as GE paid!}




*   "systems software" covered OS principles along with
compilers/linkers/etc, and language design. "business" had two terms of
statistics using SPSS (I'm sure these days they'd be using R [optimal],
Octave [as a backup -- Octave being a number cruncher/display tool, where R
includes more statistics testing built-in]), or maybe Python with SciPy and
or pandas extensions.
.


-- 
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/pktnagp3uoktfbhbc9ijpg455n3u498gs2%404ax.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Sat, 22 May 2021 12:00:54 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Karishma Jaiswal
 wrote:

> 15.945s postfix.service

Do you need a mail delivery service? http://www.postfix.org/ You have
scripts sending emails?

> 12.165s generic-board-startup.service
>  8.654s apache2.service

Do you need a web-server -- and if you do, does it have to be Apache?
Consider that nginx is installed as part of the normal Debian images.

>  7.635s systemd-logind.service
>  6.160s avahi-daemon.service

https://www.linux.com/topic/desktop/cleaning-your-linux-startup-process/
"""
avahi-daemon.service is supposed to provide zero-configuration network
discovery, and make it super-easy to find printers and other hosts on your
network. I always disable it and don’t miss it.
"""


>  5.594s systemd-hwdb-update.service
>  5.568s ondemand.service
>  5.432s loadcpufreq.service
>  4.968s bb-wl18xx-bluetooth.service
>  4.578s led-status.service
>  3.547s networking.service
>  2.981s capemgr.service
>  2.412s hostapd.service

Do you need to have the unit operate as a WiFi hotspot (Access Point)?
Note: not sure if the authentication feature is used for regular connection
/to/ an access point (WiFi Router). https://man.openbsd.org/hostapd.8

>  2.389s rsyslog.service
>  2.073s cpufrequtils.service
>  1.535s ssh.service
>  1.477s systemd-user-sessions.service
>  1.389s pppd-dns.service

Same web site:
"""
pppd-dns.service is a relic of the dim past. If you use dial-up Internet,
keep it. Otherwise, you don’t need it.

"""
>  1.151s systemd-udev-trigger.service
>  1.040s archive_log.service
>  1.011s systemd-journal-flush.service
>   979ms rc-local.service
>   860ms brltty.service
Ditto:
"""
brltty.service provides Braille device support, for example, Braille
displays.
"""

>   653ms keyboard-setup.service
>   629ms systemd-journald.service
>   609ms tacread-keymap.service

Can't find any information on "tacread" via Google... Nor via apt
search in Buster IoT release.

>   499ms rename-bluetooth-hardware.service
>   494ms systemd-update-utmp.service
>   462ms systemd-udevd.service
>   451ms resolvconf.service
>   437ms dev-mqueue.mount
>   437ms sys-kernel-debug.mount


-- 
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/k4ijagp7lm355ji1vg6pt54eglkdq034jl%404ax.com.

[beagleboard] Re: ioctl messages to Beagle SPI port.

[Dennis Lee Bieber]

On Fri, 21 May 2021 09:39:34 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>static const char *device = "/dev/spidev1.0";
>   fd = open(device, O_RDWR);
>   if (fd < 0)
>   pabort("can't open device");
>
>One of two things happen.  Either It opens the SPI bus which includes 
>everything that config-pin does or it fails because config-pin wasn't done.

Hypothesis: The "device" (driver) is loaded -- but the pin-mux does not
have the pins connected to the internal port(s) used by the driver... So
the driver is basically dumping output into the "bit-bucket".

It can't really take control -- since the same pins are used by I2C
mode, if opening the "device" did the pin-mux one could really mess up data
transfers (open "I2C" start transfer, then open SPI using the same pins).

>> >Oh and none of this explains why the ioctl regardless of C or Pascal 
>> >
>can't handle more than 4096 data bytes while the Python code can when sending 
>a large bitmap to the SPI port.  
>...
>> debian@beaglebone:~$ cat /sys/module/spidev/parameters/bufsiz
>> 4096
>> debian@beaglebone:~$
>
>How did you know to look at this file to determine the SPI buf size?  

https://www.kernel.org/doc/Documentation/spi/spidev
"""
- There's a limit on the number of bytes each I/O request can transfer
  to the SPI device.  It defaults to one page, but that can be changed
  using a module parameter.

- Because SPI has no low-level transfer acknowledgement, you usually
  won't see any I/O errors when talking to a non-existent device.
"""

along with the source for the Python spidev module, which explicitly
mentions that parameter... Though just doing 

sudo find / -iname "spidev" 

and exploring what each result contains (or to bypass one layer)

debian@beaglebone:~$ ls -R `sudo find / -iname "spidev"`
/sys/bus/spi/drivers/spidev:
bind  module  spi0.0  spi0.1  spi1.0  spi1.1  uevent  unbind

/sys/class/spidev:
spidev0.0  spidev0.1  spidev1.0  spidev1.1

/sys/devices/platform/ocp/4803.spi/spi_master/spi0/spi0.0/spidev:
spidev0.0

/sys/devices/platform/ocp/4803.spi/spi_master/spi0/spi0.0/spidev/spidev0.0:
dev  device  power  subsystem  uevent

/sys/devices/platform/ocp/4803.spi/spi_master/spi0/spi0.0/spidev/spidev0.0/power:
async runtime_active_kids  runtime_status
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
control   runtime_enabled  runtime_usage

/sys/devices/platform/ocp/4803.spi/spi_master/spi0/spi0.1/spidev:
spidev0.1

/sys/devices/platform/ocp/4803.spi/spi_master/spi0/spi0.1/spidev/spidev0.1:
dev  device  power  subsystem  uevent

/sys/devices/platform/ocp/4803.spi/spi_master/spi0/spi0.1/spidev/spidev0.1/power:
async runtime_active_kids  runtime_status
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
control   runtime_enabled  runtime_usage

/sys/devices/platform/ocp/481a.spi/spi_master/spi1/spi1.0/spidev:
spidev1.0

/sys/devices/platform/ocp/481a.spi/spi_master/spi1/spi1.0/spidev/spidev1.0:
dev  device  power  subsystem  uevent

/sys/devices/platform/ocp/481a.spi/spi_master/spi1/spi1.0/spidev/spidev1.0/power:
async runtime_active_kids  runtime_status
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
control   runtime_enabled  runtime_usage

/sys/devices/platform/ocp/481a.spi/spi_master/spi1/spi1.1/spidev:
spidev1.1

/sys/devices/platform/ocp/481a.spi/spi_master/spi1/spi1.1/spidev/spidev1.1:
dev  device  power  subsystem  uevent

/sys/devices/platform/ocp/481a.spi/spi_master/spi1/spi1.1/spidev/spidev1.1/power:
async runtime_active_kids  runtime_status
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
control   runtime_enabled  runtime_usage

/sys/module/spidev:
coresize  holders   initstate  parameters  sections  uevent
drivers   initsize  notes  refcnt  taint

/sys/module/spidev/drivers:
spi:spidev

/sys/module/spidev/holders:

/sys/module/spidev/notes:

/sys/module/spidev/parameters:  <
bufsiz  
<

/sys/module/spidev/sections:
__jump_table  __mcount_loc  __param  __verbose
debian@beaglebone:~$



-- 
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/v2pgag101omfhqgj1h5p4o03b3ilskegli%404ax.com.

[beagleboard] Re: ioctl messages to Beagle SPI port.

[Dennis Lee Bieber]

On Thu, 20 May 2021 19:19:08 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


>The sad thing is that Derek Molloy's book, only in passing refers to enabling 
>the SPI port, and the book, in trying to also deal with the pocket beagle pins 
>leaves out things where repetition is actually beneficial.  Maybe somewhere it 
>says that you have to use config-pin to set up SPI.  I missed it.  I think in 
>Chapter 8 page 363 needs a bit of work.

One: you have to look at the default pin-mux tables -- the default for
many is as GPIO.

Two: config-pin is discussed in chapter 6 (which also has a
hard-to-read version of the tables). It doesn't mention SPI explicitly, but
does mention that the tool is used in later chapters.

debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -i
p9_18
Pin name: P9_18
Function if no cape loaded: gpio
Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input spi i2c
pwm pru_uart
Function information: gpio0_4 default gpio0_4 gpio0_4 gpio0_4 gpio0_4
spi0_d1 i2c1_sda ehrpwm0_tripzone_input pru_uart
Kernel GPIO id: 4
PRU GPIO id: 36
debian@beaglebone:~$



>Oh and none of this explains why the ioctl regardless of C or Pascal can't 
>handle more than 4096 data bytes while the Python code can when sending a 
>large bitmap to the SPI port.  Nor why, according to this web site

debian@beaglebone:~$ cat /sys/module/spidev/parameters/bufsiz
4096
debian@beaglebone:~$

https://pypi.org/project/spidev/
"""
writebytes2(list of values)

Similar to writebytes but accepts arbitrary large lists. If list size
exceeds buffer size (which is read from
/sys/module/spidev/parameters/bufsiz), data will be split into smaller
chunks and sent in multiple operations.
"""

>https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/spi
>nothing is said about config-pin operations so the python library must do this 
>automatically?

A lot of that is a bit out-of-date -- references to kernel 3.8! Though
I do have to admit I can't find where in Adafruit_BBIO it might do that
set-up -- it doesn't seem to be done in the above spidev Python interface,
which is used by (now deprecated in favor of blinka/circuitpython)
Adafruit_BBIO... And I can't find a config change in blinka or
Adafruit_PureIO. {PureIO may not invoke the above spidev module, so how
/it/ handles large blocks is unknown}




-- 
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/peifag10s2ohjmb53f5naa8hcgmtmhc9go%404ax.com.

[beagleboard] Re: Reducing Boottime in Beaglebone Black

[Dennis Lee Bieber]

On Wed, 19 May 2021 09:37:32 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>Hi Amit,
>Interesting.  4.19.94 is a only a little bit faster than 4.14.108.  Is there a 
>document somewhere that explains what to do to even just speed up both start 
>up and shut down?
>What did you do to get it to 50 seconds?
> 
>John
> 
> 
>debian@ebb:~$ uname -a
>Linux ebb 4.14.108-ti-r136 #1stretch SMP PREEMPT Mon Jun 8 15:38:30 UTC 2020 
>armv7l GNU/Linux
> 
>debian@ebb:~$ systemd-analyze
>Startup finished in 40.059s (kernel) + 1min 27.889s (userspace) = 2min 7.948s
> 
>debian@ebb:~$ systemd-analyze blame
>1min 47.177s dev-mmcblk0p1.device
>1min 13.819s generic-board-startup.service
> 
>debian@beaglebone:~$ uname -a
>Linux beaglebone 4.19.94-ti-r63 #1buster SMP PREEMPT Fri May 14 16:42:32 UTC 
>2021 armv7l GNU/Linux
> 
>debian@beaglebone:~$ systemd-analyze
>Startup finished in 26.608s (kernel) + 1min 32.506s (userspace) = 1min 59.114s
>graphical.target reached after 1min 32.205s in userspace
> 
>debian@beaglebone:~$ systemd-analyze blame
>1min 20.997s generic-board-startup.service
> 1min 4.519s dev-mmcblk0p1.device
> 11.344s udisks2.service
> 

Just to add a data point: Buster IoT image on uSD card...

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux

debian@beaglebone:~$ systemd-analyze
Startup finished in 10.915s (kernel) + 1min 961ms (userspace) = 1min
11.877s
graphical.target reached after 1min 668ms in userspace

That's odd -- Did I leave the LXQT image in the board (I have uSD for
both IoT and LXQT)

debian@beaglebone:~$ systemd-analyze blame
 51.745s generic-board-startup.service
 40.798s dev-mmcblk0p1.device
  4.064s nginx.service
  3.587s systemd-udev-trigger.service

From DMESG one finds such ...

[1.668861] ALSA device list:
[1.668877]   #0: TI BeagleBone Black
[1.675450] Freeing unused kernel memory: 1024K
[1.676178] Run /init as init process
[2.664089] [drm] Cannot find any crtc or sizes
[   10.155042] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[   10.955497] systemd[1]: System time before build time, advancing clock.

EIGHT seconds mounting file system

[   13.203659] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[   14.816264] systemd-journald[893]: Received request to flush runtime
journal from PID 1
[   21.928916] net eth0: initializing cpsw version 1.12 (0)
[   22.000769] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL)

SEVEN seconds initializing eth0

[   27.071692] configfs-gadget gadget: high-speed config #1: c
[   27.072147] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   27.277845] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[   69.566416] remoteproc remoteproc0: wkup_m3 is available
[   69.658941] remoteproc remoteproc0: powering up wkup_m3
[   69.658973] remoteproc remoteproc0: Booting fw image
am335x-pm-firmware.elf, size 217168

FORTY seconds preparing the PRUs with remoteproc

Let me switch uSD card...

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux

debian@beaglebone:~$ systemd-analyze
Bootup is not yet finished
(org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs
debian@beaglebone:~$ systemctl list-jobs
JOB UNIT TYPE  STATE
 89 getty.target start waiting
 69 generic-board-startup.servicestart running
 97 serial-getty@ttyGS0.service  start waiting
  2 multi-user.targetstart waiting
  1 graphical.target start waiting
 81 systemd-update-utmp-runlevel.service start waiting
 98 dev-ttyGS0.devicestart running

7 jobs listed.

Hmmm, looks like I need to attach an HDMI cable and monitor to
determine which has the LXQT image...

debian@beaglebone:~$ systemctl list-jobs
No jobs running.

debian@beaglebone:~$ systemd-analyze
Startup finished in 11.355s (kernel) + 1min 24.913s (userspace) = 1min
36.268s
graphical.target reached after 1min 24.632s in userspace
debian@beaglebone:~$ systemd-analyze blame
1min 15.551s generic-board-startup.service
 1min 1.691s dev-mmcblk0p1.device
  9.380s udisks2.service

DMESG output snippets

[1.928371] Run /init as init process
[2.920215] [drm] Cannot find any crtc or sizes
[   10.473694] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[   11.394359] systemd[1]: System time before build time, advancing clock.

SEVEN and a half seconds mounting filesystem

[   14.116062] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[  

[beagleboard] Re: Unable to boot from SD card or mount a blank one

[Dennis Lee Bieber]

On Tue, 18 May 2021 16:28:18 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Shrikumar Sharma
 wrote:

>Thank you for your answers. However, the board never recognizes the SD 
>card...
>
Which could mean a faulty uSD card socket...


-- 
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/nes8agdf7f9kn5to2r9qlltslmqltpd4v3%404ax.com.

[beagleboard] Re: Weird C problem: PRU doesn't respond to host if two variables aren't initialized in loop

[Dennis Lee Bieber]

On Tue, 18 May 2021 11:22:20 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>Here's the code snippet with the two variables in bold.  If those lines of 
>code do not exist, the host doesn't hear from the PRU.

Such formatting does not get through the gmane list<>newsgroup
interface. I'm going to presume you mean the lines with * markers. Posting
with a client that keeps indentation would also help... hard to keep track
of what is nested into what when everything is left justified with excess
blank lines.

Normal recommendation is to condense the code down to the minimum that
still reproduces the problem, and to post the minimized files completely
(probably need both PRU and ARM programs). That allows others to attempt to
run/compare/debug.

>
> 
>
>count = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFOCOUNT(0));
>
> 
>
>for (i = 0; i < count; i++) 
>
>{
>
>Data = HWREG(SOC_ADC_TSC_0_REGS + TSC_ADC_SS_FIFODATA(0));
>
>StepRead = (Data >> 16) & 0xF;
>
>RawAnalog = Data & 0xFFF;
>
> 
>
>switch (StepRead)
>
>{
>
>case 0:
>
> 
>
>DetTSampleSet[pnr]=RawAnalog;
>
>break;
>
>case 1:
>
>  
>
>*start_of_pulse = 0;*
>
>*end_of_pulse = 0;*

Where were these declared?
>
> 
>
>DetBSampleSet[pnr]=RawAnalog;
>
>if ((pnr == end_of_pulse) && (in_pulse == E_YES)) // seen a pulse and at 
>end of it analyze signal

Where is pnr defined/initialized? Same for in_pulse. 
>
>{
>
>DetBSignalAverage= AnalyzeSignal(start_of_pulse, pnr);
>
>start_of_pulse = -1;
>
>end_of_pulse = -1;
>

If pnr is an index into some buffer, I'd probably use -1 to signal NO
DATA, and use the pnr values active at the time the pulse is detected for
start_of_pulse and the when the pulse ended for end_of_pulse

>samples_in_pulse = 0;
>
>in_pulse = E_NO;

In a way, all these seem redundant: start at -1 indicates no data,
no samples, and not in a pulse. Samples_in_pulse at 0 indicates no data, no
samples, and likely not in a pulse. in_pulse at E_NO implies no data, no
samples.

So, start are set to the appropriate pnr values... "in_pulse" is
indicated by start_of_pulse > -1 AND end_of_pulse = -1; "not in_pulse" is
indicated by (start_of_pulse > -1 AND end_of_pulse > -1) OR (start_of_pulse
= -1) //presumes you set both start/end to -1 at the same time

>
>if (start_of_pulse < 0) start_of_pulse = pnr;  // set start pointer in ring 
>buffer if it hasn't already been set for this pulse
>

Okay, you do set start/end to the instantaneous pnr value... Just
emphasizes that samples_in_pulse and in_pulse are logically redundant and
hence a potential source of error (samples_in_pulse should be end - start
(maybe with a +1; do the math with a sample buffer). Note: if this is a
circular buffer you'll need to account for wrap-around.


-- 
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/bmk8ag1h4l4qsl9enn0ri3spm326qtbpdj%404ax.com.

[beagleboard] Re: Setting Up Beaglebone Green Wireless

[Dennis Lee Bieber]

On Tue, 18 May 2021 03:22:59 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Nyasha Mabasa
 wrote:

"Information... We want... Information"

>
>Good day, I'm trying to setup my beagleboard and the drivers are failing to 
>install. please assist

Which drivers? What OS?



-- 
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/ula7agt7n530o5olbuudqbqhi0cd1l45b3%404ax.com.

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

On Mon, 17 May 2021 20:37:36 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


>A bit of a mystery in how it works other than it creates an OS fault to signal 
>issues.  My new function is more complicated:
>{
>The ExportPin procedure has been expanded to test to see if it is already 
>exported.  If it was already there then a new bit flag is set so that when
>the application calls to unexport pins, the ones that were there are left 
> alone.
>}
>procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
>var val : StdChar;
>begin
>  // First check to see if we already exported this pin inside this 
> application.
>  if (not IsPinBitSet(Pin, ExportedBitmask)) then begin

Suggest

if (not (IsPinBitSet(Pin, ExportedBitmask) 
or IsPinBitSet(Pin, ExportDefinedBitmask)) then begin

That way you don't waste time with the TryReadCharFromFile() if you already
know it was externally exported.
> 
>So where does the delay suggestion you made come in?  When we try and set the 
>direction of the pin!  Which is done in the user application.  
>// Switch LED pin for output.
>GPIO.PinMode[PinLED] := TPinMode.Output;
>
I'd put the delay immediately after

  // Wasn't exported when program started so now let's export it.
  if TryWriteTextToFile(FExportFileName, IntToStr(Pin)) then
begin
 SetPinBit(Pin, ExportedBitmask);
  *** put delay statement here  ***;
end;


>
>
>The only issue I've run into is the repeat until loop.  Seems like the file is 
>readable in about 100mS but fails with the write unless the delay is 500mS.
>

Which "file" (there are so many created under each exported pin)  

It may be that the OS default for those files permits reading -- but
the group hasn't been changed yet so only root can write. Sometime after
the creation, the logic that sets up special groups runs and changes the
file to a group that allows you to write.


-- 
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/40a7ag9gv2635mshemm4euqic4370aodfr%404ax.com.

[beagleboard] Re: Shared PRU Memory and beyond

[Dennis Lee Bieber]

On Mon, 17 May 2021 13:00:04 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester
 wrote:

>  Not sure I am replying properly to preserve the format desired for this 
>page, but your (Dennis B) response definitely deserves a response from me.

Difficult -- somehow your added comments are formatted as quoted text
(ie, my comments).

>
>On Monday, May 17, 2021 at 12:39:53 PM UTC-5 Dennis Bieber wrote:
>

>> 80 samples/msec... or 8 per second. If I converted properly, about 
>> 0.0125msec per sample. 
>>
>> I will be sampling from an ADC up to 1MHz maybe. 

The PRU itself only runs at 200MHz, and you have to account for how
many instructions are needed to run your ADC-start, read, store, notify
host logic.

>> Does the second addition contain the updates to the remote proc process?
>
It uses Remote Proc for the examples -- but does NOT have ADC examples.
It does warn that Remote Proc/rpmsg is fairly new (at the time of the book)
and that things might change. Unfortunately TI has changed its document
access, so the links in the 2nd edition book don't work. Most of the
documentation seems to be at
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_PRU-ICSS_PRU_ICSSG.html#remoteproc-and-rpmsg
(note: processor SDK -- TI's raw OS build system).

The examples are the simple Blink LED until Button Pressed; a PWM
generator, Ultrasonic distance sensor.

>> Thanks for the DSP lead...that is awesome as well.

On the BB AI -- and not much information has appeared on programming
them.



-- 
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/v2u5ag1dlpbh5fkli20unvb8d8a2b254o3%404ax.com.

[beagleboard] Re: Shared PRU Memory and beyond

[Dennis Lee Bieber]

On Mon, 17 May 2021 07:50:02 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bruce Chidester
 wrote:
>This leaves me with a total memory of 28K. Storing float's I can store 
>7,168 values. I would like to capture 20,000 values in about 250ms.

Capture from what? 

80 samples/msec... or 8 per second. If I converted properly, about
0.0125msec per sample.

>
>The Derek Malloy tutorial on PRU's (
>http://exploringbeaglebone.com/chapter15/) claims, "a pool of 2,000,000 
>bytes is allocated for the sample data". Things appear to have changed 
>since the writing of that tutorial. No more dynamic Device Tree through UIO 

The tutorial you reference is based upon the FIRST EDITION of the book
"Additional Content for First Edition" (when it was chapter 13).

>and PRU's accessed through Remote Proc. Not sure if the architecture 

Device trees are now loaded by u-Boot. If you really want UIO, there is
a device tree for that... By default, current images use the TI recommended
RPROC/msg system (partly because that is supposed to work with multiple
types of special processor cores -- the BB AI not only has PRU, but DSP
processors).

Extract from /boot/uEnv.txt:

###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###

You would have to uncomment the UIO line, and comment out the active
RPROC line (only one mode allowed at a time); then reboot.

>changed as well. This makes most of the printed material out of date 
>concerning PRU's and it's painful to figure out what is current and not. I 
>would love to have these 2,000,000 bytes available in the new architecture. 

Note that those bytes are allocated in the DDR RAM. There is no
hardware change.


>Needing help with the addressing, and some code samples would be excellent. 
>Hoping someone out there can help me get it.
>

Might https://github.com/pgmmpk/bbb_pru_adc be of use? Note that the
maximum speed for that code is 15KHz, or just 1/5th of your 80KHz desire.



-- 
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/4ia5agdtnlotv9rv9uqfmvfe0p8ld8diub%404ax.com.

[beagleboard] Re: Unable to boot from SD card or mount a blank one

[Dennis Lee Bieber]

On Sun, 16 May 2021 09:49:02 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>If it's like the Beaglebone Black, when you apply power,  you have to hold the 
>boot button down for quite a while.That's what tells the system to boot 
>from the sd card.
> 

That has only applied to very old BBB eMMC images... Sometime in the
late Wheezy or mid-Jessie era, u-Boot was modified to automatically search
for a uSD card image, and transfer control to the SD card if found.

I haven't had to touch the boot select switch in something like 3+
years.

Note: the BB AI does not have a boot select switch -- it expects the
eMMC u-Boot to do the switching if a proper card is found.


-- 
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/gnu2agtirijnefdifu8ogutmo8amqhj2u7%404ax.com.

[beagleboard] Re: unexpected "low speed" of PRU 1

[Dennis Lee Bieber]

On Thu, 13 May 2021 11:46:06 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"din...-re5jqeeqqe8avxtiumw...@public.gmane.org"
 wrote:

>Which assembler are you using? It should have warned you that "loop weiter" 
>body must be at least two instructions, whereas you have zero. 
>

Sliding into the thread...

From the manual:
"""
Hardware Loop Assist (LOOP) Defines a hardware-assisted loop operation. The
loop is noninterruptible (LOOP). The loop operation works by detecting when
the instruction pointer would normal hit the instruction at the designated
target label, and instead decrementing a loop counter and jumping back to
the instruction immediately following the loop instruction.
"""

So, yes... the loop encounters the target label... and jumps back to...
the target label as there is no intervening opcode to use as a target for
the jump. Might be optimized out completely unless one puts at least a NOP
instruction inside -- though the next comment probably voids all
consideration.

Not sure of the "at least two instructions" -- seems one, with label on
the next (outside of loop) instruction, would be viable. PC would hit
label, so jump back to the (one) instruction following LOOP statement.


>Also, you cannot nest HW-assisted loops.
>

A critical item to consider...


-- 
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/ef0r9g9oltoh89vm9n4t9c4ku03oibd8d9%404ax.com.

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

On Thu, 13 May 2021 10:05:24 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>I've been playing with that yesterday.  
>I think the library needs to be changed in a couple of places.  As you pointed 
>out, it doesn't really know if the GPIO pin was already exported until it 
>tries to do it and then flags that it's exported in the flags variable.
>
On further scanning of the source -- it will all come down to the
library. I think the Export method is declared as private, so your
application couldn't call it directly without modifying the library spec.
And if one is modifying the library, might as well fix it all within the
library instead of still requiring applications to change also.

>The problem is if the export fails it then not only checks an invalid flag 
>setting and does the unexport but that ends up removing an exported pin that 
>was already there when the program stops.  I don't like that behaviour.  I 
>thought I saw that it only changes it to input from output but yet it's gone 
>when the program finishes so that will take some more investigation.
>
The change from in to out might be linked to the re-export if the
kernel tears down the pin configuration and rebuilds it (or -- it might
have been built into some overhead library operation, forgive me for not
doing a scan of the sources again).

>What I found yesterday is by adding the delay you suggested down in the 
>library after the TryWriteTextToFile() that I now get run from command line 
>performance.  Most of yesterday was a bit of a write-off dealing with a 
>missing SIM card for my wife's new iPhone 12 and some running around to get 
>other problems solved.
>
>From puTTY I reliably get this now.
>debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ 
>./Blinky
>Blinking LED, press any key to exit...
>debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$
>
Progress... 

>Today I want to change that low level code to:
>1. Not set the exported flag if the pin is already there so it won't be 
>unexported at the end but only set to what it was before the program ran.   
>This means we also won't try to export it at the start.

That might add a bit more overhead than you want -- if you are talking
about adding a test to see if the .../gpioXX directory (or a file within
the directory) exists and is accessible. After all, it appears that every
access of a pin includes the test for is-pin-exported. You might want to
add a parallel bitmap similar to the one currently used in which you record
pins that were found to be externally exported.

That would make the is-pin-exported something like

 OR 

That way you only invoke the export function if the pin is in neither
bitmap. Export function could then be something like

if <.../gpioXX directory exists> then
update new bitmap
else
write the export command
sleep
update old bitmap




-- 
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/f8sq9g1722mq93tv2vcdfe0lq9c9683hbv%404ax.com.

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

o/~ Talking to myself in public... o/~

On Wed, 12 May 2021 17:22:04 -0400, in gmane.comp.hardware.beagleboard.user
Dennis Lee Bieber 
wrote:

I'd strongly recommend editing this and doing whatever needs to be done
to rebuild the PXL library (if it doesn't just compile from sources
everytime) OR...

>procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
>begin
>  TryWriteTextToFile(FExportFileName, IntToStr(Pin));

Sleep(1000);<<<<<

>  SetPinBit(Pin, ExportedBitmask);
>end;   

... modifying the source program (for test: Blinky) to explicitly export
pins and delay before trying to do anything with them...

"""
begin
  GPIO := TSysfsGPIO.Create;

  GPIO.ExportPin(PinLED);   <<<<<<<<
  Sleep(1000);  <<<<<<<<

  try
// Switch LED pin for output.
GPIO.PinMode[PinLED] := TPinMode.Output;

WriteLn('Blinking LED, press any key to exit...');
"""

Modifying the library (and fine-tuning the sleep duration to the
minimum that is reliable) should ensure that any implicit pin export works
safely. Modifying the application source, OTOH, means if one exports ALL
NEEDED pins at the start, only one sleep would suffice for the batch,
rather than getting a sleep on each implicit export.

*** WORRY ABOUT SPI AFTER THE GPIO PROBLEM IS SOLVED***



-- 
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/nriq9ghfakl67f0tdb9mm6qdqriiiundg6%404ax.com.

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

On Wed, 12 May 2021 10:54:12 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:


>Now let's look at groups.
>debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ls -l 
>Blinky
>-rwxr-xr-x 1 debian debian 270880 May 11 15:08 Blinky
>
>Hmmm.  Not part of the gpio group
>
It shouldn't be... That line says the file "Blinky" is owned by user
"debian" and is part of the group "debian"... And group/other have
read/execute permission on the file.

You /run/ the file from your account, and your account is a member of
"gpio" group.

>debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ 
>./Blinky
>An unhandled exception occurred at $000282E0:
> ESysfsFileOpenWrite: Cannot open 
> file  for writing.
>  $000282E0  WRITETEXTTOFILE,  line 68 of 
> /home/debian/lazarus/pxl/Source/PXL.Sysfs.Types.pas
> $00021CB4  TSYSFSGPIO__SETPINMODE,  line 200 of 
> /home/debian/lazarus/pxl/Source/PXL.Sysfs.GPIO.pas
>
>So let’s add it to the gpio group:  
>   
>   
> debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ chgrp 
> gpio Blinky

Which only means users with group "gpio" membership now have access to
the file. It does nothing for what permissions the file itself is running
under -- those are defined by the user group membership.

Unfortunately, the PXL source doesn't return the actual error code
which fpGetErrno would report; it raises that exception for any error code
(the help systems says "negative value if there was an error" whereas
fpwrite explicitly says -1 for an error; in either case, having fpgeterrno
value could help pin down what the real problem is).

  Handle := fpopen(FileName, O_WRONLY);
  if Handle < 0 then
raise ESysfsFileOpenWrite.Create(Format(SCannotOpenFileForWriting,
[FileName]));

I see that setpinmode does do an export of the pin if it is not already
exported... As my tests with Ada program show, I needed a delay (used one
second I believe) after doing an export or I'd get a similar problem with
opening the pin's files. However -- "not already exported" is PXL's
concept, not reality. PXL maintains a bit-map of "exported" pins, meaning
pins IT has done an export for...

function TSysfsGPIO.IsPinExported(const Pin: TPinIdentifier): Boolean;
begin
  Result := IsPinBitSet(Pin, ExportedBitmask);
end;

This means the every time you run the program, it starts with the
assumption that the pin is NOT exported, and issues an export operation. I
suspect -- based on my timing issues -- that 

procedure TSysfsGPIO.ExportPin(const Pin: TPinIdentifier);
begin
  TryWriteTextToFile(FExportFileName, IntToStr(Pin));
  SetPinBit(Pin, ExportedBitmask);
end;   

needs to have some sleep/delay placed in it before it returns... say

Sleep(1000);

for a 1 second delay (if that runs you could try fine-tuning downwards
until it fails, then add a safety margin to the last working value).
>After every compile I could run the application from the command line with a 
>sudo but that's not the solution I need.  Nor to each time change the 
>permissions at the command line level.  If we can figure out what the 
>attributes of the program are supposed to be so it runs without the sudo then 
>I can potentially change something with the Lazarus IDE or Free Pascal 
>Compiler to properly configure the executable.  But at the moment I can't get 
>the executable to run.

The program attributes should only be a need to have eXecute permission
on thre file. Everything else should be defined by the /user account/
membership and the permissions of the target files.

I don't know why "sudo" doesn't have the problem, unless, again, it is
a timing matter -- and immediately after the export the direction file
starts with root:root and needs time to be changed to root:gpio. If so,
then sudo would be owner of root and not tied to the group access... and if
so, adding a delay immediately after the export write in PXL may suffice.
After all, the program, as I understand the calling sequences and tests, IS
WRITING TO /sys/class/gpio/export without a problem.


>debian@ebb:/sys/class/gpio/gpio48$ ls /dev/spi*
>/dev/spidev1.0  /dev/spidev1.1  /dev/spidev2.0  /dev/spidev2.1
>
>/dev/spi:
>0.0  0.1  1.0  1.1
>

Try ls -l   This appears to be another change as mine map 
1:1
(another reason to create an current Debian 10/buster uSD card). I wouldn't
be surprised if Stretch maps 0.0 to spidev2.0, while 1.0 goes to spidev1.0.

debian@beaglebone:~$ ls -l /dev/spi*
crw-rw 1 root spi  153, 0 May 12 12:46 /dev/spidev0.0
crw-rw 1 root spi  153, 1 May 12 12:46 /dev/spidev0.1
crw-rw 1 root spi  153, 2 May 12 15:58 /dev/spidev1.0
crw-rw 1 root spi  153, 3 May 12 15:58 /dev/spidev1.1

/dev/spi:
total 0

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

On Tue, 11 May 2021 18:51:22 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>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.
>

pi@rpi3bplus-1:~/PI_GPIO$ uname -a
Linux rpi3bplus-1 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
GNU/Linux
pi@rpi3bplus-1:~/PI_GPIO$

If I interpret that, the current R-Pi is up to kernel 5.10 vs 4.18 for
BBB

debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux
debian@beaglebone:~$


Well, there are some weird things on the R-Pi... My Ada program is able
to export a GPIO (they aren't exported by default, unlike the BBB). But it
fails when opening the direction file to change from "in" to "out". I even
tried changing from "out_file" to "append_file".

Turns out to be a timing issue -- the OS hasn't finished creating the
pin files by the time it tried to write the direction. {This is
Raspberry-Pi -- I didn't have that problem on BBB, but wasn't exporting in
code either}. Putting in a 1 second delay after closing the export file let
the program run. I also had to add an exception handler on the export
operation in case the pin had already been exported (along with adding an
Unexport function called at the end). Other than using GPIO 18, and using
export (with delay), unexport -- this is the same program that ran on the
BBB. In fact, I just built and ran it on the BBB (Using GPIO 18). (Changed
to GPIO 48 -- and first run had the same timing error -- since it took the
exception branch; subsequent runs no problem).

pi@rpi3bplus-1:~/PI_GPIO$ 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
pi@rpi3bplus-1:~/PI_GPIO$ ./main
Opening /sys/class/gpio/export
Writing pin number: 18
Closing /sys/class/gpio/export
Delaying to allow pin control files to be set up

Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value

Current value of 18 is  1

Opening /sys/class/gpio/gpio18/direction
Writing direction: out
Closing /sys/class/gpio/gpio18/direction


Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value

Current value of 18 is  0

Opening /sys/class/gpio/gpio18/value
Writing value:  0
Closing /sys/class/gpio/gpio18/value

Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value

Current value of 18 is  0

Opening /sys/class/gpio/gpio18/value
Writing value:  1
Closing /sys/class/gpio/gpio18/value

Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value

Current value of 18 is  1

Opening /sys/class/gpio/gpio18/direction
Writing direction: in
Closing /sys/class/gpio/gpio18/direction

Opening /sys/class/gpio/unexport
Writing pin number: 18
Closing /sys/class/gpio/unexport


>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.  
>

As I mentioned, uSD cards are getting cheap... Write a current OS image
and try it on a fresh 8+GB card (don't forget to resize the partition after
first boot). If it works, great. If it doesn't you still have your original
image to mess with. I'd suggest
https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_LXQt
at a minimum, or
https://rcn-ee.net/rootfs/bb.org/testing/2021-04-19/buster-lxqt/ (to save
time bringing the image up-to-date -- note that the latter is Buster 10-9
while the shipping image https://beagleboard.org/latest-images is 10-3 and
a year out-of-date).

>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?

It doesn't... It changes the OWNER of /sys/devices/gpio to BE the user
"nick" (note -- it isn't changing the files under that directory!), while
also putting them into a group called "digital". As owner, "nick" then has
full privileges to the file, and any user in the "digital" group has group
privileges.

The second, again, would change the OWNER to "debian" but put the file
into a group called "root". And, again, it doesn't change what is below
that directory. That's one reason for all those nasty udev rules -- the
sysfs is created at boot time, and the pin files are created 

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

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

[Dennis Lee Bieber]

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 

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

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 

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

On Mon, 10 May 2021 13:33:01 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

>To deal with CAN bus on the Pi3/Pi4 requires access to the SPI bus for the 
>MCP2515.  On the Beagle it's the on chip CAN device.  And if I want to talk to 
>sensors like I2C or One-Wire plus inexpensive LCD displays I need access to 
>the hardware.  
>
>So I installed the PXL library and that's where I ran into the next roadblock. 
> First you can't, from within the IDE and debugging, work with SPI bus without 
>running Lazarus as root.  Or it just won't work with the /sys/class/gpio 
>folders.  And that's the reason for wanting to free up access to the gpio.
>
>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

>It's possible to use:
>$ sudo echo 48 > /sys/class/gpio/export 

Really?

debian@beaglebone:~$ sudo echo 48 > /sys/class/gpio/export
[sudo] password for debian:
echo: write error: Operation not permitted

To my knowledge, the redirection part is still done as the debian user,
only the echo is being done by sudo.

debian@beaglebone:~$ sudo su
root@beaglebone:/home/debian# echo 48 > /sys/class/gpio/export

>to create the gpio48 folder and as super user the VXP library can do that but 
>then it fails on the write to SPI.
>

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.


debian@beaglebone:~$ ls -l /sys/bus/spi/devices
total 0
lrwxrwxrwx 1 root root 0 Dec 31  1999 spi0.0 ->
../../../devices/platform/ocp/4803.spi/spi_master/spi0/spi0.0
lrwxrwxrwx 1 root root 0 Dec 31  1999 spi0.1 ->
../../../devices/platform/ocp/4803.spi/spi_master/spi0/spi0.1
lrwxrwxrwx 1 root root 0 Dec 31  1999 spi1.0 ->
../../../devices/platform/ocp/481a.spi/spi_master/spi1/spi1.0
lrwxrwxrwx 1 root root 0 Dec 31  1999 spi1.1 ->
../../../devices/platform/ocp/481a.spi/spi_master/spi1/spi1.1
debian@beaglebone:~$

debian@beaglebone:~$ ls -l /sys/devices/platform/ocp/4803.spi/
total 0
lrwxrwxrwx 1 root gpio0 May 10 15:42 driver ->
../../../../bus/platform/drivers/omap2_mcspi
-rw-rw-r-- 1 root gpio 4096 May 10 15:42 driver_override
-r--r--r-- 1 root gpio 4096 May 10 15:42 modalias
lrwxrwxrwx 1 root gpio0 May 10 15:42 of_node ->
../../../../firmware/devicetree/base/ocp/spi@4803
drwxrwxr-x 2 root gpio0 May 10 15:42 power
drwxrwxr-x 3 root gpio0 May 10 15:42 spi_master
lrwxrwxrwx 1 root gpio0 May 10 15:42 subsystem ->
../../../../bus/platform
-rw-rw-r-- 1 root gpio 4096 May 10 15:42 uevent
debian@beaglebone:~$

debian@beaglebone:~$ ls -l
/sys/devices/platform/ocp/4803.spi/spi_master/spi0
total 0
lrwxrwxrwx 1 root gpio0 May 10 15:42 device -> ../../../4803.spi
lrwxrwxrwx 1 root gpio0 May 10 15:42 of_node ->
../../../../../../firmware/devicetree/base/ocp/spi@4803
drwxrwxr-x 2 root gpio0 May 10 15:42 power
drwxrwxr-x 5 root gpio0 May 10 15:42 spi0.0
drwxrwxr-x 5 root gpio0 May 10 15:42 spi0.1
drwxrwxr-x 2 root gpio0 May 10 15:42 statistics
lrwxrwxrwx 1 root gpio0 May 10 15:42 subsystem ->
../../../../../../class/spi_master
-rw-rw-r-- 1 root gpio 4096 May 10 15:42 uevent
debian@beaglebone:~$



NOTE: there are two config-pin in Buster, maybe even Stretch. The one
you get if you just enter "config-pin" is a compiled executable with some
limitations (if there is no pinmux file found it objects). I'm using the
older PERL script version which has a few more capabilities.

debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -i
p9_15
Pin name: P9_15
Function if no cape loaded: gpio
Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input pwm
Function information: gpio1_16 default gpio1_16 gpio1_16 gpio1_16 gpio1_16
ehrpwm1_tripzone_input
Kernel GPIO id: 48
PRU GPIO id: 80
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -i
p9_17
Pin name: P9_17
Function if no cape loaded: gpio
Function if cape loaded: default gpio gpio_pu gpio_pd gpio_input spi_cs i2c
pwm pru_uart
Function information: gpio0_5 default gpio0_5 gpio0_5 gpio0_5 gpio0_5
spi0_cs0 i2c1_scl ehrpwm0_synci pru_uart
Kernel GPIO id: 5
PRU GPIO id: 37
debian@beaglebone:~$
/opt/source/bb.org-overlays/tools/beaglebone-universal-io/config-pin -q
p9_15
P9_15 Mode: default Direction: in Value: 1
debian@beaglebone:~$

[beagleboard] Re: Using GPIOs without Using sudo

[Dennis Lee Bieber]

On Mon, 10 May 2021 10:09:14 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer"  wrote:

Suspect I'm not really going to be of much help -- but a few
comments...

>I'm still not sure of the actual process with this revision of the OS.
>debian@ebb:~/lazarus$ uname -a
>Linux ebb 4.14.108-ti-r136 #1stretch SMP PREEMPT Mon Jun 8 15:38:30 UTC 2020 
>armv7l GNU/Linux
>
Stretch is getting a bit long in the tooth -- is there some reason you
need to stay on it (Debian organization is in the midst of finalizing the
replacement for Buster!).

You also appear to have changed your Beagle's host name to match that
Malloy used for his -- the initials of "e/xploring b/eagleb/one". Just an
observation.

> 
>And then create the shell script as outlined but with user debian in group 
>gpio?  
>Eg: 
>chown -R nick:digital /sys/devices/gpio
> 
>becomes 
>chown -R debian:gpio /sys/devices/gpio
>
I'm somewhat surprised at that. My understanding is that adding the
"debian" user to the GROUP gpio should allow that user to access anything
that is part of the gpio group, using the group permissions rather than
owner permissions -- so should not need to be changed to debian as owner.

Unfortunately, I can't state anything specific. Buster doesn't seem to
have the same layout.
 
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux
debian@beaglebone:~$ ls /sys/devices
armv7_cortex_a8  kprobesoc0  system  uprobe
breakpoint   platform  software  tracepoint  virtual
debian@beaglebone:~$

NOTE: NO /sys/devices/gpio!

debian@beaglebone:~$ ls -l /dev/gpiochip*
crw-rw 1 root gpio 254, 0 Apr 30 20:46 /dev/gpiochip0
crw-rw 1 root gpio 254, 1 Apr 30 20:46 /dev/gpiochip1
crw-rw 1 root gpio 254, 2 May 10 14:51 /dev/gpiochip2
crw-rw 1 root gpio 254, 3 May 10 14:51 /dev/gpiochip3
debian@beaglebone:~$


If I interpret the permissions, owner (root) and group (gpio) both have
R/W, so if debian is added to the group...

debian@beaglebone:~$ ls -l /sys/class/gpio
total 0
--w--w 1 root gpio 4096 Apr 30 20:46 export
lrwxrwxrwx 1 root gpio0 Apr 30 20:46 gpio10 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio10
lrwxrwxrwx 1 root gpio0 Apr 30 20:46 gpio11 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio11

... and those (links) are open to everyone, although...
 
debian@beaglebone:~$ ls -l
/sys/devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio10
total 0
-rwxrwx--- 1 root gpio 4096 Apr 30 20:46 active_low
lrwxrwxrwx 1 root gpio0 Apr 30 20:46 device -> ../../../gpiochip0
-rwxrwx--- 1 root gpio 4096 Apr 30 20:46 direction
-rwxrwx--- 1 root gpio 4096 Apr 30 20:46 edge
-rwxrwx--- 1 root gpio 4096 Apr 30 20:46 label
drwxrwx--- 2 root gpio0 Apr 30 20:46 power
lrwxrwxrwx 1 root gpio0 Apr 30 20:46 subsystem ->
../../../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Apr 30 20:46 uevent
-rwxrwx--- 1 root gpio 4096 Apr 30 20:46 value
debian@beaglebone:~$

... what they link to is back to root:gpio without everyone.


-- 
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/ca0j9g14h5jubcksh801t2sptka3l62cnd%404ax.com.

[beagleboard] Re: wiegand protocal

[Dennis Lee Bieber]

On Sat, 1 May 2021 10:05:21 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Rukku Raghu
 wrote:

>hai all
>  any one share me wiegand and  beagle bone black with 
>gpio pins source code
>

Most hits are for Raspberry-Pi, so any solution would need to be ported
to the Beagle GPIO libraries. Easiest would be to start with Python and
Adafruit_BBIO. The protocol appears to rely upon both data lines be high as
a NULL state, if either data line goes low you have a 0 or 1 (depending
upon which data line) and both data lines low is an error condition.
However,
https://stackoverflow.com/questions/35148766/python-raspberry-pi-gpio-and-wiegand-issues
implies Python may not be fast enough.

https://gist.github.com/hsiboy/9598741 is an R-Pi C-language source --
again you'd have to update the GPIO calls to some equivalent library on the
Beagle.

Javascript (which may imply node.js usage)
https://github.com/samt/node-wiegand

You may also find sample libraries for Arduino boards, which shouldn't
be too difficult to port over to Beagle GPIO.


-- 
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/o0lu8gd7uab1shna5e60amigoup578ks4b%404ax.com.

[beagleboard] Re: TI PRU_ADC_onChip example

[Dennis Lee Bieber]

On Fri, 30 Apr 2021 13:09:02 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Cheng Chen
 wrote:


>My BBB wireless can compile pru code successfully because I installed 
>PRU_CGT compiler. But it is unable to compile ARM code. I think that is 
>because ARM_CCT cross-compiler toochain environment is missing, in another 
>word, I need to install processor-sdk-am335x
>
The key is probably in the phrase "cross-compiler"... If you are
compiling ON the Beagle, you are using the "native" compiler, not a
cross-compiler ("cross" implies a toolchain that runs on a different
OS/architecture but which builds binary files meant for the target of the
toolchain -- but you are ON ARM, building FOR ARM).

>My first questions is can I install processor-sdk-am335x  into Debian 
>system I currently have (Linux beaglebone 4.19.94-ti-r62 ) ? I am a little 
>confused about the relationship between this SDK and Debian system. Why is 
>the tutorial asking me to compile  pru_adc_userspace.c  in the Beaglebone. 
>I thought it is supposed to be executed in a cross-compilation environment.
>

Cross compilation is used mostly for a couple of reasons: either the
target system does not support a native compiler (you aren't going to run a
compiler on something like a Tiva C board, or an Arduino Due [both of which
run ARM M-series processors] -- though the native compiler on a
Beagle/Debian might be able to build files that can be downloaded to such
boards); the target board is not yet built -- in which case one is likely
going to be "running" the code using something like QEMU or other software
emulation of the hardware system; the target board has a compiler, but the
speed of the cross-compiler environment is much faster (consider a
hyper-threaded 64-bit processor -- which is seen as 8-cores by the OS, each
running at 2.5-3.5GHz, with 12GB of RAM, vs a single 32-bit core running at
1GB with less than 1GB of RAM).

>I ended up installing processor-sdk-am335x on my linux desktop and compiled 
>successfully. Then I copied the generated file back to BBB wireless. But 
>when I tried to run the program, it shows the following error. 
>
>Reading voltage at ADC Channel: 5
>/dev/rpmsg_pru30 could not be opened.
>Trying to initialize PRU using sysfs interface.
>ERROR: Could not open /dev/rpmsg_pru30
>

This is a different matter, and likely means the device tree
configuration is not set correctly -- over the last few years there have
been two INCOMPATIBLE means of accessing the PRU. RemoteProc/RPMsg is the
newer system, pru_uio is older -- current images for the Beagle load
RemoteProc -- check /boot/uEnv.txt to see what version your system is
loading...

###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###

... however, I don't seem to have any /dev/rpmsg* entries either.

I'm sure this have been brought up in this forum a few times in the
last year or so, but I don't recall the solution (if any). I did find that
the default firmware was not "running"...  But starting it didn't add the
/dev/rpmsg*

debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/*
cat: /sys/class/remoteproc/remoteproc1/device: Is a directory
am335x-pru0-fw
4a334000.pru
cat: /sys/class/remoteproc/remoteproc1/power: Is a directory
offline <*
cat: /sys/class/remoteproc/remoteproc1/subsystem: Is a directory
DEVTYPE=remoteproc
debian@beaglebone:~$ echo 'start' > /sys/class/remoteproc/remoteproc1/state
debian@beaglebone:~$ cat /sys/class/remoteproc/remoteproc1/*
cat: /sys/class/remoteproc/remoteproc1/device: Is a directory
am335x-pru0-fw
4a334000.pru
cat: /sys/class/remoteproc/remoteproc1/power: Is a directory
running <*
cat: /sys/class/remoteproc/remoteproc1/subsystem: Is a directory
DEVTYPE=remoteproc



-- 
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/7t3p8gpavcmimaf0mo826i5ak6sr8l6qg6%404ax.com.

[beagleboard] Re: Beaglebone Black [BBB] Read Shared memory from PRU

[Dennis Lee Bieber]

On Fri, 30 Apr 2021 08:22:10 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>I checked with ls -ls /dev/mem logged in as debian and it's there.
>
debian@beaglebone:~$ ls -ls /dev/mem
0 crw-r- 1 root kmem 1, 1 Apr 30 12:06 /dev/mem
debian@beaglebone:~$
debian@beaglebone:~$ groups
debian adm kmem dialout cdrom floppy audio dip video plugdev users
systemd-journal input bluetooth netdev i2c remoteproc eqep pwm cloud9ide
xenomai weston-launch tisdk docker iio spi admin gpio
debian@beaglebone:~$


That is what my BBB shows.

Owner (root) has R/W permission
Group (kmem) has Read-Only permission.

The debian account has kmem group access.

From your earlier post...

>fd = open ("/dev/mem", O_RDWR | O_SYNC);

... you are asking for R/W access -- which is not set for members of the
kmem group. What happens if you attempt to open /dev/mem for read-only
access?


-- 
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/33bo8g5lcseq60uiq86ubie7pspjaioidm%404ax.com.

[beagleboard] Re: Beaglebone AI eMMC flasher

[Dennis Lee Bieber]

On Mon, 26 Apr 2021 10:18:00 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Pedro Cruz
 wrote:

>Hi,
>
>I am trying to flash BB_AI with eMMC flasher 
>with am57xx-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img but it 
>aborts flashing.
>
I never use the pre-built flasher images. My normal procedure is to use
the "runable" image on the SD card, boot with it, perform any updates (10.3
is positively ancient*), and only after confirming the card is
working/configured do I go in and modify the last line of /boot/uEnv.txt --
which turns the card into a flasher; reboot to flash that image.

>It comes with the following error:
>
>Error: [/dev/mmcblk1] does not exist
>

Where does it "come" -- a proper flasher image takes control at the end
of u-Boot loading uEnv.txt, before any SSH type console is normally
available. That message seems to imply a problem with the SD card -- either
the socket is bad, the card is bad, or possibly it is not formatted for
Linux.

How did you put the image on the card? Balena Etcher has been the
recommended tool for creating working cards from img files, for a few years
now. If you just copied the img file onto a card, it will never work.


* the most recent testing build is
https://rcn-ee.net/rootfs/bb.org/testing/2021-04-19/buster-iot/am57xx-debian-10.9-iot-armhf-2021-04-19-4gb.img.xz
which is SIX minor versions of Debian newer. I'd suggest burning that to
the SD card, then booting it to ensure it works (runs). Only after that go
into the /boot/uEnv.txt and uncomment the last line. Reboot. It should
flash the eMMC Remove the SD card and reboot -- confirm the eMMC is up to
the current Debian. Note that this SD card is now a flasher image, and if
you boot with it installed, it will just reflash the eMMC.


-- 
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/9rbg8g9tr8jeui2b2j1jmagv1uv5pc228c%404ax.com.

[beagleboard] Re: rtcwake support on BeagleBone Blue

[Dennis Lee Bieber]

On Sat, 17 Apr 2021 14:14:03 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Mykolas Juraitis
 wrote:

>Hello,
>
>I am experimenting with rtcwake on BeagleBone Blue. Running command:
>

Note that there is no REAL RTC on most BeagleBone variants (I don't
know if the Blue has an add-on RTC). cf:
https://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/overview


>I tried to check time before and after standby by running:
>
>sudo hwclock && date && sudo rtcwake -d /dev/rtc0 -m standby -s 20 && date 
>&& sudo hwclock
>2021-04-17 21:42:40.123908+00:00
>Sat 17 Apr 2021 09:42:40 PM UTC
>rtcwake: wakeup from "standby" using /dev/rtc0 at Sat Apr 17 21:43:02 2021
>Sat 17 Apr 2021 09:43:06 PM UTC
>2021-04-17 21:43:07.802256+00:00
>
>Last 2 time lines are printed after manual wake up by pressing power 
>button. They seem to be showing that only twenty some seconds passed but 
>actually much more time passed until I pressed power button. Which is weird 
>because if RTC doesn't work then I would expect time to be reset. If it 
>does work it should be correct time.
>

Beaglebones periodically save the system clock value, and use that to
reload the system clock on startup. The value you are seeing is likely that
of the last time this fake hwclock was written... cf:
https://manpages.debian.org/jessie/fake-hwclock/fake-hwclock.8.en.html

Also...
https://unix.stackexchange.com/questions/187261/automatically-update-hwclock-at-boot
https://groups.google.com/g/beagleboard/c/n1noGnM30sQ



-- 
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/a3mo7gls3hp901pi4r91rfvkkq7q7g2nti%404ax.com.

[beagleboard] Re: Autorun Python Script can't write files

[Dennis Lee Bieber]

On Fri, 16 Apr 2021 09:01:33 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"stl...-re5jqeeqqe8avxtiumw...@public.gmane.org"
 wrote:

>I want my autorun python script to write information into a text file. 
> This works fine when the python file is run from the Cloud9 interface, but 
>does not run properly when the beagleboard restarted.  
>
>The command that is failing is:
>
>with open("/home/debian/logs/testlog.txt",'a',encoding = 'utf-8') as f:
>   f.write("bbb autorun test\n")
>
>I am running Buster IoT Image 2020-04-06 on a beagle board black.
>
>I have tried using chmod 666, chmod 755 etc, on the target file and 
>enclosing directory with no success.
>
>I see a number of older threads about using chron, but these don't seem 
>applicable in light of having autorun.
>
>Any idea what is preventing this script from writing to a file when it is 
>autorun?  Is this a permissions issue and how would I change that?

I have no idea what systemd does when starting Cloud9 and processing
its "autorun" directory...

Personally, I would move your file /out of/ Cloud9 into some location
in your home directory...

{in Cloud9}
debian@beaglebone:/var/lib/cloud9$ mv autorun/autotest.py ~

... and then add it to that user's crontab...

{rest is all via SSH using PuTTY}
debian@beaglebone:~$ crontab -e
no crontab for debian - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /usr/bin/vim.nox
  2. /bin/nano< easiest
  3. /usr/bin/vim.basic
  4. /usr/bin/vim.tiny
  5. /bin/nano-tiny

Choose 1-5 [2]: 3
crontab: installing new crontab

{the vim session is not shown} 

Locating the actual crontab file...

debian@beaglebone:~$ sudo cat /var/spool/cron/crontabs/debian
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.Wesos5/crontab installed on Fri Apr 16 15:00:39 2021)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
# Edit this file to introduce tasks to be run by cron.
#
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
#
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').
#
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
#
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
#
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
#
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
@reboot sleep 30 && /home/debian/autotest.py
>/home/debian/logs/unexpected.log  2>&1

debian@beaglebone:~$
Note: the crontab operation wrapped, the redirection is part of the
@reboot line.

I found I had to put in the 30 second delay to allow the system time to
set up the GPIOs, without the job failed on 

GPIO.setup(relay3, GPIO.OUT)

with a missing file or permission error.

I ended on 30 seconds as that is where dmesg had a major break...

[   25.949286] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[   26.184613] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready
[   66.991145] remoteproc remoteproc0: wkup_m3 is available
[   67.376203] remoteproc remoteproc0: powering up wkup_m3



-- 
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/k4mj7g99ck3j9l01upctmbtuj500b3afoh%404ax.com.

[beagleboard] Re: What is the difference between flasher and microSD images?

[Dennis Lee Bieber]

On Wed, 14 Apr 2021 21:23:16 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user eb
 wrote:


>I'm having trouble finding information on the difference between the 
>flasher and microSD images. Why can an image made for microSD not be 
>flashed to eMMC?
>
The difference is one line at the bottom of /boot/uEnv.txt

If you uncomment the line, the card becomes a flasher image (and if you
don't remove it after the flashing, rebooting will repeat flashing...).


-- 
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/t3jj7g5rbjiko507uopddstrfchl8sitvr%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Thu, 15 Apr 2021 09:35:20 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>So if I had an application that had a sensor A that needs to be read every 
>10ms and sensor B that only needs to be read every minute, I could wire 
>channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
>B and assign it to step 2. 
>
>Then at startup, when I want to read both sensors, I enable steps 1 and 2 
>but not 3-16.  This saves time on the read as channels 3-7 aren't needed 
>and steps 3-16 aren't needed so I don't use them.  Then after the initial 
>read when I don't need to read sensor B until a minute passes, I can change 
>STEPENABLE so only step 1 is enabled and execute a read every 10 ms.  Only 
>sensor A would be read.  Then at one minute intervals, I change STEPENABLE 
>so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
>read. 
>

Seems like a lot of fiddling around with step enables, and assumes ADC
reading is a one-shot operation. I'd likely just create a process loop with
major frame of 1 minute, minor frame of 10ms (use a "frame counter" that
you increment after every read), and read both sources each time -- but
only report the one-minute source at top of major frame; counter at 6
if my calculations are right).

The ADC configurations supports continuous mode in which, after all
enabled steps are processed, it loops back to the top and restarts the step
sequence. Note:

"
12.3.4 One-Shot (Single) or Continuous Mode

When the sequencer finishes cycling through all the enabled steps, the
user can decide if the sequencer should stop (one-shot), or loop back and
schedule the step again (continuous).

If one-shot mode is selected, the sequencer will take care of disabling
the step enable bit after the conversion. If continuous mode is selected,
it is the software’s responsibility to turn off the step enable bit.
"
... if doing one-shot, you don't have to turn off the second step enable...
You have to, instead, turn ON the steps you want active before doing the
reads -- every time.

Also pertinent -- as soon as any step is enabled, the ADC goes out of
IDLE to handle enabled steps. There is a master Enable in the CTRL register
-- to synchronize the reads, you'd likely have to set it to 0, program the
steps, then set it to 1 to start the ADC. 




-- 
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/69hj7g140e9n0vp111gpr7tiltonan0c41%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Wed, 14 Apr 2021 08:03:30 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

> The TSC_ADC only has 8 channels.  So why are there 16 STEP registers? 

So far as I can make out, since each step config includes the
input/channel, it means one can sample the same channel multiple times
during a sequence.


-- 
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/i1je7g5lji264tiuae2ftumvb1e3mauicv%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Tue, 13 Apr 2021 11:25:06 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

>We're designing it the way you suggested.  The nice thing is that basically 
>the control logic has already been written in C on the ARM side.  Now, I 
>just
>Here's one more thing I am struggling with though.  It's a mental block I 
>think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
>appears that on the PRU, we use __R30 instead but I don't understand how 
>that works.  I read through it this morning and it still isn't sinking in.  
>If anyone can help make this clearer, I'd appreciate it.
>
More details of what is confusing you would help.

R30 (output)/R31 (input) registers are mapped as one GPIO per bit
https://elinux.org/Ti_AM33XX_PRUSSv2#Beaglebone_PRU_connections_and_modes
and those bits/GPIOs you are using will need to be properly pin-muxed in
u-Boot uEnv.txt.

As for using the registers... For input it should just be a case of
bitwise AND on the register content and test for result of 0/not 0
(assuming you are testing just one input at a time...). {Treat the
following as pseudo-code; I've not done any PRU programming, and am getting
stale with C]

inputX = 0 != (__R31 & (1 << desired_bit))

For output, you likely will need to maintain a copy (can the output
register be read by C code? -- if it can, forget the copy). You would AND
the inverse of the desired bit (to retain the other bits, but clear the
desired bit to 0) then OR the desired bit with the wanted value and write
the register with the combined result.

to set
__R30 = (__R30 & ^(1 << desired_bit)) | (1 << desired_bit)
to clear
__R30 = __R30 & ^(1 << desired_bit)

You'll likely want to prebuild the (1^^desired_bit) as constants for
each input/output of interest.


-- 
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/8uge7glso7meuilk7p7orm8jnqd5se1866%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Mon, 12 Apr 2021 13:08:48 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

>What's really throwing me is the + between what looks like two macro 
>values.   Normally, we see the + on the right sign of the equals, right?  
>Or am I forgetting something I used to know!?
>

Why? Take into account the ()s.

From what I can tell, this is adding the ADC register offset to the
base address of the (?) wakeup register block, which is passed as parameter
to HWREG (no doubt some macro that sets up actual access to the SoC
registers and returns a pointer or some such), and then assigns 0x02 into
the register so indicated.


-- 
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/44cb7gtf6pl4d4j3e6oqo57g5n0hobi29c%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Fri, 9 Apr 2021 11:15:49 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:


>1 - start / stop reading the sensors - considering just flipping a bit in a 
>memory location both can access for this.  ARM will have write access, PRU 
>will just monitor it.  (I don't really know how to do this yet. Still 
>learning.)

Well, since the PRU doesn't have asynchronous interrupts, using a
polling loop on the interrupt bits, that's probably reasonable -- though
I'd hope that RPMsg (since TI pushes it these days) should be usable
without a polling loop itself.

Especially if you can test for an incoming message between actually
reading an ADC sample.

>2 - raw data collected about the event by the PRU doesn't really have to be 
>accessed by the ARM in normal operation.  (For R, we'd probably like to 
>have it though.)  Every sensor reading has to have its corresponding 
>timestamp but all this data can be tossed once it is consumed.   The PRU 
>will need to be able to do some statistics on it like mean, mode, std. dev. 

Which probably need to be transferred to the Linux side -- another
RPMsg message block?  Using the same channel as #3 below, just different
message contents (or same message for both?)

>3 - if conditions are met, the PRU needs to tell the ARM.  considering just 
>flipping a bit in a memory location the PRU can write to and the ARM can 
>only read from for this.
>
Ugh... Polling loop sucking up CPU cycles on an OS that already adds
potential process swapping when the loop eats all cycles of a quantum...

Just feels like attempting a (blocking) read on an RPMsg channel would
be cleaner. Linux side waits for PRU to send some message without eating
cycles. However ...

https://www.kernel.org/doc/html/latest/staging/rpmsg.html

... seems to rely upon a callback function for return data on the channel.
Example is too brief to really understand the API -- which does not seem to
have explicit RECV (to complement the SEND calls). Makes it a touch
confusing to me... Is the callback "active' from the moment the channel is
created, or only when a SEND operation was performed (since the channel is
considered bidrectional, I'd expect the callback to be active from the
start -- so either side can act upon a message sent by the other).





-- 
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/bjn37gptcvkq383mq75qovi2ti3lk6n1ls%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Fri, 9 Apr 2021 11:50:56 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

>When I try to run this in Cloud9, I'm getting this error.  I'm not sure 
>where type __far is defined but apparently I'm missing that definition.  I 

>When I try to run this in Cloud9, I'm getting this error.  I'm not sure 
>where type __far is defined but apparently I'm missing that definition.  I 

That looks more like a compiler directive than a type in its own right
-- something forcing a pointer type to be a full address, and not a short
relative address. You may need to ask the source of the code what compiler
they were using?


-- 
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/khn37gpapmc79mrpoago56gk466rbas5ff%404ax.com.

[beagleboard] Re: Periodic delay reading analog inputs with C, will PRUs solve it and is it worth it?

[Dennis Lee Bieber]

On Fri, 9 Apr 2021 09:30:53 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

>We are still experimenting but our preliminary calculations lead us to 
>believe a reading every 50 microseconds will be sufficient. We can probably 
>get by with 100 microseconds if we have to but I think the BBBw can easily 
>sample at this rate, right?

Well, the SoC reference (SPRS717J) indicates that the ADC should be
capable of 200K samples per second. If I haven't flubbed the math, that
appears to come down to one sample every 5us.

As I recall, the PRU runs on a 200MHz clock, and PRU instructions, for
the most, run in one clock cycle. Should be enough cycles per sample to
handle processing 

Of course, it may matter how you have the ADC programmed.



-- 
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/gh417gtj1fku7qtbq4bifp3h8567v0b7c4%404ax.com.

[beagleboard] Re: PRU remoteproc1 and 2 missing

[Dennis Lee Bieber]

On Wed, 7 Apr 2021 09:31:04 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Cheng Chen
 wrote:

>I am following the Molloy's book chapter 15 to learn PRU. 

First or Second edition?


>kernel:[4.19.94-ti-r42]

>uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]

>pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]

Might be relevant -- you are running a 4.19.x kernel, but loading 4.14
PRU RPROC firmware...

>[   51.242110] remoteproc remoteproc0: wkup_m3 is available
>[   51.258161] remoteproc remoteproc0: powering up wkup_m3
>[   51.258191] remoteproc remoteproc0: Booting fw image 
>am335x-pm-firmware.elf, size 217168
>[   51.258458] remoteproc remoteproc0: remote processor wkup_m3 is now up
>dmesg | grep pru


-- 
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/g4bs6g5d95et8vj7i6ccujhn31ldm990uj%404ax.com.

[beagleboard] Re: service that starts at boot can't use PRU - uio_pruss unavailable

[Dennis Lee Bieber]

On Fri, 2 Apr 2021 14:36:51 -0600, in gmane.comp.hardware.beagleboard.user
John Allwine  wrote:

>That said I still don't fully understand the problem. Where is U-boot
>stored? I'm booting from a microSD card and using that card in one board
>works, but didn't when I switched to this other board. Does it not pull
>that data from the microSD card? Is it reading from the eMMC of the other
>board?

As I understand the process... Unless the boot-select button is held
down, recent images (mid-Jessie time-frame I believe) contain a u-Boot that
checks for the uSD card. So...

Without boot-select, the u-Boot on the eMMC is loaded. It then checks
for the presence of the uSD card, and then for a bootable system on that
card. If such is found, the uSD card is made primary and booting
/continues/ using the files found on the card. u-Boot is still the version
from the eMMC.

With the boot-select, the eMMC is completely bypassed and the uSD card
is made primary, and u-Boot searched for on the uSD card. If found, it is
loaded and continues booting using the uSD card.

I'm not certain of when the "u-Boot loads device tree" vs "kernel loads
device tree" change took place. If it was after the auto-uSD card boot
change, one has the potential to have an eMMC u-Boot that expects the
kernel to load device tree, while the kernel on the uSD expected u-Boot to
load them (or if the uSD card is old enough, an eMMC u-Boot that does load
device trees, running a kernel that expects to read the device tree files).

Periodic flashing of the eMMC with current images is probably
recommended, just to ensure the u-Boot image is up-to-date (and cleaning
out crud that might have accumulated on the eMMC  )


-- 
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/q23h6g9cq5a32t5c25ca6fn85avstk01j7%404ax.com.

[beagleboard] Re: BIG problem with BBB and logging into ANY username

[Dennis Lee Bieber]

On Wed, 31 Mar 2021 10:59:10 -0700, in gmane.comp.hardware.beagleboard.user
Bob Hammond  wrote:

>debian@beaglebone:/mnt/media/etc$ su root
>Password:
>su: Authentication failure
>debian@beaglebone:/mnt/media/etc$ su root
>Password:
>su: Authentication failure
>debian@beaglebone:/mnt/media/etc$ sudo nano shadow
>  GNU nano 2.7.4 File: shadow
>

I'm beginning to get lost in just what machine is which in this
discussion.

You obviously have some device that boots and lets you sign in. I'm
presuming you then mounted an SD card (or subdirectory of said card).

Note that, by default for quite some years, a stock Beaglebone does not
assign a password to the root account (or it is something impossible to
enter), and prevents direct login as root. Your "su root" is likely failing
for that reason. However, you do have sudo privileges (had you run sudo
recently before the above cut -- on normal Beagle images, the first
run of sudo [and runs after some timeout period] prompt for the user
password, but you don't appear to have had to enter that). 

Try entering

sudo su

or maybe

sudo bash

debian@beaglebone:~$ sudo su
[sudo] password for debian:
root@beaglebone:/home/debian# exit
exit
debian@beaglebone:~$ sudo bash
root@beaglebone:/home/debian# exit
exit
debian@beaglebone:~$

debian@beaglebone:~$ sudo cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...
debian@beaglebone:~$ sudo cat /etc/shadow
root:$6$5qgZEu6UrcE6p.vz$HcTDnuyYnQDb3QCslR59OSMIor.Y4ugey8DNqPvoNDvZ8BFBZqIbQQkKBpf9SeT3Bma5xG8EsIX7bt1OWUKmV/:18493:0:9:7:::
...

Granted, those are for the local machine. Have you tried "diff"ing the
running (eMMC?) version of the files with the files on the mounted SD? Also
compare the file owner/group and access (hmmm... group and gshadow files
too)

debian@beaglebone:~$ ls -l /etc
total 784
...
-rw-r--r-- 1 root root1095 Feb 24 09:41 group
-rw-r--r-- 1 root root1086 Oct  1 01:59 group-
-rw-r- 1 root shadow   933 Feb 24 09:41 gshadow
-rw-r- 1 root shadow   924 Oct  1 01:59 gshadow-
...
-rw-r--r-- 1 root root1600 Aug 19  2020 passwd
-rw-r--r-- 1 root root1533 Aug 19  2020 passwd-
...
-rw-r- 1 root shadow   934 Aug 19  2020 shadow
-rw-r- 1 root shadow   902 Aug 19  2020 shadow-
...
debian@beaglebone:~$

Unless you've created a lot of custom users on the SD card, it could be
worth just copying the files (using sudo) from the running machine to the
SD card, and verifying (ls) they have the correct privileges/owner/group
after the copy.


-- 
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/sui96g1iedi1ov59hgijg54hb37o0akmam%404ax.com.

[beagleboard] Re: Boot pins/sequence

[Dennis Lee Bieber]

On Wed, 31 Mar 2021 02:46:53 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user "'Adam' via BeagleBoard"
 wrote:

>
>Hi,
>
>I'm using a BBB with Debian on an SD card, and am having issues booting up 
>whilst Pin 31 on P8 is held low.
>
>When P8.31 is held high, i.e. held at 3V3, or not connected to anything, 
>the normal boot-up sequence occurs. I can see LEDs D2 to D5 flashing, and 
>can see the standard boot-up output from the debug serial connection on my 
>terminal emulator. 
>

From the BBB SRM:
"""
* These pins are also the SYSBOOT pins. DO NOT drive them before the
SYS_RESETN signal goes high. If you do, the board may not boot because you
would be changing the boot order of the processor.
"""

SYSBOOT 14-15 appear to define the crystal frequency. See SPRUH73P (TRM)
table 26-7


-- 
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/r8796g19ll0d6l4gh0i8b0nifgqe6e2p9n%404ax.com.

[beagleboard] Re: eCAP reading a PWM signal, someone has made this functionality works?

[Dennis Lee Bieber]

On Tue, 30 Mar 2021 23:29:16 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user set_
 wrote:

>Hello,
>
>Adafruit_BBIO has some type of example plus the library has its 
>source: 
>https://github.com/adafruit/adafruit-beaglebone-io-python/tree/master/Adafruit_BBIO#usage
>

The eQEP is a different creature from eCAP. 

eQEP is to read quadrature encoded inputs (rotary knobs producing two
step waveforms in which the changes between the two identifies which
direction the knob is rotating, and how far it has been turned). From the
BBB TRM (SPRUH73P)
"""
15.4.1 Introduction
A single track of slots patterns the periphery of an incremental encoder
disk, as shown in Figure 15-130. These slots create an alternating pattern
of dark and light lines. The disk count is defined as the number of
dark/light line pairs that occur per revolution (lines per revolution). As
a rule, a second track is added to generate a signal that occurs once per
revolution (index signal: QEPI), which can be used to indicate an absolute
position. Encoder manufacturers identify the index pulse using different
terms such as index, marker, home position, and zero reference.
"""

eCAP is, as the TRM describes it
"""
15.3.1.1 Purpose of the Peripheral
Uses for eCAP include:
• Sample rate measurements of audio inputs
• Speed measurements of rotating machinery (for example, toothed sprockets
sensed via Hall sensors)
• Elapsed time measurements between position sensor pulses
• Period and duty cycle measurements of pulse train signals
• Decoding current or voltage amplitude derived from duty cycle encoded
current/voltage sensors
"""

>On Monday, March 29, 2021 at 3:14:59 PM UTC-5 
>papelhi...-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:
>
>> Someone has made this functionality works? Can be via sysfs, via PRU 
>> program handling the register, via CPU program handling the registers, or 
>> any other method?
>>
>> If yes, can give me an example or the environment details? 
>>
So far the best I've located is some 7 years old:
https://linux-arm-kernel.infradead.narkive.com/zeEA4MIa/patch-v3-0-6-iio-pulse-capture-support-for-ti-ecap

It appears your question was asked some two years ago at:
https://github.com/adafruit/adafruit-beaglebone-io-python/issues/306

{which sort of implies the previous effort was never really completed}


-- 
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/9j696g9rfqqlvs2bq0g7784ea2n3urnlt8%404ax.com.

[beagleboard] Re: BIG problem with BBB and logging into ANY username

[Dennis Lee Bieber]

On Tue, 30 Mar 2021 13:36:11 -0400 (EDT), in
gmane.comp.hardware.beagleboard.user Robert Heller
 wrote:


>Right.  GRUB is pretty much a x86-only program.  Most ARM boards use uBoot.  
>The Raspberry-Pi's use their own thing and are the only (?) ARM boards that 
>that need a FAT /boot partition.
>

Yeah, the R-Pi is weird... as I recall, the graphics core is what gets
started at boot, and IT is what loads the Linux image into the ARM
processor. Though the newer SoCs may do things differently (the foundation
pages mention that is an interactive bootload is needed, one should use
u-Boot -- which may imply a way to have the GPU  load a secondary
boot-loader... actually, Google found one site that mentions replacing the
kernel.img file with one containing u-Boot... Which would make it a third
stage bootloader; first and second stage loaders running in the proprietary
GPU)



-- 
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/rlo66g5ladnveivbpuv8go6o5jeiot39d9%404ax.com.

[beagleboard] Re: BIG problem with BBB and logging into ANY username

[Dennis Lee Bieber]

On Tue, 30 Mar 2021 07:02:25 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Bob Hammond
 wrote:


>I am now attempting to get into GRUB during boot.  I never see a GRUB menu 
>show up by pressing/holding ESC or left shift.  What I do see is that I can 
>interrupt boot by pressing the spacebar.  I then get a command prompt in 
>??.  And I have no idea what to do after that.

What leads you to believe the Beagles have GRUB installed?. The
boot-loader is u-Boot.

https://www.denx.de/wiki/U-Bootdoc/BasicCommandSet
(or, the whole shmear as a PDF
http://www.denx.de/wiki/publish/U-Bootdoc/U-Bootdoc.pdf )

Raspberry-Pi's don't use GRUB either, nor do most all ARM-based boards
(Xylinx Zynq, etc.)


-- 
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/q9n66g9bieq37f1l3a36t7nc2c0curebv3%404ax.com.

[beagleboard] Re: QT GUI for BB Board

[Dennis Lee Bieber]

On Sat, 27 Mar 2021 07:16:26 +0900, in gmane.comp.hardware.beagleboard.user
ashnote8  wrote:

>Hi Alexandre, Thanks for your reply.well, I need to develop a simple GUI 
>application on Beaglebone Board to control the Servo (in my case it's 
>Dynamixel) parameters like speed, mode, direction..etc. The Servo provider 
>provides the SDK based on API and protocol. I wish to use this SDK while 
>Integrate with Qt-gui. I individually tested the SDK to control the servo, but 
>how to integrated it with Qt-gui, I am new to this. Any test example or 
>suggestions would be highly appreciated. Please help.Thanks,/Ash

You've basically just repeated your original message, which doesn't
really help anyone in offering assistance.

You are unlikely to get any "test example" as that requires someone
else to have similar hardware (servo).

The particular GUI toolkit is likely irrelevant. You need to define
what operations of the servo you want to expose to the user of the GUI
application, you need to decide what type of controls the GUI toolkit
provides best map to each operation, and you then need to create call-back
functions (most GUI toolkits these days rely upon call-backs to implement
operations -- whereas the ancient Amiga required one to code the
"main-loop" which received event messages and had to dispatch to the
appropriate function; hmmm, looks like PyGame also uses user-defined
main-loop). Call-back functions need to be short and fast, as the GUI will
be "hung" while a call-back is processing.

Have you written code for ANY GUI system? Is the servo library
available from Python (may need to study the ctypes module to access the
servo library). I ask as there are lots of Python-based frameworks for the
various low-level GUI back-ends, which may be easier to code for. Any code
for a call-back event handling system? Have you studied any tutorials for
the GUI framework you intend to use?
https://towardsdatascience.com/top-10-python-gui-frameworks-for-developers-adca32fbe6fc
Consider looking at the docs for PySimpleGUI -- since the above linked
article implies that one can select from Qt, WxPython, Tkinter, and some
other for the actual back-end.
https://pysimplegui.readthedocs.io/en/latest/
(separate pip install for each backend -- pysimpleguiqt vs pysimpleguiwx,
etc.)

Current Qt for Python appears to be pyside2, so that documentation may
be relevant.

If doing "native" GUI you may be impacted by the API being either C or
C++ compatible.




-- 
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/v6ps5gdp8e7bbfi7tfusrd3tc0i5u69flu%404ax.com.

[beagleboard] Re: How to access GPIO using derek molloy's GPIO Library

[Dennis Lee Bieber]

On Thu, 25 Mar 2021 10:07:13 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"jeff-re5jqeeqqe8avxtiumw...@public.gmane.org"
 wrote:


>
>The following post shows a line in uEnv.txt for enabling, and I assuming 
>disabling cape universal:
>
>https://github.com/beagleboard/bb.org-overlays/issues/79
>
>enable_uboot_cape_universal=1
>
>So, not sure if this means that if you change to 0 in uEnv.txt, that it 
>would free up pins so that pin-config no longer gives an error.
>

I seem to recall that disabling cape_universal ALSO disables any use of
config-pin. More likely is that one needs to disable /other/ overlays that
are claiming the desired pins. From my BBB:

###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1

Though what overlay claims P1_36 (PWM0 A) is not apparent. May have to
search the device tree sources to find it.


-- 
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/gv2q5gpoi1o10hfvio4ishmebffvhlrusc%404ax.com.

[beagleboard] Re: BB boot from eMMC/SD

[Dennis Lee Bieber]

On Wed, 24 Mar 2021 19:20:26 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user ASH KR
 wrote:

>Hi,
>Since first when I have the new BB, I successfully booted it from already 
>flashed image in 4gb eMMC. I need to install some libraries and other stuff 
>related to Qt, so there is no space left on eMMC. I wish to use SD slot for 
>my work from now. I flashed the image to SD and plugged it into BB, power 
>on while pressing the 'boot' button keep it booted but when i check the 
>storage using 'df -h' it doesn't show it. Please suggest. I am new to this.

Any Beagle made in the last few years should not need you to hold down
the boot select switch. The u-Boot (in eMMC) should detect that there is an
OS on the uSD card, and will transfer to use that card for the rest of the
boot process.

>
>What is the best way to use both eMMC and SD together OR separately ?
>
>Is it possible to use it like...
>1. eMMC (boot) + SD (further install)
>2. SD (boot + install)

When using a uSD card, #2 is the normal operation mode. Option #1 will
be problematic to set up as the card needs to be NON-Bootable; you'd have
to mount the card after the Beagle has booted from eMMC, and then create
mount points to overlay certain standard directories (/bin, etc.) -- which
would need have copies of everything from the equivalent eMMC directory.
After which, apt install should put the newly installed stuff into the uSD
directory. However, that can lead to some confusion -- as you may still
need to have LXQT on eMMC so the X environment is started early.

My recommendation -- just get a large uSD card, burn a recent image to
it, boot it, then run the partition expansion script to make the whole card
available.


-- 
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/djfp5gpnkc9tabiv84f3v525i5hgqj48aj%404ax.com.

[beagleboard] Re: How to access GPIO using derek molloy's GPIO Library

[Dennis Lee Bieber]

On Tue, 23 Mar 2021 14:17:30 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Piyush Raj ae19m009
 wrote:


>I have started using GPIOs on pocketbeagle in my application. I need 24 of 
>them. However, using the GPIO library on github (exploring BB), i am able 
>to access only 18 of them. How can i access more GPIOs on the P1 header say 
>for instance, gpio110 (P1_36).
>

You have to reconfigure the pin-mux for those pins. config-pin might be
capable of that (note: there are two config-pin executables; the one on the
path is a compiled version that lacks some capability over the older shell
script version [searching the file system should find it]).

At worse, it may require modifying one or more device tree files.


-- 
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/aukm5ghounegkeqb68so8lf1as2ge1srls%404ax.com.

[beagleboard] Re: [BBB] How much current is supplied with 3.3V header pin?

[Dennis Lee Bieber]

On Sun, 21 Mar 2021 20:58:18 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user JeongHwan Kim
 wrote:

>
>I'm using USB2 interface for powering BBB.

Which, for a compliant USB2 socket, provides a maximum of 500mA. Most
of that is used by the SoC and support (I think I read that the peak during
boot is around 400mA), so the amount available on the 3.3V pins will likely
be less than the 250mA (which should be available if using a 5V barrel jack
power supply). The main 5V pins are disabled under USB power.



-- 
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/3jih5gh6g483km4hkeep0sr6hhtqfmqc9m%404ax.com.

[beagleboard] Re: [BBB] How much current is supplied with 3.3V header pin?

[Dennis Lee Bieber]

On Sun, 21 Mar 2021 07:29:27 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user JeongHwan Kim
 wrote:


>I'm attaching the audio codec breakout board with BBB.

A link to the documentation of said board would be useful -- I don't
know if there are multiple makers of boards that qualify as an "audio codec
breakout".

>How much current is supplied with 3.3V header pin of BBB?

How are you powering the BBB? Note that, if using the USB-2 interface,
the entire board is running from a 5V 500mA supply (if the source can
provide it). Using the barrel connector with a wall-wart supply can provide
around 2.5A. You would now have to check the documentation for the voltage
regulation chip on the BBB to find out how much gets passed through it...

Documentation for the PMIC indicate 1.2A available output powering the
entire board. The BBB SRM shows that it has four LDOs, two at 100mA and two
at 285mA (I'd guess at least one of those is providing the 3.3V outputs on
the connectors). The spec sheet for the PMIC (-C variant) says 400mA for
the those two LDOs

The SRM states the expansion board headers provide up to 250mA @ 3.3V
(I can't tell if that is shared by the two pins, or if each pin can supply
250mA for a total of 500mA). The VDD 5V can provide 1A.

This is as much research as I'm willing to put in... All the documents
are available on-line (well, maybe the PMIC is blocked depending upon one's
country -- TI is weird that way).


-- 
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/fpse5gtg2e0hvoj37berjim21807237464%404ax.com.

[beagleboard] Re: python script error

[Dennis Lee Bieber]

On Thu, 18 Mar 2021 23:42:04 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Ekkam Singh
 wrote:

>hi 
>i am writing a code in python but it is coming error when i write the 
>program :-
>for line in username:
>content = username.split(' , ')

content = line.split(",")

NOTE: your split is explicitly expecting  which is
an unnatural usage of commas. Better, I would think, is to use
content[*].strip() to get rid of the spaces after splitting on the comma.

>if content[0] == userName:
>content[1] = score
>line = content[0] + ', ' + content[1] + '\n'

Confusing usage. Your main input is a list or iterable called
"username", yet you are expecting the first term of each LINE of that
iterable to contain something you compare to whatever userName contains.

Also, note that you are appending a newline when recreating line, but
does the unmodified line end with a newline? (I'm assuming you later write
either the modified or unmodified line to some file).

There is no need to bind "score" to content[1] if the only usage is
then to join strings. Also, "score" needs to be a string for that joining
to work -- if it is numeric you need to convert it. Consider:

for line in username:   #still don't like that object name...
#user_scores may be more 
applicable.
uName = line.split(",")[0].strip()  #don't care about rest
if uName == userName:
line = "%s, %s\n" % (uName, score)
#using %s means whatever "score" type, it will
#be converted to a string representation

 


-- 
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/tg7a5gp6hvmoltbr1klop0kugovngg6j9k%404ax.com.

[beagleboard] Re: Servomotor Herkulex Beaglebone

[Dennis Lee Bieber]

On Thu, 18 Mar 2021 08:27:40 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Adnane Dinar
 wrote:

>I need someone who know how control a herkulex servo with my beagle bone in 
>python or c 

Typically, servos are controlled by using a PWM signal. cf:
https://stackoverflow.com/questions/50203064/pwm-on-beaglebone-black-v4-14

However, the documentation for this servo
https://www.robotshop.com/media/files/pdf2/_eng_herkulex_manual_20140218.pdf
indicates that this servo uses 115200bps 8n1 TTL level SERIAL communication
-- eg: a UART.

Unfortunately, the diagram on page 51 indicates that "TTL" means
original 5V TTL. 5V will kill a Beagle -- the pins are limited to 3.3V. The
diode/resistor set shown at the top left /might/ imply that the TTL is
using a pull-up circuit -- in which case feeding 3.3V instead of 5V may be
sufficient.


-- 
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/43595g109c2mpctr8tenjsptjld41ajap1%404ax.com.

[beagleboard] Re: Beaglebone Ai overheating

[Dennis Lee Bieber]

On Tue, 16 Mar 2021 10:20:43 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user
"robert.sty...-re5jqeeqqe8avxtiumw...@public.gmane.org"
 wrote:



>
>Which one of these http://beagleboard.org/latest-images do you put on a 
>SD-Card or USB flash memory stick?

The BBAI is a 5729 SoC. I wouldn't use any of the images from that page
-- they are nearly a year old and you would need a large uSD or eMMC
freespace to run an "apt update/apt upgrade" sequence.

I'd suggest visiting https://rcn-ee.net/rootfs/bb.org/testing/ and
checking for a more recent build that includes the updates of the last
year. Maybe not the most recent build (these /are/ labeled "testing, after
all) but not too old either. (Note that 2021-02-15 has Debian 10.8, vs the
10.3 of the "latest images" page). Decide if you want a graphical desktop
(images with LXQT) or Internet of Things (images with iot), TI Deep
Learning (images with tidl) [Note that these are not mutually exclusive:
LXQT & TIDL, IOT & TIDL, LXQT only, IOT only)]

>Which updates the on board memory?

Updating the eMMC is performed by loading the appropriate "Flasher"
image onto an uSD card, and booting with that card inserted.

Alternatively, non-flasher images can be turned into flasher images by
editing the /boot/uEnv.txt file. Typically the last line of that file has a
commented line; removing the # from the line enables the flashing mode.

Note that if you boot with a flasher image, it WILL rewrite the eMMC --
every time. You would have to mount the uSD after a boot from the eMMC to
recomment the line in uEnv.txt.



-- 
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/91l45gd19hesakk5cekb4knb1qblvu0r66%404ax.com.

[beagleboard] Re: Trying to get data from ADC-HX711 through GPIO9_12(60)(SCK) and GPIO9_15(48)(Dout)

[Dennis Lee Bieber]

On Sun, 14 Mar 2021 04:08:20 -0700 (PDT), in
gmane.comp.hardware.beagleboard.user Vivek Yadav
 wrote:


>I have set the direction of these 2 pins after going under 
>/sys/class/gpio/gpioxx/direction as OUT and IN as per requirements.
>But I am not able to get data from HX711. So I debug and Find out that I am 
>taking one time than required. Typically my SCK pin must remain high1-2 
>mico Seconds but I am taking 5-6 mico Seconds. Which is not desirable. *All 
>this Code is in C language.*
>

The first thing to understand is that the BBB is not a microcontroller
with deterministic timing (the PRU modules, however, ARE microcontrollers).
The documentation for that chip assumes a microcontroller.

You are going through the LINUX file system to access kernel modules
for GPIO. LINUX is not real-time. Essentually, each time you issue a set
(write) or read of a GPIO, your process is suspended, while the OS
schedules your I/O. If there are other processes suspended, of equal
priority, one of them may be woken up next.

The actual read-back of a sample is close to the SPI protocol, but the
odd timings needed for configuring the chip are not...

>Now I need Your suggestions that How can I speed up my GPIO pin reading and 
>Writing Time.
>

Avoid the sysfs calls if possible (you don't show your code so it is
difficult to make suggestions). Write a driver using the PRU, and an
interface to the application running on Linux (remoteproc/rpmsg).

>I have seen some example where writers trying to Show the GPIO 
>configuration. using mmap(). But no one talking about the GPIO speed.
>

mmap() is bypassing the sysfs kernel calls by running as a privileged
process with direct access to the processor registers controlling GPIO.


-- 
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/51j15gp5gv1490cvi22pv4cnso66vmk70a%404ax.com.

[beagleboard] Re: EmcApplication, LinuxCNC, and BBG w/ 5" Seeed LCD Cape...

[Dennis Lee Bieber]

On Thu, 4 Mar 2021 20:51:56 -0800 (PST), in
gmane.comp.hardware.beagleboard.user set_
 wrote:

>*OF: graph: no port node found in /ocp/lcdc@4830e000OF: graph: no port node 
>found in /ocp/lcdc@4830e000OF: graph: no port node found in 
>/ocp/lcdc@4830e000*
>
Is that an actual cut or did you attempt to transcribe from the
Beagle to your message? Those look like they should be on three separate
lines.

https://e2e.ti.com/support/processors/f/791/t/804806

Unfortunately every thread I've seen that mentions that error comes
down to making one module "external" so it get loaded later, not as part of
the u-boot startup.

However...

>   - BeagleBone Green
>   - 5" Seeed LCD Cape
>   - LinuxCNC/EMCApplication/Axis
>
>So, when I run the command, *linuxcnc*, everything is in order. The GUI 
>comes up, the options are there on my LCD panel, and only when I double 
>click on *axis *does this error happen.
>

... this implies you do have a functioning display so I'd be tempted to
blame your CNC application.

>The error points to a specific error code on my LCD Panel. It is a 5" LCD 
>and the file that pops up will not allow me to save it. If this is a BBG 
>issue, okay, I will stay w/ this thread for a while.
>
>If it is a linuxcnc/EMCApplication issue, I will go the other way and 
>revisit machinekit on the google groups and their chat(s). 

Can't tell as the critical data is missing... For example: "file that
pops up" doesn't tell me anything -- where does a file pop up? "File"
implies it has a file name somewhere in the file system of the Beagle. If
you mean you get an error trace on the LCD itself, maybe you should try
running your application with stderr redirected to a named file, rather
than going to a screen. What error code?


-- 
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/vai34g9rud0n6gtct2ia72osioogkpt91e%404ax.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

[Dennis Lee Bieber]

On Thu, 4 Mar 2021 12:48:59 -0500, in gmane.comp.hardware.beagleboard.user
Don Pancoe  wrote:

>But if I used the following, would it not evaluate only at the start of the
>while loop? The main loop of the whole test lasts on the order of minutes
>even if all sub-tests pass, so how would that capture a <1sec button press?
>Or is Python an event-driven language, where a change in the evaluated
>condition will break the loop at any point?
>
>while pruio_gpio_Value(io, abortPIN)

Python is not event-driven -- Node.js/Bonescript MIGHT be such, but I
have never been able to make sense of even a short example where everything
seems to be written as a call-back function triggered by other
call-backs... I also have never been able to make sense of Python's asyncio
library either, for the same reason. Threads with some form of interprocess
(interthread) communication (Queue) is something I can work with.

The only difference between the above "while" and my "while" is that
the above is reading the pin when called, whereas mine is reading a global
variable that gets set by a call-back when Adafruit_BBIO detects a state
change on the pin. So the above may only see the button pressed at one
point in the code, and the next test may not see it -- and if the code does
not poll the pin fast enough, one may even miss the button press.  libpruio
does not seem to support such -- cf:
https://groups.google.com/g/beagleboard/c/3wphAPs9Uws (which is the
underlying C level, I doubt the Python interface adds any features)

In both styles, you need to include a test (either "while" or "if") at
any point in the code where you can implement a break in execution. In both
styles, backing out from multiple levels of loops will require either a
custom exception which can be trapped at the point where you can clean-up
from the aborted loops, or some sort of "if" test immediately after a
single level "break".

while main-loop-conditional:
if abortFlag: break
while loop1-conditional:
if abortFlag: break
#do short bit of work
if abortFlag: break
#do more work
if abortFlag: 
#clean up loop1 stuff
break
while loop2-conditional:
if abortFlag: break
#do short bit of work
if abortFlag: break
#do more work
if abortFlag:
#clean up loop2 stuff
break
if abortFlag:
#clean up main loop stuff
#otherwise normal exit of main loop

Note that the proposed in-line pruio_gpio_Value() version has the
problem that the state may change between reads -- so one might abort one
inner loop, but the next test finds the button is not pressed and doesn't
propagate the abort upwards.


OR using custom exception (but with 1-level cleanup)

while main-loop-conditional:
try:
if abortFlag: raise abortException
while loop1-conditional:
try:
if abortFlag: raise abortException
#do short bit of work
if abortFlag: raise abortException
#do more work
except abortException:
#clean up loop1 stuff
#if you want to propagate the abort 
#reraise the exception
raise
#otherwise clear abortFlag to allow second loop 
to run
#or just
break
#to move on
while loop2-conditional:
try:
if abortFlag: raise abortException
#do short bit of work
if abortFlag: raise abortException
#do more work
except abortException:
#clean up loop2 stuff
#if you want to propagate the abort 
#reraise the exception
raise
#otherwise clear abortFlag to allow second loop 
to run
#or just
break
#to move on
except abortException:
#clean up main loop stuff
#otherwise normal exit of main loop

OR IF you can postpone all clean-up to the end

while main-loop-conditional:
try:
if abortFlag: raise abortException
while loop1-conditional:
if abortFlag: raise abortException
#do short bit of work
if abortFlag: raise abortException

[beagleboard] Re: iperf server side does not quit

[Dennis Lee Bieber]

On Thu, 4 Mar 2021 06:25:19 -0800 (PST), in
gmane.comp.hardware.beagleboard.user S Pazouki
 wrote:


>after printing the result, the client iperf quits its function but the 
>server stays in it.
>
Off-hand, I'd expect a server to remain running... Waiting for the
/next/ client to connect.

https://iperf.fr/iperf-servers.php
"""
iPerf3 servers will only allow one iPerf connection at a time. Multiple
tests at the same time is not supported. If a test is in progress, the
following message is displayed: "iperf3: error - the server is busy running
a test. try again later" 
"""

https://iperf.fr/
"""
-s, --serverRun iPerf in server mode. (This will only allow one iperf
connection at a time)
"""

One connection at a time, but nothing says only one connection per
invocation!


-- 
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/5a224ghtr1dduuttudcak0p8dna766ebd2%404ax.com.

[beagleboard] Re: PWM wave in pocketbeagle

[Dennis Lee Bieber]

On Wed, 3 Mar 2021 06:18:40 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Rafael Meyer

wrote:

>
>I would like to know how to generate a PWM wave with code in python3. 
>

https://adafruit-bbio.readthedocs.io/en/latest/PWM.html

Based upon
https://raw.githubusercontent.com/wiki/beagleboard/pocketbeagle/images/PocketBeagle_pinout.png
there are four pins that support PWM output. P1_33 (defaults to PRU), P1_36
(PWM), P2_1 (PWM), P2_3 (default GPIO).

If Adafruit_BBIO.PWM can't change the pin mode, you may have to play
with config-pin external to the program first.

It looks like PWM has also been added to the blinka/circuitpython
adapter.




-- 
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/sdp04g50hhjhfbs5f57la9h1v1orub8dla%404ax.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

[Dennis Lee Bieber]

On Wed, 3 Mar 2021 18:11:27 -0500, in gmane.comp.hardware.beagleboard.user
Don Pancoe  wrote:


>The PCBA test program is a long series of while loops, if statements and
>timeout counters that wait for inputs and evaluate them, or move on if
>they're taking too long. I was thinking of using an AdafruitBB_IO edge
>detect to watch for an abort button press, then having that trigger a
>function that handles any wrap-up tasks and calls a *break* function to pop
>out of the main test loop to another outer loop so that it returns to the
>top of the test. I'm actually doing this now to halt the test if the
>in-circuit programmer reports a flashing failure. The difference is: the
>programmer failure happens at a known point where I know to look for it,
>but the abort button should be able to be used at any time.
>
>One idea I've had but not tested yet is to replace the *sleep()* functions
>I judiciously use for timing throughout the test with a custom function
>that breaks the sleep period (anywhere from 10 ms to 10 s) into smaller
>chunks interspersed with checking of the abort button GPIO. This I could do
>just with libpruio as suggested by TJF. Theoretically, I could wait for
>every subsequent while loop to time out at 60 seconds each, but that's not
>practical for test throughput, or when you are billed for testing by the
>minute.
>

If using Adafruit_BBIO edge detect with a call-back function, that
call-back probably should do nothing more than set a "global" flag.

Your sleep() and loops would then include something like "while not
abortFlag".  

There is no easy way in Python to back out of multiple levels of loops
except via an exception (so something like "if abortFlag: raise
customAbortException"). You'd catch that exception at the outermost level,
and the handler does the clean-up. A one-level loop can be exited with
"break".


-- 
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/ikm04gtkhni4rvnvbon1nfffuk76nmkf6l%404ax.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

[Dennis Lee Bieber]

On Mon, 1 Mar 2021 17:14:01 -0800 (PST), in
gmane.comp.hardware.beagleboard.user set_
 wrote:


>I can use config-pin p9.21 uart && config-pin p9.22 uart and have that 
>command turn successful.
>
So far as I've been able to determine, config-pin (and Adafruit_BBIO)
rely upon cape-universal to provide the pin-mux capability. The OP has
stated that his application disabled cape-universal. As a result,
config-pin, and any configuration required to be performed by Adafruit_BBIO
is likely to fail.

Using CircuitPython libraries via the blinka adapter layer probably has
similar requirements.

As for the OP's query:

>If anyone can give tips on how to do a button-based interrupt (abort)
>without BBB_IO, I'm all ears. I guess I could just start programming the
>BBB in C. I already program embedded microcontrollers in that language, so
>why not SBC?

I've not heard of BBB_IO before. Adafruit_BBIO, OTOH, is common,
followed by using CircuitPython libraries (designed for Arduino-like
boards) via the adapter library "blinka", would be second.

The trick with Adafruit_BBIO will be in the GPIO setup if
cape-universal is not present, since I believe it provides the system
"files" for the GPIOs that config-pin and Adafruit_BBIO require to
configure the pin.

If you can get past, say

import Adafruit_BBIO.GPIO as GPIO

GPIO.setup("P8_14", GPIO.IN) may not work without 
cape

then setting up an "interrupt" would be something like (not a callback --
requires your application to have a polling loop)

GPIO.add_event_detect("P8_14", GPIO.FALLING)
#your amazing code here
#detect wherever:
if GPIO.event_detected("P8_14"):
print "event detected!"

Hmmm, according to
https://adafruit-beaglebone-io-python.readthedocs.io/en/latest/GPIO.html
you CAN set up a callback function. Your choice is to detect
rising/falling/both so if you have a pull-up on the pin, and the button
takes it to ground, falling is likely what you'd use. You also need to
specify a "bouncetime" so the callback doesn't get triggered by button
bounces.


https://circuitpython.readthedocs.io/projects/blinka/en/latest/
describes the blinka adapter for CircuitPython libraries. Off-hand, it
doesn't look favorable for "interrupt" on GPIO.


-- 
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/qh9t3gtlmogs0i33gpkp24p7219aps2ioo%404ax.com.

[beagleboard] Re: POCKETBEAGLE: UART Help - Garbage data along with requisite data

[Dennis Lee Bieber]

On Mon, 1 Mar 2021 18:30:04 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Piyush Raj ae19m009
 wrote:


>
>bytes_written = write(file, ,6);

You are writing 6 bytes even though "HIGH\n" is only 5 characters (and
"LOW\n" is only 4!). That means you have 1 or 2 bytes of "garbage"
(whatever was in memory -- and since it appears the buffers are being
allocated on the stack that could mean anything). I'm also not sure of that
 -- I thought char arrays automatically pass as the address of the
array.

>sleep(1);
>read_code= read(file,receive,10);

Here you are asking to read 10 bytes, even though you are only writing
4 or 5.

>if(bytes_written>0  && read_code>0  ) 

Here you only check that at least 1 byte was written and received...
And a 1 byte receive IS possible (I haven't found any documentation that
indicates how read() handles a serial port that does not have data in it...
It's possible that the outgoing port may still be sending [the
"bytes_written" may only indicate that the kernel buffered that many for
the sending device]).

I'd probably change the write() to specify strlen(transmit) AND confirm
that bytes_written = strlen(transmit). Similar for the read() operation --
check how many bytes were received.


-- 
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/8vgs3gp74f45g0iuccs01thu57kh5b2jir%404ax.com.

[beagleboard] Re: Compatibility of Debian and Matlab

[Dennis Lee Bieber]

On Sun, 28 Feb 2021 22:01:53 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Cheng Chen
 wrote:

>Yes. Matlab is using SSH for connection. I think the problem I met is 
>exactly what you described: unable to respond to the prompt for root user 
>password. Could you elaborate on "configure the sudoers file to not require 
>a user password for sudo" a little more please? Thanks. 
>

Middle section on adding user to sudoers file -- has an example for a
use with a NOPASSWD option
https://devconnected.com/how-to-add-a-user-to-sudoers-on-debian-10-buster/

If you can configure Matlab as to the user account to use in SSH, you
may be able to create an account specific for it on the Beagle.


-- 
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/fucq3g5fn7av0vpu4hegulebp04h6cpr2b%404ax.com.

[beagleboard] Re: Beaglebone Seeed green (custom LCD read post) GUI

[Dennis Lee Bieber]

On Sun, 28 Feb 2021 12:03:40 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Don Kiser
 wrote:


>*UNIT 2:*
>Device has a modified Debian Jessie OS. By design it starts Qtopia?. The 
>board is a Beagleboard Green from Seeed Studio so no HDMI. I tried 
>installing lxqt but apt doesn't know where to find it.
>
Jessie is old enough that the graphical desktop was probably LXDE, not
LXQT.

>My concern is that overwriting it the OS with a new one 
>(bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.gz)  will lose what makes 
>the LCD work. I tried this didn't work well, had to dd a different unit to 
>get this one working again. 
>

Stretch is pretty old too. Current OS is based on Buster (Debian 10.x).

So DON'T overwrite (flash) the eMMC -- run an SD card image directly
until you verify that it does what you want. THEN convert the card to a
flasher to update the eMMC.

Note: depending upon just how old that Jessie image is, you may have to
use the boot-select button when applying power to the board. I believe it
was sometime late in the Jessie period that u-Boot was modified to
automatically switch to the SD card. Also take note of the fact that Jessie
is still in the "Linux kernel loads device tree overlays" -- for some time
now, it is u-boot that loads the overlays, so updating the eMMC by some
means that doesn't update the u-boot will cause problems.



-- 
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/psqo3g1jdil5f525m4e48ggl0r6hr6anl6%404ax.com.

[beagleboard] Re: How to change default ssid and password of wifi i.e. "BeagleBone-xxxx" and "BeagleBone"

[Dennis Lee Bieber]

On Sun, 28 Feb 2021 10:37:28 -0600, in gmane.comp.hardware.beagleboard.user
Robert Nelson 
wrote:


>I think your 3 character password is just too short..  It looks like
>we need a minimum of 8 characters for ^ configuration..

https://www.routersecurity.org/wepwpawpa2.php
"""
The shortest password allowed with WPA2 is 8 characters long. A password of
14 or 15 characters should be long enough to defeat most brute force
guessing. The German government recommends 20 characters as a minimum. WPA2
passwords can be up to 63 characters long. Of course, it is better to
include both upper and lower case letters along with numbers. WPA2
passwords can also contain a host of special characters.
"""


-- 
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/mrln3g93m8qu5lbs9dko9otfb4qpr1jvtm%404ax.com.

[beagleboard] Re: Compatibility of Debian and Matlab

[Dennis Lee Bieber]

On Fri, 26 Feb 2021 11:51:39 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Cheng Chen
 wrote:

>Hi, 
>
>I have a question about connection between Beaglebone Black and Matlab. 
>I was trying to control BBB with Matlab. But when I ran the command on 
>Matlab, there is always some errors suggested access denied. Then I found 
>that is because I do not have access to superuser. While I checked Debian I 

For quite some years now login as root has been disabled in many Linux
distributions; logging as a regular user configured for sudoer privilege
has been standard.

What "command"? How does Matlab make its connection -- using SSH? You
may have to see how to configure Matlab to use a different account for
logging into the BBB, and then modify these commands to use "sudo" (though
you still have the problem then of how do you respond to the prompt for
user password -- you might be able to configure the sudoers file to not
require a user password for sudo; Raspberry-Pi is configured that way for
the standard account).



-- 
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/5kik3g5fikvbjmt01nvnkjh1bodotql90h%404ax.com.

[beagleboard] Re: BBB only power LED is glowing ?

[Dennis Lee Bieber]

On Wed, 24 Feb 2021 09:59:38 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Ankur Rastogi
 wrote:


>when I am starting with a validated and verified bootable sdcard  to BBB 

How did you perform this "validated and verified bootable" check? By
using a second BBB?

>board, only power LED is continuously glowing. Other four LEDs are dead. I 

If it works on one BBB but not another, the odds lean toward a dead
BBB. Have you held down the boot select button while connecting a power
supply to the BBB barrel connector? The boot select button should force it
to use the SD card for booting, totally ignoring an (potentially
corrupted/empty) eMMC (images from the last few years normally load u-Boot
from the eMMC, but that u-Boot then detects the SD card and transfers the
rest of the boot process over to it; very old images did not, and the boot
select was always needed for a cold start of SD card).

If using the boot select succeeds, you most likely want to boot from a
FLASHER image to restore the eMMC with a usable system.


-- 
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/1ehf3g96ha09ek8ouf70j4at5fqea2bi9a%404ax.com.

[beagleboard] Re: the way to set MMC mode(8-bit transfer) and 384Mbps at BBBW

[Dennis Lee Bieber]

On Wed, 24 Feb 2021 22:40:45 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ha ppay
 wrote:

>I understand that the default eMMC on the board is unpublished in speed and 
>version and unreliable, is that correct?

Pardon... The eMMC used was chosen BECAUSE it is RELIABLE. However, the
more reliable flash memories tend to be slower.

Technically NOT "unpublished" either since you should be able to look
up the specification sheet for the eMMC chip on your board (mine has the
Micron chip:
https://www.datasheet4u.com/datasheet-pdf/Micron/MTFC4GLDEA-0M-WT/pdf.php?id=1025550
there is a PDF linked lower on that page for the 26 page data sheet).

It is SD cards that are difficult to find specifications for as makers
may keep the same "name/part" but change out the internals. eMMC, OTOH,
tend to be ordered /by/ manufacturers and they specify performance when
doing so.


-- 
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/t6hf3gd2lv6b1atfdnqc0qaep4b3foo06o%404ax.com.

[beagleboard] Re: HELP : pocketbeagle UART issue using node js

[Dennis Lee Bieber]

On Wed, 24 Feb 2021 06:33:30 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Piyush Raj ae19m009
 wrote:

>
>what is it that i need to do differently in pocketbeagle. This same code 
>works for my pocket beagle. i have also ensured that my ttyO4 is enabled.
>

Please clarify "pocketbeagle" vs "pocket beagle"? I suspect you mean
one of the beaglebone black series...

>My code is as below. any help would be highly appreciable. Thanks
>

A Google search reports a BBB showing the same message -- on
StackOverflow, three years ago -- with no answers.

No confirmed answers here either
https://groups.google.com/g/beagleboard/c/kBfn3JW2Kao
though I would suggest verifying the /boot/uEnv.txt files on the two
systems you mention, along with checking kernel version, bonescript and
node.js versions.

The message itself appears to be produced at line 462 of
https://github.com/jadonk/bonescript/blob/master/src/my.js but as I don't
"do" node.js I can't really follow that logic.


-- 
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/r0rc3ghase0mnqh6rj04adssgoe9b1eo0g%404ax.com.

[beagleboard] Re: the way to set MMC mode(8-bit transfer) and 384Mbps at BBBW

[Dennis Lee Bieber]

On Tue, 23 Feb 2021 18:30:40 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ha ppay
 wrote:

>Hi Dennis Bieber
>
>Thank you for the detailed explanation of the SD card standard (class) and 
>features.
>
>>The SanDisk Class 4 was easily 8 times faster than the Kingston Class 
>>10 for regular write, rewrite, and random write, and was also faster (if 
>>not as much) for read/reread/random read.
>We will use it as a reference when selecting an SD card. 
>It turns out that like SD cards, MMCs have completely different transfer 
>rates. 
>>https://en.wikipedia.org/wiki/MultiMediaCard#Table 
>so many version...
>Is the transfer speed of MMC completely different like SD card? 
>

I would suspect the primary factor is the on-chip /controller/ section
-- which is responsible for handling the erasure/reuse of allocation units.
There may be some effect if the flash memory itself is NAND or NOR type.

See https://www.pidramble.com/wiki/benchmarks/microsd-cards

While that site is focused on the Raspberry Pi, the benchmarks WILL run
on a Beaglebone (though one test won't run on the eMMC -- the script is
still trying to access the SD card for that test).


-- 
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/gfkb3gh4ofeijbftq6r8ade5nc8g0mgt7u%404ax.com.

[beagleboard] Re: the way to set MMC mode(8-bit transfer) and 384Mbps at BBBW

[Dennis Lee Bieber]

On Tue, 23 Feb 2021 15:40:22 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ha ppay
 wrote:

>I thought that the SDHC/MMC are type of media, and "high speed"  indicates 
>4-bit mode.

https://en.wikipedia.org/wiki/MultiMediaCard#Table
For the most part, high speed is likely any mode that is not using a single
data line (1-bit) mode. eMMC is based on an 8-bit mode, and does not
support 1-bit SPI mode. SDxx supports 1-bit (both SPI and MMC) modes, and
4-bit mode -- but does not support an 8-bit mode (not enough pins)


-- 
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/pv4b3gdbpacl4ki36kj40kacone627bpg1%404ax.com.

[beagleboard] Re: the way to set MMC mode(8-bit transfer) and 384Mbps at BBBW

[Dennis Lee Bieber]

On Mon, 22 Feb 2021 18:20:16 -0800 (PST), in
gmane.comp.hardware.beagleboard.user ha ppay
 wrote:


>For confirmation, I wrote the same image to the SD card and eMMC and 
>compared the BOOT time, and the result was that eMMC was only a few seconds 
>faster.

Not a valid test without knowing the details of the uSD card -- in
particular how many open "allocation units" the card supports. Cheaper
cards support only two AUs -- which is compatible with the non-journalling
FAT file system (one unit for current data file, one unit for maintaining
the FAT itself); using a journalling file system (ext4, say), can result in
a lot of flushing and loading of AUs (most impact for writing, but still
has some as the file system has to track directory files, map to inodes,
and from there to actual data blocks).

The cheaper Class-10 cards are especially bad at this, as the Class-10
rating was based upon streaming a single file (video) to/from a freshly
formatted card, whereas Class-2/4/6 are rated on transferring smaller files
(still image photos) to/from a fragmented file system (as if one has
deleted a few photos leaving gaps).

Repeating something I posted start of the month:

-=-=-=-

Note that "Class 10" cards are speed rated for STREAMING a single file
to/from a freshly formatted card (eg: video). "Class 2/4/6" cards are rated
for multiple small file writes with fragmentation (eg: still photo
camera with some images deleted). Also note that all such are based upon
FAT file system -- not a journaling system.

Some card makers of "Class 10" cards take advantage of this, and fit
controllers on the card that can only track TWO "open" "allocation units"
-- the FAT table, and the data file. Every time the filesystem has to open
another file (and that happens a lot with journals -- write new contents
somewhere, write metadata to journal, sometime later wipe out original
metadata, followed by writing journal metadata and deleting journal) it has
to obtain a new allocation unit -- this involves closing and flushing the
current allocation unit to the memory, finding and erasing a free
allocation unit (erase is slow, as it has to set every bit in the unit to
"1" -- writing can only toggle a "1" bit to a "0"), then copying unchanged
data that might be in an old allocation unit before writing new data to
that unit.

Better cards will support 4 to 6 simultaneous open allocation units,
meaning one can be updating multiple files in parallel without forcing
erase cycles and copying partial units around.

From a post I made last March

>From a post (of mine) on the R-Pi group... Running the "Raspberry Pi
>Dramble microSD benchmarks".
>curl
>https://raw.githubusercontent.com/geerlingguy/raspberry-pi-dramble/master/setup/benchmarks/microsd-benchmarks.sh
>>benchmark.sh
>
>"bdr-" is the "buffered disk read" from hdparm
>"dd-" are, well, "dd"
>The rest are "iozone" results.
>
>The BBB has
>   SanDisk Edge 8GB Class 4 HC I8227DTJLT009
>Not sure of the eMMC version
>The R-Pi3B+ has
>   Kingston 16GB Class 10 HC I U1 SDC10G2/16GB N0581-002.A00LF
>
>
>metric BBB (SD)RPi3B+  eMMC
>bdr-MB 21.74   21.97   hdparm did not run (tried to access SD)*
>dd-sec 89.4367 67.4917 63.8932
>dd-MB  4.7 6.2 6.6 
>write  1652250 1814
>rewrite2306237 1888
>read   637158145039
>reread 637557985038
>ranread536451383562
>ranwrite   1157234 395
>
>   The Class 4 SanDisk, in the 1GHz single-core BBB readily beat the Class
>10 Kingston in a 1.4GHz quad-core R-Pi3B+ in any meaningful test (the
>Kingston only won out on the "bdr" and "dd" test cases, and the BBB eMMC
>beat it on the "dd" test). {Note: I just reran on the SD card, and
>"write"/"rewrite" only showed 405/284, which still beats the Class 10 --
>suspect if I redid the test it might improve as the SD card may have
>remnants getting reused)

The SanDisk Class 4 was easily 8 times faster than the Kingston Class
10 for regular write, rewrite, and random write, and was also faster (if
not as much) for read/reread/random read.




-- 
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/imca3gp7nerl0e3jnv24v0qe9plosmcrjp%404ax.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Dennis Lee Bieber]

On Thu, 18 Feb 2021 08:27:48 -0800 (PST), in
gmane.comp.hardware.beagleboard.user Walter Cromer
 wrote:

>I think if I could just find how to read the clock on the PRU with C, I can 
>probably take it from here.   And of course, it needs to be giving me 
>milliseconds.  From what I read the main clock functions don't work below 
>seconds.

Have you even looked at the link I posted some hours ago? Duplicated
below.

>On Wed, 17 Feb 2021 10:45:49 -0800 (PST), in
>gmane.comp.hardware.beagleboard.user Walter Cromer
>
> wrote:
>
>>You are correct that this application does not need to know the actual real 
>>time but only the relative (elapsed) time since the subroutine began.  I'm 
>>familiar with clock_gettime but didn't think it could give me subsecond 
>>information.  I'll explore it!
>>
>
>https://www.tutorialspoint.com/c_standard_library/c_function_clock.htm
>
>   The worst you may have to handle is the wrap-around in a long-running
>program.

According to the documentation, that function returns clock TICKS
(whatever the tick rate is for the system in question). If you know the
CLOCKS_PER_SECOND you should be able to compute the clocks per
millisecond...

https://linux.die.net/man/3/clock

or use

https://linux.die.net/man/2/times

or better

https://linux.die.net/man/2/clock_gettime in which the return structure is
seconds AND NANOSECONDS


-- 
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/vsct2gpnn5bt691c6kfggvoe6p2miehf4u%404ax.com.