[beagleboard] help a newbie get potentiometer input into a beagleboard x15

[martinbarker99]

Hello I'm trying to connect rotary encoders and potentiometers to my 
beagleboard x15 to make a guitar pedal, do I need to use a breakoutboard 
for this? I'm having trouble finding the correct type of expansion cable to 
use to connect my beagleboard x15 to a breadboard, i know the expansion 
ports are 60 pins but is there an official cable to use or path I should 
take for accomplishing this?

Thanks, Martin

-- 
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/0dbfcd76-8940-45a8-b7fc-6e1f176fe45c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PRU remoteproc[12] not appearing under /sys/class/remoteproc/

[ethshea]

I've just set up a new Debian 9.5 (kernel 14.4.71-ti-r80) image 

 
and made the following changes to /boot/uEnv.txt:

disable_uboot_overlay_video=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo

I've also disabled loading of the uio modules. (
/etc/modprobe.d/pruss-blacklist.conf)
blacklist uio
blacklist uio_pdrv_genirq

However, I don't see any evidence that the rproc module has loaded the PRU:
"uio\|pru"

Specifically, there is no module for the PRU in /sys/class/remoteproc/. 
remoteproc0 appears, but this is for the M3 power management unit.

Am I doing anything wrong? or is there an additional step to allow use of 
the PRUs? What should I look at to debug this issue?

-- 
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/175aee21-2342-4047-8de3-e898ff831bf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to enable and use pru-rproc/remoteproc interface for 4.14 kernel on debian?

[Bill M]

Greetings Robert,

I apologize for the necro/somewhat-off-topic post. What is the best way to 
access PRU remoteproc carveouts from userspace? 

I have a (working) project for reading an 8-bit parallel interface camera 
that I originally wrote using UIOPRUSS. I decided to take the plunge and 
work through the remoteproc documentation to see if I could move to that. I 
didn't want to use rpmsg, because I doubted it could handle the data 
velocity (320 x 240 x 24bit color x 15 frames per second = 3,456,000 bytes, 
roughly 3MB a second). I discovered carveouts in the resource table 
headers, and thought this was excellent since it was much like how I was 
already doing it with UIOPRUSS. It works and simplifies the code greatly, 
but I have to use debugfs to get the carveout location to mmap to, which 
seems less than ideal. 

Any suggestions appreciated.


On Saturday, February 24, 2018 at 1:15:01 AM UTC-5, RobertCNelson wrote:

> On Fri, Feb 23, 2018 at 9:52 PM, mallets  > wrote: 
> > There are a lot of useful guides and manuals all over the net for using 
> the 
> > PRUs on the BBB. Ex: 
> > 
> http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_4:_Introduction_to_Linux_driver
>  
> > But none of them seem to be applicable to the newer images/kernel. 
> Either 
> > the sysfs setup is wrong or those interfaces just don't exist. 
> > 
> > What is the best way to get started on PRU programming, using the latest 
> > kernel? 
> > I don't want to go back to an older image as I need the improved network 
> > latency provided by the 4.14 kernel (getting almost 30-40us better 
> latency 
> > over UDP, don't know how or why). Image info below. 
>
> TI just recently merged in their pru changes into their v4.14.x 
> branch, just run: 
>
> sudo /opt/scripts/tools/update_kernel.sh 
>
> > 
> > dogtag:[BeagleBoard.org Debian Image 2017-10-10] 
> > bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 
> > 2017.09-2-g0f3f1c7907] 
> > kernel:[4.14.17-ti-r32] 
> > nodejs:[v6.12.3] 
> > uboot_overlay_options:[enable_uboot_overlays=1] 
> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
> > uboot_overlay_options:[disable_uboot_overlay_wireless=1] 
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
>  
>
>
> Remove this option ^... 
>
> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
> > pkg:[bb-cape-overlays]:[4.4.20180126.0-0rcnee0~stretch+20180126] 
> > pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee2~stretch+20180104] 
> > pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830] 
>
> 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/0e664c0e-c293-4882-aee0-c8bb4f21beee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] RE: [EXTERNAL] Re: Industrial Beagle Bone Black damages SD cards.

[Dr. Michael J. Chudobiak]

  
  
On 4/9/19 7:59 AM, Steffensen, Flemming [COMRES/SOL/AAR] wrote:

  
  The failing SD-cards are for the most
part the consumer
SanDisk Ultra A1 SDHC 16gb, but we also have a few Kingston
  industrial 8gb (SDCIT/8GB B0623-004.A00LFTS).

  They are bought through official distributors of the
  respective brands, and not likely to be fake, although we have
  not performed tests anywhere near as detailed as the one you
  link to.
Talking with the distributer, I’m told that
  they internally have 0.08 % failure rate on the consumer
  SanDisk, and less than 0.00 % of the industrial Kingston.
  
  The datasheet for either card makes no promise in this regard,
  except 5 and 10 year warranty. I’ve asked for further details,
  if possible.
  

I had the same problems until switching to SwissBit SLC SD cards,
  which are supposed to have aggressive power-up/power-down
  protection circuits. No problems since. Very expensive, but
  cheaper than in-field failures.
- Mike

  




-- 
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/1868d7f9-5cb8-385b-49a6-6100fe8c73bc%40avtechpulse.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [EXTERNAL] Re: Industrial Beagle Bone Black damages SD cards.

[Graham]

 

> I happened to run across this series of articles yesterday.
>
If you are wearing out the cards, due to frequent writes driven by logging, 
here is a way to reduce the write transactions.
Although written for a similar sounding problems on a Raspberry Pi, the 
underlying solution was written for generic Debian.


https://mcuoneclipse.com/2019/04/01/log2ram-extending-sd-card-lifetime-for-raspberry-pi-lorawan-gateway/

https://github.com/azlux/log2ram

A transient /var/log:
https://debian-administration.org/article/661/A_transient_/var/log

==

-- 
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/562f1c62-d8c3-4f3c-a8dd-3228eba1eab1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] RE: [EXTERNAL] Re: Industrial Beagle Bone Black damages SD cards.

[Steffensen, Flemming [COMRES/SOL/AAR]]

Thank you for your answer and time, Jason, it’s really appreciated.
Per your request, I’m also adding 
beagleboard@googlegroups.com to the list 
of recipients.
The failing SD-cards are for the most part the consumer SanDisk Ultra A1 SDHC 
16gb, but we also have a few Kingston industrial 8gb (SDCIT/8GB 
B0623-004.A00LFTS).
They are bought through official distributors of the respective brands, and not 
likely to be fake, although we have not performed tests anywhere near as 
detailed as the one you link to.
Talking with the distributer, I’m told that they internally have 0.08 % failure 
rate on the consumer SanDisk, and less than 0.00 % of the industrial Kingston.
The datasheet for either card makes no promise in this regard, except 5 and 10 
year warranty. I’ve asked for further details, if possible.
We have already planned to make the root filesystem read-only (and later move 
it to the eMMC). The ‘overlayroot’ suggested by Robert Nelson may come in handy 
here.
However, will this solve the issue?
Afterall, what we experience is not filesystem corruption, which is what we 
would have expected, but that the entire card becomes unreadable/unrecognized.
It looks to us that the problem can occur to the card at different points in 
time:

  1.  During normal usage of the card, where the cards properties are cached in 
RAM. (Invisible corruption)
  2.  During the system shutdown and restart, where there are no 
power-fluctuations.
  3.  During the power starvation that occur after a correct shutdown, when the 
power to the BBB is cut.
  4.  During the power starvation that occur due to accidental external 
power-loss.
  5.  During the bootloader at startup.
We always discover the problem at 5, following either 4, 3, or 2. But the 
problem may actually occur at 1.
In regards to 1, are there any means to monitor whether the CID/CSD or other 
“embedded” SD registers change under normal usage (reading/writing to the 
filesystem) of the card?
Do you have other ideas on how we can dig deeper than just the error message 
from dmesg?
Best regards,
--
Flemming Steffensen | Senior Software Engineer | Transportation Solutions
Emerson Commercial & Residential Solutions | Axel Kiers Vej 5A | Højbjerg | 
DK-8270 | Denmark
T +45 7023  | D +45 8987 3710 | M +45 4094 3793
flemming.steffen...@emerson.com
Twitter | 
Facebook | 
LinkedIn | 
YouTube | Climate Conversations 
Blog


This e-mail message is intended by Emerson Commercial & Residential Solutions, 
for use only by the individual or entity to which it is addressed. This message 
may contain information that is protected, privileged or confidential. It is 
not intended for transmission to, or receipt by, anyone other than the named 
addressee (or a person authorized to receive and deliver it to the named 
addressee). If you have received this transmission in error, please delete it 
from your system without copying or forwarding it, and notify the sender of the 
error by reply e-mail or by calling +45 7023 



From: Jason Kridner 
Sent: 5. april 2019 20:29
To: Steffensen, Flemming [COMRES/SOL/AAR] 
Cc: Urup, Mark [EXTERNAL/CONTRACTOR] ; Ranum, Morten 
[COMRES/SOL/AAR] ; Robert Nelson 
; Christine Kridner 
Subject: [EXTERNAL] Re: Industrial Beagle Bone Black damages SD cards.



On Fri, Apr 5, 2019 at 5:17 AM Steffensen, Flemming [COMRES/SOL/AAR] 
mailto:flemming.steffen...@emerson.com>> wrote:
Hi Jason,

I’m addressing you directly, as this is very specifically an error that it’s 
not likely the community can help with.

You could be surprised. In any respects, I like to answer all follow-up 
questions with the community list 
(beagleboard@googlegroups.com) in copy 
such that we all benefit from the answers.


We are working on a product that incorporates the Industrial version of the 
BeagleBone Black: element14 BeagleBone Black Industrial, BBONE-BLACK-IND-4G.

We are using a slightly modified version of you IoT Debian 9.3, to run our 
application, and to access our custom cape (The mandatory I2C chip, custom 
power-supply, a few basic IO’s and serial ports).
Everything is working as expected… Our app is running, and logging a few things 
to a file on the SD card.

On rare occasions we cold-boot, either due to external power-loss, or more 
normally on a regular shutdown followed by a correct power-off.
This typically works flawless, but on a few occasions, it’s no longer possible 
to boot from the SD card.
As we have the hard set up as R/W, we understand that we might damage the 
filesystem, but this appear to not be the case here.
Examining the SD card (several brands, some industrial others not) we find that 
they are utterly unrecognized by everything. The cards internal registers, such 
as 

[beagleboard] Wifi module modification beaglebone black wireless

[yigu6254]

I really hope someone could help me on this.
I am wondering could I modify the Wifi Module on BeagleBone Black Wireless, 
e.g., change the MAC layer and application layer of the 802.11 protocol.
If yes, is there any open source code for WiFi?

-- 
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/2c4ddc02-5e6f-4d51-834c-32a68a8d5fa1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] activation error of pinmux for pru1

[ABAN]

Hello
i'm new to using PRU, what i want to do is configure the pins P8.27, P8.28, 
P8.29 and P8.30 in BBB but i have trouble configuring them. The code i use 
is the following:

/dts-v1/;
/plugin/;

/ {
   compatible = "ti,beaglebone", "ti,beaglebone-black";

   part-number = "EBB-PRU-Example";
   version = "00A0";

   /* This overlay uses the following resources */
   exclusive-use =
 "P8.27", "P8.28", "P8.29", "P8.30", "pru1";

   fragment@0 {
  target = <_pinmux>;
  __overlay__ {

 pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
pinctrl-single,pins = <
   0x0e0 0x0d  // P8_27 
   0x0e8 0x2e  // P8_28 
   0x0e4 0x0d  // P8_29
   0x0ec 0x0d  // P8_30

>;
 };
  };
   };

   fragment@1 { // Enable the PRUSS
  target = <>;
  __overlay__ {
 status = "okay";
 pinctrl-names = "default";
 pinctrl-0 = <_pru_pins>;
  };
   };
};


After saving this i do the following:

root@beaglebone:~# dtc -O dtb -o EBB-PRU-Example-00A0.dtbo -b 0 -@ 
EBB-PRU-Example.dts
root@beaglebone:~# sudo sh -c "echo EBB-PRU-Example > 
/sys/devices/platform/bone_capemgr/slots"

Finally when reviewing the pins their values have not changed...

root@beaglebone:~# cat $PINS |grep '56\|57\|58\|59'
pin 22 (44e10858.0) 0017 pinctrl-single
pin 56 (44e108e0.0)  pinctrl-single
pin 57 (44e108e4.0)  pinctrl-single
pin 58 (44e108e8.0)  pinctrl-single
pin 59 (44e108ec.0)  pinctrl-single
pin 86 (44e10958.0) 0037 pinctrl-single

and when i check with dmesg it tells me the following and i do not know 
what it means:

root@beaglebone:~# dmesg |grep pru
[  229.784032] pinctrl-single 44e10800.pinmux: pin 44e108e0.0 already 
requested by 0-0070; cannot claim for 4a30.pruss
[  229.794920] pinctrl-single 44e10800.pinmux: pin-56 (4a30.pruss) 
status -22
[  229.802176] pinctrl-single 44e10800.pinmux: could not request pin 56 
(44e108e0.0) from group pinmux_pru_pru_pins  on device pinctrl-single
[  229.814713] pruss_uio 4a30.pruss: Error applying setting, reverse 
things back

Does anyone know what is happening here?

i would like to understand in detail what happens here. I hope you can help 
me clarify this, i'm using Linux beaglebone 4.4.145-bone23

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/5a7f7a86-59dd-4ab5-90b7-19c73ffe59a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.