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

[Mark A. Yoder]

4a334000.pru
>> [  594.762821] remoteproc remoteproc1: powering up 4a334000.pru
>> [  594.763533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
>> size 11
>> [  594.777049] remoteproc remoteproc1: registered virtio0 (type 7)
>> [  594.777060] remoteproc remoteproc1: remote processor 4a334000.pru is 
>> now up
>> dmesg | grep pru
>> [   72.319951] remoteproc remoteproc1: 4a334000.pru is available
>> [   72.320135] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
>> successfully
>> [   72.335870] remoteproc remoteproc2: 4a338000.pru is available
>> [   72.336020] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
>> successfully
>> [  564.302719] remoteproc remoteproc1: powering up 4a334000.pru
>> [  564.303391] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
>> size 118908
>> [  564.304236] pruss 4a30.pruss: configured system_events[63-0] = 
>> ,0003
>> [  564.304251] pruss 4a30.pruss: configured intr_channels = 
>> 0x0005 host_intr = 0x0005
>> [  564.316324] remoteproc remoteproc1: remote processor 4a334000.pru is 
>> now up
>> [  564.391508] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 
>> 0x1e
>> [  564.467856] rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: 
>> /dev/rpmsg_pru30
>> [  590.322860] pruss 4a30.pruss: unconfigured system_events[63-0] = 
>> ,0003
>> [  590.322880] pruss 4a30.pruss: unconfigured host_intr = 0x0005
>> [  590.322924] remoteproc remoteproc1: stopped remote processor 
>> 4a334000.pru
>> [  594.762821] remoteproc remoteproc1: powering up 4a334000.pru
>> [  594.763533] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, 
>> size 11
>> [  594.764695] pruss 4a30.pruss: configured system_events[63-0] = 
>> ,0003
>> [  594.764710] pruss 4a30.pruss: configured intr_channels = 
>> 0x0005 host_intr = 0x0005
>> [  594.775769] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 
>> 0x1e
>> [  594.776757] rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: 
>> /dev/rpmsg_pru30
>> [  594.777060] remoteproc remoteproc1: remote processor 4a334000.pru is 
>> now up
>> dmesg | grep pinctrl-single
>> [0.952360] pinctrl-single 44e10800.pinmux: 142 pins, size 568
>> dmesg | grep gpio-of-helper
>> [0.965863] gpio-of-helper ocp:cape-universal: ready
>> lsusb
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> END
>>
>>
>> On Wednesday, March 13, 2019 at 10:57:39 AM UTC-4 Mark A. Yoder wrote:
>>
>>> The PRU Cookbook has an exampled of writing shared memory with the ARM.
>>>
>>>
>>> https://markayoder.github.io/PRUCookbook/05blocks/blocks.html#_controlling_the_pwm_frequency
>>>  
>>>
>>> --Mark
>>>
>>>
>>> On Tuesday, March 12, 2019 at 12:54:06 PM UTC-4, marcu...@gmail.com 
>>> wrote:
>>>>
>>>> i wrote a PRU Programm where i read some Sensors and calculate 
>>>> something. Then i save the Data in the shared RAM.
>>>>
>>>> But how can i read the memory from the ARM? is it possible to read it 
>>>> from an c programm or shell? edit: i programm the PRU with this method: 
>>>> https://markayoder.github.io/PRUCookbook/index.html
>>>>
>>>> Greetings Marcus
>>>>
>>>

-- 
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/e4e86c7b-5bee-41ea-9adc-7a952a442aden%40googlegroups.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

There is a cycle count register[1]

I'm not using wireless, so I don't know it's current status.

--Mark

[1] 
https://markayoder.github.io/PRUCookbook/07more/more.html#_using_the_built_in_counter_for_timing

On Thursday, February 18, 2021 at 12:38:24 PM UTC-5 
wal...@edenconceptsllc.com wrote:

> I'll look into the pthread tutorials.   
>
> So is there no way to just read the clock on the PRU to get elapsed time?
>
> Also,  I've booted my BBB Wireless with the SD card with the OS that you 
> recommended and the access point doesn't come up.  It doesn't appear to be 
> disabled in uEnv.txt.  Any ideas on this?
>
> Walter
>
> On Thursday, February 18, 2021 at 11:45:52 AM UTC-5 Mark A. Yoder wrote:
>
>> I use *__delay_cycles()* on the PRU to get accurate timing. Each cycle 
>> is 5 ns.  
>>
>> Here [1] is an example of passing data between the PRU and the ARM.
>>
>> Try googling *pthread tutorial,* there appear to be many examples.
>>
>> I'm still voting for pthreads.
>>
>> --Mark
>>
>> [1] 
>> https://markayoder.github.io/PRUCookbook/05blocks/blocks.html#_controlling_neopixels_through_a_kernel_driver
>>  
>>
>> On Thursday, February 18, 2021 at 11:27:48 AM UTC-5 
>> wal...@edenconceptsllc.com 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.
>>>
>>>
>>> On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder wrote:
>>>
>>>> Have you tried starting a pthread that sleeps for 20 ms and then it 
>>>> stops the read?
>>>>
>>>> On Thursday, February 18, 2021 at 10:35:04 AM UTC-5 
>>>> wal...@edenconceptsllc.com wrote:
>>>>
>>>>> Mark, 
>>>>>
>>>>> I use usleep a lot but in this case I don't want to pause.  I want to 
>>>>> keep reading the sensors for N milliseconds.   I do pause between reads 
>>>>> using usleep(2) to create a 20ms delay between sensor reads.   I 
>>>>> started with a routine that essentially counts up the amount of time by 
>>>>> estimating how long the sensor read routine takes plus the fixed delay 
>>>>> time 
>>>>> between sensor reads and accumulating this value in a while loop until it 
>>>>> reaches the 'stop value' that is approximately the time the valve needs 
>>>>> to 
>>>>> stay on.  But this is sketchy and I don't like it.  Lots could go wrong.  
>>>>>  
>>>>>
>>>>> In essence, I'm looking to interrupt the sensor read procedure after N 
>>>>> milliseconds pass.   
>>>>>
>>>>> Walter
>>>>>
>>>>>
>>>>> On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder 
>>>>> wrote:
>>>>>
>>>>>> Walter:
>>>>>>   It's good to hear you have the PRUs working.  I still think if all 
>>>>>> you need is millisecond timing the PRUs are over kill.
>>>>>>
>>>>>> In C you can use *usleep()* and pass it the number of microseconds 
>>>>>> you want to pause.
>>>>>>
>>>>>> --Mark
>>>>>> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
>>>>>> wal...@edenconceptsllc.com wrote:
>>>>>>
>>>>>>> I've gone through the cookbook and it's very helpful. 
>>>>>>>
>>>>>>> I'm still fuzzy on how to do what I need to do.  
>>>>>>>
>>>>>>> My main code for controlling the valves, getting user input, etc. is 
>>>>>>> in C.  
>>>>>>>
>>>>>>> I need to call a procedure in C that reads sensors.  I will pass 
>>>>>>> this procedure the number of milliseconds it should read the sensors 
>>>>>>> and 
>>>>>>> then return to the main program and turn the valves off.   The number 
>>>>>>> of 
>>>>>>> milliseconds can, and will likely, change depending on what we are 
>>>>>>> processing with these valves.   I get that input at the start of the 
>>>>>>> main 
>>>>>>> program.
>>>>>>>
>>>>>>> My thought is that in 

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

I use *__delay_cycles()* on the PRU to get accurate timing. Each cycle is 5 
ns.  

Here [1] is an example of passing data between the PRU and the ARM.

Try googling *pthread tutorial,* there appear to be many examples.

I'm still voting for pthreads.

--Mark

[1] 
https://markayoder.github.io/PRUCookbook/05blocks/blocks.html#_controlling_neopixels_through_a_kernel_driver
 

On Thursday, February 18, 2021 at 11:27:48 AM UTC-5 
wal...@edenconceptsllc.com 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.
>
>
> On Thursday, February 18, 2021 at 10:37:59 AM UTC-5 Mark A. Yoder wrote:
>
>> Have you tried starting a pthread that sleeps for 20 ms and then it stops 
>> the read?
>>
>> On Thursday, February 18, 2021 at 10:35:04 AM UTC-5 
>> wal...@edenconceptsllc.com wrote:
>>
>>> Mark, 
>>>
>>> I use usleep a lot but in this case I don't want to pause.  I want to 
>>> keep reading the sensors for N milliseconds.   I do pause between reads 
>>> using usleep(2) to create a 20ms delay between sensor reads.   I 
>>> started with a routine that essentially counts up the amount of time by 
>>> estimating how long the sensor read routine takes plus the fixed delay time 
>>> between sensor reads and accumulating this value in a while loop until it 
>>> reaches the 'stop value' that is approximately the time the valve needs to 
>>> stay on.  But this is sketchy and I don't like it.  Lots could go wrong.   
>>>
>>> In essence, I'm looking to interrupt the sensor read procedure after N 
>>> milliseconds pass.   
>>>
>>> Walter
>>>
>>>
>>> On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder wrote:
>>>
>>>> Walter:
>>>>   It's good to hear you have the PRUs working.  I still think if all 
>>>> you need is millisecond timing the PRUs are over kill.
>>>>
>>>> In C you can use *usleep()* and pass it the number of microseconds you 
>>>> want to pause.
>>>>
>>>> --Mark
>>>> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
>>>> wal...@edenconceptsllc.com wrote:
>>>>
>>>>> I've gone through the cookbook and it's very helpful. 
>>>>>
>>>>> I'm still fuzzy on how to do what I need to do.  
>>>>>
>>>>> My main code for controlling the valves, getting user input, etc. is 
>>>>> in C.  
>>>>>
>>>>> I need to call a procedure in C that reads sensors.  I will pass this 
>>>>> procedure the number of milliseconds it should read the sensors and then 
>>>>> return to the main program and turn the valves off.   The number of 
>>>>> milliseconds can, and will likely, change depending on what we are 
>>>>> processing with these valves.   I get that input at the start of the main 
>>>>> program.
>>>>>
>>>>> My thought is that in the procedure that reads the sensors, it will 
>>>>> grab a start time (doesn't have to be actual time) value from the PRU, 
>>>>> read 
>>>>> the sensors, and loop until the current time-start time equals the amount 
>>>>> of time it should read the sensors.  Then it will return to the main 
>>>>> program.
>>>>>
>>>>> I just don't know how to read the PRU's clock to get the time values.  
>>>>>  I don't think I saw an example in the cookbook for 'branching' out from 
>>>>> a 
>>>>> main program to use the PRUs for this type of processing.  Just point me 
>>>>> in 
>>>>> the right direction, please.
>>>>>
>>>>> Walter
>>>>>
>>>>>
>>>>> On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:
>>>>>
>>>>>> Mark ,
>>>>>>
>>>>>> It is working with the updated OS.  Thanks so much!   
>>>>>>
>>>>>> Now I will explore how to get the simple timing that I need using the 
>>>>>> PRU.
>>>>>>
>>>>>> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer 
>>>>>> wrote:
>>>>>>
>>>>>>> Mark, 
>>>>>>>
>>>>&g

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

Have you tried starting a pthread that sleeps for 20 ms and then it stops 
the read?

On Thursday, February 18, 2021 at 10:35:04 AM UTC-5 
wal...@edenconceptsllc.com wrote:

> Mark, 
>
> I use usleep a lot but in this case I don't want to pause.  I want to keep 
> reading the sensors for N milliseconds.   I do pause between reads using 
> usleep(2) to create a 20ms delay between sensor reads.   I started with 
> a routine that essentially counts up the amount of time by estimating how 
> long the sensor read routine takes plus the fixed delay time between sensor 
> reads and accumulating this value in a while loop until it reaches the 
> 'stop value' that is approximately the time the valve needs to stay on.  
> But this is sketchy and I don't like it.  Lots could go wrong.   
>
> In essence, I'm looking to interrupt the sensor read procedure after N 
> milliseconds pass.   
>
> Walter
>
>
> On Thursday, February 18, 2021 at 10:29:44 AM UTC-5 Mark A. Yoder wrote:
>
>> Walter:
>>   It's good to hear you have the PRUs working.  I still think if all you 
>> need is millisecond timing the PRUs are over kill.
>>
>> In C you can use *usleep()* and pass it the number of microseconds you 
>> want to pause.
>>
>> --Mark
>> On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
>> wal...@edenconceptsllc.com wrote:
>>
>>> I've gone through the cookbook and it's very helpful. 
>>>
>>> I'm still fuzzy on how to do what I need to do.  
>>>
>>> My main code for controlling the valves, getting user input, etc. is in 
>>> C.  
>>>
>>> I need to call a procedure in C that reads sensors.  I will pass this 
>>> procedure the number of milliseconds it should read the sensors and then 
>>> return to the main program and turn the valves off.   The number of 
>>> milliseconds can, and will likely, change depending on what we are 
>>> processing with these valves.   I get that input at the start of the main 
>>> program.
>>>
>>> My thought is that in the procedure that reads the sensors, it will grab 
>>> a start time (doesn't have to be actual time) value from the PRU, read the 
>>> sensors, and loop until the current time-start time equals the amount of 
>>> time it should read the sensors.  Then it will return to the main program.
>>>
>>> I just don't know how to read the PRU's clock to get the time values.  
>>>  I don't think I saw an example in the cookbook for 'branching' out from a 
>>> main program to use the PRUs for this type of processing.  Just point me in 
>>> the right direction, please.
>>>
>>> Walter
>>>
>>>
>>> On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:
>>>
>>>> Mark ,
>>>>
>>>> It is working with the updated OS.  Thanks so much!   
>>>>
>>>> Now I will explore how to get the simple timing that I need using the 
>>>> PRU.
>>>>
>>>> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
>>>>
>>>>> Mark, 
>>>>>
>>>>> With the current OS there isn't a /dev/remoteproc even.   
>>>>>
>>>>> I'm going to try the updated OS build this morning.  
>>>>>
>>>>> Walter
>>>>>
>>>>> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder 
>>>>> wrote:
>>>>>
>>>>>> I fired up the Beagle at home it the PRU works out of the box.
>>>>>>
>>>>>> What do you get running
>>>>>> *ls /dev/remoteproc*
>>>>>>
>>>>>> I get:
>>>>>> *ls -ls /dev/remoteproc*
>>>>>> total 0
>>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>>>>>> /sys/class/remoteproc/remoteproc1
>>>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
>>>>>> /sys/class/remoteproc/remoteproc2
>>>>>>
>>>>>> If you are missing pruss-core0 and pruss-core1 you could try adding 
>>>>>> the links by hand and see what happens.
>>>>>>
>>>>>> *cd /dev/remoteproc*
>>>>>>
>>>>>> *sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
>>>>>> *sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
>>>>>> On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
>>>>>&g

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

Walter:
  It's good to hear you have the PRUs working.  I still think if all you 
need is millisecond timing the PRUs are over kill.

In C you can use *usleep()* and pass it the number of microseconds you want 
to pause.

--Mark
On Thursday, February 18, 2021 at 10:00:10 AM UTC-5 
wal...@edenconceptsllc.com wrote:

> I've gone through the cookbook and it's very helpful. 
>
> I'm still fuzzy on how to do what I need to do.  
>
> My main code for controlling the valves, getting user input, etc. is in 
> C.  
>
> I need to call a procedure in C that reads sensors.  I will pass this 
> procedure the number of milliseconds it should read the sensors and then 
> return to the main program and turn the valves off.   The number of 
> milliseconds can, and will likely, change depending on what we are 
> processing with these valves.   I get that input at the start of the main 
> program.
>
> My thought is that in the procedure that reads the sensors, it will grab a 
> start time (doesn't have to be actual time) value from the PRU, read the 
> sensors, and loop until the current time-start time equals the amount of 
> time it should read the sensors.  Then it will return to the main program.
>
> I just don't know how to read the PRU's clock to get the time values.   I 
> don't think I saw an example in the cookbook for 'branching' out from a 
> main program to use the PRUs for this type of processing.  Just point me in 
> the right direction, please.
>
> Walter
>
>
> On Thursday, February 18, 2021 at 9:27:34 AM UTC-5 Walter Cromer wrote:
>
>> Mark ,
>>
>> It is working with the updated OS.  Thanks so much!   
>>
>> Now I will explore how to get the simple timing that I need using the PRU.
>>
>> On Thursday, February 18, 2021 at 8:54:10 AM UTC-5 Walter Cromer wrote:
>>
>>> Mark, 
>>>
>>> With the current OS there isn't a /dev/remoteproc even.   
>>>
>>> I'm going to try the updated OS build this morning.  
>>>
>>> Walter
>>>
>>> On Wednesday, February 17, 2021 at 5:34:37 PM UTC-5 Mark A. Yoder wrote:
>>>
>>>> I fired up the Beagle at home it the PRU works out of the box.
>>>>
>>>> What do you get running
>>>> *ls /dev/remoteproc*
>>>>
>>>> I get:
>>>> *ls -ls /dev/remoteproc*
>>>> total 0
>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
>>>> /sys/class/remoteproc/remoteproc1
>>>> 0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
>>>> /sys/class/remoteproc/remoteproc2
>>>>
>>>> If you are missing pruss-core0 and pruss-core1 you could try adding the 
>>>> links by hand and see what happens.
>>>>
>>>> *cd /dev/remoteproc*
>>>>
>>>> *sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
>>>> *sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
>>>> On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
>>>> wal...@edenconceptsllc.com wrote:
>>>>
>>>>> I'll get this one onto an SD card and give it a try.   If I can just 
>>>>> get this configured I think I can make quick work of this problem!  
>>>>>
>>>>> On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder 
>>>>> wrote:
>>>>>
>>>>>> Good point, it should work  I'm running a newer test image[1], 
>>>>>> but I took my Beagle home so I can't do a quick check on it until later.
>>>>>>
>>>>>>
>>>>>> --Mark
>>>>>> [1]
>>>>>> https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
>>>>>>  
>>>>>>
>>>>>> On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
>>>>>> wal...@edenconceptsllc.com wrote:
>>>>>>
>>>>>>> I asked because the ones on the page @ the link are older than the 
>>>>>>> one I have installed.
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On newer versions of the SD card image /var/lib/cloud9 is a git 
>>>>>>>> repo which you can do a git pull to update.  Your version is too old.
>>>>>>>>
>>>>>>>> Follow the instructions at: 
>>

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

I fired up the Beagle at home it the PRU works out of the box.

What do you get running
*ls /dev/remoteproc*

I get:
*ls -ls /dev/remoteproc*
total 0
0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core0 -> 
/sys/class/remoteproc/remoteproc1
0 lrwxrwxrwx 1 root root 33 Feb 17 17:26 pruss-core1 -> 
/sys/class/remoteproc/remoteproc2

If you are missing pruss-core0 and pruss-core1 you could try adding the 
links by hand and see what happens.

*cd /dev/remoteproc*

*sudo ln -s /sys/class/remoteproc/remoteproc1 pruss-core0*
*sudo ln -s /sys/class/remoteproc/remoteproc2 pruss-core1*
On Wednesday, February 17, 2021 at 3:56:21 PM UTC-5 
wal...@edenconceptsllc.com wrote:

> I'll get this one onto an SD card and give it a try.   If I can just get 
> this configured I think I can make quick work of this problem!  
>
> On Wednesday, February 17, 2021 at 3:47:04 PM UTC-5 Mark A. Yoder wrote:
>
>> Good point, it should work  I'm running a newer test image[1], but I 
>> took my Beagle home so I can't do a quick check on it until later.
>>
>>
>> --Mark
>> [1]
>> https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
>>  
>>
>> On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
>> wal...@edenconceptsllc.com wrote:
>>
>>> I asked because the ones on the page @ the link are older than the one I 
>>> have installed.
>>>
>>>
>>> On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:
>>>
>>>> On newer versions of the SD card image /var/lib/cloud9 is a git repo 
>>>> which you can do a git pull to update.  Your version is too old.
>>>>
>>>> Follow the instructions at: 
>>>> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>>>>  
>>>> to download and install an updated version of the SD card image.
>>>>
>>>> --Mark
>>>>
>>>> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
>>>> wal...@edenconceptsllc.com wrote:
>>>>
>>>>> Mark, 
>>>>>
>>>>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository 
>>>>> (or any of the parent directories): .git 
>>>>>
>>>>> I'm such a neophyte on git.  What do I need to do?
>>>>>
>>>>> And, what do you mean by updating to a new version of the SD card? The 
>>>>> OS is booting from the SD card and the version.sh information posted 
>>>>> earlier is based on that.
>>>>>
>>>>>
>>>>> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder 
>>>>> wrote:
>>>>>
>>>>>> I suggest updating to a new version of the SD card.  It looks like 
>>>>>> the PRUs are getting started at boot time, but the path isn't setup 
>>>>>> right. 
>>>>>> I think we setup some links so the path* 
>>>>>> /dev/remoteproc/pruss-core0/state  
>>>>>> *points to the right place.
>>>>>>
>>>>>> You could also try:
>>>>>> *cd */var/lib/cloud9
>>>>>> *git* pull
>>>>>> to update cloud9 folders.
>>>>>>
>>>>>> --Mark
>>>>>>
>>>>>> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
>>>>>> wal...@edenconceptsllc.com wrote:
>>>>>>
>>>>>>> Mark, 
>>>>>>>
>>>>>>> I got the latest PRUCookbook downloaded and when trying to make the 
>>>>>>> hello.pru0.c program in 1.6, I got this error.  
>>>>>>>
>>>>>>> *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ 
>>>>>>> make TARGET=hello.pru0*
>>>>>>> */var/lib/cloud9/common/Makefile:29: 
>>>>>>> MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
>>>>>>> *-Stopping PRU 0*
>>>>>>> */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: 
>>>>>>> Directory nonexistent*
>>>>>>> *Cannot stop 0*
>>>>>>> *CC  hello.pru0.c*
>>>>>>> *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: 
>>>>>>> #warning directive: "Found am335x"*
>>>>>>> *LD  /tmp/cloud9-examples/hello.pru0.o*
>>>>>>> *-   c

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

Good point, it should work  I'm running a newer test image[1], but I 
took my Beagle home so I can't do a quick check on it until later.


--Mark
[1]https://rcn-ee.com/rootfs/bb.org/testing/2021-02-15/buster-iot/bone-debian-10.8-iot-armhf-2021-02-15-4gb.img.xz
 

On Wednesday, February 17, 2021 at 2:46:35 PM UTC-5 
wal...@edenconceptsllc.com wrote:

> I asked because the ones on the page @ the link are older than the one I 
> have installed.
>
>
> On Wednesday, February 17, 2021 at 2:30:58 PM UTC-5 Mark A. Yoder wrote:
>
>> On newer versions of the SD card image /var/lib/cloud9 is a git repo 
>> which you can do a git pull to update.  Your version is too old.
>>
>> Follow the instructions at: 
>> https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
>>  
>> to download and install an updated version of the SD card image.
>>
>> --Mark
>>
>> On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
>> wal...@edenconceptsllc.com wrote:
>>
>>> Mark, 
>>>
>>> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or 
>>> any of the parent directories): .git 
>>>
>>> I'm such a neophyte on git.  What do I need to do?
>>>
>>> And, what do you mean by updating to a new version of the SD card? The 
>>> OS is booting from the SD card and the version.sh information posted 
>>> earlier is based on that.
>>>
>>>
>>> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder wrote:
>>>
>>>> I suggest updating to a new version of the SD card.  It looks like the 
>>>> PRUs are getting started at boot time, but the path isn't setup right. I 
>>>> think we setup some links so the path* /dev/remoteproc/pruss-core0/state  
>>>> *points to the right place.
>>>>
>>>> You could also try:
>>>> *cd */var/lib/cloud9
>>>> *git* pull
>>>> to update cloud9 folders.
>>>>
>>>> --Mark
>>>>
>>>> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
>>>> wal...@edenconceptsllc.com wrote:
>>>>
>>>>> Mark, 
>>>>>
>>>>> I got the latest PRUCookbook downloaded and when trying to make the 
>>>>> hello.pru0.c program in 1.6, I got this error.  
>>>>>
>>>>> *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make 
>>>>> TARGET=hello.pru0*
>>>>> */var/lib/cloud9/common/Makefile:29: 
>>>>> MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
>>>>> *-Stopping PRU 0*
>>>>> */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: 
>>>>> Directory nonexistent*
>>>>> *Cannot stop 0*
>>>>> *CC  hello.pru0.c*
>>>>> *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: 
>>>>> #warning directive: "Found am335x"*
>>>>> *LD  /tmp/cloud9-examples/hello.pru0.o*
>>>>> *-   copying firmware file /tmp/cloud9-examples/hello.pru0.out to 
>>>>> /lib/firmware/am335x-pru0-fw*
>>>>> *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': 
>>>>> Permission denied*
>>>>> */var/lib/cloud9/common/Makefile:180: recipe for target 'install' 
>>>>> failed*
>>>>> *make: *** [install] Error 1*
>>>>> *rm /tmp/cloud9-examples/hello.pru0.o*
>>>>>
>>>>>  Initially, I did not have a folder called /var/lib/cloud9/common.  To 
>>>>> remedy this I copied the contents of 
>>>>> /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  Maybe 
>>>>> this created a problem?Nevertheless,  I found some other discussions that 
>>>>> suggested updating the scripts and kernels from 
>>>>> beagleboard.org/upgrade which I did.  I am now running...
>>>>>
>>>>> Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 
>>>>> 01:48:39 UTC 2020 armv7l GNU/Linux
>>>>>
>>>>> And the output of version.sh is 
>>>>>
>>>>> *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
>>>>> *[sudo] password for debian:*
>>>>> *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
>>>>> *eeprom:[A335BNLT00C04417BBBK1847]*
>>>>> *model:[TI_AM335x_BeagleBone_Black]*
>>>>> *dogtag:[BeagleBoard

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

On newer versions of the SD card image /var/lib/cloud9 is a git repo which 
you can do a git pull to update.  Your version is too old.

Follow the instructions 
at: 
https://markayoder.github.io/PRUCookbook/02start/start.html#_installing_the_latest_os_on_your_bone
 
to download and install an updated version of the SD card image.

--Mark

On Wednesday, February 17, 2021 at 2:25:40 PM UTC-5 
wal...@edenconceptsllc.com wrote:

> Mark, 
>
> git pull on /var/lib/cloud9 fails with 'fatal: Not a git repository (or 
> any of the parent directories): .git 
>
> I'm such a neophyte on git.  What do I need to do?
>
> And, what do you mean by updating to a new version of the SD card? The OS 
> is booting from the SD card and the version.sh information posted earlier 
> is based on that.
>
>
> On Wednesday, February 17, 2021 at 2:02:55 PM UTC-5 Mark A. Yoder wrote:
>
>> I suggest updating to a new version of the SD card.  It looks like the 
>> PRUs are getting started at boot time, but the path isn't setup right. I 
>> think we setup some links so the path* /dev/remoteproc/pruss-core0/state  
>> *points to the right place.
>>
>> You could also try:
>> *cd */var/lib/cloud9
>> *git* pull
>> to update cloud9 folders.
>>
>> --Mark
>>
>> On Wednesday, February 17, 2021 at 1:53:35 PM UTC-5 
>> wal...@edenconceptsllc.com wrote:
>>
>>> Mark, 
>>>
>>> I got the latest PRUCookbook downloaded and when trying to make the 
>>> hello.pru0.c program in 1.6, I got this error.  
>>>
>>> *debian@beaglebone:/var/lib/cloud9/PRUCookbook/docs/02start/code$ make 
>>> TARGET=hello.pru0*
>>> */var/lib/cloud9/common/Makefile:29: 
>>> MODEL=TI_AM335x_BeagleBone_Black,TARGET=hello.pru0*
>>> *-Stopping PRU 0*
>>> */bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory 
>>> nonexistent*
>>> *Cannot stop 0*
>>> *CC  hello.pru0.c*
>>> *"/var/lib/cloud9/common/prugpio.h", line 53: warning #1181-D: #warning 
>>> directive: "Found am335x"*
>>> *LD  /tmp/cloud9-examples/hello.pru0.o*
>>> *-   copying firmware file /tmp/cloud9-examples/hello.pru0.out to 
>>> /lib/firmware/am335x-pru0-fw*
>>> *cp: cannot create regular file '/lib/firmware/am335x-pru0-fw': 
>>> Permission denied*
>>> */var/lib/cloud9/common/Makefile:180: recipe for target 'install' failed*
>>> *make: *** [install] Error 1*
>>> *rm /tmp/cloud9-examples/hello.pru0.o*
>>>
>>>  Initially, I did not have a folder called /var/lib/cloud9/common.  To 
>>> remedy this I copied the contents of 
>>> /var/lib/cloud9/PRUCookbook/docs/common to /var/lib/cloud9/common.  Maybe 
>>> this created a problem?Nevertheless,  I found some other discussions that 
>>> suggested updating the scripts and kernels from beagleboard.org/upgrade 
>>> which I did.  I am now running...
>>>
>>> Linux beaglebone 4.14.108-ti-r137 #1stretch SMP PREEMPT Tue Aug 25 
>>> 01:48:39 UTC 2020 armv7l GNU/Linux
>>>
>>> And the output of version.sh is 
>>>
>>> *debian@beaglebone:/$ sudo opt/scripts/tools/version.sh*
>>> *[sudo] password for debian:*
>>> *git:/opt/scripts/:[e4e4854ef8ff9ada5c85553376043ee7679167ca]*
>>> *eeprom:[A335BNLT00C04417BBBK1847]*
>>> *model:[TI_AM335x_BeagleBone_Black]*
>>> *dogtag:[BeagleBoard.org Debian Image 2018-10-07]*
>>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 
>>> 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)]:[location: dd 
>>> MBR]*
>>> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>> 2018.09-2-g0b54a51eee]:[location: dd MBR]*
>>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 
>>> 2018.03-2-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd 
>>> MBR]*
>>> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
>>> 2018.03-2-gac9cce7c6a]:[location: dd MBR]*
>>> *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
>>> *kernel:[4.14.108-ti-r137]*
>>> *nodejs:[v6.14.4]*
>>> */boot/uEnv.txt Settings:*
>>> *uboot_overlay_options:[enable_uboot_overlays=1]*
>>>
>>> *uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo]*
>>> *uboot_overlay_options:[disable_uboot_overlay_video=1]*
>>>
>>> *uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]*
>>> *uboot_overlay_options:[enable_uboot_cape_universal=1]*
>>&

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

eproc remoteproc1: 4a334000.pru is available*
> *[  108.634642] pru-rproc 4a334000.pru: PRU rproc node 
> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@34000 probed successfully*
> *[  108.656634] remoteproc remoteproc2: 4a338000.pru is available*
> *[  108.656808] pru-rproc 4a338000.pru: PRU rproc node 
> /ocp/pruss_soc_bus@4a326004/pruss@0/pru@38000 probed successfully*
> *dmesg | grep pinctrl-single*
> *[0.783913] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568*
> *dmesg | grep gpio-of-helper*
> *[0.796624] gpio-of-helper ocp:cape-universal: ready*
> *lsusb*
> *Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub*
> *END*
>
> Any ideas?
>
> On Wednesday, February 17, 2021 at 10:10:53 AM UTC-5 Mark A. Yoder wrote:
>
>> The PRUs can give you 10's of ns timing, which is more than good enough 
>> for milliseconds, but might be over kill.
>>
>> I'd think using C on the ARM processor should be fast enough.  I'd use 
>> gpiod[1].
>>
>> If you really want the ns timing of the PRUs, check out the PRU 
>> Cookbook[2]
>>
>> --Mark
>>
>> [1] https://github.com/starnight/libgpiod-example
>> [2] https://github.com/MarkAYoder/PRUCookbook
>>
>> On Tuesday, February 16, 2021 at 10:51:11 AM UTC-5 pierric...@gadz.org 
>> wrote:
>>
>>> Depending on how precise you need to be, I would go for the PRU-ICSS. 
>>> They can control the GPIOs pretty easily. 
>>>
>>> Le mardi 16 février 2021 à 10:03:47 UTC-5, wal...@edenconceptsllc.com a 
>>> écrit :
>>>
>>>> I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP 
>>>> PREEMPT Fri May 24 22:12:34 UTC 2019 armv7l GNU/Linux
>>>>
>>>> I am writing in C.
>>>>
>>>> I turn a valve on and then need to read some sensors for N milliseconds 
>>>> and then turn the valve off.
>>>>
>>>> What's the best way to read milliseconds on the BBBw?  I don't have a 
>>>> RTC on this particular unit but could add one using I2C.  I have an 
>>>> Adafruit 4282 with a DS3231 RTC on it on another BBBw that I could use 
>>>> temporarily to prove it works.  What other options are available?
>>>>
>>>>
>>>>

-- 
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/d21960fc-c959-4d86-9847-8fd8e5fdf010n%40googlegroups.com.

[beagleboard] Re: Best way to get elapsed milliseconds

[Mark A. Yoder]

The PRUs can give you 10's of ns timing, which is more than good enough for 
milliseconds, but might be over kill.

I'd think using C on the ARM processor should be fast enough.  I'd use 
gpiod[1].

If you really want the ns timing of the PRUs, check out the PRU Cookbook[2]

--Mark

[1] https://github.com/starnight/libgpiod-example
[2] https://github.com/MarkAYoder/PRUCookbook

On Tuesday, February 16, 2021 at 10:51:11 AM UTC-5 pierric...@gadz.org 
wrote:

> Depending on how precise you need to be, I would go for the PRU-ICSS. They 
> can control the GPIOs pretty easily. 
>
> Le mardi 16 février 2021 à 10:03:47 UTC-5, wal...@edenconceptsllc.com a 
> écrit :
>
>> I have a BBB Wireless running Linux beaglebone 4.14.108-ti-r106 #1 SMP 
>> PREEMPT Fri May 24 22:12:34 UTC 2019 armv7l GNU/Linux
>>
>> I am writing in C.
>>
>> I turn a valve on and then need to read some sensors for N milliseconds 
>> and then turn the valve off.
>>
>> What's the best way to read milliseconds on the BBBw?  I don't have a RTC 
>> on this particular unit but could add one using I2C.  I have an Adafruit 
>> 4282 with a DS3231 RTC on it on another BBBw that I could use temporarily 
>> to prove it works.  What other options are available?
>>
>>
>>

-- 
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/3d57e46f-1a11-4635-9150-4fefaf3e76edn%40googlegroups.com.

[beagleboard] Re: A novice for help! PRU __R30 GPO toggle.

[Mark A. Yoder]

Have you run* config-pin *to make sure the pin in muxed to pruout?

Have you seen the PRU Cookbook ?  
It has lots of examples that could help.

--Mark

On Thursday, February 4, 2021 at 7:56:42 AM UTC-5 
che...@robotics-robotics.com wrote:

> Hi,
>
> I'm a beginner in BeagleBoard-X15. I'm using the beagleboard PRU and i 
> want to debug the PRU gpio which using the CCS and the JTAG. I learned that 
> PRU can directly control GPIO through __R30. I found out from the schematic 
> diagram that the pin GPIO3_7 of P19 on Beagleboard-X15 is PR1_PRU0_GPO0. I 
> want to output Toggle level directly through __R30 and then observe it 
> through oscilloscope but it is doesn't work.I don't know what to do next.
> Here is my code :
>  
> [image: PRU.png]
>

-- 
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/d53ca9b0-b493-485e-a0bf-6b74d125f685n%40googlegroups.com.

Re: [beagleboard] Help to mate a GUI

[Mark A. Yoder]

That has an HDMI interface, so it should show up as a frame buffer.  I have 
some examples of using pygame to display some text and an analog clock[1] 
on a frame buffer.

--Mark

[1] 
https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/displays/ili9341/pygame

On Friday, January 22, 2021 at 3:37:20 AM UTC-5 yako...@gmail.com wrote:

>
> I have the 4dcape-50ct-cbl screen and I want to show some indicators as 
> meters so that the user can view information from some sensors
>
> El jue., 21 de ene. de 2021 1:49 p. m., jonnymo  
> escribió:
>
>> Could you be a bit more specific with what you are looking for?
>> Will this be with a display or headless?
>>
>> With Display, something like PyGame, Qt, Gtk, Tkinter, wxPython and many 
>> others.
>>
>> Headless, something like Flask or Bonescript(NodeJS) would allow you to 
>> get a webserver based gui using a python or javascript backend.
>>
>> Jon 
>>
>> On Thu, Jan 21, 2021 at 10:39 AM ciriaco ortiz carrasco <
>> yako...@gmail.com> wrote:
>>
>>> someone knows how to make a little GUI using beaglebone black
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/CAD5%3DEfQ3E2bgsohvz6N_dDsQ39Gt%2BZ_Q3fu2tk8BDRwc2vmyNQ%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAG99bkq_RNKHFtaUQkaLGQ6Oqhpq%2B8wj_C6ykqFi4RG5YZsdBg%40mail.gmail.com
>>  
>> 
>> .
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b23d5d97-6747-4018-b24f-1b6967bdcf51n%40googlegroups.com.

Re: [beagleboard] Adding a SPI-based SD card reader

[Mark A. Yoder]

It's running a pygame-based weather app right now.  
Details:  https://elinux.org/EBC_Exercise_12a_2.4_TFT_LCD_display_via_SPI

--Mark

On Monday, December 14, 2020 at 7:24:24 PM UTC-5 Calvin Slater wrote:

> Have you got the screen up and running? 
>
> If so, what driver/library did you use?
>
> On Mon, 14 Dec 2020 at 16:15, Mark A. Yoder  wrote:
>
>> It's an ili9341.
>>
>> --Mark
>>
>> On Monday, December 14, 2020 at 6:53:45 PM UTC-5 Calvin Slater wrote:
>>
>>> Hi Mark,
>>>
>>> What model of TFT screen is this? Specifically what chip is used for the 
>>> LCD driver?
>>>
>>>
>>> On Thu, 29 Oct 2020 at 08:25, Mark A. Yoder  wrote:
>>>
>>>> I have a 2.4" TFT LCD display that also has a SPI-based SD card reader 
>>>> on it.  I'd like to interface it to my BeagleBone Black.  I see there's a 
>>>> Pocket Beagle device tree[1] for a SPI-based micro sd on a click board.  
>>>>
>>>> Could this project be as easy as editing this dt to change it to the 
>>>> BBB's SPI bus?  What am I missing?
>>>>
>>>> --Mark
>>>>
>>>> [1] 
>>>> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-SPI0-MICROSD-CLICK.dts
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/beagleboard/b3806a43-92a6-4c84-a75a-695920999404n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/b3806a43-92a6-4c84-a75a-695920999404n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/b66d82e9-0817-4159-af57-a09a3f3f378fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/b66d82e9-0817-4159-af57-a09a3f3f378fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/ef3d5776-1975-432b-9033-4b98b2d91675n%40googlegroups.com.

Re: [beagleboard] Adding a SPI-based SD card reader

[Mark A. Yoder]

It's an ili9341.

--Mark

On Monday, December 14, 2020 at 6:53:45 PM UTC-5 Calvin Slater wrote:

> Hi Mark,
>
> What model of TFT screen is this? Specifically what chip is used for the 
> LCD driver?
>
>
> On Thu, 29 Oct 2020 at 08:25, Mark A. Yoder  wrote:
>
>> I have a 2.4" TFT LCD display that also has a SPI-based SD card reader on 
>> it.  I'd like to interface it to my BeagleBone Black.  I see there's a 
>> Pocket Beagle device tree[1] for a SPI-based micro sd on a click board.  
>>
>> Could this project be as easy as editing this dt to change it to the 
>> BBB's SPI bus?  What am I missing?
>>
>> --Mark
>>
>> [1] 
>> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-SPI0-MICROSD-CLICK.dts
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/b3806a43-92a6-4c84-a75a-695920999404n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/b3806a43-92a6-4c84-a75a-695920999404n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/b66d82e9-0817-4159-af57-a09a3f3f378fn%40googlegroups.com.

Re: [beagleboard] Latest kernel supported on beaglebone black.

[Mark A. Yoder]

If you have the bone running try:
bone$ */opt/scripts/tools*
bone$ *sudo ./update_kernel.sh --bone-kernel*
[sudo] password for debian: 
info: checking archive
2020-11-30 14:53:46 
URL:https://rcn-ee.com/repos/latest/buster-armhf/LATEST-omap-psp [254/254] 
-> "LATEST-omap-psp" [1]
-
Kernel Options:
ABI:1 LTS44 4.4.145-bone23
ABI:1 LTS49 4.9.178-bone15
ABI:1 LTS414 4.14.198-bone40
ABI:1 LTS419 4.19.142-bone56
ABI:1 LTS54 5.4.70-bone38
ABI:1 LTS510 5.10.0-rc5-bone4
ABI:1 STABLE 5.8.18-bone23
ABI:1 TESTING 5.9.1-bone12
ABI:1 EXPERIMENTAL 5.9.1-bone10
-
Kernel version options:
-
LTS414: --lts-4_14
LTS419: --lts-4_19
LTS54: --lts-5_4
STABLE: --stable
TESTING: --testing
-
Please pass one of the above kernel options to update_kernel.sh

Looks like 5.8 or 5.9 should work.

--Mark
On Monday, November 30, 2020 at 5:17:47 AM UTC-5 atiqu...@gmail.com wrote:

> Build Info with latest supported kernel version
> https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone
>
> On Mon, Nov 30, 2020 at 8:17 PM Rajesh Kumbhakar  
> wrote:
>
>> Hello everyone, I am new to beaglebone. I want to know what is the latest 
>> kernel version supported on beaglebone black, and where to find the source 
>> tree for it? Furthermore is there any place where I can keep track of it 
>> beagleboard.org doesn't has no info about it (maybe I am wrong sorry!).
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/f7ad9b99-fa5a-467d-8436-9015c2f8e835n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Regards,
> Atique u Rehman
>

-- 
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/67eb0100-4c99-497a-8a80-49bdb79655a2n%40googlegroups.com.

[beagleboard] Re: [Solved] ADAFRUIT 2.4" LCD on SPI0

[Mark A. Yoder]

It turns out P9_19 and P9_20 default to i2c.  I changed the .dts file to 
set them to gpio and the display works on SPI0.

--Mark

On Tuesday, November 3, 2020 at 5:17:18 PM UTC-5 Mark A. Yoder wrote:

> I have an ADAFRUIT 3.4" LCD display that works on SPI1 using [1].  When 
> switching it to SPI0 and [2] I get the following error.
>
> [  +0.064441] omap2_mcspi 4803.spi: chipselect 0 already in use
> [  +0.006268] spi_master spi0: spi_device register error 
> /ocp/spi@4803/channel@0
> [  +0.007651] spi_master spi0: Failed to create SPI device for 
> /ocp/spi@4803/channel@0
>
> Any ideas what's up?  The backlight works, but the LCD doesn't display 
> anything.
>
> [1] 
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-LCD-ADAFRUIT-24-SPI1-00A0.dts
>
> [2] 
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-LCD-ADAFRUIT-24-SPI0-00A0.dts
>
> sudo /opt/scripts/tools/version.sh 
> [sudo] password for debian: 
> git:/opt/scripts/:[ef16ffa8c27225005cc2b2c974a83da3dee6c1ef]
> eeprom:[A335BNLT0A5A1513BBBK3586]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-08-31]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-gc9b3922522]:[location: dd MBR]
> UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
> UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
> UBOOT: Loaded Overlay:[BB-ADC-00A0]
> UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
> UBOOT: Loaded Overlay:[BB-LCD-ADAFRUIT-24-SPI0-00A0]
> kernel:[4.19.94-ti-r50]
> nodejs:[v10.21.0]
> /boot/uEnv.txt Settings:
> uboot_overlay_options:[enable_uboot_overlays=1]
>
> uboot_overlay_options:[uboot_overlay_addr4=BB-LCD-ADAFRUIT-24-SPI0-00A0.dtbo]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
>
> uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.14.20200814.0-0~buster+20200814]
> pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
> pkg:[kmod]:[26-1]
> pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
> pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
> groups:[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]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
> dmesg | grep remote
> [   64.629243] remoteproc remoteproc0: wkup_m3 is available
> [   64.647970] remoteproc remoteproc0: powering up wkup_m3
> [   64.648005] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
> [   64.648293] remoteproc remoteproc0: remote processor wkup_m3 is now up
> [   66.850264] remoteproc remoteproc1: 4a334000.pru is available
> [   66.866379] remoteproc remoteproc2: 4a338000.pru is available
> dmesg | grep pru
> [   66.850264] remoteproc remoteproc1: 4a334000.pru is available
> [   66.851362] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
> successfully
> [   66.866379] remoteproc remoteproc2: 4a338000.pru is available
> [   66.866574] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
> successfully
> dmesg | grep pinctrl-single
> [0.926234] pinctrl-single 44e10800.pinmux: 142 pins, size 568
> dmesg | grep gpio-of-helper
> [0.939877] gpio-of-helper ocp:cape-universal: ready
> lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> END
>

-- 
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/e19866fe-bae8-4aee-8c21-671b29f64d4an%40googlegroups.com.

[beagleboard] ADAFRUIT 2.4" LCD on SPI0

[Mark A. Yoder]

I have an ADAFRUIT 3.4" LCD display that works on SPI1 using [1].  When 
switching it to SPI0 and [2] I get the following error.

[  +0.064441] omap2_mcspi 4803.spi: chipselect 0 already in use
[  +0.006268] spi_master spi0: spi_device register error 
/ocp/spi@4803/channel@0
[  +0.007651] spi_master spi0: Failed to create SPI device for 
/ocp/spi@4803/channel@0

Any ideas what's up?  The backlight works, but the LCD doesn't display 
anything.

[1] 
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-LCD-ADAFRUIT-24-SPI1-00A0.dts

[2] 
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-LCD-ADAFRUIT-24-SPI0-00A0.dts

sudo /opt/scripts/tools/version.sh 
[sudo] password for debian: 
git:/opt/scripts/:[ef16ffa8c27225005cc2b2c974a83da3dee6c1ef]
eeprom:[A335BNLT0A5A1513BBBK3586]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-08-31]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-gc9b3922522]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-LCD-ADAFRUIT-24-SPI0-00A0]
kernel:[4.19.94-ti-r50]
nodejs:[v10.21.0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=BB-LCD-ADAFRUIT-24-SPI0-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20200814.0-0~buster+20200814]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[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]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   64.629243] remoteproc remoteproc0: wkup_m3 is available
[   64.647970] remoteproc remoteproc0: powering up wkup_m3
[   64.648005] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[   64.648293] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   66.850264] remoteproc remoteproc1: 4a334000.pru is available
[   66.866379] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[   66.850264] remoteproc remoteproc1: 4a334000.pru is available
[   66.851362] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
successfully
[   66.866379] remoteproc remoteproc2: 4a338000.pru is available
[   66.866574] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
successfully
dmesg | grep pinctrl-single
[0.926234] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[0.939877] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

-- 
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/456eb6ad-24a8-4e3e-9089-ce986012b21an%40googlegroups.com.

[beagleboard] Re: Interfacing a 16x2 char HD44780 LCD display

[Mark A. Yoder]

Thanks to all for following up on this.  

amf:  What device tree are you using?

--Mark

On Tuesday, November 3, 2020 at 10:26:52 AM UTC-5 amf wrote:

> Just wanting to follow up on this. The LCD display is working, just had to 
> remove the R/W parameter from the dts and tie the LCD R/W to ground. The 
> driver does not seem to support reading from the display, so no harm in 
> doing it this way.
>
> amf
>
> On Monday, November 2, 2020 at 6:56:25 PM UTC-6 amf wrote:
>
>> Hi Mark
>> Seen RCN's response below. I have several of the *hd44780 LCD displays 
>> also, *spent the weekend trying to get it to work with the info RCN 
>> provided. Seems the R/W line is always high, thus all the data signals are 
>> distorted. If I pull the R/W line low, then the data signals are ok, but 
>> nothing is written to the display. I know the displays are good, I wrote a 
>> uart-to-parallel with an atmel chip several years ago. if you have success 
>> with the Linux driver, I would like to know. 
>> amf
>>
>> On Thursday, October 29, 2020 at 1:39:54 PM UTC-5 Mark A. Yoder wrote:
>>
>>> I've just recently discovered I have access to lots of 16x2 LCD displays.
>>>
>>> I see there are many examples of interfacing it to a Linux machine, but 
>>> most are via user space.  I'm looking for kernel space examples.  *modinfo 
>>> hd44780* shows a driver is there, but how do I use it.  
>>>
>>> Is there a device tree for the hd44780 for a parallel interface?
>>>
>>> --Mark
>>>
>>

-- 
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/50ae8317-09d2-46f7-8113-e32a489fef23n%40googlegroups.com.

[beagleboard] Interfacing a 16x2 char HD44780 LCD display

[Mark A. Yoder]

I've just recently discovered I have access to lots of 16x2 LCD displays.

I see there are many examples of interfacing it to a Linux machine, but 
most are via user space.  I'm looking for kernel space examples.  *modinfo 
hd44780* shows a driver is there, but how do I use it.  

Is there a device tree for the hd44780 for a parallel interface?

--Mark

-- 
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/691add1c-90ad-4702-a2de-c8ec7ce4f9bcn%40googlegroups.com.

[beagleboard] Logging Data in Google Sheets

[Mark A. Yoder]

I just updated my instructions for how to log data on the Bone to Google 
Sheets.

Enjoy.

https://elinux.org/EBC_Exercise_37_Logging_to_Sheets

--Mark

-- 
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/bb711e75-975b-439a-9dbe-b509b6648197n%40googlegroups.com.

[beagleboard] Adding a SPI-based SD card reader

[Mark A. Yoder]

I have a 2.4" TFT LCD display that also has a SPI-based SD card reader on 
it.  I'd like to interface it to my BeagleBone Black.  I see there's a 
Pocket Beagle device tree[1] for a SPI-based micro sd on a click board.  

Could this project be as easy as editing this dt to change it to the BBB's 
SPI bus?  What am I missing?

--Mark

[1] 
https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/PB-SPI0-MICROSD-CLICK.dts

-- 
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/b3806a43-92a6-4c84-a75a-695920999404n%40googlegroups.com.

[beagleboard] Selecting which glibc to use

[Mark A. Yoder]

I've cross compiled busybox and when I run it on the bone I get:
./busybox.dynamic: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.29' 
not found (required by ./busybox.dynamic)

So, two questions:
When cross compiling, how do I get it to compile against glic 2.28?

How do I install glic 2.29 on my Bone?

--Mark

-- 
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/7d30c709-1b4b-48ec-a8dc-79b1809cce2dn%40googlegroups.com.

[beagleboard] Re: /dev/remoteproc/pruss-core0/state not found

[Mark A. Yoder]

*sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=1*  solved the problem. 

On Friday, October 16, 2020 at 4:58:57 PM UTC-4 emil...@gmail.com wrote:

> I'm trying to run the pru examples in /var/lib/cloud9 and I am getting 
> this error message. Anyone have any suggestions?
>
> Started /var/lib/cloud9/: neopixelDynamic.pru0.c
> File path: /var/lib/cloud9/BeagleBone/Black/pru
> File: /var/lib/cloud9/BeagleBone/Black/pru/neopixelDynamic.pru0.c
> Arguments: 
> File name: neopixelDynamic.pru0.c
> File extension: c
> File base name: neopixelDynamic.pru0
> Packages: ~.c9/packages
> Project path: /var/lib/cloud9/
> Project name: projectname
> Hostname: localhost
> Hostname path: 
> https://undefined/BeagleBone/Black/pru/neopixelDynamic.pru0.c
> URL: http://localhost
> Port: 8080
> IP: 0.0.0.0
> Command: BeagleBone/Black/pru/neopixelDynamic.pru0.c
> Python: python3
> Python path: 
> /usr/lib/python3.7/dist-packages:/usr/local/lib/python3.7/dist-packages
> /var/lib/cloud9/common/Makefile:27: 
> MODEL=TI_AM335x_BeagleBone_Black,TARGET=neopixelDynamic.pru0,COMMON=/var/lib/cloud9/common
> /var/lib/cloud9/common/Makefile:146: 
> GEN_DIR=/tmp/cloud9-examples,CHIP=am335x,PROC=pru,PRUN=0,PRU_DIR=/dev/remoteproc/pruss-core0,EXE=.out
> -Stopping PRU 0
> /bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory 
> nonexistent
> Cannot stop 0
> CC  neopixelDynamic.pru0.c
> "/var/lib/cloud9/common/prugpio.h", line 55: warning #1181-D: #warning 
> directive: "Found am335x"
> LD  /tmp/cloud9-examples/neopixelDynamic.pru0.o
> -   copying firmware file 
> /tmp/cloud9-examples/neopixelDynamic.pru0.out to 
> /lib/firmware/am335x-pru0-fw
> write_init_pins.sh
> writing "pruout" to "/sys/devices/platform/ocp/ocp:P9_31_pinmux/state"
> -Starting PRU 0
> /bin/sh: 1: cannot create /dev/remoteproc/pruss-core0/state: Directory 
> nonexistent
> make: *** [/var/lib/cloud9/common/Makefile:166: start] Error 2
> rm /tmp/cloud9-examples/neopixelDynamic.pru0.o
>
>
>
> *debian@beaglebone:/var/lib/cloud9/BeagleBone/Black/pru$ sudo 
> /opt/scripts/tools/version.sh *
> *[sudo] password for debian: *
> *git:/opt/scripts/:[ef16ffa8c27225005cc2b2c974a83da3dee6c1ef]*
> *eeprom:[A335BNLT000C2025BBBG0598]*
> *model:[TI_AM335x_BeagleBone_Black]*
> *dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-08-31]*
> *bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-gc9b3922522]:[location: dd MBR]*
> *bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> 2019.04-2-gf15b99f0b6]:[location: dd MBR]*
> *UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]*
> *UBOOT: Loaded Overlay:[BB-ADC-00A0]*
> *UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]*
> *kernel:[4.19.94-ti-r50]*
> *nodejs:[v10.21.0]*
> */boot/uEnv.txt Settings:*
> *uboot_overlay_options:[enable_uboot_overlays=1]*
> *uboot_overlay_options:[disable_uboot_overlay_video=1]*
>
> *uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]*
> *uboot_overlay_options:[enable_uboot_cape_universal=1]*
> *pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]*
> *pkg:[bb-cape-overlays]:[4.14.20200814.0-0~buster+20200814]*
> *pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]*
> *pkg:[kmod]:[26-1]*
> *pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]*
> *pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]*
> *groups:[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]*
> *cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]*
> *dmesg | grep remote*
> *[   63.167635] remoteproc remoteproc0: wkup_m3 is available*
> *[   63.236184] remoteproc remoteproc0: powering up wkup_m3*
> *[   63.236216] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168*
> *[   63.236494] remoteproc remoteproc0: remote processor wkup_m3 is now up*
> *dmesg | grep pru*
> *dmesg | grep pinctrl-single*
> *[0.926013] pinctrl-single 44e10800.pinmux: 142 pins, size 568*
> *dmesg | grep gpio-of-helper*
> *[0.939591] gpio-of-helper ocp:cape-universal: ready*
> *lsusb*
> *Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub*
> *END*
> *debian@beaglebone:/var/lib/cloud9/BeagleBone/Black/pru$ *
>
>

-- 
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/8a51b087-8a9f-4fa0-a222-aeee35b4a07en%40googlegroups.com.

[beagleboard] Re: PRU Memory Store Instruction with Autoincrement?

[Mark A. Yoder]

BeagleLogic[1] does some interesting tricks[2] to get a solid 100MHz 
sampling rate.  The *PRU Cookbook* presents an overview of it. Check it out.

--Mark

[1] https://beaglelogic.readthedocs.io/en/latest/ 
[2] 
https://theembeddedkitchen.net/beaglelogic-building-a-logic-analyzer-with-the-prus-part-1/449
[3] 
https://markayoder.github.io/PRUCookbook/01case/case.html#_beaglelogic_a_14_channel_logic_analyzer

On Monday, October 19, 2020 at 5:25:45 AM UTC-4 Andrew P. Lentvorski wrote:

> Hmm, that's an interesting idea, Dimitar, to encode the increment in the 
> immediate.  That's probably ... useful.
>
> That mechanism would give me a 64-sample burst per register which could 
> possibly get me to 1920 samples *if* the SBBO doesn't stall out anywhere.
>
> I thought about the BeagleLogic, but it relies on the fact that every 
> other cycle is NOP, so it can effectively run something simultaneously at 
> half-speed in the interleaved time.
>
> Looks like it's time for some experiments.  I'll report back if I see 
> anything interesting.
> On Sunday, October 18, 2020 at 12:11:33 PM UTC-7 din...@gmail.com wrote:
>
>> Hi,
>>
>> Do you require continuous 200MHz sampling? That would be difficult I 
>> think.
>>
>> If you require bursts of 200MHz sampling, how long should those bursts 
>> be? Even if you find autoincrement opcode, you would still need to add one 
>> jump instruction to "loop".
>>
>> You can try hardcoding the "increment" into the constant offset field. 
>> And load several registers with starting address of each 256-byte chunk of 
>> your destination buffer. Example:
>>
>> init:
>>  ldi r0, __buf_start
>>  ldi r1, __buf_start+256
>>  ldi r2, __buf_start+256*2
>>   ...
>> burst_store:
>>  sbbo , r0, 0, 4
>>  sbbo , r0, 4, 4
>>  sbbo , r0, 8, 4
>>  sbbo , r0, 12, 4
>>  sbbo , r0, 16, 4
>>  
>>  sbbo , r0, 252, 4
>>  sbbo , r1, 0, 4
>>  sbbo , r0, 4, 4
>>  ...
>>
>> I am not sure what are the buffering limits of PRU's posted writes. I 
>> doubt if so many consecutive sbbo instructions would not stall.
>>
>> You should also examine BeagleLogic firmware's operation mode for 100MHz. 
>> Perhaps you can modify it to take 200MHz bursts instead of continuous 
>> 100MHz sampling. Difference with above single-PRU example is that you would 
>> use PRU register banks for buffering, which would decouple sampling from 
>> SBBO bus operations.
>>
>> Regards,
>> Dimitar
>>
>> On Sunday, October 18, 2020 at 10:16:44 AM UTC+3 Andrew P. Lentvorski 
>> wrote:
>>
>>> Hi, folks,
>>>
>>> I'm trying to dump R31 over and over into either RAM0 or Shared DRAM 
>>> (Data RAM).
>>>
>>> So, basically it looks like I have to do:
>>>
>>> Store R31 to address in register
>>> Increment address in register
>>> (Lather rinse repeat)
>>>
>>> As that stands, that's a 100MHz sample of R31.  Is there anyway to do 
>>> the autoincrement on the store?  That would double my sampling rate to 
>>> 200MHz which would be the maximum possible.
>>>
>>> Alternatively, is there a different way to sample and store R31 
>>> repeatedly to RAM0 or Shared DRAM?  I can't seem to see one, but there are 
>>> so many permutation of Store Burst, mapping, the broadside transfer bus, 
>>> and peripherals that I can quite easily be missing something that someone 
>>> more experienced knows about.
>>>
>>> Thanks.
>>>
>>

-- 
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/c9c6d7a7-8da7-488d-9051-888a1901e41an%40googlegroups.com.

[beagleboard] Re: Controling sample rate

[Mark A. Yoder]

If it's the ADC you want to control, I have some note's here[1] on how to 
change the sampling rate.

--Mark

[1] 
https://elinux.org/EBC_Exercise_10a_Analog_In#Analog_in_-_Continuous.2C_Change_the_sample_rate
 

On Saturday, October 17, 2020 at 5:35:59 PM UTC-4 barkan.ugu...@gmail.com 
wrote:

> Hello Frederico,
>
> I assume you want to create a fixed sampling rate so that you can use the 
> BeagleBone as a controller for a feedback system. 
> If this is the case, I advise you to run it via Linux with an RTOS patch, 
> preferably Xenomai:
> https://cvra.ch/blog/2015/xenomai-installation-on-a-beaglebone-black
>
> Barkan
>
>
> On Saturday, September 28, 2019 at 6:55:08 PM UTC+3, Frederico Alves de 
> Oliveira Silva wrote:
>>
>>
>> Helllo guys,
>>
>> I am a total begginner with BeagleBone.
>> I would like to ask how can I control the sample rate of BeagleBone Black.
>> Is there a minimal example?
>>
>> Thank you for the attention!
>> Frederico
>>
>

-- 
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/b5ece2c5-7d0c-4c0d-843c-917ca079b53dn%40googlegroups.com.

Re: [beagleboard] Re: User LEDs control

[Mark A. Yoder]

This may be off topic, but I have some notes on how to switch a GPIO pin to 
be an LED.

https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED

--Mark

On Sunday, October 11, 2020 at 5:54:41 PM UTC-4 jonn...@gmail.com wrote:

> I'm not sure what board you have or what kernel you are running, however 
> on a Beaglebone Black running a 4.19 kernel, the LED settings are located 
> in the bone-common.dtsi file:
> Note: From the BBB schematic, led1 is connected to the Ethernet port, so 
> perhaps you are trying to control usr0 LED. 
> Ex:
>   /opt/source/dtb-4.19-ti/src/arm/am335x-bone-common.dtsi
>
> *leds {*
> *pinctrl-names = "default";*
> *pinctrl-0 = <_leds_s0>;*
>
> *compatible = "gpio-leds";*
>
> *led2 {*
> *label = "beaglebone:green:usr0";*
> *gpios = < 21 GPIO_ACTIVE_HIGH>;*
> *linux,default-trigger = "heartbeat";*
> *default-state = "off";*
> *};*
>
> *led3 {*
> *label = "beaglebone:green:usr1";*
> *gpios = < 22 GPIO_ACTIVE_HIGH>;*
> *linux,default-trigger = "mmc0";*
> *default-state = "off";*
> *};*
>
> *led4 {*
> *label = "beaglebone:green:usr2";*
> *gpios = < 23 GPIO_ACTIVE_HIGH>;*
> *linux,default-trigger = "cpu0";*
> *default-state = "off";*
> *};*
>
> *led5 {*
> *label = "beaglebone:green:usr3";*
> *gpios = < 24 GPIO_ACTIVE_HIGH>;*
> *linux,default-trigger = "mmc1";*
> *default-state = "off";*
> *};*
> *};*
>
> Cheers,
>
> Jon
>
>
> On Sun, Oct 11, 2020 at 12:34 PM Joshua Park  wrote:
>
>> Also, I figure that I process is controlling the blinking of user LED 1 
>> since that is the only one I cannot change. Can anyone tell me what this 
>> process is and if I can stop it from controlling LED 1?
>>
>> On Sunday, October 11, 2020 at 3:01:06 PM UTC-4 Joshua Park wrote:
>>
>>> Hi all,
>>>
>>> I am trying to change the user LEDs but I am unable to make permanent 
>>> changes to the files in */sys/devices/platform/leds/leds*. Can someone 
>>> help me out? 
>>>
>>> Thanks in advance.
>>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/acfff9b2-a632-47a7-a4f0-29991e4475c5n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/cf2d3944-7e0f-46c0-8bb3-59c4c0e84cd9n%40googlegroups.com.

[beagleboard] Using gpiod in a Kernel module

[Mark A. Yoder]

I'm looking for examples of using the new gpiod[1] interface in a kernel 
module. 
I'd like to see Derek Molloy's gpio_test[2] example converted from the 
/sys/class/gpio approach to the gpiod.

Who can point me to some examples?

--Mark

p.s.  I'm not looking for libgpiod examples, those I've already done[3].

[1] https://www.kernel.org/doc/Documentation/gpio/consumer.txt
[2] 
https://github.com/derekmolloy/exploringBB/tree/version2/extras/kernel/gpio_test
 
[3] 
https://github.com/beagleboard/cloud9-examples/tree/v2020.08/BeagleBone/Black/gpiod

-- 
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/d80c6fe0-aba5-48cf-a514-1d39a775b55an%40googlegroups.com.

Re: [beagleboard] Re: pygame displaying on /dev/fb0 - Solved

[Mark A. Yoder]

Jon:
  Thanks...

I'm thinking of getting rid of reset.sh since on.sh effectively does a 
reset when you rerun it.

--Mark

On Sunday, September 13, 2020 at 7:32:53 PM UTC-4 jonn...@gmail.com wrote:

> I was able to resolve the issue I was having with your fb and pygame 
> examples.  I had to ensure the BUS was set to '0' and the pin GPIO values 
> were set properly in 'on.sh'. The same was true in reset.sh with 'busnum=0'
>
> Also, it seemed that if I ran the examples in 'usr', I had to reboot the 
> board for the 'fb' examples to work.
>
> It's all working now.
> Nice job.
>
> Jon
>
> On Sat, Sep 12, 2020 at 5:05 PM jonnymo  wrote:
>
>> Cool.
>>
>>   I am unable to get your pygame or other fb examples to work but I can 
>> get the 'usr' examples to work. 
>>  
>> Perhaps this is for another post, but in your examples, are you using 
>> SPI0 or SPI1?  It seems some of the setup for the examples are set for SPI0 
>> and some are set for SPI1 yet the wiring listing in "EBC Exercise 12a 2.4 
>> TFT LCD display via SPI" seems to indicate SPI0.  
>>
>>
>> Cheers,
>>
>> Jon 
>>
>> On Sat, Sep 12, 2020 at 1:20 PM Mark A. Yoder  
>> wrote:
>>
>>> I now have it working with sudo.  I just added 
>>> https://github.com/MarkAYoder/BeagleBoard-exercises/blob/a531dca3a5f52813623bd40ea42bc733decfc70d/displays/ili9341/fb/pygame/clock.py#L26
>>>
>>> I needed to set SDL_NOMOUSE to 1.
>>>
>>> --Mark
>>>
>>> On Saturday, September 12, 2020 at 3:33:23 PM UTC-4 Mark A. Yoder wrote:
>>>
>>>> Jon:
>>>>   Well.  su does give different results than sudo.  I tried su 
>>>> again and it works!
>>>>
>>>> So, how can I set permissions so I don't have to su or sudo?
>>>>
>>>> --Mark
>>>>
>>>> p.s.  Thanks for all the suggestions.
>>>>
>>>> On Friday, September 11, 2020 at 6:23:45 PM UTC-4 jonn...@gmail.com 
>>>> wrote:
>>>>
>>>>> In my config, BBAI running 4.14 kernel, I found two instances of fbcon:
>>>>> $ sudo find / -name fbcon
>>>>>
>>>>> * /sys/devices/virtual/graphics/fbcon*
>>>>> * /sys/class/graphics/fbcon*
>>>>>
>>>>>
>>>>> The framebuffer console seems to be attached to the console layer. 
>>>>>
>>>>> *$ cat /sys/class/vtconsole/vtcon1/bind*
>>>>> *1*
>>>>> *$ cat /sys/class/vtconsole/vtcon0/bind*
>>>>> *0*
>>>>>
>>>>>
>>>>> Info on fbcon:
>>>>> https://www.kernel.org/doc/html/latest/fb/fbcon.html
>>>>>
>>>>>
>>>>> Not sure if this helps at all.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Jon
>>>>>
>>>>>
>>>>> On Fri, Sep 11, 2020 at 11:24 AM Robert Nelson  
>>>>> wrote:
>>>>>
>>>>>> On Fri, Sep 11, 2020 at 12:56 PM Dennis Lee Bieber
>>>>>>  wrote:
>>>>>> >
>>>>>> > On Fri, 11 Sep 2020 04:56:42 -0700 (PDT), in
>>>>>> > gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
>>>>>> >  wrote:
>>>>>> >
>>>>>> >
>>>>>> > >
>>>>>> > >Are you sure there is a fbcon module?
>>>>>> >
>>>>>> > 
>>>>>> https://www.kernel.org/doc/html/latest/fb/fbcon.html#a-configuration
>>>>>> >
>>>>>> > ... seems to imply it may not have been built for the standard 
>>>>>> release BBB
>>>>>> > kernels.
>>>>>>
>>>>>> It's enabled:
>>>>>>
>>>>>> │ 
>>>>>> ┌───┐
>>>>>>  │
>>>>>>   │ │[*] Framebuffer Console support
>>>>>>  │ │
>>>>>>   │ │-*-   Map the console to the primary display device
>>>>>>  │ │
>>>>>>   │ │[*]   Framebuffer Console Rotation
>>>>>>  │ │
>>>>>>   │ │[ ]   Framebuffer Console Deferred Takeover  
>>>>>>   │
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>&

Re: [beagleboard] Re: pygame displaying on /dev/fb0 - Solved

[Mark A. Yoder]

I now have it working with sudo.  I just added 
https://github.com/MarkAYoder/BeagleBoard-exercises/blob/a531dca3a5f52813623bd40ea42bc733decfc70d/displays/ili9341/fb/pygame/clock.py#L26

I needed to set SDL_NOMOUSE to 1.

--Mark

On Saturday, September 12, 2020 at 3:33:23 PM UTC-4 Mark A. Yoder wrote:

> Jon:
>   Well.  su does give different results than sudo.  I tried su again 
> and it works!
>
> So, how can I set permissions so I don't have to su or sudo?
>
> --Mark
>
> p.s.  Thanks for all the suggestions.
>
> On Friday, September 11, 2020 at 6:23:45 PM UTC-4 jonn...@gmail.com wrote:
>
>> In my config, BBAI running 4.14 kernel, I found two instances of fbcon:
>> $ sudo find / -name fbcon
>>
>> * /sys/devices/virtual/graphics/fbcon*
>> * /sys/class/graphics/fbcon*
>>
>>
>> The framebuffer console seems to be attached to the console layer. 
>>
>> *$ cat /sys/class/vtconsole/vtcon1/bind*
>> *1*
>> *$ cat /sys/class/vtconsole/vtcon0/bind*
>> *0*
>>
>>
>> Info on fbcon:
>> https://www.kernel.org/doc/html/latest/fb/fbcon.html
>>
>>
>> Not sure if this helps at all.
>>
>> Cheers,
>>
>> Jon
>>
>>
>> On Fri, Sep 11, 2020 at 11:24 AM Robert Nelson  
>> wrote:
>>
>>> On Fri, Sep 11, 2020 at 12:56 PM Dennis Lee Bieber
>>>  wrote:
>>> >
>>> > On Fri, 11 Sep 2020 04:56:42 -0700 (PDT), in
>>> > gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
>>> >  wrote:
>>> >
>>> >
>>> > >
>>> > >Are you sure there is a fbcon module?
>>> >
>>> > https://www.kernel.org/doc/html/latest/fb/fbcon.html#a-configuration
>>> >
>>> > ... seems to imply it may not have been built for the standard release 
>>> BBB
>>> > kernels.
>>>
>>> It's enabled:
>>>
>>> │ 
>>> ┌───┐ │
>>>   │ │[*] Framebuffer Console support
>>>  │ │
>>>   │ │-*-   Map the console to the primary display device
>>>  │ │
>>>   │ │[*]   Framebuffer Console Rotation
>>>  │ │
>>>   │ │[ ]   Framebuffer Console Deferred Takeover
>>> │
>>>
>>> Regards,
>>>
>>> -- 
>>> Robert Nelson
>>> https://rcn-ee.com/
>>>
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgkXSOoJQ%3D_iBLcYBuFc4Q0%3D%2B6y29EXzABPn5uK-Qbqdw%40mail.gmail.com
>>> .
>>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/ea2cc40d-aa9e-462e-a454-b0bea9a7da4cn%40googlegroups.com.

Re: [beagleboard] Re: pygame displaying on /dev/fb0 - Solved

[Mark A. Yoder]

Jon:
  Well.  su does give different results than sudo.  I tried su again 
and it works!

So, how can I set permissions so I don't have to su or sudo?

--Mark

p.s.  Thanks for all the suggestions.

On Friday, September 11, 2020 at 6:23:45 PM UTC-4 jonn...@gmail.com wrote:

> In my config, BBAI running 4.14 kernel, I found two instances of fbcon:
> $ sudo find / -name fbcon
>
> * /sys/devices/virtual/graphics/fbcon*
> * /sys/class/graphics/fbcon*
>
>
> The framebuffer console seems to be attached to the console layer. 
>
> *$ cat /sys/class/vtconsole/vtcon1/bind*
> *1*
> *$ cat /sys/class/vtconsole/vtcon0/bind*
> *0*
>
>
> Info on fbcon:
> https://www.kernel.org/doc/html/latest/fb/fbcon.html
>
>
> Not sure if this helps at all.
>
> Cheers,
>
> Jon
>
>
> On Fri, Sep 11, 2020 at 11:24 AM Robert Nelson  
> wrote:
>
>> On Fri, Sep 11, 2020 at 12:56 PM Dennis Lee Bieber
>>  wrote:
>> >
>> > On Fri, 11 Sep 2020 04:56:42 -0700 (PDT), in
>> > gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
>> >  wrote:
>> >
>> >
>> > >
>> > >Are you sure there is a fbcon module?
>> >
>> > https://www.kernel.org/doc/html/latest/fb/fbcon.html#a-configuration
>> >
>> > ... seems to imply it may not have been built for the standard release 
>> BBB
>> > kernels.
>>
>> It's enabled:
>>
>> │ 
>> ┌───┐ │
>>   │ │[*] Framebuffer Console support
>>  │ │
>>   │ │-*-   Map the console to the primary display device
>>  │ │
>>   │ │[*]   Framebuffer Console Rotation
>>  │ │
>>   │ │[ ]   Framebuffer Console Deferred Takeover  
>>   │
>>
>> Regards,
>>
>> -- 
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgkXSOoJQ%3D_iBLcYBuFc4Q0%3D%2B6y29EXzABPn5uK-Qbqdw%40mail.gmail.com
>> .
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/40a351c9-4e79-44e9-9ca3-299225f1c877n%40googlegroups.com.

Re: [beagleboard] pygame displaying on /dev/fb0

[Mark A. Yoder]

bone$ *lsmod*
Module  Size  Used by
fb_ili9341 16384  3
fbtft_device   49152  0
fbtft  45056  2 fbtft_device,fb_ili9341
pru_rproc  28672  0
irq_pruss_intc 20480  1 pru_rproc
pruss  16384  1 pru_rproc
pm33xx 16384  0
wkup_m3_ipc16384  1 pm33xx
wkup_m3_rproc  16384  1
remoteproc 57344  3 pru_rproc,wkup_m3_rproc,wkup_m3_ipc
virtio 16384  1 remoteproc
virtio_ring28672  1 remoteproc
pruss_soc_bus  16384  0
usb_f_acm  16384  2
u_serial   20480  3 usb_f_acm
usb_f_ncm  28672  2
uio_pdrv_genirq16384  0
usb_f_mass_storage 53248  2
uio20480  1 uio_pdrv_genirq
usb_f_rndis32768  4
u_ether20480  2 usb_f_ncm,usb_f_rndis
libcomposite   65536  18 
usb_f_acm,usb_f_ncm,usb_f_mass_storage,usb_f_rndis
spidev 20480  0

bone$ *sudo modprobe fbcon*
sudo: unable to resolve host ece434: No address associated with hostname
modprobe: FATAL: Module fbcon not found in directory 
/lib/modules/4.19.94-ti-r50

Are you sure there is a fbcon module?
On Friday, September 11, 2020 at 1:09:11 AM UTC-4 jonn...@gmail.com wrote:

> If you run 'lsmod" does the fbcon module show in the output?
>
> If not, try to load it manually:
>   #* modprobe fbcon*
>
> Does this show an error?
>
> Check  
>
> On Thu, Sep 10, 2020 at 5:52 PM Mark A. Yoder  wrote:
>
>> Good idea, but I'm in group video.
>>
>> On Thursday, September 10, 2020 at 5:15:32 PM UTC-4 jonn...@gmail.com 
>> wrote:
>>
>>> Just a thought, is your user part of the 'video' group?  I would suspect 
>>> it is since you were able to run the fbi stuff but it wouldn't hurt to 
>>> check.
>>>
>>> Cheer,
>>>
>>> Jon
>>>
>>> On Thu, Sep 10, 2020 at 11:59 AM jonnymo  wrote:
>>>
>>>> Have you tried running it as root? Not 'sudo' but su to root and try it 
>>>> there.  It could still be a permission issue.
>>>>
>>>> Cheers,
>>>>
>>>> Jon
>>>>
>>>> On Thu, Sep 10, 2020 at 11:50 AM Mark A. Yoder  
>>>> wrote:
>>>>
>>>>> I tried the 4.14 and 5.6 kernels, but no luck.
>>>>>
>>>>> --Mark
>>>>>
>>>>> On Thursday, September 10, 2020 at 2:38:08 PM UTC-4 RobertCNelson 
>>>>> wrote:
>>>>>
>>>>>> On Thu, Sep 10, 2020 at 12:00 PM Mark A. Yoder  
>>>>>> wrote: 
>>>>>> > 
>>>>>> > Yup, I think before it would grap fbcon, but not now. 
>>>>>>
>>>>>> Was it with v4.14.x before? i wonder if the new tinydrm driver in 
>>>>>> v4.19.x is causing a fun issue? 
>>>>>>
>>>>>> Regards, 
>>>>>>
>>>>>> -- 
>>>>>> Robert Nelson 
>>>>>> https://rcn-ee.com/ 
>>>>>>
>>>>> -- 
>>>>> For more options, visit http://beagleboard.org/discuss
>>>>> --- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "BeagleBoard" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to beagleboard...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/beagleboard/31150241-e86b-4a41-a7e8-769ec7cbc490n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/beagleboard/31150241-e86b-4a41-a7e8-769ec7cbc490n%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/a965806b-842c-4443-9340-603d201538a3n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/a965806b-842c-4443-9340-603d201538a3n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/8f4f1762-ea77-4a4a-b955-351aaa43fb56n%40googlegroups.com.

Re: [beagleboard] pygame displaying on /dev/fb0

[Mark A. Yoder]

Good idea, but I'm in group video.

On Thursday, September 10, 2020 at 5:15:32 PM UTC-4 jonn...@gmail.com wrote:

> Just a thought, is your user part of the 'video' group?  I would suspect 
> it is since you were able to run the fbi stuff but it wouldn't hurt to 
> check.
>
> Cheer,
>
> Jon
>
> On Thu, Sep 10, 2020 at 11:59 AM jonnymo  wrote:
>
>> Have you tried running it as root? Not 'sudo' but su to root and try it 
>> there.  It could still be a permission issue.
>>
>> Cheers,
>>
>> Jon
>>
>> On Thu, Sep 10, 2020 at 11:50 AM Mark A. Yoder  
>> wrote:
>>
>>> I tried the 4.14 and 5.6 kernels, but no luck.
>>>
>>> --Mark
>>>
>>> On Thursday, September 10, 2020 at 2:38:08 PM UTC-4 RobertCNelson wrote:
>>>
>>>> On Thu, Sep 10, 2020 at 12:00 PM Mark A. Yoder  
>>>> wrote: 
>>>> > 
>>>> > Yup, I think before it would grap fbcon, but not now. 
>>>>
>>>> Was it with v4.14.x before? i wonder if the new tinydrm driver in 
>>>> v4.19.x is causing a fun issue? 
>>>>
>>>> Regards, 
>>>>
>>>> -- 
>>>> Robert Nelson 
>>>> https://rcn-ee.com/ 
>>>>
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/31150241-e86b-4a41-a7e8-769ec7cbc490n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/31150241-e86b-4a41-a7e8-769ec7cbc490n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/a965806b-842c-4443-9340-603d201538a3n%40googlegroups.com.

Re: [beagleboard] pygame displaying on /dev/fb0

[Mark A. Yoder]

su gives the same results.

On Thursday, September 10, 2020 at 3:00:00 PM UTC-4 jonn...@gmail.com wrote:

> Have you tried running it as root? Not 'sudo' but su to root and try it 
> there.  It could still be a permission issue.
>
> Cheers,
>
> Jon
>
> On Thu, Sep 10, 2020 at 11:50 AM Mark A. Yoder  
> wrote:
>
>> I tried the 4.14 and 5.6 kernels, but no luck.
>>
>> --Mark
>>
>> On Thursday, September 10, 2020 at 2:38:08 PM UTC-4 RobertCNelson wrote:
>>
>>> On Thu, Sep 10, 2020 at 12:00 PM Mark A. Yoder  
>>> wrote: 
>>> > 
>>> > Yup, I think before it would grap fbcon, but not now. 
>>>
>>> Was it with v4.14.x before? i wonder if the new tinydrm driver in 
>>> v4.19.x is causing a fun issue? 
>>>
>>> Regards, 
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>> -- 
>>
> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/31150241-e86b-4a41-a7e8-769ec7cbc490n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/31150241-e86b-4a41-a7e8-769ec7cbc490n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/b2f31b19-7874-42ce-a2e6-658b80c97257n%40googlegroups.com.

Re: [beagleboard] pygame displaying on /dev/fb0

[Mark A. Yoder]

I tried the 4.14 and 5.6 kernels, but no luck.

--Mark

On Thursday, September 10, 2020 at 2:38:08 PM UTC-4 RobertCNelson wrote:

> On Thu, Sep 10, 2020 at 12:00 PM Mark A. Yoder  
> wrote:
> >
> > Yup, I think before it would grap fbcon, but not now.
>
> Was it with v4.14.x before? i wonder if the new tinydrm driver in
> v4.19.x is causing a fun issue?
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/31150241-e86b-4a41-a7e8-769ec7cbc490n%40googlegroups.com.

Re: [beagleboard] pygame displaying on /dev/fb0

[Mark A. Yoder]

Yes, I've tried it with and without sudo.  Same results.

--Mark

On Thursday, September 10, 2020 at 2:07:47 PM UTC-4 jonn...@gmail.com wrote:

> Are you running it as sudo?
>
>
> https://learn.adafruit.com/pi-video-output-using-pygame/pointing-pygame-to-the-framebuffer
>
> Jon
>
> On Thu, Sep 10, 2020 at 10:00 AM Mark A. Yoder  
> wrote:
>
>> Yup, I think before it would grap fbcon, but not now.
>>
>> --Mark
>>
>> On Thursday, September 10, 2020 at 12:21:35 PM UTC-4 RobertCNelson wrote:
>>
>>> On Thu, Sep 10, 2020 at 11:16 AM Mark A. Yoder  
>>> wrote: 
>>> > 
>>> > I have a ili9341 2.4" TFT display wired to SP1 on my BeagleBone Black 
>>> and it's working fine when I run fbi to display images, or mplayer to play 
>>> movies. 
>>> > 
>>> > I'm unable to get pygame to display on it. I'm trying to get my 
>>> clock.py[1] to work and all I get is: 
>>> > pygame 1.9.4.post1 
>>> > Hello from the pygame community. 
>>> https://www.pygame.org/contribute.html 
>>> > Driver: fbcon failed. 
>>>
>>> I'd expect it to use fbcon.. 
>>>
>>> But why didn't it pick it up... 
>>>
>>> Regards, 
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/d43c767e-987b-49a5-91d2-ffc8f95132cen%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/d43c767e-987b-49a5-91d2-ffc8f95132cen%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/77088527-8d7e-480f-98fd-9680347f706dn%40googlegroups.com.

Re: [beagleboard] pygame displaying on /dev/fb0

[Mark A. Yoder]

Yup, I think before it would grap fbcon, but not now.

--Mark

On Thursday, September 10, 2020 at 12:21:35 PM UTC-4 RobertCNelson wrote:

> On Thu, Sep 10, 2020 at 11:16 AM Mark A. Yoder  
> wrote:
> >
> > I have a ili9341 2.4" TFT display wired to SP1 on my BeagleBone Black 
> and it's working fine when I run fbi to display images, or mplayer to play 
> movies.
> >
> > I'm unable to get pygame to display on it. I'm trying to get my 
> clock.py[1] to work and all I get is:
> > pygame 1.9.4.post1
> > Hello from the pygame community. https://www.pygame.org/contribute.html
> > Driver: fbcon failed.
>
> I'd expect it to use fbcon..
>
> But why didn't it pick it up...
>
> Regards,
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d43c767e-987b-49a5-91d2-ffc8f95132cen%40googlegroups.com.

[beagleboard] pygame displaying on /dev/fb0

[Mark A. Yoder]

I have a ili9341 2.4" TFT display wired to SP1 on my BeagleBone Black and 
it's working fine when I run fbi to display images, or mplayer to play 
movies.

I'm unable to get *pygame* to display on it.  I'm trying to get my 
clock.py[1] to work and all I get is:
pygame 1.9.4.post1
Hello from the pygame community. https://www.pygame.org/contribute.html
Driver: fbcon failed.
Driver: directfb failed.
Driver: svgalib failed.
Traceback (most recent call last):
  File "./clock.py", line 142, in 
clock = pyclock()
  File "./clock.py", line 38, in __init__
raise Exception('No suitable video driver found!')
Exception: No suitable video driver found!

/opt/scripts/tools/version.sh is here[2].  There are no messages in dmesg.

This worked a couple of years ago.  Any ideas how to get this pup running 
again?

---Mark

[1] 
https://github.com/MarkAYoder/BeagleBoard-exercises/blob/master/displays/ili9341/fb/pygame/clock.py

[2]
git:/opt/scripts/:[ef16ffa8c27225005cc2b2c974a83da3dee6c1ef]
eeprom:[A335BNLT0A5A1513BBBK3586]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-08-31]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-gc9b3922522]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
kernel:[4.19.94-ti-r50]
nodejs:[v10.21.0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20200814.0-0~buster+20200814]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.5-git20200715.0-0~buster+20200716]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm tty 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]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
dmesg | grep remote
[   67.629755] remoteproc remoteproc0: wkup_m3 is available
[   67.697686] remoteproc remoteproc0: powering up wkup_m3
[   67.697720] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[   67.697999] remoteproc remoteproc0: remote processor wkup_m3 is now up
[   69.600373] remoteproc remoteproc1: 4a334000.pru is available
[   69.602641] remoteproc remoteproc2: 4a338000.pru is available
dmesg | grep pru
[   69.600373] remoteproc remoteproc1: 4a334000.pru is available
[   69.600538] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed 
successfully
[   69.602641] remoteproc remoteproc2: 4a338000.pru is available
[   69.602818] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed 
successfully
dmesg | grep pinctrl-single
[0.925809] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
[0.939434] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

-- 
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/f2131d8c-d8c5-4392-b837-52efeb347b78n%40googlegroups.com.

Re: [beagleboard] Welcome the Fall 2020 Embedded Linux Class

[Mark A. Yoder]

Thanks to all for you interest in the class.  Most of the materials 
on https://elinux.org/Category:ECE497 and you are welcome to see/use them.
Unfortunately much of the other content is not available to those out is 
the class.

--Mark

On Tuesday, September 1, 2020 at 4:17:05 PM UTC-4 jonn...@gmail.com wrote:

> I would be interested in checking out your class.
>
> Is there a site to sign up for this?
>
> Cheers,
>
> Jon
>
> On Tue, Sep 1, 2020 at 1:05 PM Mark A. Yoder  wrote:
>
>> The purpose of this posting is to announce that I'm once again teaching 
>> an Embedded Linux class based on the BeagleBone[1]. This time I'm using
>> the  *BeagleBone Black.* 
>> I'm teaching as open-source as I can and have have posted many of course 
>> materials on eLinux.org [2] and github[3].
>>
>> I'm always open to ideas on what topics to include in the class and 
>> suggestions for interesting course projects.  For example we are starting
>> Python this week and hope to be writing simple kernel module 5 weeks from 
>> now.  That will be followed by a week of PRU programming.
>>
>> Class, please respond to this posting.  Others, please welcome my class.
>>
>> --Mark 
>>
>> --Prof. Mark A. Yoder 
>>   Rose-Hulman Institute of Technology [4] 
>>
>> [1] http://elinux.org/Embedded_Linux,_Rose-Hulman 
>> [2] http://elinux.org/index.php?title=Category:ECE497 
>> [3] https://github.com/MarkAYoder/BeagleBoard-exercises 
>> [4] http://www.rose-hulman.edu 
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/e7663106-85ab-4e88-9863-6c66676af9e1n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/e7663106-85ab-4e88-9863-6c66676af9e1n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/fb9e30e7-e05e-4a9e-9821-4220c3bf3e47n%40googlegroups.com.

[beagleboard] Welcome the Fall 2020 Embedded Linux Class

[Mark A. Yoder]

The purpose of this posting is to announce that I'm once again teaching 
an Embedded Linux class based on the BeagleBone[1]. This time I'm using
the  *BeagleBone Black.* 
I'm teaching as open-source as I can and have have posted many of course 
materials on eLinux.org [2] and github[3].

I'm always open to ideas on what topics to include in the class and 
suggestions for interesting course projects.  For example we are starting
Python this week and hope to be writing simple kernel module 5 weeks from 
now.  That will be followed by a week of PRU programming.

Class, please respond to this posting.  Others, please welcome my class.

--Mark 

--Prof. Mark A. Yoder 
  Rose-Hulman Institute of Technology [4] 

[1] http://elinux.org/Embedded_Linux,_Rose-Hulman 
[2] http://elinux.org/index.php?title=Category:ECE497 
[3] https://github.com/MarkAYoder/BeagleBoard-exercises 
[4] http://www.rose-hulman.edu 

-- 
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/e7663106-85ab-4e88-9863-6c66676af9e1n%40googlegroups.com.

[beagleboard] Re: Troubles when adding a LED to Device Tree

[Mark A. Yoder]

Pedro:
  I think I got lucky and the mux was already set to gpio.

--Mark

On Tuesday, September 1, 2020 at 3:55:33 PM UTC-4 phfber...@gmail.com wrote:

> Hi Mark. Great, thanks!
>
> Per my understanding, the Device Tree approach of 
> https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED doesn't 
> include modifying user_leds_s0 (pinmux for user leds). Do you know why 
> isn't this needed?
>
>
> Best Regards,
> Pedro Bertoleti
>
> Em terça-feira, 1 de setembro de 2020 às 16:47:15 UTC-3, Mark A. Yoder 
> escreveu:
>
>> Your steps look right, but there is a simpler way to do them.  Check out:
>> https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED
>>
>> No need to cross compile etc.
>>
>> --Mark
>>
>> On Tuesday, September 1, 2020 at 10:36:13 AM UTC-4 TJF wrote:
>>
>>> Hi!
>>>
>>> Forget about all that device tree trouble, use libpruio 
>>> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html>
>>>  
>>> instead. You can configure the pin and set the desired output state by a 
>>> single function call in your programm running at user space (no sudo 
>>> commands, no rebooting, ...)
>>>
>>> gpio_setValue(Io, P9_15, 1) // configure and set high
>>>>
>>> gpio_setValue(Io, P9_15, 0) // set low
>>>>
>>>  
>>> You'll have faster boot, less memory consumption, and your code executes 
>>> much faster (compared with sysfs GPIO control).
>>>
>>> You may want to check out some examples 
>>> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html>
>>> .
>>>
>>> Regards
>>>
>>

-- 
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/5481c6eb-9b19-4efa-9028-7dbc197ae055n%40googlegroups.com.

[beagleboard] Re: Troubles when adding a LED to Device Tree

[Mark A. Yoder]

Your steps look right, but there is a simpler way to do them.  Check out:
https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED

No need to cross compile etc.

--Mark

On Tuesday, September 1, 2020 at 10:36:13 AM UTC-4 TJF wrote:

> Hi!
>
> Forget about all that device tree trouble, use libpruio 
>  
> instead. You can configure the pin and set the desired output state by a 
> single function call in your programm running at user space (no sudo 
> commands, no rebooting, ...)
>
> gpio_setValue(Io, P9_15, 1) // configure and set high
>>
> gpio_setValue(Io, P9_15, 0) // set low
>>
>  
> You'll have faster boot, less memory consumption, and your code executes 
> much faster (compared with sysfs GPIO control).
>
> You may want to check out some examples 
> 
> .
>
> Regards
>

-- 
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/49032644-ee3e-4e3f-b988-aa12cdca0f27n%40googlegroups.com.

Re: [beagleboard] Switching a GPIO to and LED via the device tree

[Mark A. Yoder]

Jim:
  Thanks for the feedback.  I like your suggestions.  Responses below:

On Thursday, August 27, 2020 at 2:17:24 PM UTC-4 jimf...@gmail.com wrote:

> Hi Mark,
>
> Nice tutorial. Wish I'd had that quite some time ago, I had to pull all 
> those pieces together myself.
>
> From having read a bunch of posts here, I have a few suggestions for your 
> consideration.
>
> 1. User needs to be in the gpio group. This isn't mentioned.
>
*The debian image has user debian in the gpio group by default.  Though 
there are other use cases, I want to keep this focused on my students.*
*They are fighting too many alligators for me to add the group alligator.*

> 2. People often ignore parts of instructions. If your prompt included the 
> current directory name, it would be slightly more obvious where each 
> command is run. 
>
*Good suggestion.  To keep the clutter down I just converted all paths to 
absolute.  Does that work?* 

> 3. It would be AMAZING if tutorials such as these included a description 
> of what version of code this was developed/tested on. You could either 
> mention the RCN release number or the kernel build, but it would be so 
> great if this were a standard thing to mention. Consider how much things 
> have changed with device trees over the past five (?) years. There's tons 
> of now-wrong notes on how to do things. (I know you mention a kernel in the 
> compilation section, I guess it would be nice to spell this out up top, 
> i.e. "This tutorial is applicable to Beaglebone release xxx").
>
*Great idea.  Wiki pages age so quickly.   I've added a footnote that 
displays the output of uname and cat /etc/dogtag.  What do you think?* 
(https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED)

> 4. Not sure this comment is welcome, but a top level Tutorials page 
> containing all the EBC## tutorials would be cool. I found the others by 
> clicking on your ECE497 link, but that isn't exactly obvious (to me). Those 
> look like some great materials that I hadn't come across before, for some 
> reason.
>
*Another good idea, but...  I'm sticking with using the Category to collect 
all my pages.  I hope my titles are descriptive enough that I can remember 
what's in them.* 

Thanks again for the feedback.

--Mark


> Best,
>
> Jim
>
> On Wed, Aug 26, 2020 at 10:23 PM Mark A. Yoder  
> wrote:
>
>> Beagler's:
>>   I just wrote up some notes on how to edit the device tree to change a 
>> GPIO into an LED.
>>
>> Switching_a_GPIO_to_an_LED 
>> <https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED>
>>
>> It's are rather involved process that requires understanding some deeper 
>> magic.
>>
>> Let me know what you think.
>>
>> --Mark
>>
>> -- 
>>
> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/25d5f747-227b-4e2a-b988-f86e00311c0bn%40googlegroups.com.

Re: [beagleboard] Switching a GPIO to and LED via the device tree

[Mark A. Yoder]

Jon:
  Thanks for the suggestions.  I'll address each in line..

--Mark

On Thursday, August 27, 2020 at 12:11:56 PM UTC-4 jonn...@gmail.com wrote:

> Very cool Mark.
>
> A couple of notes:
> 1.  It might be a good idea to put a note in there for the folks to back 
> up their currently booted dts/dtb files before editing them.
>  *Good idea, but this is a git repo, so I added the following: *
> https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED#Recovering_from_a_miss-edit
> 2. Under "Finding which device tree to edit" I believe there is a typo:
>  Note: If you want to edit the source using cloud9 us the following 
> trick ...
>Should be:
>  Note: If you want to edit the source using cloud9 *use* the 
> following trick ...
> *Fixed.  Thanks.*
> 3. When you run make, would it be best to just run it against the file 
> that was edited rather than the whole folder?
>  Maybe the build script is smart enough to figure this out.
> *You can do the individual file, but it more typing.  I guess I'm lazy.  
> And it still installs everything.*
> 4.  Under "Adding our LED" there is the following without explaining the 
> why.  Was this intentional?
> "How did I know to use *gpio1* and *18*?"
> *That was intentional to get my students to think a bit.  Should I include 
> the answer for the broader **audience**? *
> This is a nice series.  Thanks for sharing.
>
> Cheers,
>
> Jon
>
> On Thu, Aug 27, 2020 at 8:31 AM Renaud Waldura  wrote:
>
>> Good stuff, thank you Mark!
>>
>> How are the triggers defined? They're more or less self explanatory, I'm 
>> just curious how it works.
>>
>>
>> On Thu, Aug 27, 2020, 6:06 AM Mark A. Yoder  wrote:
>>
>>>
>>> Yup, years for facing blank stares has taught me a few things.
>>>
>>> This particular example touched on so many different things it could be 
>>> a nice final exam.
>>>
>>> --Mark
>>> On Wednesday, August 26, 2020 at 9:59:23 PM UTC-4 lazarman wrote:
>>>
>>>>
>>>> Well presented I like your approach at documentation I bet that comes 
>>>> from teaching 
>>>>
>>>>
>>>> Sent from Yahoo Mail on Android 
>>>> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>>>>
>>>> On Wed, Aug 26, 2020 at 5:30 PM, Mark A. Yoder
>>>>  wrote:
>>>>
>>>> Beagler's:
>>>>   I just wrote up some notes on how to edit the device tree to change a 
>>>> GPIO into an LED.
>>>>
>>>> Switching_a_GPIO_to_an_LED 
>>>> <https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED>
>>>>
>>>> It's are rather involved process that requires understanding some 
>>>> deeper magic.
>>>>
>>>> Let me know what you think.
>>>>
>>>> --Mark
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/6203e02e-107b-4404-b952-0ef40ad12118n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/6203e02e-107b-4404-b952-0ef40ad12118n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAN%2B%3DRhG066CY6W8sC8M%3D2-fPbqEv8uTHJEShNiAU4_CgN2pJWw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/CAN%2B%3DRhG066CY6W8sC8M%3D2-fPbqEv8uTHJEShNiAU4_CgN2pJWw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/792ec4de-54ab-48da-8662-dc48137500ccn%40googlegroups.com.

Re: [beagleboard] Switching a GPIO to and LED via the device tree

[Mark A. Yoder]

Ren:
  Good question.  I poked around the kernel source 
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/leds/trigger?h=v4.19.142>
 a 
bit hoping to create an example for my students.  
But it was more complicated than what I wanted for my students.

--Mark

On Thursday, August 27, 2020 at 11:30:59 AM UTC-4 Ren W wrote:

> Good stuff, thank you Mark!
>
> How are the triggers defined? They're more or less self explanatory, I'm 
> just curious how it works.
>
>
> On Thu, Aug 27, 2020, 6:06 AM Mark A. Yoder  wrote:
>
>>
>> Yup, years for facing blank stares has taught me a few things.
>>
>> This particular example touched on so many different things it could be a 
>> nice final exam.
>>
>> --Mark
>> On Wednesday, August 26, 2020 at 9:59:23 PM UTC-4 lazarman wrote:
>>
>>>
>>> Well presented I like your approach at documentation I bet that comes 
>>> from teaching 
>>>
>>>
>>> Sent from Yahoo Mail on Android 
>>> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>>>
>>> On Wed, Aug 26, 2020 at 5:30 PM, Mark A. Yoder
>>>  wrote:
>>>
>>> Beagler's:
>>>   I just wrote up some notes on how to edit the device tree to change a 
>>> GPIO into an LED.
>>>
>>> Switching_a_GPIO_to_an_LED 
>>> <https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED>
>>>
>>> It's are rather involved process that requires understanding some deeper 
>>> magic.
>>>
>>> Let me know what you think.
>>>
>>> --Mark
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>> -- 
>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/6203e02e-107b-4404-b952-0ef40ad12118n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/6203e02e-107b-4404-b952-0ef40ad12118n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/ee0a5f7c-3939-4227-bc4d-a94dffdea591n%40googlegroups.com.

Re: [beagleboard] Switching a GPIO to and LED via the device tree

[Mark A. Yoder]

Yup, years for facing blank stares has taught me a few things.

This particular example touched on so many different things it could be a 
nice final exam.

--Mark
On Wednesday, August 26, 2020 at 9:59:23 PM UTC-4 lazarman wrote:

>
> Well presented I like your approach at documentation I bet that comes from 
> teaching 
>
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Wed, Aug 26, 2020 at 5:30 PM, Mark A. Yoder
>  wrote:
>
> Beagler's:
>   I just wrote up some notes on how to edit the device tree to change a 
> GPIO into an LED.
>
> Switching_a_GPIO_to_an_LED 
> <https://elinux.org/EBC_Exercise_17_Switching_a_GPIO_to_an_LED>
>
> It's are rather involved process that requires understanding some deeper 
> magic.
>
> Let me know what you think.
>
> --Mark
>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/6203e02e-107b-4404-b952-0ef40ad12118n%40googlegroups.com.

[beagleboard] Switching a GPIO to and LED via the device tree

[Mark A. Yoder]

Beagler's:
  I just wrote up some notes on how to edit the device tree to change a 
GPIO into an LED.

Switching_a_GPIO_to_an_LED 


It's are rather involved process that requires understanding some deeper 
magic.

Let me know what you think.

--Mark

-- 
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/61317cde-fb07-4c98-bc56-c968e58e7a10n%40googlegroups.com.

[beagleboard] Re: Updating kernel from command line without trashing SD card

[Mark A. Yoder]

Hmmm.  I haven't seen that one before.  Maybe a
bone$ *sudo apt update*
bone$ *sudo apt dist-upgrade*

is needed.

--Mark
On Monday, August 24, 2020 at 1:27:41 PM UTC-4 steaksa...@gmail.com wrote:

> Hi Mark,
>
> I tried the above, but get the following error:
>
> root@beaglebone:~# cd /opt/scripts/tools
> root@beaglebone:/opt/scripts/tools# git pull
> Already up-to-date.
> root@beaglebone:/opt/scripts/tools# sudo ./update_kernel.sh --bone-kernel
> syncing local clock to pool.ntp.org
> info: checking archive
> GnuTLS: A TLS fatal alert has been received.
> Unable to establish SSL connection.
>
> Seems like there's more problems...
>
> On Monday, 24 August 2020 15:27:28 UTC+1, Mark A. Yoder wrote:
>>
>> Try this:
>>
>> bone$ *cd /opt/scripts/tools*
>> bone$ *git pull*
>> bone$ *sudo ./update_kernel.sh --bone-kernel*
>> 2020-08-24 10:25:12 URL:
>> https://rcn-ee.com/repos/latest/buster-armhf/LATEST-omap-psp [223/223] 
>> -> "LATEST-omap-psp" [1]
>> -
>> Kernel Options:
>> ABI:1 LTS44 4.4.145-bone23
>> ABI:1 LTS49 4.9.178-bone15
>> ABI:1 EXPERIMENTAL 5.7.2-bone9
>> ABI:1 LTS414 4.14.192-bone38
>> ABI:1 LTS419 4.19.135-bone54
>> ABI:1 LTS54 5.4.58-bone33
>> ABI:1 STABLE 5.7.16-bone18
>> ABI:1 TESTING 5.8.2-bone13
>> -
>> Kernel version options:
>> -
>> LTS414: --lts-4_14
>> LTS419: --lts-4_19
>> LTS54: --lts-5_4
>> STABLE: --stable
>> TESTING: --testing
>> -
>> Please pass one of the above kernel options to update_kernel.sh
>>
>> You can now pick which kernel you want to update to.  
>>
>>
>> bone$ *sudo ./update_kernel.sh **--lts-4_14*
>>
>> --Mark
>> On Monday, August 24, 2020 at 7:35:50 AM UTC-4 steaksa...@gmail.com 
>> wrote:
>>
>>> Hi,
>>>
>>> I have a Beaglebone Black running kernel 3.8 (I think - I don't have 
>>> access to the BBB at the moment, so this is from memory). 
>>> I am using this with a cape to drive a custom display. 
>>>
>>> I am pretty sure it's booting from SD card, which has multiple 
>>> partitions (one labelled rootfs and not visible to windows, and one that 
>>> windows can access). Both partitions are accessible when I plug into my 
>>> linux VM. 
>>> The SD card is configured such that the display is all set on boot (not 
>>> really sure how this happens), and I can call scripts that are on the FAT 
>>> partition by SSHing into the BBB and running from the shell. 
>>>
>>> There's a lot I don't understand about the configuration of the SD card, 
>>> but as it works, I'm not that fussed. 
>>>
>>>
>>> However, I now want to migrate this over to the Beaglebone Black 
>>> Wireless and I'm having real difficulty. 
>>>
>>> My thoughts are that I need to upgrade the kernel to a version closer to 
>>> 4.4, but I can't seem to find a method of doing this without completely 
>>> trashing the SD card. 
>>>
>>> If this makes sense, can anyone point me in the right direction?
>>>
>>> Thanks
>>>
>>

-- 
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/4dd2eaa6-02ce-455f-b9ee-44f8b40af7a5n%40googlegroups.com.

[beagleboard] Re: Updating kernel from command line without trashing SD card

[Mark A. Yoder]

Try this:

bone$ *cd /opt/scripts/tools*
bone$ *git pull*
bone$ *sudo ./update_kernel.sh --bone-kernel*
2020-08-24 10:25:12 
URL:https://rcn-ee.com/repos/latest/buster-armhf/LATEST-omap-psp [223/223] 
-> "LATEST-omap-psp" [1]
-
Kernel Options:
ABI:1 LTS44 4.4.145-bone23
ABI:1 LTS49 4.9.178-bone15
ABI:1 EXPERIMENTAL 5.7.2-bone9
ABI:1 LTS414 4.14.192-bone38
ABI:1 LTS419 4.19.135-bone54
ABI:1 LTS54 5.4.58-bone33
ABI:1 STABLE 5.7.16-bone18
ABI:1 TESTING 5.8.2-bone13
-
Kernel version options:
-
LTS414: --lts-4_14
LTS419: --lts-4_19
LTS54: --lts-5_4
STABLE: --stable
TESTING: --testing
-
Please pass one of the above kernel options to update_kernel.sh

You can now pick which kernel you want to update to.  


bone$ *sudo ./update_kernel.sh **--lts-4_14*

--Mark
On Monday, August 24, 2020 at 7:35:50 AM UTC-4 steaksa...@gmail.com wrote:

> Hi,
>
> I have a Beaglebone Black running kernel 3.8 (I think - I don't have 
> access to the BBB at the moment, so this is from memory). 
> I am using this with a cape to drive a custom display. 
>
> I am pretty sure it's booting from SD card, which has multiple partitions 
> (one labelled rootfs and not visible to windows, and one that windows can 
> access). Both partitions are accessible when I plug into my linux VM. 
> The SD card is configured such that the display is all set on boot (not 
> really sure how this happens), and I can call scripts that are on the FAT 
> partition by SSHing into the BBB and running from the shell. 
>
> There's a lot I don't understand about the configuration of the SD card, 
> but as it works, I'm not that fussed. 
>
>
> However, I now want to migrate this over to the Beaglebone Black Wireless 
> and I'm having real difficulty. 
>
> My thoughts are that I need to upgrade the kernel to a version closer to 
> 4.4, but I can't seem to find a method of doing this without completely 
> trashing the SD card. 
>
> If this makes sense, can anyone point me in the right direction?
>
> Thanks
>

-- 
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/9b234d14-5fdd-46cc-b00f-d888cc478701n%40googlegroups.com.

[beagleboard] gpiod C and python examples in /var/lib/cloud9

[Mark A. Yoder]

Beaglers:
   I've just created some gpiod examples in both C and python.  You can get 
to them via:

bone$ *cd /var/lib/cloud9*
bone$ *git pull*
bone$ *git checkout v2020.08*
bone$ *cd BeagleBone/Black/gpiod*
bone$ *sudo apt update; sudo apt install libgpiod-dev*

(Or go to 
https://github.com/beagleboard/cloud9-examples/tree/v2020.08/BeagleBone/Black/gpiod
)

Here's the ReadMe.md

libgpiod is a new C library and tools for interacting with the linux GPIO 
character device. Detailed information is here 
 and 
Adafruit 

 also 
has information.

One of the advantages of gpiod is that it can toggle multiple bits on the 
same gpio chip at the same time. The toggle2 examples show how it's done.

The directory contains examples of using gpiod with *C* and *python* to 
read/write a gpio pin.
FileDescription
toggle1 

Toggles one pin as fast as possible. (300KHz in C, 57KHz in python)
toggle2 

Toggles two pins as fast as possible. (280KHz in C, 55KHz in python)
get 

Reads an input pin and prints its value.
getset 

Reads an input pin and writes its value to an output pin. (5us delay in C, 
20 us Delay in python)
getsetEvent 

Like *getset*, but uses events. (40 us delay in C, 75 us delay in python)
toggleLED 

Toggles the four built in USR LEDs.

Tip: Use *gpioinfo* to lookup chip and line numbers for various pins.


Feedback is welcome.

--Mark

-- 
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/4e673149-b692-493c-ade0-aa964f7b0a1dn%40googlegroups.com.

Re: [beagleboard] LCD driver

[Mark A. Yoder]

I've used a 2.4" LCD in my class.  Here 
 are 
details.

--Mark

On Wednesday, August 12, 2020 at 9:22:48 AM UTC-4 evilw...@gmail.com wrote:

> read the datasheet, that has SPI  there is already a frame buffer written 
> for it
> I have used it
>
>
> On 8/11/2020 10:41 AM, Mehul Shah wrote:
>
> i want SPI interface LCD
>
> On Wed, Aug 12, 2020 at 4:33 AM evilwulfie  wrote:
>
>> I have used this
>>
>> https://www.buydisplay.com/tft-5-inch-lcd-display-module-controller-board-serial-i2c-ra8875
>> your mileage may vary
>>
>>
>> On 8/11/2020 3:49 PM, voip...@gmail.com wrote:
>>
>> Hi All.
>>
>> I want to write/test a basic framebuffer  based driver for LCD on 
>> Beaglebone black
>> having an SPI interface.
>> My question is 
>>
>> 1> which LCD should I order? I think I should order the LCD whose driver 
>> already there in the kernel, am I right? but which one.
>>
>> 2> Any TFT or STN LCD, please let me know.  How I go about it, I 
>> basically want to 
>> change some parameters and experiment and test...
>>
>> I do not have a monitor.
>>
>>
>>
>> Regards,
>> Mehul  
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/8d35e694-11e4-463c-b1ea-85f050ef1e7co%40googlegroups.com
>>  
>> 
>> .
>>
>>
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/VWZs5zxB0nM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/90786190-2419-425c-534b-f72dabb2708f%40gmail.com
>>  
>> 
>> .
>>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAGk2dzrFDgJVrR_gPyFRaK4GkkmeW0OiP33ApPb9eKAG7F0_tw%40mail.gmail.com
>  
> 
> .
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/7f1b5f11-63d7-4575-bc0e-b346786f420bn%40googlegroups.com.

Re: [beagleboard] Re: libgpiod on Beaglebone AI

[Mark A. Yoder]

My code is a bit sloppy.  I keep reopening the and closing the file rather 
than using a lseek().

Using lseek() is about the same speed as the python.
On Monday, August 10, 2020 at 2:40:06 PM UTC-4 John Allwine wrote:

> How is the toggling rate slower in C than in Python when using sysfs? That 
> seems strange to me.
>
> On Mon, Aug 10, 2020 at 12:31 PM Mark A. Yoder  
> wrote:
>
>> Interesting...  Why go through all the trouble to set bits on a chip by 
>> chip basis, and then end up setting them in a loop?
>>
>> Here are the toggling standings.   
>> c via sysfs:   3kHz
>> python via sysfs:  6KHz
>> c via gpiod:  300KHz
>>
>> Now to get python via gpiod to work.
>>
>> --Mark
>> On Monday, August 10, 2020 at 2:19:27 PM UTC-4 Dennis Bieber wrote:
>>
>>> On Mon, 10 Aug 2020 08:33:55 -0700 (PDT), in 
>>> gmane.comp.hardware.beagleboard.user "Mark A. Yoder" 
>>>  wrote: 
>>>
>>> >Interesting I wrote a c version 
>>> ><
>>> https://github.com/MarkAYoder/BeagleBoard-exercises/blob/master/gpiod/bulk.c>
>>>  
>>> and 
>>> >the pins are toggle *at the exact same time*. Now, how to get gpioset 
>>> to 
>>> >work correctly. 
>>> > 
>>>
>>> It doesn't seem to use the same/direct calls... I've tracked it down to 
>>> the function at line 661 
>>> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/lib/core.c 
>>> and macro definition at line 778 
>>>
>>> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/include/gpiod.h
>>>  
>>> which seems to define a loop 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/29db35f1-9022-453e-8966-1a75da8512d4n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/29db35f1-9022-453e-8966-1a75da8512d4n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/e727f6da-fbe3-495a-92ee-736e182ee605n%40googlegroups.com.

[beagleboard] Re: libgpiod on Beaglebone AI

[Mark A. Yoder]

Well, toggling python using gpiod is around 6.5KHz for one pin and about 
half that for two.  Which is what you expect since it's looped.


On Monday, August 10, 2020 at 2:37:36 PM UTC-4 Dennis Bieber wrote:

> On Mon, 10 Aug 2020 09:58:36 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
>  wrote:
>
> >I've been looking through *gpioset.c*, but it's rather involved so I 
> >haven't figured it out yet.
> >
> >Could the python *libgpiod* be rewritten to use just on call to set the 
> >pins so there isn't a delay?
> >
>
> For the most part, the Python library is just a wrapper of the C
> library.
>
> The Python gpiod_LineBulk_set_values invokes gpiod_line_set_value_bulk
> which, at line 848 of
> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/lib/core.c
> operates using a loop.
>
>
> -- 
> 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/e5d43f18-0e3f-4a72-91f1-85dad7917b08n%40googlegroups.com.

[beagleboard] Re: libgpiod on Beaglebone AI

[Mark A. Yoder]

Interesting...  Why go through all the trouble to set bits on a chip by 
chip basis, and then end up setting them in a loop?

Here are the toggling standings.   
c via sysfs:   3kHz
python via sysfs:  6KHz
c via gpiod:  300KHz

Now to get python via gpiod to work.

--Mark
On Monday, August 10, 2020 at 2:19:27 PM UTC-4 Dennis Bieber wrote:

> On Mon, 10 Aug 2020 08:33:55 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
>  wrote:
>
> >Interesting I wrote a c version 
> ><
> https://github.com/MarkAYoder/BeagleBoard-exercises/blob/master/gpiod/bulk.c> 
> and 
> >the pins are toggle *at the exact same time*. Now, how to get gpioset to 
> >work correctly.
> >
>
> It doesn't seem to use the same/direct calls... I've tracked it down to
> the function at line 661
> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/lib/core.c
> and macro definition at line 778
>
> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/include/gpiod.h
> which seems to define a loop 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/29db35f1-9022-453e-8966-1a75da8512d4n%40googlegroups.com.

[beagleboard] Re: libgpiod on Beaglebone AI

[Mark A. Yoder]

I've been looking through *gpioset.c*, but it's rather involved so I 
haven't figured it out yet.

Could the python *libgpiod* be rewritten to use just on call to set the 
pins so there isn't a delay?

On Monday, August 10, 2020 at 12:25:03 PM UTC-4 Dennis Bieber wrote:

> On Mon, 10 Aug 2020 07:27:08 -0700 (PDT), in
> gmane.comp.hardware.beagleboard.user "Mark A. Yoder"
>  wrote:
>
> >Yes, but the hardware on the am335x can toggle multiple pins on the same 
> >chip in the same clock cycle. Seems like the software should be able to 
> >support it.
>
> You could always look at the source code for libgpiod.
>
> https://github.com/brgl/libgpiod/
> """
> libgpiod - C library and tools for interacting with the linux GPIO
> character device (gpiod stands for GPIO device)
>
> Since linux 4.8 the GPIO sysfs interface is deprecated. User space should
> use the character device instead. This library encapsulates the ioctl calls
> and data structures behind a straightforward API.
> """
>
> However, to save some time -- from what I can tell, while the library
> consolidates multiple pins (lines) per controller chip, it then passes that
> on to a kernel call. I've not located the source (kernel) for that level.
> If it is somewhat generalized, it may be coded to handle hardware that can
> only get/set one line at a time -- even if the actual hardware allows
> parallel 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/cb278520-7eab-4e8f-b214-6c2c3051c502n%40googlegroups.com.

Re: [beagleboard] libgpiod on Beaglebone AI

[Mark A. Yoder]

Interesting   I wrote a c version 
<https://github.com/MarkAYoder/BeagleBoard-exercises/blob/master/gpiod/bulk.c> 
and 
the pins are toggle *at the exact same time*.  Now, how to get gpioset to 
work correctly.

--Mark

On Monday, August 10, 2020 at 10:27:08 AM UTC-4 Mark A. Yoder wrote:

> Yes, but the hardware on the am335x can toggle multiple pins on the same 
> chip in the same clock cycle.  Seems like the software should be able to 
> support it.
>
> On Monday, August 10, 2020 at 10:20:10 AM UTC-4 evilw...@gmail.com wrote:
>
>> software takes time to execute.
>>
>>
>> On 8/10/2020 7:09 AM, Mark A. Yoder wrote:
>>
>> I'm starting to play with gpiod on a Beaglebone Black.  One of the 
>> advantages of gpiod is you can toggle multiple pins on the same chip all at 
>> once. 
>> So I try:
>> while true; do 
>> gpioset 1 18=0 19=0
>> gpioset 1 18=1 19=1
>> done
>>
>> This is toggling pins P9_14 and P9_16.  I expect to see the two pins 
>> toggle on at the same time, but what I get is
>> a 4 microsecond delay from P9_14 switching and P9_16 switching.  
>>
>> *Should there be such a long delay? * I'd expect the two to switch at 
>> the same time (which is what happens when toggle pins via the PRU).
>>
>> I do the same experiment with python and I see a 70 us delay.
>>
>> --Mark
>> On Friday, March 27, 2020 at 3:58:21 PM UTC-4 Drew Fustini wrote:
>>
>>> On Fri, Mar 27, 2020 at 8:45 PM John Allwine  
>>> wrote: 
>>> > 
>>> > I don't intend to toggle a GPIO as fast as possible (except to test), 
>>> but from a performance standpoint that demonstration seemed to indicate 
>>> that there are issues with sysfs. Hopefully, libgpiod will prove to be 
>>> better! 
>>>
>>> Bartosz explains the differences and improvements that new gpiod 
>>> interface provides in this talk: 
>>> https://www.youtube.com/watch?v=cdTLewJCL1Y 
>>>
>>> Essentially, if you need read or set multiple lines, it is faster. 
>>> Also, it has an improved way to read events as well. 
>>>
>>> Slides if you prefer over video: 
>>>
>>> https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776
>>>  
>>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/16a18eef-a649-46d9-b126-f774a8eb1522n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/16a18eef-a649-46d9-b126-f774a8eb1522n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>
>>

-- 
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/ab17b85d-7f42-42cb-9793-ed7d04a44e27n%40googlegroups.com.

Re: [beagleboard] libgpiod on Beaglebone AI

[Mark A. Yoder]

Yes, but the hardware on the am335x can toggle multiple pins on the same 
chip in the same clock cycle.  Seems like the software should be able to 
support it.

On Monday, August 10, 2020 at 10:20:10 AM UTC-4 evilw...@gmail.com wrote:

> software takes time to execute.
>
>
> On 8/10/2020 7:09 AM, Mark A. Yoder wrote:
>
> I'm starting to play with gpiod on a Beaglebone Black.  One of the 
> advantages of gpiod is you can toggle multiple pins on the same chip all at 
> once. 
> So I try:
> while true; do 
> gpioset 1 18=0 19=0
> gpioset 1 18=1 19=1
> done
>
> This is toggling pins P9_14 and P9_16.  I expect to see the two pins 
> toggle on at the same time, but what I get is
> a 4 microsecond delay from P9_14 switching and P9_16 switching.  
>
> *Should there be such a long delay? * I'd expect the two to switch at the 
> same time (which is what happens when toggle pins via the PRU).
>
> I do the same experiment with python and I see a 70 us delay.
>
> --Mark
> On Friday, March 27, 2020 at 3:58:21 PM UTC-4 Drew Fustini wrote:
>
>> On Fri, Mar 27, 2020 at 8:45 PM John Allwine  
>> wrote: 
>> > 
>> > I don't intend to toggle a GPIO as fast as possible (except to test), 
>> but from a performance standpoint that demonstration seemed to indicate 
>> that there are issues with sysfs. Hopefully, libgpiod will prove to be 
>> better! 
>>
>> Bartosz explains the differences and improvements that new gpiod 
>> interface provides in this talk: 
>> https://www.youtube.com/watch?v=cdTLewJCL1Y 
>>
>> Essentially, if you need read or set multiple lines, it is faster. 
>> Also, it has an improved way to read events as well. 
>>
>> Slides if you prefer over video: 
>>
>> https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776
>>  
>>
> -- 
> 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/16a18eef-a649-46d9-b126-f774a8eb1522n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/16a18eef-a649-46d9-b126-f774a8eb1522n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
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/2a0cf82e-d223-4cfe-a623-27687edc3b4bn%40googlegroups.com.

Re: [beagleboard] libgpiod on Beaglebone AI

[Mark A. Yoder]

I'm starting to play with gpiod on a Beaglebone Black.  One of the 
advantages of gpiod is you can toggle multiple pins on the same chip all at 
once.
So I try:
while true; do 
gpioset 1 18=0 19=0
gpioset 1 18=1 19=1
done

This is toggling pins P9_14 and P9_16.  I expect to see the two pins toggle 
on at the same time, but what I get is
a 4 microsecond delay from P9_14 switching and P9_16 switching.  

*Should there be such a long delay? * I'd expect the two to switch at the 
same time (which is what happens when toggle pins via the PRU).

I do the same experiment with python and I see a 70 us delay.

--Mark
On Friday, March 27, 2020 at 3:58:21 PM UTC-4 Drew Fustini wrote:

> On Fri, Mar 27, 2020 at 8:45 PM John Allwine  
> wrote:
> >
> > I don't intend to toggle a GPIO as fast as possible (except to test), 
> but from a performance standpoint that demonstration seemed to indicate 
> that there are issues with sysfs. Hopefully, libgpiod will prove to be 
> better!
>
> Bartosz explains the differences and improvements that new gpiod
> interface provides in this talk:
> https://www.youtube.com/watch?v=cdTLewJCL1Y
>
> Essentially, if you need read or set multiple lines, it is faster.
> Also, it has an improved way to read events as well.
>
> Slides if you prefer over video:
>
> https://ostconf.com/system/attachments/files/000/001/532/original/Linux_Piter_2018_-_New_GPIO_interface_for_linux_userspace.pdf?1541021776
>

-- 
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/16a18eef-a649-46d9-b126-f774a8eb1522n%40googlegroups.com.

[beagleboard] Python example of continuous analog in

[Mark A. Yoder]

I have a python example here[1] of how to setup the Beagle to do continuous 
analog in and plot it via gnuplot.
[image: tri10k.png]

The example also shows which device tree to edit to set the sampling rate 
to 200k samples/second.

I hope someone finds it helpful.

--Mark
[1] https://elinux.org/EBC_Exercise_10a_Analog_In#Analog_in_-_Continuous

-- 
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/55f76994-deab-4d3f-b34e-c0629d966897n%40googlegroups.com.

[beagleboard] Re: printf support when you program PRUs in beagle board AI

[Mark A. Yoder]

The PRU Cookbook[1] has an example of using the UART and printf on the 
PRU[2].  Maybe it will help.

--Mark

[1] https://github.com/MarkAYoder/PRUCookbook
[2] https://markayoder.github.io/PRUCookbook/04debug/debug.html#_uart

On Monday, July 20, 2020 at 12:15:42 PM UTC-4 sreeko...@gmail.com wrote:

> Hi
>
> I am just trying to print some values to check if the condition meets the 
> requirement in beagle bone AI board. But it is not happening when I program 
> PRUs.
>
> Do I have to configure UART in PRU to achieve this capability?
>
> please help me crack this, help would be appreciated,
>
> thank you'
> sreekanth m.
>

-- 
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/3f00cc45-b545-44c4-9851-c0564855b018n%40googlegroups.com.

[beagleboard] Re: Problems reading PRU data RAM from host side on beaglebone black

[Mark A. Yoder]

Chris:
  The code you give is running on the ARM side.  It's copying data from the 
PRUs by mmap().  What's running on the PRU side?  If it c code, did you 
take into account the PRU c compiler stores it's stack and heap at the 
beginning of the shared ram?

--Mark

On Saturday, July 18, 2020 at 3:47:28 PM UTC-4 hans...@gmail.com wrote:

> I'm using both PRU0 and PRU1 for data acquition.  The PRUs write data to 
> their respective memory blocks and I read the data from the host arm core 
> via mmaps.  I.E.,
>
>  pru0mem = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
> PRU0_RAM & ~MAP_MASK);
>   pru1mem = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
> PRU1_RAM & ~MAP_MASK);
>   pru0point = (int32_t *) mmap(0, MAP_SIZE, PROT_READ, MAP_SHARED, fd, 
> PRU_SHARED & ~MAP_MASK);
>
> bigbuf[k] = prumem0[k];
> ...
> where bigbuf is a big array on the arm side.
>
> It seems to work, however, when it runs continuously it seems like there 
> is some type of random glitch where occasionally I am getting bad data.  
> Any idea how this could happen?  Could it be something with the pru_rproc 
> driver?  Is there a better way to do this?
>
> Thanks.
> Chris
>
>

-- 
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/6c68d818-fabc-45a7-ab01-6f521b8111fcn%40googlegroups.com.

[beagleboard] Re: soft UART implementation on the AM335x PRU

[Mark A. Yoder]

I've just posted v2 of the PRU Cookbook[1].  It should help with some of 
your questions.

I suggest doing all the development in cloud9 on the Beagle.  the PRU 
compiler is already installed on the current images.

--Mark
[1] https://github.com/MarkAYoder/PRUCookbook


On Friday, June 19, 2020 at 9:37:17 AM UTC-4, awainia...@gmail.com wrote:
>
> Hello,
>
> I am still a newbie to PRU development, and I am trying to  use the 9 bits 
> UART capability of the UART PRU firmware and I have a couple of questions 
>
> 1- in the code composer studio,do I use the PRU compiler or the ARM 
> compiler ?
> 2- do i have to use sys/bios when using the soft implementatio of the UART 
> ? if so how to upload the generated file to the card without an emulator, ( 
> I used FTP to deploy .out files to the beaglebone black and then coppying 
> the firmware to the remoteproc when getting introduced to the PRU 
> development)
>  
>

-- 
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/1edca93b-87b1-413f-a688-e4821149b17eo%40googlegroups.com.

Re: [beagleboard] eQEP Python error on PocketBeagle

[Mark A. Yoder]

It's also missing on the 5.4 and 4.14 kernels.

On Wednesday, June 17, 2020 at 10:01:10 AM UTC-4, Mark A. Yoder wrote:
>
> Drew:
>   Yes, 
> /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep
>
> is missing.  There's no errors in dmesg about eqp.
>
> I'm running the current image.
> *cat /ID.txt *
> BeagleBoard.org Debian Buster IoT Image 2020-04-06 
> *uname -a *
> Linux pocket 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 
> 2020 armv7l GNU/Linux 
>
>
> On Wednesday, June 17, 2020 at 8:05:13 AM UTC-4, Drew Fustini wrote:
>>
>> On Wed, Jun 17, 2020 at 2:26 AM Mark A. Yoder  wrote: 
>> > 
>> > I'm trying to use the encoders via Python: 
>> > 
>> > from Adafruit_BBIO.Encoder import RotaryEncoder, eQEP2 
>> > import time 
>> > 
>> > 
>> > # Instantiate the class to access channel eQEP2, and initialize 
>> > # that channel 
>> > myEncoder = RotaryEncoder(eQEP2) 
>> > 
>> > 
>> > # Get the current position 
>> > 
>> > 
>> > while True: 
>> > cur_position = myEncoder.position 
>> > print(cur_position) 
>> > time.sleep(1) 
>> > 
>> > But I get the following error: 
>> > 
>> > Traceback (most recent call last): 
>> >   File "./eQEP.py", line 8, in  
>> > myEncoder = RotaryEncoder(eQEP2) 
>> >   File 
>> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py",
>>  
>> line 195, in __init__ 
>> > self._eqep = _eQEP.fromdict(_eQEP_DEFS[eqep_num]) 
>> >   File 
>> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py",
>>  
>> line 126, in fromdict 
>> > return cls(**df) 
>> >   File 
>> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py",
>>  
>> line 150, in __init__ 
>> > self.node = Node(sys_path) 
>> >   File 
>> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/sysfs.py",
>>  
>> line 78, in __init__ 
>> > self.__dict__.update(dict.fromkeys(listdir(self._path_))) 
>> > FileNotFoundError: [Errno 2] No such file or directory: 
>> '/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep' 
>> > 
>> > 
>> > I'm running a current image: 
>> > 
>> > cat /ID.txt 
>> > BeagleBoard.org Debian Buster IoT Image 2020-04-06 
>> > name -a 
>> > Linux pocket 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 
>> UTC 2020 armv7l GNU/Linux 
>> > 
>> > Any suggestions on how to make it work? 
>> > 
>> > --Mark 
>>
>> I think the problem is 
>> /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep is missing. 
>>
>> It is possible the eQEP driver is not being loaded.  I've not tried to 
>> use it in a long time. 
>>
>> Which image are you using?  I can try to replicate. 
>>
>> thanks, 
>> drew 
>>
>

-- 
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/d03c8786-a49c-4f11-af6b-b84037524628o%40googlegroups.com.

Re: [beagleboard] eQEP Python error on PocketBeagle

[Mark A. Yoder]

Drew:
  Yes, 
/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep

is missing.  There's no errors in dmesg about eqp.

I'm running the current image.
*cat /ID.txt *
BeagleBoard.org Debian Buster IoT Image 2020-04-06 
*uname -a *
Linux pocket 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 
2020 armv7l GNU/Linux 


On Wednesday, June 17, 2020 at 8:05:13 AM UTC-4, Drew Fustini wrote:
>
> On Wed, Jun 17, 2020 at 2:26 AM Mark A. Yoder  wrote: 
> > 
> > I'm trying to use the encoders via Python: 
> > 
> > from Adafruit_BBIO.Encoder import RotaryEncoder, eQEP2 
> > import time 
> > 
> > 
> > # Instantiate the class to access channel eQEP2, and initialize 
> > # that channel 
> > myEncoder = RotaryEncoder(eQEP2) 
> > 
> > 
> > # Get the current position 
> > 
> > 
> > while True: 
> > cur_position = myEncoder.position 
> > print(cur_position) 
> > time.sleep(1) 
> > 
> > But I get the following error: 
> > 
> > Traceback (most recent call last): 
> >   File "./eQEP.py", line 8, in  
> > myEncoder = RotaryEncoder(eQEP2) 
> >   File 
> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py",
>  
> line 195, in __init__ 
> > self._eqep = _eQEP.fromdict(_eQEP_DEFS[eqep_num]) 
> >   File 
> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py",
>  
> line 126, in fromdict 
> > return cls(**df) 
> >   File 
> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py",
>  
> line 150, in __init__ 
> > self.node = Node(sys_path) 
> >   File 
> "/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/sysfs.py",
>  
> line 78, in __init__ 
> > self.__dict__.update(dict.fromkeys(listdir(self._path_))) 
> > FileNotFoundError: [Errno 2] No such file or directory: 
> '/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep' 
> > 
> > 
> > I'm running a current image: 
> > 
> > cat /ID.txt 
> > BeagleBoard.org Debian Buster IoT Image 2020-04-06 
> > name -a 
> > Linux pocket 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 
> 2020 armv7l GNU/Linux 
> > 
> > Any suggestions on how to make it work? 
> > 
> > --Mark 
>
> I think the problem is 
> /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep is missing. 
>
> It is possible the eQEP driver is not being loaded.  I've not tried to 
> use it in a long time. 
>
> Which image are you using?  I can try to replicate. 
>
> thanks, 
> drew 
>

-- 
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/4cd0889e-e2e4-4974-b292-5977eb1d1813o%40googlegroups.com.

[beagleboard] eQEP Python error on PocketBeagle

[Mark A. Yoder]

I'm trying to use the encoders via Python:

from Adafruit_BBIO.Encoder import RotaryEncoder, eQEP2
import time


# Instantiate the class to access channel eQEP2, and initialize
# that channel
myEncoder = RotaryEncoder(eQEP2)


# Get the current position


while True:
cur_position = myEncoder.position
print(cur_position)
time.sleep(1)

But I get the following error:

Traceback (most recent call last):
  File "./eQEP.py", line 8, in 
myEncoder = RotaryEncoder(eQEP2)
  File 
"/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py"
, line 195, in __init__
self._eqep = _eQEP.fromdict(_eQEP_DEFS[eqep_num])
  File 
"/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py"
, line 126, in fromdict
return cls(**df)
  File 
"/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/Encoder.py"
, line 150, in __init__
self.node = Node(sys_path)
  File 
"/usr/local/lib/python3.7/dist-packages/Adafruit_BBIO-1.1.1-py3.7-linux-armv7l.egg/Adafruit_BBIO/sysfs.py"
, line 78, in __init__
self.__dict__.update(dict.fromkeys(listdir(self._path_)))
FileNotFoundError: [Errno 2] No such file or directory: 
'/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep'


I'm running a current image:

cat /ID.txt 
BeagleBoard.org Debian Buster IoT Image 2020-04-06
name -a
Linux pocket 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 
2020 armv7l GNU/Linux

Any suggestions on how to make it work?

--Mark



-- 
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/de74f762-06c9-4a26-867f-45c8f178e7d1o%40googlegroups.com.

[beagleboard] Re: PocketScroller pin out

[Mark A. Yoder]

Dan:
  Thanks for the help.  It turns out the panel was plugged into connector 
J6, rather than J1.  Once I figure that out things made much more sense.

--Mark

The other things I learned is don't leave PRU 1 running while trying to 
debug PRU 0.

On Sunday, June 14, 2020 at 4:02:18 PM UTC-4, Daniel Kulp wrote:
>
>
> The newer pocketscrollers are use a slightly different pinout than the 
> originals.  The OE line was moved to a pin that could use the PWM hardware 
> in hopes of updating the PRU code to use that, but I never got around to 
> doing that. 
>
> If you are using one of the newer PocketScrollers with the OLED 
> header/buttons, then you can SSH into the FPP instance and look in 
> /home/fpp/media/tmp/panels and there is a JSON file that describes the pins 
> the various outputs use.  If using the older PocketScroller without the 
> eeprom, you would look in /opt/fpp/capes/pb/panels/PocketScroller.json.
>
> Dan
>
>
> On Friday, June 12, 2020 at 4:39:13 PM UTC-4, Mark A. Yoder wrote:
>>
>> I have a PocketScroller on my Pocket Beagle.  In the past I've had no 
>> trouble running fpp on it.
>>
>> Now I want to drive it directly from by own PRU code[1].  The code worked 
>> fine when I hand wired the P10 panel to my Pocket Beagle, but I don't know 
>> how things are attached internally so the
>> code doesn't work.  
>>
>> Is there a schematic I could reference?
>>
>> Thanks...
>>
>> --Mark
>>
>> [1] 
>> https://github.com/MarkAYoder/PRUCookbook/blob/master/docs/05blocks/code/rgb1.c
>>
>

-- 
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/3da41fc8-ad21-43be-8369-34428b525955o%40googlegroups.com.

[beagleboard] PocketScroller pin out

[Mark A. Yoder]

I have a PocketScroller on my Pocket Beagle.  In the past I've had no 
trouble running fpp on it.

Now I want to drive it directly from by own PRU code[1].  The code worked 
fine when I hand wired the P10 panel to my Pocket Beagle, but I don't know 
how things are attached internally so the
code doesn't work.  

Is there a schematic I could reference?

Thanks...

--Mark

[1] 
https://github.com/MarkAYoder/PRUCookbook/blob/master/docs/05blocks/code/rgb1.c

-- 
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/9074bd2b-d8af-4478-b745-1c56fd5f65b2o%40googlegroups.com.

Re: [beagleboard] Re: BBAI accessing PRU UART

[Mark A. Yoder]

Mark:
  Got it ported!

It turns out the am572x pru_uart.h has more descriptive names for the 
fields than the am53xx pru_uart.h did.  So DLL is converted 
to DIVISOR_REGISTER_LSB_ and so on.

Plus I had to find the right pins on the P8 header and get the device tree 
configured to bring out the pru uart.  And make the rx pin is set to an 
INPUT.

But it's now working.  It's all documented here[1], but it won't appear in 
a nice format until I merge the changes with the master branch.

--Mark

[1] 
https://github.com/MarkAYoder/PRUCookbook/blob/v2.0/docs/04debug/debug.html

On Thursday, June 11, 2020 at 11:50:10 AM UTC-4, lazarman wrote:
>
> Hi Mark
>
> Good point.
> EE or CE. In 81 We were handed an MCS51 manual and told to program a 
> digital clock on an Intel eval board that had 7 segment LCD and promised an 
> A if we could get it to work. 6 registers  6 segments. Only one person got 
> it but he was a straight A student. 
>
> If it was me I'd do a brief lecture on Memory Maps and porting issues 
> related.
> I have to say the 2 classes I enjoyed the most were related to issues you 
> see  in real world but generally are not covered in school
>
> One focused on microprocessor pin drive capabilities and
> The other was a GE Medical Engineer focused on noise and modeling it in 
> spice for high integrity  signals as in used in cat scan A/D 
>
> I see a lot of young engineer's intimidated by the TRM  which usually have 
> steps to program Karts perhaps  a step by step comparison  of these 
> instructions in verbage to the C code along with added comments oh he's 
> setting this bit and that does this would be helpful to a budding low level 
> microprocessor lover of the future. I'm retired myself don't have an AI 
> board but could envisio myself porting this at work because  my boss 
> didn't  have any work for me.
>
> Those C files look alot like what my last job had gotten from TI  to bring 
> up the boot level part of an RTOS based product. They also board support 
> files  provided by the BSP/RTOS  vendor. The RTOS files were propriety. 
> It's also good to see them available  on within good resources  for bare 
> metal type stuff which is what PRU is. I worked  with Mark Kraeling at 
> Cummins and then GE we were using NXP ARM when I left for TI he spoke 
> highly of you and of course was a proud alumni  but I couldn't sell him the 
> TI based solutions mainly  necause they were RTOS based company. I did 
> point him tobthe fact you were using this platform to teach.  You duing9 
> something that's awesome  I think for our engineer's 
>
> Regards 
>
> Mark
>
>
>
>
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Thu, Jun 11, 2020 at 9:47 AM, Mark A. Yoder
> <> wrote:
> An interesting suggestion.  The trick then is figuring out what background 
> most they need to solve it.
>
> --Mark
>
> On Wednesday, June 10, 2020 at 7:44:04 PM UTC-4, lazarman wrote:
>
> Porting that might be a good class project for your student's 
>  Mod the offsets if the register offsets have changed between  chips in 
> the .h file.
>  the UART itself is HW IP I bet. If done  properly  the .c wouldn't  
> change 
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Wed, Jun 10, 2020 at 11:51 AM, Mark A. Yoder
> <> wrote:
> It turns out I don't have PRU code for the AI to access it's UART.  There 
> are examples
> here[1] for the Black's am335x, but not the AI's am5729.
>
> --Mark
>
> [1] https://git.ti.com/cgit/ pru-software-support-package/ 
> pru-software-support-package/ tree/examples/ 
> <https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/>
>
> On Tuesday, June 9, 2020 at 10:14:27 PM UTC-4, Dennis Bieber wrote:
>
> On Tue, 9 Jun 2020 14:00:21 -0700 (PDT), in 
>
> gmane.comp.hardware. beagleboard.user "Mark A. Yoder" 
>  > wrote: 
>
> >I see the BBAI has a JST connector for accessing a UART.   
>
> I believe that is the UART used by u-boot and the kernel -- 
> essentially 
> a console debug port, though it may be available under Linux (the SRM is 
> confusing... That connector appears to be UART1, while UART3/5/8/10 go to 
> P8 and P9, variously, and the PRU UART0 [PRU1 and PRU2] go to P8). No idea 
> where UART2/4/6/7/9 go... 
>
>
>
> -- 
> 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 
>

Re: [beagleboard] Re: BBAI accessing PRU UART

[Mark A. Yoder]

An interesting suggestion.  The trick then is figuring out what background 
they need to solve it.

--Mark

On Wednesday, June 10, 2020 at 7:44:04 PM UTC-4, lazarman wrote:
>
> Porting that might be a good class project for your student's 
>  Mod the offsets if the register offsets have changed between  chips in 
> the .h file.
>  the UART itself is HW IP I bet. If done  properly  the .c wouldn't  
> change 
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Wed, Jun 10, 2020 at 11:51 AM, Mark A. Yoder
> <> wrote:
> It turns out I don't have PRU code for the AI to access it's UART.  There 
> are examples
> here[1] for the Black's am335x, but not the AI's am5729.
>
> --Mark
>
> [1] 
> https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/
>
> On Tuesday, June 9, 2020 at 10:14:27 PM UTC-4, Dennis Bieber wrote:
>
> On Tue, 9 Jun 2020 14:00:21 -0700 (PDT), in 
>
> gmane.comp.hardware. beagleboard.user "Mark A. Yoder" 
>  > wrote: 
>
> >I see the BBAI has a JST connector for accessing a UART.   
>
> I believe that is the UART used by u-boot and the kernel -- 
> essentially 
> a console debug port, though it may be available under Linux (the SRM is 
> confusing... That connector appears to be UART1, while UART3/5/8/10 go to 
> P8 and P9, variously, and the PRU UART0 [PRU1 and PRU2] go to P8). No idea 
> where UART2/4/6/7/9 go... 
>
>
>
> -- 
> 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/5815c826-3d03-4763-8399-3e6293f6ba28o%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/5815c826-3d03-4763-8399-3e6293f6ba28o%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/e705baeb-415c-448d-886a-92e4179e8dc7o%40googlegroups.com.

[beagleboard] Re: rpmsg example on working on AI

[Mark A. Yoder]

I figured it out.  I have the wrong include file.  I switched code from 
PRU0 to PRU1_1 and should have used:

#include "resource_table_*1*.h"

I was using the *0* version.

--Mark

On Wednesday, June 10, 2020 at 3:26:25 PM UTC-4, Mark A. Yoder wrote:
>
> I have an rpmsg example[1] that runs on the BB Black.  It creates 
> */dev/rpmsg_pru30* which allows the ARM to talk to PRU0.
>
> I have a parallel example[2] that's supposed to run on PRU 1_1 on the AI 
> and do the same thing.  I thought it was working last year.
> Now, it doesn't even create */dev/rpmsg_pru30.* 
>
> Any ideas what might have broken since last year?
>
> I'm running the current image (BeagleBoard.org Debian Buster IoT Image 
> 2020-04-06) on the Black and the AI.
>
> --Mark
>
> [1] 
> https://github.com/beagleboard/cloud9-examples/blob/v2020.01/BeagleBone/Black/pru/neopixelRpmsg.pru0.c
> [2] 
> https://github.com/beagleboard/cloud9-examples/blob/v2020.01/BeagleBone/AI/pru/neopixelRpmsg.pru1_1.c
>

-- 
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/7b63c701-fe8d-4f5e-9cb7-0e4902f61986o%40googlegroups.com.

[beagleboard] rpmsg example on working on AI

[Mark A. Yoder]

I have an rpmsg example[1] that runs on the BB Black.  It creates 
*/dev/rpmsg_pru30* which allows the ARM to talk to PRU0.

I have a parallel example[2] that's supposed to run on PRU 1_1 on the AI 
and do the same thing.  I thought it was working last year.
Now, it doesn't even create */dev/rpmsg_pru30.* 

Any ideas what might have broken since last year?

I'm running the current image (BeagleBoard.org Debian Buster IoT Image 
2020-04-06) on the Black and the AI.

--Mark

[1] 
https://github.com/beagleboard/cloud9-examples/blob/v2020.01/BeagleBone/Black/pru/neopixelRpmsg.pru0.c
[2] 
https://github.com/beagleboard/cloud9-examples/blob/v2020.01/BeagleBone/AI/pru/neopixelRpmsg.pru1_1.c

-- 
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/47bbb876-72fb-4502-9036-425f39186288o%40googlegroups.com.

[beagleboard] Re: BBAI accessing PRU UART

[Mark A. Yoder]

It turns out I don't have PRU code for the AI to access it's UART.  There 
are examples
here[1] for the Black's am335x, but not the AI's am5729.

--Mark

[1] 
https://git.ti.com/cgit/pru-software-support-package/pru-software-support-package/tree/examples/

On Tuesday, June 9, 2020 at 10:14:27 PM UTC-4, Dennis Bieber wrote:
>
> On Tue, 9 Jun 2020 14:00:21 -0700 (PDT), in 
> gmane.comp.hardware.beagleboard.user "Mark A. Yoder" 
>  wrote: 
>
> >I see the BBAI has a JST connector for accessing a UART.   
>
> I believe that is the UART used by u-boot and the kernel -- 
> essentially 
> a console debug port, though it may be available under Linux (the SRM is 
> confusing... That connector appears to be UART1, while UART3/5/8/10 go to 
> P8 and P9, variously, and the PRU UART0 [PRU1 and PRU2] go to P8). No idea 
> where UART2/4/6/7/9 go... 
>
>
>
> -- 
> 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/5815c826-3d03-4763-8399-3e6293f6ba28o%40googlegroups.com.

[beagleboard] BBAI accessing PRU UART

[Mark A. Yoder]

I see the BBAI has a JST connector for accessing a UART.  

Can I access the PRU UART?  Do I access  it from this JST connector?

--Mark

-- 
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/11a3f786-8943-474f-bdb4-af681aa9326eo%40googlegroups.com.

[beagleboard] Re: PRU pins on BBAI

[Mark A. Yoder]

It's not a problem.  I'm just surprised to see several on the ICSS2 PRU0 
pins are attached to the header in two places.

--Mark

On Thursday, June 4, 2020 at 2:13:10 PM UTC-4, Mark A. Yoder wrote:
>
> I see that the SRM[1] ([2] is easier to read) for the BBAI shows that some 
> PRU pins appear at 2 of the P8/P9 header pins.
>
> Is this really so?
>
> --Mark
>
> [1] 
> https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#pru-icss2-pin-access
> [2] 
> https://docs.google.com/spreadsheets/d/1dFSBVem86vAUD7MLXvqdS-N0Efi8_g_O1iTqzql8DAo/edit#gid=0
>

-- 
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/9c98fc7f-b143-42f5-8a4c-148c7f1cdf4eo%40googlegroups.com.

[beagleboard] PRU pins on BBAI

[Mark A. Yoder]

I see that the SRM[1] ([2] is easier to read) for the BBAI shows that some 
PRU pins appear at 2 of the P8/P9 header pins.

Is this really so?

--Mark

[1] 
https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#pru-icss2-pin-access
[2] 
https://docs.google.com/spreadsheets/d/1dFSBVem86vAUD7MLXvqdS-N0Efi8_g_O1iTqzql8DAo/edit#gid=0

-- 
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/2d54785c-148b-45e6-9475-7b5d23861e10o%40googlegroups.com.

Re: [beagleboard] config-pin for gpio output

[Mark A. Yoder]

Well, my solution, for now, was to write a wrapper[1] for config-pin that 
uses gpioinfo when 'in' or 'out' are used.

--Mark

[1] 
https://github.com/MarkAYoder/PRUCookbook/blob/v2.0/docs/common/config-pin.sh

On Wednesday, June 3, 2020 at 10:27:38 AM UTC-4, RobertCNelson wrote:
>
> On Wed, Jun 3, 2020 at 9:15 AM Mark A. Yoder <> wrote: 
> > 
> > So is, 
> >  echo out > /sys/class/gpio/gpio30/direction 
> > 
> > The proper way to set it to output? 
>
> The proper way is to use libgpiod tools such as gpioset ;) 
>
> sudo gpioset gpiochip0 30=1 
>
> But that old way still woks. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/80eeb3ac-bdff-4bf4-82d0-43781dbe8371%40googlegroups.com.

Re: [beagleboard] config-pin for gpio output

[Mark A. Yoder]

So is,  
 echo out > /sys/class/gpio/gpio30/direction

The proper way to set it to output?

--Mark

On Wednesday, June 3, 2020 at 9:45:00 AM UTC-4, RobertCNelson wrote:
>
> On Wed, Jun 3, 2020 at 8:16 AM Mark A. Yoder  wrote: 
> > 
> > In the day I did: 
> > 
> > config-pin P9_11 out 
> > 
> > to make it a gpio output.  Now it appears I have to do: 
> > 
> > config-pin P9_11 gpio 
> > 
> > But how do I make it an output?  Must I do: 
> > 
> > echo out > /sys/class/gpio/gpio30/direction  ? 
>
> The concept of out/in is not currently supported in the c based 
> re-write of config-pin used in Buster.. 
>
>
> https://github.com/beagleboard/bb.org-overlays/tree/master/tools/pmunts_muntsos
>  
>
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin#L1088-L1108
>  
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9ec1351c-9cfe-4e82-9b34-9b099dc2c33c%40googlegroups.com.

[beagleboard] config-pin for gpio output

[Mark A. Yoder]

In the day I did:

*config-pin P9_11 out*

to make it a gpio output.  Now it appears I have to do:

*config-pin P9_11 gpio*

But how do I make it an output?  Must I do:

*echo out > /sys/class/gpio/gpio30/direction*  ?

--Mark

-- 
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/850578e5-9a98-466c-8f0e-8409f70254e3%40googlegroups.com.

[beagleboard] Re: how to access GPIO on Beaglebone AI via /dev/mem

[Mark A. Yoder]

Here[1] are some notes I wrote for my students for accessing GPIO via 
/dev/mem on the BB Black.  I'm not sure how much carries over to the AI.

--Mark

[1] https://elinux.org/EBC_Exercise_11b_gpio_via_mmap

On Friday, March 27, 2020 at 1:13:57 PM UTC-4, Dennis Bieber wrote:
>
> On Fri, 27 Mar 2020 05:37:02 -0700 (PDT), in 
> gmane.comp.hardware.beagleboard.user John Allwine 
>  wrote: 
>
>
> >What is or how do I find the control register address for the AM5x? The 
> system 
> >manual 
> ><
> https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#connector-p8>
>  
> seems 
> >to list the offsets from the control register, but I'm unsure what that 
> is. 
> > 
>
> Probably in the TI technical reference manual SPRUHZ6L ( 
>
> https://www.google.com/url?sa=t=j==s=web=1=2ahUKEwirrfuAk7voAhUOQK0KHbWUBAsQFjAAegQIBBAB=http%3A%2F%2Fwww.ti.com%2Flit%2Fug%2Fspruhz6l%2Fspruhz6l.pdf=AOvVaw2uBbdusraPEVEasMDIT-r7
>  
> ). Section 27.6 seems a candidate... 
>
> """ 
> 27.6.1 General-Purpose Interface Instance Summary 
> Table 27-16 summarizes the general-purpose interface instance. 
> Table 27-16. Instance Summary 
> Module Name Module Base Address Size 
> GPIO7 0x4805 1000 408 Bytes 
> GPIO8 0x4805 3000 408 Bytes 
> GPIO2 0x4805 5000 408 Bytes 
> GPIO3 0x4805 7000 408 Bytes 
> GPIO4 0x4805 9000 408 Bytes 
> GPIO5 0x4805 B000 408 Bytes 
> GPIO6 0x4805 D000 408 Bytes 
> GPIO1 0x4AE1  408 Bytes 
> """ 
>
>
> -- 
> 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/0550e92c-41b8-4c60-8670-e563c6fac9e1%40googlegroups.com.

[beagleboard] Re: Best IDE for kernel and PRU programming and debugging for the Beaglebone Black

[Mark A. Yoder]

I found the builtin Cloud9 IDE worked fine for me for the PRU Cookbook[1].  
prudebug[2] is a simple way to see the registers.

It's already installed, so it pretty easy to get started.

--Mark

[1] https://github.com/MarkAYoder/PRUCookbook
[2] 
https://markayoder.github.io/PRUCookbook/04debug/debug.html#debug_prudebug

On Thursday, February 27, 2020 at 11:24:40 AM UTC-5, eadbos...@gmail.com 
wrote:
>
>
>I am currently using visualgdb with visual micorsoft visual studio. I 
> don't have any issues with applications, but I don't have the visibility 
> with the kernel or PRU's. Should I just use TI studio composer? 
>

-- 
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/53eb543e-f5f9-4f76-9391-7c2dea5ea5f8%40googlegroups.com.

[beagleboard] Re: Stopping an restarting cloud9

[Mark A. Yoder]

Rebooting caused cloud9 to restart.

Using iptables to block port 3000 might be the easiest thing to do.

--Mark

On Saturday, January 4, 2020 at 3:21:14 PM UTC-5, Mark A. Yoder wrote:
>
> I'd like to be able to stop and later restart cloud9.  The following 
> stopped cloud9
>
> bone$ *sudo systemctl stop cloud9*
>
> But the following didn't restart it.
>
> bone$ *sudo systemctl start cloud9*
> bone$ *systemctl status cloud9*
> ● cloud9.service - Cloud9 IDE
>Loaded: loaded (/lib/systemd/system/cloud9.service; static; vendor 
> preset: enabled)
>Active: failed (Result: exit-code) since Sat 2020-01-04 19:45:12 UTC; 
> 2s ago
>   Process: 5485 ExecStartPre=/opt/cloud9/cloud9-symlink (code=exited, 
> status=0/SUCCESS)
>   Process: 5491 ExecStart=/opt/cloud9_support/bin/node server.js --packed 
> -w /var/lib/cloud9 (code=exited, status=1/FAILURE)
>  Main PID: 5491 (code=exited, status=1/FAILURE)
>
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  port: '3000',
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  host: '127.0.0.1',
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  websocket: true,
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  showRealIP: true,
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  secure: undefined,
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  provides: [ 'connect', 'http' 
> ],
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  consumes: [],
> Jan 04 19:45:12 ece312 cloud9ide[5491]:  setup: [Function: startup] } 
> } 'Error: No or too many file descriptors received.\nat Server.listen 
> (/opt/cloud9/node_modules
> Jan 04 19:45:12 ece312 systemd[1]: cloud9.service: Main process exited, 
> code=exited, status=1/FAILURE
> Jan 04 19:45:12 ece312 systemd[1]: cloud9.service: Failed with result 
> 'exit-code'.
>
> bone$ *cat /ID.txt*
> BeagleBoard.org Debian Image 2019-12-16
> bone $ *uname -a*
> Linux ece312 4.19.79-ti-r30 #1buster SMP PREEMPT Mon Nov 4 20:38:01 UTC 
> 2019 armv7l GNU/Linux
>
> Or is there a better way to turn off cloud9 access and restore it later?
>
> --Mark
>

-- 
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/3b39975d-e122-4af4-905f-97cd11ffa8e4%40googlegroups.com.

[beagleboard] Stopping an restarting cloud9

[Mark A. Yoder]

I'd like to be able to stop and later restart cloud9.  The following 
stopped cloud9

bone$ *sudo systemctl stop cloud9*

But the following didn't restart it.

bone$ *sudo systemctl start cloud9*
bone$ *systemctl status cloud9*
● cloud9.service - Cloud9 IDE
   Loaded: loaded (/lib/systemd/system/cloud9.service; static; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-01-04 19:45:12 UTC; 2s 
ago
  Process: 5485 ExecStartPre=/opt/cloud9/cloud9-symlink (code=exited, 
status=0/SUCCESS)
  Process: 5491 ExecStart=/opt/cloud9_support/bin/node server.js --packed 
-w /var/lib/cloud9 (code=exited, status=1/FAILURE)
 Main PID: 5491 (code=exited, status=1/FAILURE)

Jan 04 19:45:12 ece312 cloud9ide[5491]:  port: '3000',
Jan 04 19:45:12 ece312 cloud9ide[5491]:  host: '127.0.0.1',
Jan 04 19:45:12 ece312 cloud9ide[5491]:  websocket: true,
Jan 04 19:45:12 ece312 cloud9ide[5491]:  showRealIP: true,
Jan 04 19:45:12 ece312 cloud9ide[5491]:  secure: undefined,
Jan 04 19:45:12 ece312 cloud9ide[5491]:  provides: [ 'connect', 'http' 
],
Jan 04 19:45:12 ece312 cloud9ide[5491]:  consumes: [],
Jan 04 19:45:12 ece312 cloud9ide[5491]:  setup: [Function: startup] } } 
'Error: No or too many file descriptors received.\nat Server.listen 
(/opt/cloud9/node_modules
Jan 04 19:45:12 ece312 systemd[1]: cloud9.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 04 19:45:12 ece312 systemd[1]: cloud9.service: Failed with result 
'exit-code'.

bone$ *cat /ID.txt*
BeagleBoard.org Debian Image 2019-12-16
bone $ *uname -a*
Linux ece312 4.19.79-ti-r30 #1buster SMP PREEMPT Mon Nov 4 20:38:01 UTC 
2019 armv7l GNU/Linux

Or is there a better way to turn off cloud9 access and restore it later?

--Mark

-- 
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/e2529db4-b210-4ba3-875c-9073f90b48d3%40googlegroups.com.

[beagleboard] Re: Build device tree for 1-wire failed

[Mark A. Yoder]

I think dtc doesn't do the preprocess of the include files.  The easiest 
way might be to follow the instructions here[1] to find the sources on your 
bone.  Put your new .dts file in with the sources in src/arm and run make.

--Mark

[1] https://elinux.org/EBC_Exercise_31_Dallas_1-Wire

On Monday, November 18, 2019 at 11:22:57 AM UTC-5, Fohnbit wrote:
>
> Hello,
>
> I used the P9.12 pin for 1-wire ... this is working.
>
> Now I want 2 lanes more. I thought to use for the second lane: P8.27 and 
> P8.28
>
> /*
>  * Copyright (C) 2015 Robert Nelson >
>  *
>  * Virtual cape for onewire on connector pin P9.12
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
>
> /* Modified by Connor Shapiro for use with P8.27 & P8.28 */
>
> /dts-v1/;
> /plugin/;
>
> #include 
> #include 
> #include 
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black", 
> "ti,beaglebone-green";
>
> /* identification */
> part-number = "BB-W1-P8.27_28";
> version = "00A0";
>
> /* state the resources this cape uses */
> exclusive-use =
> /* the pin header uses */
> "P8.27",
> "P8.28";
>
> /*
>  * Free up the pins used by the cape from the pinmux helpers.
>  */
> fragment@0 {
> target = <>;
> __overlay__ {
> P8_27_pinmux { status = "disabled"; };
> P8_28_pinmux { status = "disabled"; };
> };
> };
> 
> fragment@1 {
> target = <_pinmux>;
> __overlay__ {
>
> dallas_w1_1_pins: pinmux-dallas-w1-1pins {
> pinctrl-single,pins = < 
> BONE_P8_27 0x37
> >;
> };
>
> dallas_w1_2_pins: pinmux-dallas-w1-2-pins {
> pinctrl-single,pins = < 
> BONE_P8_28 0x37
> >;
> };
> };
> };
> fragment@2 {
> target-path="/";
> __overlay__ {
>
> onewire2 {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_w1_pins>;
>
> compatible = "w1-gpio";
> gpios = < 22 GPIO_ACTIVE_HIGH>;
> };
> };
> };
>
> fragment@3 {
> target-path="/";
> __overlay__ {
>
> onewire3 {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <_w1_pins>;
>
> compatible = "w1-gpio";
> gpios = < 24 GPIO_ACTIVE_HIGH>;
> };
> };
> };
> };
>
>
> But when I try to compile, I get an error:
> > dtc -O dtb -o BB-W1-P8.27_28-00A0.dtbo -b o -@ BB-W1-P8.27_28-00A0.dts
> Error: BB-W1-P8.27_28-00A0.dts:16.1-9 syntax error
> FATAL ERROR: Unable to parse input tree
>
> Line 16:
>
> #include 
> Maybe this are not existing on my BBB?
>
> Thank you!
>
>

-- 
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/9a22fcfb-5701-4799-bfcf-9d05f2b65775%40googlegroups.com.

Re: [beagleboard] 1-wire not working

[Mark A. Yoder]

The one-wire device appears in a different place now.

Here's an example I worked up that's from 
https://elinux.org/EBC_Exercise_31_Dallas_1-Wire

Reading the DS18B20[edit 

]

bone$ *cd /sys/class/hwmon/*
hwmon0  hwmon1

Oh, we have two devices here. Let's see which is which

bone$ *cat */name*
w1_slave_temp
tmp101

So one is our one-wire temp sensor and the other is a tmp101 sensor. Let's 
read ours.

bone$ *cd hwmon0*
bone$ *ls*
device  name  power  subsystem  temp1_input  uevent
bone$ *cat temp1_input*
20812

The *20812* is the temperature in C times 1000, that is, divide this number 
by 1000 to get the temp in C.

On Monday, November 18, 2019 at 11:58:28 AM UTC-5, Jim F wrote:
>
> 1w didn't work in that version of Linux. It works in 4.14 if you enable 
> the dtb file in uenv.txt. So I think you'll have to update. 
>
> It looks like it should support multiple devices, but we're only using 
> one, so I haven't tried.
>
> Good luck. 
>
> -j
>
> On Mon, Nov 18, 2019, 10:28 AM Fohnbit > 
> wrote:
>
>> Hello,
>>
>> I tried to enable 1-wire, but did not found some paths .. maybe my 
>> installation is different?
>>
>> I´m not sure what you need, so I write what I did so far:
>>
>> */boot/uEnv.txt:*
>> #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
>>
>> uname_r=4.9.82-ti-r102
>> #uuid=
>> #dtb=
>>
>> ###U-Boot Overlays###
>> ###Documentation: 
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
>> ###Master Enable
>> enable_uboot_overlays=1
>> ###
>> ###Overide capes with eeprom
>> uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
>> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
>> uboot_overlay_addr2=/lib/firmware/BB-W1-P9.12-00A0.dtbo
>>
>> ###Cape Universal Enable
>> enable_uboot_cape_universal=1
>> ###
>>
>> ###U-Boot Overlays###
>> cape_disable=bone_capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
>> cape_enable=bone_capemgr.enable_partno=BB-UART1,BB-UART4
>>
>> cmdline=coherent_pool=1M net.ifnames=0 quiet
>>
>> I connect P9.12 to the 1-wires ... also GND and VCC (5V)
>>
>> the first issue:
>> I don´t have this folder.
>> */sys/devices/bone_capemgr.9/slots*
>>
>> Did this mean I have a different version?
>> But I have this folder:
>> */sys/devices/w1_bus_master1/*
>>
>> So the 1-wire is loaded and working?
>> I added:
>>
>> */etc/modules*
>> w1-gpio
>> w1-therm
>>
>>
>> But no sensor is found:
>>
>> *cat /sys/devices/w1_bus_master1/w1_master_slaves*
>> not found.
>>
>> I appreciate for help!
>>
>> -- 
>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/c169a7ba-37f0-45ec-8e55-3226dc50093c%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/a8303887-eafb-4fdd-ae11-ff5905b9db5e%40googlegroups.com.

Re: [beagleboard] Which rev of LCD7 cape?

[Mark A. Yoder]

I looked on the back, but don't see it.



On Monday, October 14, 2019 at 6:02:56 PM UTC-4, RobertCNelson wrote:
>
> On Mon, Oct 14, 2019 at 4:37 PM Mark A. Yoder  > wrote: 
> > 
> > I have a LCD7 caoe that works fine with my BB Black.  How can I tell 
> which version it is?  A1, A2 or A3. 
> > 
> > --Mark 
> > 
> > https://elinux.org/BeagleBone_LCD7 
>
> It should say on the pcb on the back..  Otherwise trust the eeprom.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0bac15b7-e5de-4be3-9d2f-4bb8c4c8cc15%40googlegroups.com.

[beagleboard] Which rev of LCD7 cape?

[Mark A. Yoder]

I have a LCD7 caoe that works fine with my BB Black.  How can I tell which 
version it is?  A1, A2 or A3.

--Mark

https://elinux.org/BeagleBone_LCD7

-- 
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/00e8c43e-448c-424b-886e-20c6d91ec208%40googlegroups.com.

[beagleboard] bonescript/server.js taking 100% CPU

[Mark A. Yoder]

I'm running a recent image (BeagleBoard.org Debian Image 2019-09-15, 
Buster) on a BB Black and after an hour or two I notice 
bonescript/server.js is taking 100% of the CPU.

I have a cloud9 window (or two) open.

Has anyone else seen this?  How do I scale back the CPU usage?

--Mark

uname -a
Linux bone3 4.19.59-ti-r26 #1buster SMP PREEMPT Thu Sep 5 01:03:09 UTC 2019 
armv7l GNU/Linux

-- 
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/116e5a5f-f53c-4266-b4aa-e3f4fe9aeb81%40googlegroups.com.

[beagleboard] Re: How to activate the framebuffer on the IoT (console only) Debian image ?

[Mark A. Yoder]

Maxime:
  What sort of display do you have attached to the Beagle?  For example, 
I'm using an Adafruilt 2.4: LCD[1].  Running the LCD-on.sh script in 
/var/lib/cloud9/displays will make /dev/fb0 appear.

Run it this way:

bone$ *cd /var/lib/cloud9/displays*
bone$ *git pull*
bone$ *./LCD-on.sh*

More details can be found in my class repo[2]. and eLinux site[3].
--Mark

[1] https://www.adafruit.com/product/2478
[2] 
https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/displays/ili9341
[3] https://elinux.org/EBC_Exercise_12a_2.4_TFT_LCD_display_via_SPI

On Thursday, October 10, 2019 at 9:29:47 AM UTC-4, Maxime Elkael wrote:
>
> Hi,
>
> I'm kind of new to the BeagleBoard world and I'm trying to activate the 
> framebuffer on my PocketBeagle running the IoT Debian image.
>
> I have no framebuffer file in /dev/fb* so when I launch fbset I get : "*open 
> /dev/fb0: No such file or directory*"
>
> I believe I need to install a kernel module for supporting the 
> framebuffer, however I have no idea how to do this. I tried *modprobe 
> vesafb* which gave me : 
> "*modprobe: FATAL: Module vesafb not found in directory 
> /lib/modules/4.14.108-ti-r113*"
>
> I also did *modprobe fbtft* which didn't give me any error but didn't 
> make /dev/fb0 appear either
>
> Could someone please point me in the right direction ?
>
> Thanks in advance
>

-- 
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/075f5a93-d03f-42ee-b14d-bf0f7738ace7%40googlegroups.com.

[beagleboard] dtb-rebuilder vs. BeagleBoard-DeviceTrees on BeagleBone Black

[Mark A. Yoder]

I've playing with device trees on the BeagleBone Black and have come across 
two repos that appear to do similar things.
https://github.com/RobertCNelson/dtb-rebuilder.git

and
https://github.com/beagleboard/BeagleBoard-DeviceTrees.git

What's the difference between the two?  I've been using the second to 
experiment with different device trees.  Should I be using the rebuilder?


--Mark

-- 
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/c4e5d271-1fdf-432f-88a5-df0a3125db36%40googlegroups.com.

[beagleboard] Re: TinyDRM ST7735 with BeagleBone?

[Mark A. Yoder]

David:
  I just tested it and it works!  Thanks.

--Mark

On Saturday, February 17, 2018 at 7:38:51 PM UTC-5, Drew Fustini wrote:
>
> Hi David, I was excited to see you've written a TinyDRM driver for the 
> 1.8" Adafruit TFT.  Have you tried it out with a BeagleBone?
>
> I'd like to use with the BeagleBone Black and am thinking about how go 
> about it.  I imagine I would need to create a device tree overlay to 
> initialize your driver with the appropriate settings?
>
> Thanks!
> Drew 
>

-- 
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/028bc4fb-2a15-41d9-b424-dd82fefe9b02%40googlegroups.com.

Re: [beagleboard] Re: TinyDRM ST7735 with BeagleBone?

[Mark A. Yoder]

David:
  Thanks.  I did not.  How do I discover what those values ( 1 50 0) 
are?

--Mark

On Thursday, October 3, 2019 at 2:57:38 PM UTC-4, David Lechner wrote:
>
> Did you also change pwms = < *0* 50 0>; to pwms = < 
> *1* 50 0>; ? 
>
>
>
>
> On 10/3/19 9:44 AM, Mark A. Yoder wrote:
>
> Drew, David: 
>   I've adapted the tinyDRM dtc to work with the Adafruit 2.4" TFT LCD 
> display.  It's working fine with SPI 1.  Currently it uses P9_14 for the 
> backlight.
>
> How do I switch it to use P9_16 for the backlight? 
>
> I've tried changing all the P9_14's to P9_16s, but that doesn't work.  
> P9_14 is the A side of the pwm
> and P9_16 is the B side, so I think there's a bit I need to flip, but 
> don't know what it is.
>
> --Mark
>
> p.s.  The exercise for my students will be to switch it to SPI 0!
>
> [1] 
> https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/displays/ili9341/tinyDRM
>
> On Thursday, February 22, 2018 at 4:27:10 AM UTC-5, Drew Fustini wrote: 
>>
>> fyi - I've created a bb.org-overlays pull request to add an overlay 
>> named BB-LCD-ADAFRUIT-18-SPI1-00A0.dts for the Adafruit 1.8" LCD on 
>> SPI1: 
>>
>> https://github.com/beagleboard/bb.org-overlays/pull/68 
>>
>> On Wed, Feb 21, 2018 at 11:34 PM, Drew Fustini  
>> wrote: 
>> > Thanks! I had DC and Reset swapped in the overlay file.  I've fixed and 
>> the 
>> > display is now working!  The console is displayed after bootup and 
>> libdrm 
>> > modetest is able to display color bars OK. 
>> > 
>> > Here is the updated dts: 
>> > https://gist.github.com/pdp7/aee5664598059c9b9a9020f107957f80 
>> > 
>> > Thanks, 
>> > Drew 
>> > 
>> > On Feb 21, 2018 1:53 PM, "David Lechner"  wrote: 
>> >> 
>> >> On 02/21/2018 01:18 PM, Drew Fustini wrote: 
>> >>> 
>> >>> On Wed, Feb 21, 2018 at 11:01 AM, David Lechner  
>>
>> >>> wrote: 
>> >>>> 
>> >>>> Are you sure your phandles are correct here? They don't match the 
>> >>>> comments. 
>> >>>> Should it be < 16 0> instead? 
>> >>>> 
>> >>>>> +   reset-gpios = < 16 0>; /* 
>> >>>>> reset:60 P9.12 GPIO1_28 */ 
>> >>>> 
>> >>>> 
>> >>>> And then < 28 0> here? 
>> >>> 
>> >>> Here is the full BB-SPIDEV1-00A0.dts: 
>> >>> https://gist.github.com/pdp7/aee5664598059c9b9a9020f107957f80 
>> >>> 
>> >>> I have P9.12 connected to LCD reset pin.  I have P9.15 connected to 
>> >>> LCD dc pin.  For fbtft driver, this translated to GPIO_60 for reset 
>> >>> and GPIO_48 for dc.  This is based on this pinout diagram: 
>> >>> https://elinux.org/File:Cape_expansion_headers.PNG 
>> >>> 
>> >>> For this dts file, I was trying to figure out what appropriate gpio 
>> >>> phandle.  I looked at this table for the P9 header: 
>> >>> https://elinux.org/File:H9Pinout.PNG 
>> >>> 
>> >>> I believe that gpio1[16] corresponds to P9.15 which is LCD dc pin, 
>> and 
>> >>> gpio1[28] corresponds to P9.12 which is LCD reset pin. 
>> >>> 
>> >>> My understanding of those mappings may be incorrect, so I'd 
>> appreciate 
>> >>> any additional feedback. 
>> >>> 
>> >> You understand correct, but I think you have swapped the values in 
>> your 
>> >> device tree overlay. You say "gpio1[16] corresponds to P9.15 which is 
>> LCD dc 
>> >> pin", but in the overlay, you have dc-gpios = < 28 0>;. Likewise 
>> >> "gpio1[28] corresponds to P9.12 which is LCD reset pin.", but you have 
>> >> reset-gpios = < 16 0>;. 
>> >> 
>> >> 
>> > 
>>
> -- 
> 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 beagl...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/4d796e35-4967-453e-8d92-759f448755bb%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/4d796e35-4967-453e-8d92-759f448755bb%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
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/1687083f-2813-419d-8f29-c5969c45af88%40googlegroups.com.

[beagleboard] Re: TinyDRM ST7735 with BeagleBone?

[Mark A. Yoder]

Drew, David:
  I've adapted the tinyDRM dtc to work with the Adafruit 2.4" TFT LCD 
display.  It's working fine with SPI 1.  Currently it uses P9_14 for the 
backlight.

How do I switch it to use P9_16 for the backlight? 

I've tried changing all the P9_14's to P9_16s, but that doesn't work.  
P9_14 is the A side of the pwm
and P9_16 is the B side, so I think there's a bit I need to flip, but don't 
know what it is.

--Mark

p.s.  The exercise for my students will be to switch it to SPI 0!

[1] 
https://github.com/MarkAYoder/BeagleBoard-exercises/tree/master/displays/ili9341/tinyDRM

On Thursday, February 22, 2018 at 4:27:10 AM UTC-5, Drew Fustini wrote:
>
> fyi - I've created a bb.org-overlays pull request to add an overlay 
> named BB-LCD-ADAFRUIT-18-SPI1-00A0.dts for the Adafruit 1.8" LCD on 
> SPI1: 
>
> https://github.com/beagleboard/bb.org-overlays/pull/68 
>
> On Wed, Feb 21, 2018 at 11:34 PM, Drew Fustini  > wrote: 
> > Thanks! I had DC and Reset swapped in the overlay file.  I've fixed and 
> the 
> > display is now working!  The console is displayed after bootup and 
> libdrm 
> > modetest is able to display color bars OK. 
> > 
> > Here is the updated dts: 
> > https://gist.github.com/pdp7/aee5664598059c9b9a9020f107957f80 
> > 
> > Thanks, 
> > Drew 
> > 
> > On Feb 21, 2018 1:53 PM, "David Lechner"  > wrote: 
> >> 
> >> On 02/21/2018 01:18 PM, Drew Fustini wrote: 
> >>> 
> >>> On Wed, Feb 21, 2018 at 11:01 AM, David Lechner  > 
> >>> wrote: 
>  
>  Are you sure your phandles are correct here? They don't match the 
>  comments. 
>  Should it be < 16 0> instead? 
>  
> > +   reset-gpios = < 16 0>; /* 
> > reset:60 P9.12 GPIO1_28 */ 
>  
>  
>  And then < 28 0> here? 
> >>> 
> >>> Here is the full BB-SPIDEV1-00A0.dts: 
> >>> https://gist.github.com/pdp7/aee5664598059c9b9a9020f107957f80 
> >>> 
> >>> I have P9.12 connected to LCD reset pin.  I have P9.15 connected to 
> >>> LCD dc pin.  For fbtft driver, this translated to GPIO_60 for reset 
> >>> and GPIO_48 for dc.  This is based on this pinout diagram: 
> >>> https://elinux.org/File:Cape_expansion_headers.PNG 
> >>> 
> >>> For this dts file, I was trying to figure out what appropriate gpio 
> >>> phandle.  I looked at this table for the P9 header: 
> >>> https://elinux.org/File:H9Pinout.PNG 
> >>> 
> >>> I believe that gpio1[16] corresponds to P9.15 which is LCD dc pin, and 
> >>> gpio1[28] corresponds to P9.12 which is LCD reset pin. 
> >>> 
> >>> My understanding of those mappings may be incorrect, so I'd appreciate 
> >>> any additional feedback. 
> >>> 
> >> You understand correct, but I think you have swapped the values in your 
> >> device tree overlay. You say "gpio1[16] corresponds to P9.15 which is 
> LCD dc 
> >> pin", but in the overlay, you have dc-gpios = < 28 0>;. Likewise 
> >> "gpio1[28] corresponds to P9.12 which is LCD reset pin.", but you have 
> >> reset-gpios = < 16 0>;. 
> >> 
> >> 
> > 
>

-- 
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/4d796e35-4967-453e-8d92-759f448755bb%40googlegroups.com.

[beagleboard] Compiling .dts files out of tree

[Mark A. Yoder]

I'm making up an example where I need to compile a .dts file and want to do 
it out-of-tree so I don't have to clone bb-overlays.

I've pulled together a Makefile[1] that seems to work, but is there a 
cleaner way to do this?


--Mark

[1] 
https://github.com/MarkAYoder/BeagleBoard-exercises/blob/master/displays/ili9341/tinyDRM/Makefile

-- 
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/0bfbebc1-28b9-43ed-8dd1-9f6115cd1913%40googlegroups.com.

[beagleboard] Re: which kernel source for bbb ?

[Mark A. Yoder]

Good idea.  I've just put in a pull request with a more helpful README.md

--Mark

On Thursday, September 12, 2019 at 11:00:13 AM UTC-4, Dennis Lee Bieber 
wrote:
>
> On Wed, 11 Sep 2019 14:06:07 -0700 (PDT), "Mark A. Yoder" 
> > declaimed the 
> following: 
>
> >Recheck https://github.com/RobertCNelson/bb-kernel 
> ><
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2FRobertCNelson%2Fbb-kernel=D=1=AFQjCNEphfpJo-gInNxoADXdcwriHE1dhw>.
>  
>   
> >If you change the branch you'll find it was updated a couple of days ago. 
> > 
>
> Okay -- so I normally don't use GIT, and never used branches in 
> it... 
>
>
> Maybe the readme for master could add some clause about "current 
> development is found under branches"  
>
>
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com 
> http://wlfraed.microdiversity.freeddns.org/ 
>
>

-- 
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/621a9540-f5cc-43e7-b396-26e95e292313%40googlegroups.com.

[beagleboard] Re: which kernel source for bbb ?

[Mark A. Yoder]

Recheck https://github.com/RobertCNelson/bb-kernel 
.
  
If you change the branch you'll find it was updated a couple of days ago.

In fact, that's the one I point my students to (
https://elinux.org/EBC_Exercise_08_Installing_Development_Tools_4.4)  Once 
the desired branch is selected, it has scripts to load the correct cross 
compiler and the kernel and compile everything.

--Mark

On Wednesday, September 11, 2019 at 2:44:43 PM UTC-4, Dennis Lee Bieber 
wrote:
>
> On Wed, 11 Sep 2019 09:04:15 +0200, Micka 
> > declaimed the 
> following: 
>
> >Hi, which one do you advise ? 
> > 
>
> Did you examine what each of those contains? 
>
>
> >https://github.com/RobertCNelson/ti-linux-kernel-dev 
>
> Per the readme, that is just a bunch of scripts for building the 
> kernel, but the source is elsewhere... 
>
>
> >https://github.com/RobertCNelson/bb-kernel 
>
> Last updated in 2014 -- I'd consider that quite dead 
>
>
> >https://github.com/beagleboard/linux 
>
> Readme implies four kernel versions in both normal and RT 
> variants, and 
> updated last week... 
>
>
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com 
> http://wlfraed.microdiversity.freeddns.org/ 
>
>

-- 
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/4f56ec54-ff33-4e11-8219-ce0b40a8b3bd%40googlegroups.com.

Re: [beagleboard] Welcome the Fall 2019 Embedded Linux Class

[Mark A. Yoder]

You are welcome to use any of the materials I've put online for free.  
Unfortunately I don't record the lectures, so you'll miss that part of the 
class.

--Mark

On Thursday, September 5, 2019 at 4:02:51 PM UTC-4, Specialcomp wrote:
>
> What does one do to join the class and what does it cost?
>
> On Thu, Sep 5, 2019, 12:16 PM Mark A. Yoder  > wrote:
>
>> The purpose of this posting is to announce that I'm once again teaching 
>> an Embedded Linux class based on the BeagleBone[1]. This time I'm using
>> the  *BeagleBone Black.* 
>> I'm teaching as open-source as I can and have have posted many of course 
>> materials on eLinux.org [2] and github[3].
>>
>> I'm always open to ideas on what topics to include in the class and 
>> suggestions for interesting course projects.  For example we are starting
>> Python this week and hope to be writing simple kernel module 5 weeks from 
>> now.  That will be followed by a week of PRU programming.
>>
>> Class, please respond to this posting.  Others, please welcome my class.
>>
>> --Mark 
>>
>> --Prof. Mark A. Yoder 
>>   Rose-Hulman Institute of Technology [4] 
>>
>> [1] http://elinux.org/Embedded_Linux,_Rose-Hulman 
>> [2] http://elinux.org/index.php?title=Category:ECE497 
>> [3] https://github.com/MarkAYoder/BeagleBoard-exercises 
>> [4] http://www.rose-hulman.edu 
>>
>> -- 
>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/a2d2e711-4cf7-46bc-bdb7-f6fb54b8ed0b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/a2d2e711-4cf7-46bc-bdb7-f6fb54b8ed0b%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/a3e167d8-7b36-434c-b2c3-cdf33e85e3b1%40googlegroups.com.

[beagleboard] Welcome the Fall 2019 Embedded Linux Class

[Mark A. Yoder]

The purpose of this posting is to announce that I'm once again teaching 
an Embedded Linux class based on the BeagleBone[1]. This time I'm using
the  *BeagleBone Black.* 
I'm teaching as open-source as I can and have have posted many of course 
materials on eLinux.org [2] and github[3].

I'm always open to ideas on what topics to include in the class and 
suggestions for interesting course projects.  For example we are starting
Python this week and hope to be writing simple kernel module 5 weeks from 
now.  That will be followed by a week of PRU programming.

Class, please respond to this posting.  Others, please welcome my class.

--Mark 

--Prof. Mark A. Yoder 
  Rose-Hulman Institute of Technology [4] 

[1] http://elinux.org/Embedded_Linux,_Rose-Hulman 
[2] http://elinux.org/index.php?title=Category:ECE497 
[3] https://github.com/MarkAYoder/BeagleBoard-exercises 
[4] http://www.rose-hulman.edu 

-- 
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/a2d2e711-4cf7-46bc-bdb7-f6fb54b8ed0b%40googlegroups.com.

[beagleboard] Re: How to connect to wifi network at home?

[Mark A. Yoder]

Here's[1] some notes I have on connecting.  Do they help?

--Mark

[1] https://elinux.org/EBC_Exercise_06_Setting_Up_Wifi

On Monday, September 2, 2019 at 8:11:18 PM UTC-4, user pc wrote:
>
> Hi, I am new to BB. I have a BeagleBone Black Wireless. Could you please 
> let me know how to connect it to home wifi network? I can run the board via 
> usb cable or independently connect it to an external monitor. I once 
> connected to a monitor but could not find any option to allow me to connect 
> it to the wireless internet at home. Thanks
>

-- 
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/d0567e9f-0668-44d9-8c18-cacd0be4782a%40googlegroups.com.

Re: [beagleboard] inv_mpu6050 drivers

[Mark A. Yoder]

I see the ADC's there and I see the BMP085.   I got the BMP085 to appear 
using:

*echo bmp085 0x77 > /sys/class/i2c-adapter/i2c-2/new_device*

I don't know how to get the MPU6050 to appear.

--Mark

On Friday, August 23, 2019 at 3:02:51 PM UTC-4, Vaishnav MA wrote:
>
> Hi,
>
> I believe the MPU6050 shows up as an IIO device under : /sys/bus/iio/
> devices/iio\:deviceX
>
> Regards
> Vaishnav
>
> On Sat, Aug 24, 2019 at 12:00 AM Mark A. Yoder  > wrote:
>
>> I just wired up a mpu6050 to the i2c-2 bus on my BeagleBone Black.
>> lsmod shows:
>>
>> bone$ *lsmod*
>> Module  Size  Used by
>> bmp280_i2c 16384  0
>> bmp280 20480  1 bmp280_i2c
>> *inv_mpu6050_i2c16384  0*
>> *inv_mpu605020480  1 inv_mpu6050_i2c*
>> evdev  24576  1
>> usb_f_mass_storage 53248  2
>> usb_f_acm  16384  2
>> u_serial   20480  3 usb_f_acm
>> usb_f_ecm  20480  2
>> usb_f_rndis32768  4
>> u_ether20480  2 usb_f_ecm,usb_f_rndis
>> libcomposite   65536  18 
>> usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis
>> bc_example 20480  0
>> iptable_nat16384  0
>> nf_conntrack_ipv4  20480  1
>> nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
>> nf_nat_ipv416384  1 iptable_nat
>> pvrsrvkm  442368  1 bc_example
>> nf_nat 32768  1 nf_nat_ipv4
>> nf_conntrack  143360  3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
>> iptable_mangle 16384  0
>> iptable_filter 16384  0
>> uio_pdrv_genirq16384  0
>> uio20480  1 uio_pdrv_genirq
>> spidev 20480  0
>> pruss_soc_bus  16384  0
>> pru_rproc  28672  0
>> pruss  16384  1 pru_rproc
>> pruss_intc 16384  1 pru_rproc
>> ip_tables  24576  3 iptable_mangle,iptable_filter,iptable_nat
>> x_tables   36864  3 iptable_mangle,ip_tables,iptable_filter
>>
>> What do I do next to read the device?  I assume it appears somewhere is 
>> user space, but I don't know where.
>>
>> --Mark
>>
>> -- 
>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/b85ff0ee-86be-4f2a-90ef-f1a612025727%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/b85ff0ee-86be-4f2a-90ef-f1a612025727%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/3eb9b90c-c196-42d6-9f8a-81ebd818e03b%40googlegroups.com.

[beagleboard] inv_mpu6050 drivers

[Mark A. Yoder]

I just wired up a mpu6050 to the i2c-2 bus on my BeagleBone Black.
lsmod shows:

bone$ *lsmod*
Module  Size  Used by
bmp280_i2c 16384  0
bmp280 20480  1 bmp280_i2c
*inv_mpu6050_i2c16384  0*
*inv_mpu605020480  1 inv_mpu6050_i2c*
evdev  24576  1
usb_f_mass_storage 53248  2
usb_f_acm  16384  2
u_serial   20480  3 usb_f_acm
usb_f_ecm  20480  2
usb_f_rndis32768  4
u_ether20480  2 usb_f_ecm,usb_f_rndis
libcomposite   65536  18 
usb_f_ecm,usb_f_acm,usb_f_mass_storage,usb_f_rndis
bc_example 20480  0
iptable_nat16384  0
nf_conntrack_ipv4  20480  1
nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
nf_nat_ipv416384  1 iptable_nat
pvrsrvkm  442368  1 bc_example
nf_nat 32768  1 nf_nat_ipv4
nf_conntrack  143360  3 nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
iptable_mangle 16384  0
iptable_filter 16384  0
uio_pdrv_genirq16384  0
uio20480  1 uio_pdrv_genirq
spidev 20480  0
pruss_soc_bus  16384  0
pru_rproc  28672  0
pruss  16384  1 pru_rproc
pruss_intc 16384  1 pru_rproc
ip_tables  24576  3 iptable_mangle,iptable_filter,iptable_nat
x_tables   36864  3 iptable_mangle,ip_tables,iptable_filter

What do I do next to read the device?  I assume it appears somewhere is 
user space, but I don't know where.

--Mark

-- 
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/b85ff0ee-86be-4f2a-90ef-f1a612025727%40googlegroups.com.

[beagleboard] Re: How does embedded linux boot up differ from a traditional embedded system?

[Mark A. Yoder]

Jani:
  Here's what I use with my students for the 
Beagle:  
https://github.com/MarkAYoder/BeagleBoard-exercises/blob/master/pptx/04-1%20Booting.pdf

Slide 16 shows the overall picture.

--Mark

On Monday, July 29, 2019 at 8:56:00 AM UTC-4, Jani wrote:
>
> A traditional embedded system boots from flash memory and code runs from 
> flash memory.  Usually application isn't copied to RAM, only read/write 
> variables are copied to RAM.  
> Does system running embedded Linux execute from RAM?
>
> A typical embedded Linux evaluation board running some Linux distribution 
> boots from SD card.  I believe entire kernel code, rwdata, rodata, init, 
> bss, etc. is copied to RAM and code execution occurs in RAM.  Is that 
> correct?
>
> I need to know what size DRAM I need for my embedded Linux system?  If 
> Linux distribution takes up 3GB in SD card.  Then, does this mean I need 
> 3GB DRAM?
>

-- 
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/3c4924b4-3909-4512-a3f4-33006fc31bcd%40googlegroups.com.