[beagleboard] Re: BeagleBone Black (C) USB based touch not working
on Syslog Socket. [ 12.781411] systemd[1]: Listening on udev Control Socket. [ 12.793880] systemd[1]: Starting Load Kernel Modules... [ 12.794186] systemd[1]: Reached target Slices. [ 13.551222] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro [ 14.934790] systemd-journald[897]: Received request to flush runtime journal from PID 1 [ 21.876245] net eth0: initializing cpsw version 1.12 (0) [ 21.961131] SMSC LAN8710/LAN8720 4a101000.mdio:00: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=4a101000.mdio:00, irq=POLL) [ 21.977360] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 21.977380] 8021q: adding VLAN 0 to HW filter on device eth0 [ 24.008936] cpsw 4a10.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 24.009028] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 25.307835] using random self ethernet address [ 25.307853] using random host ethernet address [ 25.888979] Mass Storage Function, version: 2009/09/11 [ 25.889003] LUN: removable file: (no medium) [ 26.287051] using random self ethernet address [ 26.287069] using random host ethernet address [ 26.572229] usb0: HOST MAC e4:15:f6:fc:4a:64 [ 26.576519] usb0: MAC e4:15:f6:fc:4a:63 [ 26.588142] usb1: HOST MAC e4:15:f6:fc:4a:66 [ 26.592612] usb1: MAC e4:15:f6:fc:4a:67 [ 26.851877] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready [ 27.090882] IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready [ 63.711187] pvrsrvkm: loading out-of-tree module taints kernel. [ 64.044239] [drm] Initialized pvr 1.17.4948957 20110701 for 5600.sgx on minor 1 [ 70.328069] remoteproc remoteproc0: wkup_m3 is available [ 70.409424] remoteproc remoteproc0: powering up wkup_m3 [ 70.409455] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217148 [ 70.409730] remoteproc remoteproc0: remote processor wkup_m3 is now up [ 70.409759] wkup_m3_ipc 44e11324.wkup_m3_ipc: CM3 Firmware Version = 0x192 [ 70.483401] PM: bootloader does not support rtc-only! [ 72.580031] remoteproc remoteproc1: 4a334000.pru is available [ 72.580220] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully [ 72.592546] remoteproc remoteproc2: 4a338000.pru is available [ 72.592751] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully *uname -a * Linux beaglebone 4.19.94-ti-r64 #1buster SMP PREEMPT Fri May 21 23:57:28 UTC 2021 armv7l GNU/Linux *ls -als /dev/input * total 0 0 drwxr-xr-x 3 root root 80 Jun 3 08:42 . 0 drwxr-xr-x 16 root root3480 Jun 3 08:43 .. 0 drwxr-xr-x 2 root root 60 Jun 3 08:42 by-path 0 crw-rw 1 root input 13, 64 Jun 3 08:42 event0 *lsmod *Module Size Used by 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 pvrsrvkm 421888 0 pruss_soc_bus 16384 0 usb_f_acm 16384 2 u_serial 20480 3 usb_f_acm usb_f_ecm 20480 2 usb_f_mass_storage 53248 2 uio_pdrv_genirq16384 0 uio20480 1 uio_pdrv_genirq 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 spidev 20480 0 The project requires the pru units, that works fine. Touch is eating up my time. And I expect it makes no sense to order other touch displays and the status is still the same. USB based touch was expected as "best and simple" solution. I need SPI and GPIO for surrounding hardware. That works fine. HDMI is required to have the possibility to connect "any" monitor. There is 1m distance between BBB and display. RPI is not an option for me, because I need the PRU's. Thanks for help Kasimir Dennis Bieber schrieb am Montag, 31. Mai 2021 um 03:08:11 UTC+2: > On Sun, 30 May 2021 16:13:00 -0700 (PDT), in > gmane.comp.hardware.beagleboard.user Kasimir > wrote: > > >But I'm hanging with touch. > >Installed is: Linux beaglebone 4.19.94-ti-r64 #1buster SMP PREEMPT Fri > May > >21 23:57:28 UTC 2021 armv7l GNU/Linux > >Plan is to write directly into the framebuffer, no X no desktop. > >That works also fine, very fast. > >But with touch I'm running out of ideas. > >Was expecting a conflict with USB Network, is now deactivated, no change. > >/dev/input/event0 is existing. But no events . > > Could you be having a conflict with the native LCD system (which is > active in parallel with the HDMI). The native LCD system e
[beagleboard] BeagleBone Black (C) USB based touch not working
Hi, working on a new product, 7" HDMI display with optical touch should be used. LCD works fine ( 1024x600). But I'm hanging with touch. Installed is: Linux beaglebone 4.19.94-ti-r64 #1buster SMP PREEMPT Fri May 21 23:57:28 UTC 2021 armv7l GNU/Linux Plan is to write directly into the framebuffer, no X no desktop. That works also fine, very fast. But with touch I'm running out of ideas. Was expecting a conflict with USB Network, is now deactivated, no change. /dev/input/event0 is existing. But no events . Touch hardware is ok, works fine on WIN10 PC. I'm sure, I'm not the first one . need help on that. Thanks in advance for every good hint :-) Kasimir PS I checked it with destop, also. Touch doesn't work. -- 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/b3f9feda-df28-4b64-a02b-ca537a0ec019n%40googlegroups.com.
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
Hi Mark, more simple .. in C source. My datastructure was not in internal ram. volatile Event_t *event_knoten = (Event_t *) (PRU0_DRAM + 0x200); and in main event_knoten = (Event_t *)malloc(100*sizeof(Event_t)); solved it. Kasimir -- 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/85feaea6-6059-4f9d-ba44-5bd44ea57f11n%40googlegroups.com.
Re: [beagleboard] Re: unexpected "low speed" of PRU 1
Hi all, it's SOLVED:-) Thanks for all your input. Problem was located in memory allocation. Was not using the PRU-Dram. The external ram is very slow and I saw also some jitter. Now it's running with expected speed and I'm happy. Was expecting the local variables in local memory by default. That's not the case. Thanks again Kasimir -- 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/ef7fb969-2794-4eed-8340-934370471cf3n%40googlegroups.com.
[beagleboard] Re: unexpected "low speed" of PRU 1
Just a moment ago, I was standing on cliffs edge, now I made a big step
forward .
I'm able to generate a 10ns trigger pulse on __R30 Bit 4 :-)).
I placed the and instruction to clear Bit 4. Now it's clear, both indirect
loads ( lbbo ) are
responsible for the unexpected delay. I was expecting both are operating
from dram with
latency of 3 cycles. What is wrong? The data structure is expected in local
ram, to get best latency.
In C it's declared that way:
typedef struct Event Event_t;
struct Event
{
unsigned int time; // number of loops
unsigned char pattern; // Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
// --+---+---+---++---++---+
// | | | |~z34|z34|~z12|z12|
// --+---+---+---++---++---+
};
int main( int argc, char *argv[])
{
int i;
int j;
unsigned char u;
*Event_t event_knoten[100];* // later on, r15 is pointing to that
address
...
...
...
ausgabe(pattern_liste.anzahl, _knoten[0].time, [0]) ;
* change to debug delay in assembler ***
naechster:
*and r30, r30, 0xEF ; debug*
lbbo, r15, 4, 1 ; (r15) = pattern <= slow
lbbo, r15, 0, 2 ; load number of loops <= slow
Any hint how to make the lbbofaster?
I'm looking forward
Kasimir
>
>
>
--
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/4a911162-7904-4709-b3c3-556e517ea887n%40googlegroups.com.
[beagleboard] Re: unexpected "low speed" of PRU 1
Hi Dennis, thanks for information I'm using currently the first version of asm, without loop. Because here is something else wrong, the timing is factor 10 to 15 far away . Think I can use only one loop for timing. If I have to insert a nop then there is no advantage. I'm hanging now a week on this point. have no progress. Thinking on a hardware solution with 2 DDS devices from analog devices. One for triangle and one for sine and -sine, comparator done. But then the BeagleBone / Sitara cpu makes no longer sense. I like BeagleBone, made a lot of nice things and it works fine. But now I need the power of the pru unit and I do not see the performance. May be my code is not placed in internal memory ... there are many possibilities to do things wrong .. Thanks again Kasimir -- 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/88e96c9e-116e-4973-8970-05536360738fn%40googlegroups.com.
Re: [beagleboard] unexpected "low speed" of PRU 1
HI Mark, was trying to use the loop instruction . .global ausgabe ausgabe: ldi r18, 0 ; initialisation ldi r30, 0x10 ; debug ldi r17, 0x00 ; debug mov r20, r15; save start addresss mov r21, r14; save number of pattern naechster: loopnext_pattern, r14 ; for each pattern lbbo, r15, 4, 1 ; output (r15) = pattern lbbo, r15, 0, 2 ; load number of delay loops loopweiter, R17 ; delay loop weiter: add r15, r15, 5 ; increment address pointer by 5 ( next data structure element ) next_pattern: mov r15, r20; load saved start address in address pointer mov r14, r21; load saved number of pattern in pattern counter lbbo, r16, 0, 1 ; check if stop request or r30, r30, (1<<4); debug qbeqnaechster, r18, 0 ; if handshake[0] == 0 continue jmp r3.w2 ; otherwise return r3 contains return address ** I used prudebug to test the behavior. So the loop instruction is not known ( UNKNOWN in disassembler list ) Is not a solution for Beaglebone black. Assembler did not warn or complain. Bottom line ... independent of the above code, I'm missing the 200MHz performance, I'm far away, seems to be 20:1 if I think in 5nsec instruction time cycles for register operations. There is something else up to now no idea what it can be. Thanks for help and thinking Kasimir -- 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/2f40337b-11dc-44a5-8c3e-c78a9e8890b1n%40googlegroups.com.
Re: [beagleboard] unexpected "low speed" of PRU 1
This is my code to output pattern on __R30
;
.global ausgabe
ausgabe:
ldi r18, 0 ; initial value
ldi r30, 0x10 ; debug
ldi r17, 0x00 ; debug
mov r13, r15; R15 contains start address, save in R13
mov r12, r14; R14 contains number of data points
naechster:
lbbo, r15, 4, 1 ; (r15) = pattern
lbbo, r15, 0, 2 ; (r17) = time to wait to output next
pattern
warte:
sub r17, r17, 1 ; delay loop
qbnewarte, r17, 0 ;
add r15, r15, 5 ; next element, update pointer
sub r14, r14, 1 ; number of remaining elements - 1
qbnenaechster, r14, 0 ; was it the last one?
mov r15, r13; yes, load addess pointer with saved value
mov r14, r12; and load loop counter with saved number of
elements
lbbo, r16, 0, 1 ; load variable, if 0 run again, if != 0 exit
or r30, r30, (1<<4); debug, trigger signal for oscilloscope
qbeqnaechster, r18, 0 ; as long handshake[0] = 0 is
jmp r3.w2 ; r3 contains return address
;*
The datastructure:
typedef struct Event Event_t;
struct Event
{
unsigned int time; // number of loops to the next event
unsigned char pattern; // Bit 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
// --+---+---+---++---++---+
// | | | d |~z34|z34|~z12|z12|
// --+---+---+---++---++---+
};
int main( int argc, char *argv[])
{
int i;
int j;
*Event_t event_knoten[500];*
...
ausgabe(pattern_liste.anzahl, _knoten[0].time, [0]) ; //
asm to write pattern
// as
long handshake[0} == 0
It works fine, only the delay time loop need better resolution, at the
moment the time for only one loop is too long.
Have no idea to optimize ist.
Also from
or r30, r30, (1<<4); debug, trigger signal for oscilloscope
to
naechster:
lbbo, r15, 4, 1 ; (r15) = pattern
I measure 250nsec . was expecting 25nsec .
I can see some jitter on my oscilloscope ( Tektronix THS730A ), has nothing
to do with
GND connection, long wires etc., all that is perfect. Oscilloscope works
fine.
Is it possible that "some what" from Linux / ARM area is disturbing my
timing?
Thanks again for any helpfull input.
Kasimir
--
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/2a9748b2-ed2a-4278-9e30-fa153bf5c0fbn%40googlegroups.com.
[beagleboard] unexpected "low speed" of PRU 1
Hi, I'm working on a sine - triangle modulator, is running on BeagleBone black / PRU 1. On Linux/Arm I calculate the pattern for one period in form of a data structure pattern to output and time to the next event. Output is PRU 1 __R30 bit 0, 1, 2, 3 ( 4 only for debug reasons, oscilloscope trigger ) It works but I'm not surprised about the speed. The output loop of the PRU is written in some lines of ASM. Frequencies: triangle should be 400kHz, better 800kHz, sine wave is between 20kHz and 100kHz Beaglebone has to drive a high speed GaN H-Bridge. The datatransport and handshake between Linux and PRU works fine. A C-Program on PRU is watching for new data. Then the new data ( pattern-time structure ) are copied into local ram, to get the best speed ( lowest latency ). If the data are stored in local ram, the assembler program is called, to output the given pattern. First the arguments are saved in registers, then the output starts in a loop. Pick up pattern from local RAM, and output, feed delay loop from local RAM, delay loop, update index register, check for possible new data, if not, back to the top, output next period. What I said ... it works. But with cycle time of 5nsec ( 1/200MHz ) and 1 cycle for most of the (ASM) instructions, I can't see the speed. So there is something wrong in my setup or code. If somebody would like to help debugging, let me know. Sources with Makefile etc are available. All based on latest Debian image, all udates are installed, HDMI is off. So, let me know, think it makes only sense to upload that stuff in case there is really somebody able to help on that. Thanks in advance Kasimir -- 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/e9fe59e9-e00d-476e-99e2-6b85a90695d2n%40googlegroups.com.
[beagleboard] Re: pru support for 4.4.84-ti-r120
I still have the problem with pru1. -Generated firmwares are : gen/puls_gen.out gen/decay95.out root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source#* config-pin overlay cape-universala* root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source# *config-pin p8.45 pruout* root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source# *config-pin -q p8.45* *P8_45 Mode: pruout* root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source# make run -copying firmware file gen/puls_gen.out to /lib/firmware/am335x-pru1-fw */bin/sh: 1: cannot create /sys/bus/platform/drivers/pru-**rproc/unbind: Permission denied* */bin/sh: 1: cannot create /sys/bus/platform/drivers/pru-**rproc/bind: Permission denied* It's really confusing and time consuming without any result. Think the hardware is very useful and interesting, but it's not an easy task to make it work. Am Dienstag, 5. September 2017 18:55:37 UTC+2 schrieb Kasimir: > > I want to use the HDMI outputs to drive external circuit. Required toggle > rate is between 1MHz and 10MHz. > Have BB black. > uname -a > Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 > armv7l GNU/Linux > cat /etc/debian_version > 9.1 > So I have to use the PRU unit. > I was searching example to have a starting point. > But it sucks already with the first step. > > ll /sys/devices/bone_capemgr* > ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory > > I load the image from here: > http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz > > What is my mistake? > Device tree compiler is up to date > device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+ > 20170719). > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > Found a lot of hints to use the 3.8 kernel. Think that one is already some > years old, can't be true. > > Question: How to create the required device tree overlay, because /sys/ > devices/bone_capemgr* is not existing? > > Thanks 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d5581556-33b9-4762-b336-393958db93c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hi Jason,
reduced the given example to a minimum, should toggle P8.45.
It doesn't work.
Log of make:
root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source# make
CCpuls_gen.c
"puls_gen.c", line 82: warning #112-D: statement is unreachable
"puls_gen.c", line 70: warning #179-D: variable "i" was declared but never
referenced
"puls_gen.c", line 70: warning #179-D: variable "j" was declared but never
referenced
LDgen/puls_gen.obj
CCpuls_gen.c
"puls_gen.c", line 82: warning #112-D: statement is unreachable
"puls_gen.c", line 70: warning #179-D: variable "i" was declared but never
referenced
"puls_gen.c", line 70: warning #179-D: variable "j" was declared but never
referenced
LDgen/decay95.obj
-Generated firmwares are : gen/puls_gen.out gen/decay95.out
root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source#*
config-pin overlay cape-universala*
root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source# *config-pin
p8.45 pruout*
root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source# *config-pin
-q p8.45*
*P8_45 Mode: pruout*
root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source# make run
-copying firmware file gen/puls_gen.out to /lib/firmware/am335x-pru1-fw
/bin/sh: 1: cannot create /sys/bus/platform/drivers/pru-rproc/unbind:
Permission denied
/bin/sh: 1: cannot create /sys/bus/platform/drivers/pru-rproc/bind:
Permission denied
-rebooting pru core 0
-pru core 1 is now loaded with gen/puls_gen.out
root@beaglebone-ln:/media/SD32/home/ln/Programme/Puls_neu/source#
My C-code:
#include
#include
#include
#include "resource_table_empty.h"
#defineINS_PER_US 200 // 5ns per instruction
#define INS_PER_DELAY_LOOP 2 // two instructions per delay loop
#define DELAY_CYCLES_US (INS_PER_US / INS_PER_DELAY_LOOP)
#define GPIO1 0x4804C000
#define GPIO_CLEARDATAOUT 0x190
#define GPIO_SETDATAOUT 0x194
#define USR0 (1<<21)
#define USR1 (1<<22)
#define USR2 (1<<23)
#define USR3 (1<<24)
unsigned int volatile * const GPIO1_CLEAR = (unsigned int *) (GPIO1 +
GPIO_CLEARDATAOUT);
unsigned int volatile * const GPIO1_SET = (unsigned int *) (GPIO1 +
GPIO_SETDATAOUT);
volatile register unsigned int __R30;
volatile register unsigned int __R31;
#define PRU0_GPIO (1<<2)
#ifndef DECAY_RATE
#define DECAY_RATE 100
#endif
#ifndef DELAY_CYCLES
#define DELAY_CYCLES DELAY_CYCLES_US
#endif
const int decay = DECAY_RATE;
void main(void) {
int i, j;
/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
//
*while (1){ __R30 |= 0x0001; // toggle
P8_45 __R30 &= 0xFFFE;}*
__halt();
}
Makefile is attached.
At the moment it works and I know why I can do the next step.
What is wrong or missing?
Thanks for help and have a good day
Kasimir
--
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/4ab1c928-c21a-4005-a8a2-05b24f0a268e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Makefile
Description: Binary data
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hi Jason, can confirm, LED is flashing. cd /var/lib/cloud9 root@beaglebone:/var/lib/cloud9# git clone https://gist.github.com/jadonk/2ecf864e1b3f250bad82c0eae12b7b64 Cloning into '2ecf864e1b3f250bad82c0eae12b7b64'... remote: Counting objects: 84, done. remote: Total 84 (delta 0), reused 0 (delta 0), pack-reused 84 Unpacking objects: 100% (84/84), done. root@beaglebone:/var/lib/cloud9# cd 2ecf864e1b3f250bad82c0eae12b7b64 root@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64# make CChello-pru.c LDgen/hello-pru.obj CChello-pru.c LDgen/decay95.obj -Generated firmwares are : gen/hello-pru.out gen/decay95.out root@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64# echo none > /sys/class/leds/beaglebone\:green\:usr0/trigger root@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64# config-pin overlay cape-universala root@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64# config-pin p9.30 pruout root@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64# make run -copying firmware file gen/hello-pru.out to /lib/firmware/am335x-pru0-fw /bin/sh: 1: cannot create /sys/bus/platform/drivers/pru-rproc/unbind: Permission denied /bin/sh: 1: cannot create /sys/bus/platform/drivers/pru-rproc/bind: Permission denied -rebooting pru core 0 -pru core 0 is now loaded with gen/hello-pru.out root@beaglebone:/var/lib/cloud9/2ecf864e1b3f250bad82c0eae12b7b64# Now I have to modify my stuff. It looks like more simple as expected. Think with given technique I can save the existing IO configuration in my loader, modify to my needs, load firmware and start the pru. At the end I should be able to set the IO configuration as it was before. But first I want to see if the pru will do what I expect Thank you very much for the useful hints. Kasimir -- 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/351b1916-2f44-4552-8dae-45f2619a2afd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hi Jason, you you know another source for download? Think the file was moved away. > The requested URL /rootfs/bb.org/testing/2017-06-11/stretch-iot/bone-debian-stretch-iot-armhf-2017-06-11-4gb.img.xz was not found on this server. Would like to try it out. Thanks and have a good day Kasimir > > > > > -- 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/32b29642-5076-4d0a-861a-f16c4b1ed8c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hi Jason, have to start again from scratch. Have no preference for a specific kernel / distribution, as long I can write C-code for ARM & PRU and they are able to communicate via shared ram. At least pru1 should have influence to the P8_43 P8_46 outputs. No HDMI required. I have a blank Beaglebone black now. Thanks again and have a good day Kasimir Am Dienstag, 5. September 2017 18:55:37 UTC+2 schrieb Kasimir: > > I want to use the HDMI outputs to drive external circuit. Required toggle > rate is between 1MHz and 10MHz. > Have BB black. > uname -a > Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 > armv7l GNU/Linux > cat /etc/debian_version > 9.1 > So I have to use the PRU unit. > I was searching example to have a starting point. > But it sucks already with the first step. > > ll /sys/devices/bone_capemgr* > ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory > > I load the image from here: > http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz > > What is my mistake? > Device tree compiler is up to date > device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+ > 20170719). > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > Found a lot of hints to use the 3.8 kernel. Think that one is already some > years old, can't be true. > > Question: How to create the required device tree overlay, because /sys/ > devices/bone_capemgr* is not existing? > > Thanks 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/525d7b19-1557-4038-abd0-d4fe23276049%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Think I have to stop that project, because it's currently only time consuming and I can't see a possible solution. First I have got the message Debian is recommended, TI advise me to use Ubuntu and different API. So I spent a lot of time for nothing. I'm pretty sure the Beaglebone black fit's perfectly to my needs. But I can't see a consistent flow / tool set / API to do the job. There is always somewhat missing. Thanks for all the hints I have got. Kasimir Am Dienstag, 5. September 2017 18:55:37 UTC+2 schrieb Kasimir: > > I want to use the HDMI outputs to drive external circuit. Required toggle > rate is between 1MHz and 10MHz. > Have BB black. > uname -a > Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 > armv7l GNU/Linux > cat /etc/debian_version > 9.1 > So I have to use the PRU unit. > I was searching example to have a starting point. > But it sucks already with the first step. > > ll /sys/devices/bone_capemgr* > ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory > > I load the image from here: > http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz > > What is my mistake? > Device tree compiler is up to date > device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+ > 20170719). > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > Found a lot of hints to use the 3.8 kernel. Think that one is already some > years old, can't be true. > > Question: How to create the required device tree overlay, because /sys/ > devices/bone_capemgr* is not existing? > > Thanks 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/75e6bf22-d107-48ea-92ed-d786ed3f97a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hello, based on this description I have the following now, think the device tree should work. Interesting is, I have to send echo RoboticsCape > /sys/devices/platform/bone_capemgr/slots & in background, otherwise the prompt is gone. But system is still working. cat /sys/devices/platform/bone_capemgr/slots 0: PF -1 1: PF -1 2: PF -1 3: PF -1 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,RoboticsCape I modified the RoboticsCape for pin40 ... pin43 mode5 outputs. Then compile and result is copied into /lib/firmware. Hope it still works after reboot. The pins are outputs now. pin 40 (44e108a0.0) 0025 pinctrl-single pin 41 (44e108a4.0) 0025 pinctrl-single pin 42 (44e108a8.0) 0025 pinctrl-single pin 43 (44e108ac.0) 0025 pinctrl-single pin 44 (44e108b0.0) 0025 pinctrl-single pin 45 (44e108b4.0) 0025 pinctrl-single pin 46 (44e108b8.0) 0025 pinctrl-single pin 47 (44e108bc.0) 0025 pinctrl-single Hope it's correct. Next is compile my sources, because gcc complains -lprusdrv is not available and so on. The pru C-Code compiles without errors. Any idea what is still missing? Thanks Kasimir Am Dienstag, 5. September 2017 18:55:37 UTC+2 schrieb Kasimir: > > I want to use the HDMI outputs to drive external circuit. Required toggle > rate is between 1MHz and 10MHz. > Have BB black. > uname -a > Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 > armv7l GNU/Linux > cat /etc/debian_version > 9.1 > So I have to use the PRU unit. > I was searching example to have a starting point. > But it sucks already with the first step. > > ll /sys/devices/bone_capemgr* > ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory > > I load the image from here: > http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz > > What is my mistake? > Device tree compiler is up to date > device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+ > 20170719). > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > Found a lot of hints to use the 3.8 kernel. Think that one is already some > years old, can't be true. > > Question: How to create the required device tree overlay, because /sys/ > devices/bone_capemgr* is not existing? > > Thanks 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7b3fd698-aadb-482a-8204-e8df7e47e610%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hi, attached is my simple testcase. puls_gen.c is the loader, pru.c is the program for pru1. It's very simple. First I write some known values in shared memory. Then I load pru progam and activate it. pru1 is moving 2 values ( just to see that it works ) and at the end it should toggle P8_45 (Pin40) full speed. Makefile is included. I'm able to compile pru.c, that works. Currently I'm unable to compile puls_gen.c, because on that ( missing prussdrv.h ) ../include/puls_gen.h:9:22: fatal error: prussdrv.h: No such file or directory #include Device tree is a real problem for me at the moment. I did follow Robert's instructions. What is my next step? Think first my puls_gen.c should compile correctly'? Do I need a local copy of prussdrv.c? I want to use the HDMI ( for test only P8_43 ... P8_46 ) as output. It's mode5 and should be connected to __R30 of pru1. Up to now I didn't find consistent information, I saw Derek Molloy's videos, but was not able to make that happen, because on a different directory structure. Best case it should be possible to modify the device tree as required out of the C-program ( Linux ), and exit from that with status as it was. At the moment I gave up the idea My device tree description is also attached. But currently I'm unable to load that one. What is your recommendation? Any help or link to working example would be appreciated Kasimir PS was not possible to attach the files, how can I provide my data ( 6kB )? Am Dienstag, 5. September 2017 18:55:37 UTC+2 schrieb Kasimir: > > I want to use the HDMI outputs to drive external circuit. Required toggle > rate is between 1MHz and 10MHz. > Have BB black. > uname -a > Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 > armv7l GNU/Linux > cat /etc/debian_version > 9.1 > So I have to use the PRU unit. > I was searching example to have a starting point. > But it sucks already with the first step. > > ll /sys/devices/bone_capemgr* > ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory > > I load the image from here: > http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz > > What is my mistake? > Device tree compiler is up to date > device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+ > 20170719). > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > Found a lot of hints to use the 3.8 kernel. Think that one is already some > years old, can't be true. > > Question: How to create the required device tree overlay, because /sys/ > devices/bone_capemgr* is not existing? > > Thanks 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/81287cc1-7501-47bb-a887-db9684071d5a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hi Robert, this is my current status ( hop I follow your advice correctly ): /opt/scripts/tools/version.sh git:/opt/scripts/:[2ce750d881941c5189db9e189af90517e11c079f] eeprom:[A335BNLT000C1914BBBK0031] dogtag:[BeagleBoard.org Debian Image 2017-08-31] bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2017.09-rc2-2-g7c9353] bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2017.09-rc2-2-g7c9353] kernel:[4.4.84-ti-r120] nodejs:[v6.11.2] uboot_overlay_options:[enable_uboot_overlays=1] uboot_overlay_options:[disable_uboot_overlay_video=1] uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo] uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo] uboot_overlay_options:[enable_uboot_cape_universal=1] pkg:[bb-cape-overlays]:[4.4.20170728.0-0rcnee1~stretch+20170728] pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829] pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830] ls -alsrt /sys/devices/bone_capemgr* ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory I reached that point multiple times in the past . what is missing? Thanks for help Kasimir -- 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/99398ae6-cfca-4cd5-a76c-62d22d76084e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
I have to decide to use what? U-Boot PRU Options With v4.4.x-ti PRU via remoteproc can be enabled by: uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo With mainline (boneX) PRU via uio (doesn't work with v4.9.x-ti yet) uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo Think that's the key point, there are many possibilities, but only one specific combination works. To find out which one it is makes not so much fun. Is somewhere an updated roadmap available, e.g. 1.) image to load 2.) if required, packages to load on top of that 3.) system setup ( I mean hardware, not user, network etc ) I expect many people are trying to use beaglebone for "real time" applications, I'm not the first and only one :-) Up to now I used µP and FPGA's for that kind of applications and I spent not so much nights on that. Thanks for help Kasimir Am Dienstag, 5. September 2017 18:55:37 UTC+2 schrieb Kasimir: > > I want to use the HDMI outputs to drive external circuit. Required toggle > rate is between 1MHz and 10MHz. > Have BB black. > uname -a > Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 > armv7l GNU/Linux > cat /etc/debian_version > 9.1 > So I have to use the PRU unit. > I was searching example to have a starting point. > But it sucks already with the first step. > > ll /sys/devices/bone_capemgr* > ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory > > I load the image from here: > http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz > > What is my mistake? > Device tree compiler is up to date > device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+ > 20170719). > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > Found a lot of hints to use the 3.8 kernel. Think that one is already some > years old, can't be true. > > Question: How to create the required device tree overlay, because /sys/ > devices/bone_capemgr* is not existing? > > Thanks 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/d99cfe9c-ff74-4e89-a11b-ddebba68a189%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: pru support for 4.4.84-ti-r120
Hi Robert, thanks for information. Beaglebone has 2 golden eggs, the PRU units. That's unique. It's confusing to get access to that. It's easy to create the program for arm and pru, but the device tree setup isn't that easy. Will start from scratch and follow your recommendation. Thank you very much Kasimir -- 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/970755ef-d482-44ef-9ef6-96782143fdff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] pru support for 4.4.84-ti-r120
I want to use the HDMI outputs to drive external circuit. Required toggle rate is between 1MHz and 10MHz. Have BB black. uname -a Linux beaglebone 4.4.84-ti-r120 #1 SMP Sun Aug 27 03:11:07 UTC 2017 armv7l GNU/Linux cat /etc/debian_version 9.1 So I have to use the PRU unit. I was searching example to have a starting point. But it sucks already with the first step. ll /sys/devices/bone_capemgr* ls: cannot access '/sys/devices/bone_capemgr*': No such file or directory I load the image from here: http://debian.beagleboard.org/images/bone-debian-9.1-iot-armhf-2017-08-31-4gb.img.xz What is my mistake? Device tree compiler is up to date device-tree-compiler is already the newest version (1.4.4-0rcnee3~stretch+ 20170719). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Found a lot of hints to use the 3.8 kernel. Think that one is already some years old, can't be true. Question: How to create the required device tree overlay, because /sys/ devices/bone_capemgr* is not existing? Thanks 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/4a0b610e-7cc7-4f97-8a93-0e956ae0412c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
