[beagleboard] Re: Reading ADC with both PRUs

where PRU1 could read it. That in itself > would have a potential conflict on PRU0 write/PRU1 read. > On Sunday, June 13, 2021 at 11:38:06 AM UTC-4 TJF wrote: > >> >> wal...@edenconceptsllc.com schrieb am Freitag, 11. Juni 2021 um 18:44:27 >> UTC+2: >> >>&

[beagleboard] Re: Reading ADC with both PRUs

wal...@edenconceptsllc.com schrieb am Freitag, 11. Juni 2021 um 18:44:27 UTC+2: > ... setting up steps 1, 2 and 3 to read three analog lines in one-shot > mode while steps 4 & are set up to read the other two analog lines in > continous mode. I'll write data from steps 1, 2 and 3 into FIFO0

Re: [beagleboard] Re: Shared PRU Memory and beyond

lazarman schrieb am Dienstag, 18. Mai 2021 um 23:02:58 UTC+2: > ... maybe TJF will reply. Hi Bruce, beside 2x8k DRam and 12k SRam libpruio is using a further memory block called ERam (extension or external), find details at https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/h

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

Hi Kasimir, sorry my post overlapped. Kasimir schrieb am Donnerstag, 13. Mai 2021 um 20:36:18 UTC+2: > So the loop instruction is not known ( UNKNOWN in disassembler list ) > Is not a solution for Beaglebone black. > Assembler did not warn or complain. > The LOOP instruction works in PASM

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

Kasimir schrieb am Mittwoch, 12. Mai 2021 um 21:49:33 UTC+2: > 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. > Twice as fast: LOOP EndWait, R17.w0 // note: max 16 bit counter

[beagleboard] Re: Placing integer arrays in PRU Shared memory

wal...@edenconceptsllc.com schrieb am Dienstag, 4. Mai 2021 um 18:16:53 UTC+2: > What am I doing wrong and/or what could I do differently? You could follow experienced councelors. A month ago I told you that libpruio provides that ADC ring buffer. -- For more options, visit

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

wal...@edenconceptsllc.com schrieb am Donnerstag, 22. April 2021 um 21:00:03 UTC+2: > You are correct to mention this TJF. In production, I won't bother to do > convert it to a human-readable number. It helps with debugging right now > though. And for debugging purposes, is it a

Re: [beagleboard] Strange behavior of value returned from PRU with RPMSG

For all who want to learn: Walter is formating a human readable number in the PRUSS code (function ltoa). How much PRU cycles does a four digit number need? And how much are necessary for a one digit number? Note: The PRUSS are fine for realtime solutions (if your code allows that). @Walter

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

ntr or TJF? I believe none of them. The hardware is reality. I make experiments (ask the hardware) to find out what's really correct. There isn't one great TI company. Hardware engineers made a great AM335x CPU design. It's not bug free, but well usable. And software engineers do everything to bl

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

Hi Mark, you're the master of reversed order! You want to code a main loop before IO is working. You want to CCS/JTAG variables before your first LOC is running. Did you ever finish a project? When a subsystem is off (not clocked) the PRU can still read or write its registers. Readings are

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

rience in developing realtime closed loop controllers. > I'm on tablet forgive my laziness where are the ADC examples located in c > language if possible > See https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html C examples including ADC: 1.c, io_input.c, rb_file.c

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

open delay and a sample delay, as well as an avaraging number. That's explained at AdcUdt::setStep() <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/class_adc_udt.html#a243d91f0b7b7a29ada9bc14364c3284f>, including a hint where to find further information in the ARM TRM.

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

lazarman schrieb am Donnerstag, 15. April 2021 um 07:55:39 UTC+2: > I thought he had an unacceptable delay reading ADC from ARM? > Just trying to understand how libpruio fixes this and if it did why even > bother with PRU? > In RB mode libpruio fetches ADC data at accurate timing (no delays) in

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

wal...@edenconceptsllc.com schrieb am Mittwoch, 14. April 2021 um 17:58:31 UTC+2: > So I looked over the libpruio page and it looks great. My head's spinning > a bit between remoteproc, uio, and libpruio options but I'd like to try > libpruio. > I don't want to break remoteproc if I set up

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

e can help make this clearer, I'd appreciate it. Check out example pruss_toggle <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle> . -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are sub

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

gt; >> I'll look at that. I thought remoteproc was the way of the future so I >> was heading down that path. And if in production I don't need to do a lot >> of data transfer, does it make sense to use uio_pruss/libpruio ( I don't >> know much about these, it's probably evid

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

Hi Walter! A further "old dog" here. Sometimes I'm still working on my old Hades computer with 68060 CPU (loving that box). In my house I'm using a BBB for a solar system running 24/7. It also controlls two valves (on/off, and four AC pumps in 16 power levels), connected to WLAN by an

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

src/python. FreeBASIC examples are in folder src/examples. And C examples are in folder src/c_examples. Find an overview at https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html Regards -- For more options, visit http://beagleboard.org/discuss --- You rec

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

Hi! Check out libpruio for easy and reliable ADC measurements with accurate timing. I guess RB (ring buffer) mode is your way to go. Regards -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed

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

Drew Fustini schrieb am Mittwoch, 31. März 2021 um 22:29:35 UTC+2: > To clarify for anyone finding this thread in the future. > > eQEP (encoder input) driver is in mainline Linux kernel thanks to David > Lechner: > https://elixir.bootlin.com/linux/latest/source/drivers/counter/ti-eqep.c > >

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

Hi Fabio! You're correct, eCAP is pretty much undocumented and unsupported. Find examples in the libpruio <https://github.com/DTJF/libpruio> project at https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPwmCap and https://users.freebasic-portal.

[beagleboard] Re: Overlay -- set GPIO initial value

Hi! rpau...@gmail.com schrieb am Donnerstag, 18. März 2021 um 16:06:43 UTC+1: > Is it possible in the device tree overlay to not only set the mux setting, > but also set the pin initial value? For example, if I set a GPIO as an > output, can I also set that output hi? No, that's not

Re: [beagleboard] Re: Recomended practices for using the PRUs

libpruio checks for claimed pins in sysfs file /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins This path changed in kernel 4.19 to /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pinmux-pins so that pinmuxing fails. You can fix it by creating a link named as the old path

[beagleboard] Re: BBB Libpruio Analog Data

16 bit = 2 byte! Parsing the buffer in JavaScript code: const val = new Uint16Array(Buffer); // val.length = 1 (2 channels x 5000 samples) // output raw data: integer from 0 (=0V) to 4095 (=1V8) console.log(val[0], val[1]); // first samples AIN-1, AIN-2 console.log(val[2], val[3]); //

[beagleboard] Re: BBB Libpruio Analog Data

Hi! ritesh...@gmail.com schrieb am Dienstag, 9. März 2021 um 21:15:01 UTC+1: > Specifically, they are collecting the data using Ring Buffer mode and > saving it to a text file to be processed further for some feature > extraction and further analysis. > > What I'm trying to understand is this:

[beagleboard] Re: GPIO, libpruio & dtbo Question

rth the effort! As mentioned above, the while loop should get placed in a custom sleep function. And since the app does nothing in that sleep function, the abortPIN can get polled fast enough (20 to 100 Hz). Dennis Bieber schrieb am Donnerstag, 4. März 2021 um 23:41:22 UTC+1: > Non Sequitur: &qu

[beagleboard] Re: GPIO, libpruio & dtbo Question

Why so complicated? Dennis Bieber schrieb am Donnerstag, 4. März 2021 um 05:03:54 UTC+1: > Your sleep() and loops would then include something like "while not > abortFlag". > Replace while not abortFlag by while pruio_gpio_Value(io, abortPIN) and drop all that IRQ magic (which only makes

[beagleboard] Re: latest machinekit image isn't loading uio dtb

In debian LTS-5_4 (20-05-18) there is no uio_pruss driver. See https://groups.google.com/g/beagleboard/c/WhS8mHDWY58/m/1Ip8wMO9AQAJ No answer yet. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups

[beagleboard] Re: GPIO, libpruio & dtbo Question

Hello Don Pancoe! Why do you think you'll need an IRQ for the "abort" button? Drop Adafruit_BBIO! Just setup the GPIO in libpruio and poll the state in your main loop (or in a timered thread). Regards donp...@gmail.com schrieb am Montag, 1. März 2021 um 19:27:01 UTC+1: > Hello all, > > I have

[beagleboard] Re: PWM

including hardware limits) at https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPins.html#sSecPwm Note: In order to benefit from all that capabilities, you've to use libpruio (Phyton binding available). Regards -- For more options, visit http://beagleboard.org/discuss --- You

[beagleboard] No uio_pruss driver in LTS-5_4 kernel?

$ sudo /opt/scripts/tools/version.sh git:/opt/scripts/:[20c080bc91f243ef852a704758788a31083b0f9e] eeprom:[A335BNLT00C03614BBBK3547] model:[TI_AM335x_BeagleBone_Black] dogtag:[BeagleBoard.org Debian Buster Console Image 2020-05-18] bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot

[beagleboard] Re: Pin MUX and other Mode Settings

Hi Fisher! For pinmuxing without limitations and performed from user space (no re-booting) check out libpruio . Drop rpmsg, it isn't helpful at all (for real projects and professional development). UIO_PRUSS is the driver to use. Regards -- For more

[beagleboard] Re: Controling sample rate

libpruio <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/> provides full access to all TSC_ADC_SS registers. It offers the most efficient (and most easy) way to controll ADC sampling. Regards -- For more options, visit http://beagleboard.org/discuss --- You re

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

@Dimitar SBBO is a two-cycle instruction. In order to get 200 MHz you've to use MOV. @Andrew The MVIx family of instructions provides an auto-increment feature. But it doesn't really help. Like Dimitar suggested it's best to code a sequence of immediate operations to store a burst of

[beagleboard] Re: Guide on configuring pins

Am Freitag, 16. Oktober 2020 14:34:30 UTC+2 schrieb dee v: > > Still, a guide on how to do this without going through third-party > libraries would be nice... Make your choice: one third-party library or several guides for each kernel version ... -- For more options, visit

[beagleboard] Re: Guide on configuring pins

switch a PIN from input to output while your program is running. And your software is working on all kernel versions from 3.8 to the current 5.x without any adaption. Find details at http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html Regards -- For more options, visit

Re: [beagleboard] Re: Boot time optimization

-bone- kernels are booting faster than the -ti- flavors. -- 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

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

PS: If somebody knows a good protection circuity for the ADC inputs (ie OP-amp working with ADC Vref), please let me know. Regards -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Andrew! I've also seen frozen ADC. I guess (not confirmed yet) it's coming from negative Voltage on the input line. I tried to disable and re-enable only the TSC_ADC_SS (while the rest of the system is running), to no avail. But after a system reset (warm-start) the ADC always runs well.

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Sorry, I forgot the second part of the command: *ExecStartPre=/bin/dash -c 'until [ -e /dev/uio5 ] ; do sleep 1 ; done ; > /bin/chown root:pruio /dev/uio5'* > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Andrew! It seems that you're making good progress with your project. Congrats! This works in my projects [Unit] > After=generic-board-startup.service libpruio-lkm.service > StartLimitIntervalSec=0 > > [Service] > Type=simple > Restart=always > User=debian >

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

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 co

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

The output lines in a GPIO subsystem are limited to a maximum current of 6 mA. The users/students should know that they need a low power/current LED for your circuit. The value of the current limiting resistor depends on the threshold voltage of the LED, which depends on the LED color. 220Ω is

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

or that two pins. Check out the docs for section Custom overlay <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPins.html#sSecCustom>. You can use the tool src/config/dts_custom.bas <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/dts__custom_8bas.html

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

or messages <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaMessages.html#sSecPruIoSetPin>). Note: I did already mentinon this above. The command lsmod should list (beside others) Module Size Used by > uio_pdrv_genirq16384 0 > libpruio

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Am Mittwoch, 19. August 2020 21:56:23 UTC+2 schrieb andrew...@gmail.com: > > I can't find a reference to the setPin function in the python library > Check out example pruss_toggle.py <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruss__toggle_8py.html> . >

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

ns to their UART mode by libpruio and make sure that the matching driver is loaded (lsmod ...). Or configure the UART pins in a custom device tree blob ( http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPins.html#sSecCustom ). -- For more options, visit http://beagleboard

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

On my system I found the files # /etc/udev/rules.d/84-gpio-noroot.rules > # > # Corrects sys GPIO permissions on the BB so non-root users in the gpio > group can manipulate bits > # > # Change group to gpio > KERNEL=="44e10800.pinmux", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio >

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Thanks for the tip! Am Donnerstag, 13. August 2020 15:47:14 UTC+2 schrieb Dennis Bieber: > > Try replacing that line with > > sys.stdout.write("%4X " % AdcV[i]) > > I've moved the space separator into the "..." format string. > > .write() doesn't add line

Re: [beagleboard] Re: libpruio (fast and easy D/A - I/O)

Am Donnerstag, 13. August 2020 18:16:55 UTC+2 schrieb Andrew Harres: > > debian@beaglebone:~$ groups > debian adm kmem dialout cdrom floppy audio dip video plugdev users > systemd-journal input bluetooth netdev cloud9ide xenomai weston-launch > tisdk docker i2c iio spi admin remoteproc eqep

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

I forgot to mention that the modified file doesn't work in python2 any more: src/test$ python 1.py > File "1.py", line 32 > print("%4X" % AdcV[i], end=" ") #output one channel in hex > ^ > SyntaxError: invalid syntax > > -- For more options, visit

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

I tried the tool Denis mentioned. It works: libpruio/src$ cp python test > libpruio/src$ 2to3 -w test > root: Generating grammar tables from > /usr/lib/python2.7/lib2to3/PatternGrammar.txt > root: Generating grammar tables from > /usr/lib/python2.7/lib2to3/PatternGrammar.txt > root: Generating

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

I forgot: $ python --version > Python 2.7.13 > $ python3 --version > Python 3.5.3 > > -- 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

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

I did some testing here on a similar system: $ uname -r > 4.14.69-ti-r76 > $ python 1.py > F800 E9C0 F3B0 8230 5370 9830 B450 F2B0 > F910 EEC0 F540 C600 9BA0 9230 9830 F2F0 > F920 EEE0 F500 CC90 ABC0 A190 9FB0 F2E0 > F960 EF20 F4B0 CDA0 AEF0 A6D0 A440 F2B0 > F960 EEA0 F510 CDB0 B240 ACF0 AAF0

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

The pinmux-pins output is reasonable. Do you have read access to the file from user space? Regarding the errors in ctypesloader.py: this isn't my code. I just reduced code from the ctypes documentation to the bare minimum. Perhaps you can try the original file? Regards -- For more options,

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Andrew! First, the boot process seems to be OK. The driver uio_pruss as well as the libpruio-lkm are loading. Am Mittwoch, 12. August 2020 17:40:45 UTC+2 schrieb Andrew Harres: debian@beaglebone:~$ python src/pruio_examples/1.py > Traceback (most recent call last): > File

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Am Dienstag, 11. August 2020 21:24:48 UTC+2 schrieb andrew...@gmail.com: > > Is python 3 not supported? > AFAIR I tested on python 2 and 3. The message (cannot open /dev/uio5) > is related to the uio_pruss driver. The interupt handler is either not present (command lsmod doesn't list

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Am Dienstag, 11. August 2020 18:19:13 UTC+2 schrieb andrew...@gmail.com: > > I've installed libpruio, python-pruio, libpruio-lkm, and libpruio-doc. > ... > Is there something I'm missing? > AFAIR the python interpreter (ctypes) also needs the dev-package to bind the library: libpruio-dev

Re: [beagleboard] libgpiod on Beaglebone AI

There're two options to control the 32 outputs of a GPIO subsystem: 1. writes to register GPIO_DATAOUT, or 2. writes to registers GPIO_SETDATAOUT and GPIO_CLEARDATAOUT In the first case all pins switch at the exact same time. But there's a downside in controlling all 32 pins at once: it

[beagleboard] Re: Python example of continuous analog in

iguration can be done in the source from user space. Ie check out the example rb_file <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaRbFile> . Regards -- For more options, visit http://beagleboard.org/discuss --- You received this mess

[beagleboard] Re: July 2020 GPIO Best Practices

Hi Dave! Am Montag, 20. Juli 2020 15:30:56 UTC+2 schrieb dave m.: > > Is there a FAQ or compendium of current best practices? > There has been good documentations for Kernel 3.8. But the kernel changed and the docs got out of date. What about PRU -- I found some stuff about libpruio that

[beagleboard] Re: Problems Reconfiguring GPIO's

1) While I'm always grateful for your responses, TJF, you need to > understand that your answers almost always come across a bit ... abrupt. I > presume it's a language thing as I couldn't possibly convey nuance in > German. > I'm sorry if you're not fast enough. 2) You know the li

[beagleboard] Re: Problems Reconfiguring GPIO's

Am Montag, 22. Juni 2020 07:45:44 UTC+2 schrieb Andrew P. Lentvorski: > > Pinmuxing *must* be done from privileged mode (effectively: Linux > kernel/kernel module only). > Correct. Neither userspace nor PRU can change a pinmux. > Not correct. In a libpruio configuration all members of

[beagleboard] Re: Problems Reconfiguring GPIO's

@ P B: > I want to ensure the pump is not triggered from any noise. Perhaps I > misunderstood this feature. > You should also consider to implement an external pulldown. The weak internal resistance isn't present in the early boot phase (it comes up 7-10 seconds after power-on). @ Dennis

[beagleboard] Re: Problems Reconfiguring GPIO's

Am Donnerstag, 18. Juni 2020 19:11:20 UTC+2 schrieb Dennis Bieber: > > -- Linux app sending command to PRU application to modify pin-mux so Linux > app can make use of new state > How do you make the PRU modify pinmuxing? You have no idea what you're talking about! Regards -- For more

[beagleboard] Re: Problems Reconfiguring GPIO's

source code, compiled against libpruio. (This also safes boot-time and kernel memory.) Example: ... // Input if (pruio_gpio_config <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__c__wrapper_8bas.html#ac5405314ef2c35a9604262a22378420d> (io, P8_11 <http://users.freebasic-p

[beagleboard] Re: eqep2 problemss

Am Samstag, 6. Juni 2020 09:49:59 UTC+2 schrieb cesare@gmail.com: > > Is there something else I can check? > Sure, check out libpruio. <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/> Easy controlling of QEP modules in one, two or three line configuration

Re: [beagleboard] config-pin for gpio output

tem group "pruio" have pinmuxing access from user space. This concept saves lots of kernel memory and more than six seconds boot-time. Check out the documentation <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html> . Regards -- For more options, vis

Re: [beagleboard] config-pin for gpio output

Am Mittwoch, 3. Juni 2020 16:27:38 UTC+2 schrieb RobertCNelson: > > The proper way is to use libgpiod tools such as gpioset ;) > The proper way is to use libpruio and do pinmuxing single source in the code ;) pruio_gpio_setValue(io, P9_11, [0,1]); Regards -- For more options, visit

Re: [beagleboard] Re: Could PRU read this signals?

I'm not sure what has to be > given up for it, ... > On BBB one can configure a 17 bit unidirectional interface on PRU-0 (perhaps also bidirectional by run-time pinmuxing). The SD card slot has to be given up for it. Find details in section PRU fast GPIO 16 bit <http://users.fr

[beagleboard] Re: Could PRU read this signals?

Am Freitag, 29. Mai 2020 11:35:56 UTC+2 schrieb PAk Ys: > > My idea is to create a simpler, better device able to work with the > beaglebone (or the beaglewire), allowing users to create their own radar > applications in a very fast way (including the UI). > You can use the second PRU to

Re: [beagleboard] Could PRU read this signals?

sub-loop. AFAI understand your signal diagram, you're dealing with redundant data. Only three lines provide information. Find example code in the libpruio documentation. Example pruss_toggle <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruTog

Re: [beagleboard] Could PRU read this signals?

Hi! Am Dienstag, 26. Mai 2020 17:04:50 UTC+2 schrieb PAk Ys: > > Our signal will be in the tens of MHz (from 5Mhz to 50MHz max), depending > on configuration. > > The polling method is what I expected, however the manual (spruh73q) > states there are three methods (Direct Input, Parallel Mode

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Thomas! Check out the ring buffer mode . Find example code in rb_file (.c, .py, .bas) or rb_oszi (.bas) . Regards -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi! By any reason the key file signing got lost. I re-signed it. It should be OK now. 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

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

PS: >From my point of view, I as a developer should not provide the packages. It'd be best to include libpruio in RCNs build farm, in order to get a fresh binary for each new update. He startet that project, but never finished jet. I don't know why. Perhaps libpruio users should motivate him

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Hans! Am Dienstag, 5. Mai 2020 00:47:22 UTC+2 schrieb Hans Leeuw: > > I have upgraded and I get this warning while compiling my program (using > rb): > I avoid updates, if possible. It takes too much time to optimize the boot time again and again. > /usr/bin/ld: warning: libtinfo.so.5,

[beagleboard] Re: Converting GPIO pins to MMC mode (BeagleBone Black)

Am Dienstag, 28. April 2020 23:56:34 UTC+2 schrieb geral...@motorolasolutions.com: > > I was able to toggle those 2 lines as GPIO and validate their manipulation > using a logic analyzer. > > When done, I went back to the other program to communicate with the micro > SD card in the slot and

Re: [beagleboard] boot time on image that ships on the Beaglebone AI

Am Montag, 27. April 2020 03:16:09 UTC+2 schrieb Bernard Fischer: > > My BBAI takes a minute and a half to boot as well. The times look similar > to what John Allwine posted. > > BB Blue is pretty pokey as well, but not as bad, I don't think (I'll have > to double check). > You must be in

[beagleboard] Re: Converting GPIO pins to MMC mode (BeagleBone Black)

Hi! In a libpruio <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/> configuration you can handle this (and all other) pinmuxing task without any reboot or device tree manipulation. Note: you've to drop the config-pin tool and all its cape-universal device tree

[beagleboard] Re: PocketBeagle Boot Time

On BBB: $ systemd-analyze Startup finished in 1.067s (kernel) + 15.828s (userspace) = 16.896s Booting with USB WiFi stick including connection with static IP adress. Should be possible with PocketBeagle as well. Find details at

[beagleboard] Re: segmentation fault PRU

Hi! Am Dienstag, 14. April 2020 21:33:09 UTC+2 schrieb hellob...@gmail.com: > > i have error "Segmentation fault" > This run-time error most likely is coming form the call to function prussdrv_open() in your ARM code. There's no way to open the /dev/uio? device, due to missing write

[beagleboard] Re: javascript / bonescript structure

You don't need interrupts for counting pulses. Instead use the hardware counters inbuild in the AM335x CPU. Those are - 3xPWMSS.eQEP - 3xPWMSS.eCAP - 4xTIMERSS Find details and example code (C, Python, BASIC) in the libpruio documentation <http://users.freebasic-portal.de/

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Am Dienstag, 10. März 2020 01:33:50 UTC+1 schrieb Hans Leeuw: > > And the other difference is that you seem to have disabled serial. I guess > that is on purpose? > Sure. Standard maintenence I do by WLAN. If I need a wired connection, ie. to configure WLAN, I use a temporary LAN connection. In

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Am Dienstag, 10. März 2020 01:14:42 UTC+1 schrieb Hans Leeuw: > > > I don't know why the pgp file is broken:-( Thanks for reporting. I >> re-signed both. Download from the PPA should be OK now. >> > Unfortunately the same error. Can it be buster related? > Yes, it can. Perhaps Buster uses a

[beagleboard] Re: Time synchronization of hardware clock and PRU?

ide that feature (32 bit counters with divider at 24 MHz --> maximal toggling time stamp = 45812984s). Find details and example code at http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaPins.html#sSecTimer But as long as you synchronise both systems by an LINUX app, you'll face l

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

Hi Hans! Don't work that late at night :-) I don't know why the pgp file is broken:-( Thanks for reporting. I re-signed both. Download from the PPA should be OK now. Find attached some files from the fast-boot system, hope that helps. $ systemd-analyze Startup finished in 1.067s (kernel) +

[beagleboard] Re: Bluetooth Android App

Why bluetooth? Isn't WiFi more easy/powerfull? Ie. a JavaScript app in a browser sending to a fcgi client on the BBB. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe

[beagleboard] Re: Time synchronization of hardware clock and PRU?

Your target seems to be possible. The PRU clock is very stable. Start with example code at pruss_toggle <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle>. Adapt the pinmuxing and the PRU firmware: 1. PRU generates your desired 1 Hz

Re: [beagleboard] Re: Need advice on how to reduce boot time

Am Donnerstag, 27. Februar 2020 16:14:08 UTC+1 schrieb RobertCNelson: > > On Thu, Feb 27, 2020 at 9:04 AM TJF > > wrote: > > > > In the past three years I learned: the newer the image, the longer the > boot time. > > > > Developers are working

[beagleboard] Re: Need advice on how to reduce boot time

In the past three years I learned: the newer the image, the longer the boot time. Developers are working in the wrong direction. They're wasting their time. They're wasting my time, since I've to spend more and more effort to strip the boot process to the bare minimum. Am Donnerstag, 27.

[beagleboard] Re: Need advice on how to reduce boot time

On 4.14.146-bone29 I've a system starting my custom application after 7 s. The entire boot process ends after 18 s, WiFi network connection included. It's a standard image, but no cape-universal overlays ==> no Adafruit libraries, instead libpruio. -- For more options, visit

[beagleboard] Re: Rotary encoder in CNC servo boucles

The AM335x CPU has three PWM subsystems, each one containing an eQEP module. So three rotary encoders are supported by the hardware (speed and direction/position @ 100 MHz counters). In order to measure speed only (no direction/speed) you can use the eCAP modules in two of that subsystems (the

[beagleboard] Re: Can't get overlay to set pinmux for IEP

I guess your overlay cannot 'disable' pins that're claimed by another overlay. And here you're facing the core problem when working with device trees: you won't get reliable error messages. Everything ends up with trail-and-error bug finding. I've good reasons why I always drop config-pin and

[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux

t; > On Sunday, January 19, 2020 at 12:38:28 AM UTC-8, TJF wrote: >> >> >> It was your idea to use the PRU-IEP module. I recommended to use a pin on >> a GPIO-SS. >> > > I went hunting for GPIO-SS--I didn't find anything. I went hunting for OE > (o

[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux

BTW: Am Sonntag, 19. Januar 2020 09:20:58 UTC+1 schrieb Andrew P. Lentvorski: > > Okay, yes, if I build a kernel module I now have full access to all > registers on the system with no restrictions. That's sort of like swatting > a fly with an H-Bomb, but it will work. > You need not build

[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux

he beginning it was a work-aroung, and only cosmetic changes were done. Anyway, you can pinmux at boot-time by writing, compiling and installing a customized device tree overlay. The tool http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/dts__custom_8bas.html may be helpful in that c

[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux

I forgot to mention: If you want to use that pin for tri-state (as discussed in an other thread), you've to enable the receiver as well if (io->setPin(io, P9_18 <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__pins_8bi.html#af38ae7c5f55c73ea6b438c6806e5cf6

[beagleboard] Re: Set pinmux to PRU Industrial Ethernet Peripheral (IEP) from Linux

No way! P9_17 is for PRU-1. But libpruio <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html> can set P9_18 to pr1_edio_data_out0, which is mode 6. Find example code at http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruss__toggle_8c_source.html I

[beagleboard] Re: Make PRU-controlled pin change direction or go tri-state?

is a driver for a one-wire (w1) bus, reading and sending data on a single GPIO line for multiple divices. The library documentation is at http://users.freebasic-portal.de/tjf/Projekte/libpruw1/doc/html/ -- For more options, visit http://beagleboard.org/discuss --- You received this message

  1   2   3   4   5   6   7   >