[beagleboard] Re: Reading ADC with both PRUs

[TJF]

I don't understand that concept. When you switch bits in the STEPENABLE 
register, you'd loose accurate ADC timing. What sampling rate are you 
talking about?

AFAIR your target is to controlling two eletromagnetic valves (water 
medium?). They've a latency of more than 10 ms -> sampling rate & 
controller loop should be 1 kHz or above.

When sampling all 5 channels continguously in one FIFO and fetching them by 
one PRU in a ring buffer (SRam), you can do this with accurate timing up to 
40 kHz (more than enough). Meanwhile the other PRU evaluates the ring 
buffer, computing the standard channels (4 &) continguously and the other 
channels (1, 2, 3) on demand. Note: There're 1000 PRU cycles between two 
ADC samples, and 5000 PRU cycles between a sequencer loop (@ 40kHz). Both 
PRUs exchange the last ring buffer writing position by DRam (or scratch 
pad).

This alternative concept does not only guarantee accurate timing, it's also 
easy to develop and maintain.

BTW: It doesn't matter which PRU (or the ARM) does the configuration. Just 
starting the sequencer (CTRL register) should be done by the ADC-PRU.

wal...@edenconceptsllc.com schrieb am Montag, 14. Juni 2021 um 19:55:30 
UTC+2:

> I am thinking that I'll have PRU0 do all the configuration and enabling of 
> the TSC and have the values for the two sensors that I want PRU1 to monitor 
> put in FIFO1.  I'll have PRU0 only read from FIFO0 and let PRU1 only read 
> from FIFO1.  
> I will set up the three I want to read in one-shot mode and have PRU0 
> enable them to be read again.   the other two will be in continuous mode so 
> PRU0 won't have to do anything as long as it doesn't change their 
> configuration.   
> If PRU-1 waits until PRU-0 is done then it can read FIFO1 as needed to get 
> the data.  I only need it to read these possibly as little as once per 
> second so that alone will reduce the number of potential conflicts with 
> PRU0.
>
> If this will work it will eliminate having PRU0 read FIFO1 and write the 
> data into shared memory space 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:
>>
>>> ... setting up steps 1, 2 and 3 to read three analog lines in one-shot 
>>> mode while steps 4 & are set up to read the other two analog lines in 
>>> continous mode.  I'll write data from steps 1, 2 and 3 into FIFO0 and 4 & 5 
>>> into FIFO1.
>>>
>> Yes. You can use the FIFO_select bit (26) in the STEPCONFIGx registers to 
>> spread the samples. And when the Mode bits (1-0) are cleared (one-shot) the 
>> sequencer will disable that step after operation (in STEPENABLE register). 
>> Next turn  the sequencer will again consider only enabled steps.
>>
>> The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
>>> the same time?
>>>
>> Not at the same time, but one after the other (L3 access control). AFAIR 
>> PRU-1 waits until PRU-0 is done. And both PRUSS are waiting until ARM is 
>> done.
>>
>>

-- 
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/229ebebd-2672-449b-a9ac-5ff2c99d2027n%40googlegroups.com.

[beagleboard] Re: Reading ADC with both PRUs

[TJF]

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 and 4 & 5 
> into FIFO1.
>
Yes. You can use the FIFO_select bit (26) in the STEPCONFIGx registers to 
spread the samples. And when the Mode bits (1-0) are cleared (one-shot) the 
sequencer will disable that step after operation (in STEPENABLE register). 
Next turn  the sequencer will again consider only enabled steps.

The question is can PRU0 read FIFO0 while PRU1 might try to read FIFO1 at 
> the same time?
>
Not at the same time, but one after the other (L3 access control). AFAIR 
PRU-1 waits until PRU-0 is done. And both PRUSS are waiting until ARM is 
done.

-- 
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/f4f5965c-6350-442a-b91a-47b7535d9cecn%40googlegroups.com.

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

[TJF]

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/html/ChaMemory.html#SecERam

This block is 128k by default and can get configured up to 8MB = 4MS@16Bit. 
Using that block your task is easy:

   1. Send the physical ERam adress to the PRU (DRam).
   2. Fetch by PRU firmware ADC samples and store them in ERam (integer).
   3. Read ERam from ARM side and compute (float).

That's how the MM and RB mode in libpruio works (fetching samples from the 
internal TSC_ADC_SS).

You're talking about 1MS/s. That's 200 PRU cycles per value. It sounds like 
a simple task.

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/5df6d3ee-47ef-49de-8c3a-acf1cab4fcban%40googlegroups.com.

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

[TJF]

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

Note: nested LOOP instructions are not allowed.

-- 
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/5562829e-1b8f-4f89-b8cc-a7d2649acccbn%40googlegroups.com.

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

[TJF]

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
EndWait:
 

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

The LBBO , r15, 4, 1 instruction needs at least 3+1 cycles (as long as 
the adress in R15 is not in the PRU local memory map). And it may take 
additional cycles in case of heavy trafic on the L3 bus.

Note: for cycle watching you don't need an osci. Instead you can use the CYCLE 
Register (offset = Ch) in the PRUSS_PRU_CTRL register space.

-- 
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/7aece696-e87a-4668-971a-932aa700ff59n%40googlegroups.com.

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

[TJF]

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 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/7e92570f-4186-4838-b6d6-a37695b2e1e5n%40googlegroups.com.

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

[TJF]

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 good idea to convert at PRU side? From 
my point of view the CCS and rproc/rpmsg concepts are dangerously 
misleading. 
<https://context.reverso.net/übersetzung/englisch-deutsch/misleading> 

-- 
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/0e11d218-d8ec-41a8-bebb-338e0f99366fn%40googlegroups.com.

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

[TJF]

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
Welcome to rproc/rpmsg - you completely lost track.

-- 
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/11b35216-030c-42c5-8ec2-5a1a1c41d40dn%40googlegroups.com.

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

[TJF]

Hi Mark,

let me first point out that this discussion isn't in my mother tongue. 
Sometimes I read your statements several times still not understanding what 
exactly you mean.

Mark Lazarewicz schrieb am Sonntag, 18. April 2021 um 16:49:22 UTC+2:

> who you want to believe Texas Instrumentr 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 block the hardware benefits.

So the question should be: blinking a led, do you want to follow an CCS 
example (changing with each new kernel version) or an libpruio example 
published years before (2014, still working)? Do you want to learn from 
coders making small examples only, or are you interested in hands-on 
experience form people who did already fill up the IRam of both PRUSS?

You're lucky, I'm waiting for feedback before starting my next project. So 
I've time to waste of good mojo. 

-- 
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/0646b780-3ac1-41fe-8c7d-3ee2b2156b66n%40googlegroups.com.

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

[TJF]

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 always zero and writings go to Nirvana, no error 
message, no exeption. How should a debugger help in this case?

Mark Lazarewicz schrieb am Sonntag, 18. April 2021 um 03:13:10 UTC+2:

> Anyway Linux is not required for CCS and its slow and inferior to Windows 
> 10 version


LINUX is stable and reliable. Anyway, CSS is not required for PRU 
development. Since I aim to open up the full PRUSS power (I've payed for), 
I continue ignoring all that CSS bloat (!! a linker for a 2k instruction 
space !!).

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/4caa73f5-e1a9-4342-b0c0-0b4fdf9ef98bn%40googlegroups.com.

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

[TJF]

lazarman schrieb am Freitag, 16. April 2021 um 09:01:56 UTC+2:

> Looks very powerful and code is very generic and well thought out. I 
> thought you couldn't code?藍

Even a blind hen sometimes finds a grain of corn. I'm not a programming 
expert, but I've a ton of hands-on experience 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

Since I don't know how to generate graphical screen output in C (or 
Python), I didn't transform the further ADC examples (ie MM mode). They're 
FreeBASIC only. (Feel free to help out here.)

I'm guessing  below reference you mentioned is the am335x TRM or are you 
> referring to the ARM intellectual property for ADC?
>
> It's also possible to directly write to the step configuration in 
> AdcSet::St_p 
> <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/class_adc_set.html#a5963b11e6b966423547162d856cc0049>
>  by 
> writing to the member variables Confg and Delay. See ARM Reference Guide, 
> chapter 12 <http://www.ti.com/lit/pdf/spruh73> for details on ADC 
> configurations.
>
Just click on the text "ARM Reference Guide, chapter 12". It's a link to 
the document I'm refering to.
 

> Thanks. Did you write this library? It's quite a bit to wrap ones mind 
> around. How long dis this take to develop. 
>
The main tasks were to get the FreeBASIC compiler running on ARM, to 
develop the CMake support for that language and to create a filter for 
Doxygen. Then the first version was less than three month. Find details at

https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaChangelog.html
 

> I've got a basic  understanding of how RPMSG works I'd like to understand 
> how libpruio handles the data exchange. 
>
> I'm wondering why Walter isn't using RPMSG  he's talking about using the 
> other unused  PRU memory to store data and have ARM read it. I'm trying to 
> see if that's doable for my own understanding. Certainly would not be good 
> if that PRU loaded code from ARM. The Linux part I'm unfamiliar with. From 
> my reading it sounds like starting PRU is manually done from linux command 
> line. 
>
> Loading and debugging PRU code seems to me to be slow and time consuming 
> compared to jtag.
>
> Lastly in the unlikely event a modified libpruio example crashes what is 
> the debug mechanisms beyond dmsg saying dude you crashed go recompile and 
> reload. Are console output echoed back.
>
Again: libpruio does not use, and will never use rproc/rpmsg.
 

> Thanks in advance also any data sharing examples in libpruio?
>
pruss_add.c, pruss_toggle.c
And, of course, libpruio itself.

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/0655e0fe-4158-473b-a47a-15ec77e533c4n%40googlegroups.com.

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

[TJF]

wal...@edenconceptsllc.com schrieb am Donnerstag, 15. April 2021 um 
18:35:20 UTC+2:

> So, STEPENABLE lets me enable the steps that I want to be executed.  (I 
> missed that concept before.)
>
> So if I had an application that had a sensor A that needs to be read every 
> 10ms and sensor B that only needs to be read every minute, I could wire 
> channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor 
> B and assign it to step 2. 
>
> Then at startup, when I want to read both sensors, I enable steps 1 and 2 
> but not 3-16.  This saves time on the read as channels 3-7 aren't needed 
> and steps 3-16 aren't needed so I don't use them.  Then after the initial 
> read when I don't need to read sensor B until a minute passes, I can change 
> STEPENABLE so only step 1 is enabled and execute a read every 10 ms.  Only 
> sensor A would be read.  Then at one minute intervals, I change STEPENABLE 
> so steps 1 & 2 are enabled and when read is triggered, sensors A and B are 
> read. 
>
There're 17 steps, one charge step and 16 sample steps. Each step 
configures not only the multiplexer (chanel 0-7), but also an 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.

In order to write to the STEPENABLE register you've to stop the sequencer, 
write the new value and restart the sequencer again. This is 3 times L3 
operation, which need at least 3 PRU cycles each (perhaps more in case of 
heavy travel). How do you what to ensure accurate ADC timing?

The outnumber of step registers isn't thought of macroscopic asymmetry (in 
your case sample channel A and B at 10 ms and ignore the B value for a 
minute). It's made for microscopic asymmetry, ie when you want to sample A 
twice as often as B.

-- 
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/def726b2-31f2-469b-a9fc-70fc429ffa59n%40googlegroups.com.

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

[TJF]

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 to a 
ring buffer. The ARM can read/evaluate the data later.

@Walter
Inspired by lazarman, just another thought: perhaps you don't need a PRU 
mainloop at all. Perhaps you can meet your needs by ARM code using the 
libpruio trigger features in MM mode.

   1. Configure your trigger event (up to four events can get chained up).
   2. Open valves.
   3. Start MM mode, synchronously waiting for trigger.
   4. Close valves.
   5. ?Perhaps evaluate pre-trigger values?
   6. Repeat from step 2.

-- 
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/65f2d6a6-7ddd-4cac-98ef-39bec6f6bc73n%40googlegroups.com.

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

[TJF]

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 to use libpruio.  Will that 
> happen?
>

libpruio will never run under rproc, since rproc isn't powerful enough 
(same issue with maschinekit). Only uio_pruss driver will meet its needs.
 

> Also, I'm running Buster (version.sh) at the bottom of this post 
> The instructions refer to Jessie.  Are the Debian packages referred to 
> compatible with Buster?  Here's what I am referring to.
>
> The easy way to benefit from *libpruio* is to install the Debian 
> packages. They're not in mainline, yet.
>
RobertCNelson started to add the packages in mainline years ago. Ask him 
why he never finished.

For kernel 4.19 you'll have to add a symlink, since a sysfs path changed. 
(Compiling from source may be a good option.)
 
Start your project by a working example. Then add features step by step. 
You cannot test your PRU mainloop before you got hardware IO running.

   1. install libpruio
   2. get pruss_toggle example running
   3. add a second output
   4. learn to read ADC values in RB mode (first from ARM side, then from 
   PRU)
   5. learn to exchange data between ARM and PRU
   6. finally put all together in your PRU mainloop (perhaps test on ARM 
   before)
   
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/7f8b9988-b6bf-4ae5-885b-818f1be0664bn%40googlegroups.com.

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

[TJF]

Nano isn't best choice for polyglot applications. I'm using Geany (on PC 
exchanging source files via virtual file system), while I compile and test 
under LINUX on the BB.

wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 20:25:06 
UTC+2:

> Here's one more thing I am struggling with though.  It's a mental block I 
> think.  I'm used to controlling GPIOs on the ARM side using sysfs.   It 
> appears that on the PRU, we use __R30 instead but I don't understand how 
> that works.  I read through it this morning and it still isn't sinking in.  
> If anyone can help make this clearer, I'd appreciate it.


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 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/8b7242d2-c15e-407c-98b0-6b4638aac63an%40googlegroups.com.

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

[TJF]

I'm not a C guy (but prefering FreeBASIC for ligh-level and ASM for PRU 
code). Just guessing:

As lazarman mentioned HWREG is a preprocessor macro (perhaps using ARM in 
supervisor mode?)
SOC_CM_WKUP_REGS is the base adress of the wakeup registers in the control 
module
CM_WKUP_ADC_TSC_CLKCTRL is the offset for the TSC_ADC_SS clock control 
register

In oder to enable the TSC_ADC_SS the value 0x02 needs to be writen to that 
register. Afterwards you can read or write the subsystems registers. 
(libpruio additionally checks read acces to the ID register in order to 
validate that the subsystem is ready.)

wal...@edenconceptsllc.com schrieb am Dienstag, 13. April 2021 um 00:44:09 
UTC+2:

> What's really throwing me is the + between what looks like two macro 
> values.   Normally, we see the + on the right sign of the equals, right?  
> Or am I forgetting something I used to know!?
>
>
> On Monday, April 12, 2021 at 4:51:52 PM UTC-4 lazarman wrote:
>
>> Look for a registrer similar name to ADC clk Ctrl in TRM under the ADC 
>> section.
>>
>> That's looks like a C  macro and it's writing 0x02 to that register. 
>> Macro  Probably defined in a header file.
>>
>>  the registers will have different offsets depending on ARM or PRU access
>>
>> Perhaps revisit init code on ARM you had working and document every bit 
>> that's important in ADC set-up and compare that to this PRU code.
>>
>> Remember getting the Data out of PRU to ARM timings are important. I see 
>> you asked me about rproc that I don't use Linux that was TJ comments.
>>
>> I'm afraid the PRU was marketed to you as the answer by people that don't 
>> understand your timing requirement. Lot's of script kiddies and cookbook 
>> reader's in this group few system engineer that actually read your intial 
>> post
>>
>> Good luck
>>
>>
>> Sent from Yahoo Mail on Android 
>> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>
>> On Mon, Apr 12, 2021 at 3:08 PM, Walter Cromer
>>  wrote:
>>
>> I'm working through this and learning a lot.  But also realizing how much 
>> I have either forgotten or just never knew.   So, can I get a quick primer 
>> on what this line of C code is doing?
>>
>> HWREG(SOC_CM_WKUP_REGS + CM_WKUP_ADC_TSC_CLKCTRL) = 0x02;
>>
>> Thanks!
>>
>> On Monday, April 12, 2021 at 10:53:22 AM UTC-4 Walter Cromer wrote:
>>
>> 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 evident that I don't know much about 
>> remoteproc either) ?
>>
>>
>> On Saturday, April 10, 2021 at 2:17:26 PM UTC-4 lazarman wrote:
>>
>> Hello TJF
>>
>> Drop rproc, and use uio_pruss driver instead. Then data exchange is 
>> pretty easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A 
>> simple and effective concept to avoid writing collisions (and pretty fast 
>> as well). uio_pruss driver provides pointers to that memory, while using 
>> rproc you've to find a solution by yourself.
>>
>>
>>
>>
>> Sent from Yahoo Mail on Android 
>> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>
>> On Sat, Apr 10, 2021 at 4:47 AM, TJF
>>  wrote:
>>
>> 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 external USB-Stick. Most temperatures are comming 
>> from 1-wire sensors, but ADC is used to fetch samples from a 
>> high-temperature sensor on the roof/collector.
>>
>> You should know that the onboard TSC_ADC_SS sometimes hangs, due to 
>> electromagnetical noice. In that case it allways measures/serves the same 
>> voltage, regardless of the changing input. There's a way to unblock the 
>> subsystem by software. But the better solution is to spend some effort in a 
>> decoupled input circruitry.
>>
>> In a new project I start the controller development on ARM, doing 
>> measurements by libpruio. Once the prove of concept is done, I 

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

[TJF]

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 external USB-Stick. Most temperatures are comming 
from 1-wire sensors, but ADC is used to fetch samples from a 
high-temperature sensor on the roof/collector.

You should know that the onboard TSC_ADC_SS sometimes hangs, due to 
electromagnetical noice. In that case it allways measures/serves the same 
voltage, regardless of the changing input. There's a way to unblock the 
subsystem by software. But the better solution is to spend some effort in a 
decoupled input circruitry.

In a new project I start the controller development on ARM, doing 
measurements by libpruio. Once the prove of concept is done, I migrate the 
controller loop to the other PRU for hard real-time capability. libpruio is 
perfect for that concept, since the measurements are available from both 
sides, ARM and PRU. All setup is coded only once (on ARM), and only the 
inner controller loop needs adaption (from ARM to PRU). In that adaption 
the controller usually gets much better, since you won't repeat the bugs 
and pitfalls from the POC phase.

The most important initial decision is concerning the kernel driver to use. 
Drop rproc, and use uio_pruss driver instead. Then data exchange is pretty 
easy. Ie use DRam[0,1] for PRU-writing and SRam for ARM-writing. A simple 
and effective concept to avoid writing collisions (and pretty fast as 
well). uio_pruss driver provides pointers to that memory, while using rproc 
you've to find a solution by yourself.

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/d715b191-d95b-4b86-8fae-eb618c74ddc5n%40googlegroups.com.

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

[TJF]

wal...@edenconceptsllc.com schrieb am Freitag, 9. April 2021 um 14:41:00 
UTC+2:

> I'm looking at some example code and there references to ADC_TSC.  I 
> realize this is a reference to the Touchscreen controller which provides 
> the ADC functionality.  And I suspect this refers to the base memory 
> address of the chip but I cannot find where that is defined in any header 
> files anywhere.  It would help me to follow these examples if I knew where 
> that reference was.


Find high-level code (FreeBASIC) in files src/pruio/pruio_adc.[bas|bi] and 
low level code (assembler) in file src/pruio/pruio_adc.p.


> Unfortunately, too, the examples are Python and I'm not a Python 
> programmer.I work in C.  So I'm having to dig through this and learn 
> some Python at the same time.  Not a bad thing but time consuming!
>

Python examples are in folder 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 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/04caf3a3-cd8c-449e-9fd7-9ed6df33f99en%40googlegroups.com.

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

[TJF]

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 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/151c541c-21ad-421d-852e-d9d3e6b63315n%40googlegroups.com.

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

[TJF]

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 
>
> eCAP (pulse input) driver is available as patch posted by Darren 
> Schachter that is known to work: 
> https://lore.kernel.org/linux-iio/2020081815361...@cornell.edu/ 
>  
>

... and - to be complete - that proven eCAP + eQEP features - well 
documented (including example code) and with similar programming interfaces 
(not changing in new kernels) - are available in libpruio since years at
https://github.com/DTJF/libpruio 

-- 
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/8363327c-b775-4f61-a704-caeaf5126eedn%40googlegroups.com.

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

[TJF]

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.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle

The first example measures a pulse train generated by a PWM subsystem 
output (31 kHz), and the second measures a pulse train generated by PRU 
firmware (20 MHz).

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/da748222-01c6-4547-865d-676b8d0aeddan%40googlegroups.com.

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

[TJF]

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 possible in device tree overlays. Only libpruio 
 provides that feature. 

-- 
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/7b5fc076-62da-4ce7-b3aa-b125c125a694n%40googlegroups.com.

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

[TJF]

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 pointing to the new 
path (admin privilegues).

PS:
Regarding FreeBASIC just execute

sudo apt install freebasic

-- 
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/6b9c78d0-7af3-4834-86d5-313e6375af37n%40googlegroups.com.

[beagleboard] Re: BBB Libpruio Analog Data

[TJF]

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]); // second samples AIN-1, AIN-2
...

// output voltage: foating point from 0.0 V to 1.8 V
const f = 1.8 / 4095;
console.log(f*val[0], f*val[1]); //  first samples AIN-1, AIN-2
console.log(f*val[2], f*val[3]); // second samples AIN-1, AIN-2
...

-- 
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/37dbce3e-7e07-4299-be5c-e67ea2250a50n%40googlegroups.com.

[beagleboard] Re: BBB Libpruio Analog Data

[TJF]

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: how does Ring Buffer sampling 
> actually work? As in, if I'm reading data using two analog inputs and 
> saving it to a text file, what order are the values in? How do I parse them 
> into meaningful sensor values? I've attached the C code I'm working with, 
> and greatly appreciate any help or pointers!
>

Your code doesn't save to a text file. Instead it saves the raw data to a 
binary file. The unshifted values (0-4095) are stored as 16-bit (unsigned 
short) binary numbers in the order as captured, like

AIN-1, AIN-2, AIN-1, AIN-2, AIN-1, AIN-2, AIN-1, AIN-2, ...

In order to parse the file, just read it into a buffer and access that 
buffer by a unsigned short pointer variable. 0 (null) means 0V, 4095 means 
1V8. So multiply the unsigned shorts by the factor 1.8/4095 to get the 
voltage as a real value.

-- 
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/fd15170d-98ce-430a-8d20-34a63fe212b5n%40googlegroups.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

[TJF]

Dennis Bieber schrieb am Donnerstag, 4. März 2021 um 23:41:22 UTC+1:

> libpruio 
> does not seem to support such -- cf: 
> https://groups.google.com/g/beagleboard/c/3wphAPs9Uws (which is the 
> underlying C level, I doubt the Python interface adds any features) 
>
Nonsens! Use

io.IntcInit

to configure the interrupt table (IRQ[0-4,6,7]). And mask your event in the 
GPIO registers

LEVELDETECT[0,1]
RISINGDETECT
FALLINGDETECT

If need be also set the GPIO registers

DEBOUNCENABLE
DEBOUNCINGTIME

and then catch (and reset) the new IRQ in a thread. But this isn't worth 
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: "TJF" is, as I recall, the author of that libpruio package, 
> and pushes it as the only solution for everything related to Beaglebone 
> GPIO. 
>
Nonsens! You can find hundreds of threads here without any pushing. Since 
the OP already implemented libpruio for the eCAP feature, why shouldn't he 
use further features?
 

-- 
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/bd3d4e00-58e8-4e6d-86df-004e5305b0a2n%40googlegroups.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

[TJF]

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 sense when you can use the 
hardware debounce feature).

And drop all that device tree magic. Instead configure the abortPIN by 
libpruio as GPIO with pull-up resistor (PRUIO_GPIO_IN_1) and wire the other 
end of the button to ground.

Focus on your major target. Don't waste your time by reading and testing a 
bunch of documentations, which are too modern (or outdated) for your 
current system.

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/a1ab4004-4871-46c2-8fd3-be8fcb160206n%40googlegroups.com.

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

[TJF]

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" 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/bd1965d5-a942-4106-bd38-0568fc061f28n%40googlegroups.com.

[beagleboard] Re: GPIO, libpruio & dtbo Question

[TJF]

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 a BBB Python application (PCBA test fixture) where I am using 
> libpruio, specifically for access to the eCAP pins. Libpruio requires that 
> the universal cape be disabled, but when I needed a UART and I2C, I was 
> able to add those back in using the existing dtbo files from /lib/firmware 
> (shown below) in my uEnv.txt.
>
> uboot_overlay_addr0=/lib/firmware/BB-I2C1-00A0.dtbo
> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
> uboot_overlay_addr2=/lib/firmware/DP-GPIO-PCBATest-00A0.dtbo (I talk 
> about this below)
>
>
> Now I want to add an "abort" button to the test fixture since the 
> technicians have reported it takes a lot of time to reset if the board 
> under test locks up. I expect that wiring a pushbutton to a GPIO with an 
> interrupt is the way to handle this, and I've been thinking that there are 
> two ways to get there.
>
>1. Include another dtbo file to add a single GPIO that I can then 
>access with Adafruit_BBIO (this is where my efforts have focused so far), 
> or
>2. Figure out how to work with the hardware-based IRQ of the PRU  with 
>libpruio (which I've been avoiding because it looks even more scary)
>
> I've tried to make a custom dtbo by following an example from Derek Molloy 
> (github.com/derekmolloy/boneDeviceTree) and while it compiled and booted 
> OK, I still get the following error when I run a simple test program. The 
> same error as when I tried running the program before I created the dtbo.
>
> kapsul@beaglebone:~/pyDev$ sudo python3 abortTest.py
> Traceback (most recent call last):
>   File "abortTest.py", line 6, in 
> GPIO.setup("P9_12", GPIO.IN)
> ValueError: Set gpio mode failed, missing file or invalid permissions.
>
>
> Further, when I do the following (with or without the dtbo), I get the 
> following...
>
> kapsul@beaglebone:~/pyDev$ config-pin -q p9.12
> P9_12 pinmux file not found!
> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_12_pinmux/state
>
>
> Any input would be appreciated, whether it is correcting me on path 1 or 
> steering me towards path 2. I will happily provide any additional info, but 
> I didn't want to start uploading stuff until I know what, exactly, will be 
> helpful.
>
> Thanks,
> --
> Don Pancoe, P.E.
> Industrial Designer, Electrical Engineer
> DonPancoe.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/e16d3e52-0239-4df2-bb47-8aac7776728dn%40googlegroups.com.

[beagleboard] Re: PWM

[TJF]

stl...@gmail.com schrieb am Donnerstag, 14. Jänner 2021 um 23:51:46 UTC+1:

> However, I feel I am missing a bunch of information. Which pwmchip exports 
> to which pwm-X:X and corresponds to which pin? 
>

There're 20 pins for hardware PWM output on BBB (11 on Pocket). Find a list 
(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 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/5ecd36c8-3893-4f19-900d-bcd91a1289b6n%40googlegroups.com.

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

[TJF]

$ 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 
2019.04-2-g31a8ae0206]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-UIO-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
kernel:[5.4.70-bone38]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.14.20201021.1-0~buster+20201021]
pkg:[bb-customizations]:[1.20200826.0-0~buster+20200826]
pkg:[bb-usb-gadgets]:[1.20200504.0-0~buster+20200504]
pkg:[bb-wl18xx-firmware]:[1.20200813.1-0~buster+20200813]
pkg:[kmod]:[26-1]
WARNING:pkg:[librobotcontrol]:[NOT_INSTALLED]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal input bluetooth netdev gpio pwm eqep 
remoteproc admin spi iio i2c docker tisdk weston-launch xenomai cloud9ide 
pruio]
cmdline:[console=ttyO0,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 
rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 
rng_core.default_quality=100 quiet video=HDMI-A-1:800x480@60e 
cape_universal=disable]
dmesg | grep remote
[1.577767] remoteproc remoteproc0: wkup_m3 is available
[3.279280] remoteproc remoteproc0: powering up wkup_m3
[3.279297] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[3.283174] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
[   14.14] libpruio: loading out-of-tree module taints kernel.
dmesg | grep pinctrl-single
[1.367822] pinctrl-single 44e10800.pinmux: 142 pins, size 568
dmesg | grep gpio-of-helper
END
$ lsmod | grep uio_
$ sudo modprobe uio_pruss
modprobe: FATAL: Module uio_pruss not found in directory 
/lib/modules/5.4.70-bone38

-- 
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/2c433534-0dd5-4de8-9da5-f27834d526cdo%40googlegroups.com.

[beagleboard] Re: Pin MUX and other Mode Settings

[TJF]

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 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/65fcac23-5740-473c-b3cd-c412d076926ao%40googlegroups.com.

[beagleboard] Re: Controling sample rate

[TJF]

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 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/16db18a9-1ab4-46b0-99c5-4493164454f2o%40googlegroups.com.

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

[TJF]

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

On PRU-1 lines 0 to 14 and 16 are wired to header pins (standard BB 2x46 
headers). By word access you'll get up to 15 input lines.

On PRU-0 lines 0 to 16 are wired (note: some of them are on the SD-card 
slot). By word access you'll get up to 16 input lines.

Let's say you sample 16 lines on PRU-0 writing to the register file by code 
like

MOV R0.w0, R31.w0
MOV R0.w2, R31.w0
MOV R1.w0, R31.w0
MOV R1.w2, R31.w0
...
MOV R29.w0, R31.w0
MOV R29.w2, R31.w0

Then you'll have to spend a cycle to save the register file

XOUT 10, R0, 120

Afterwards the initial code follows again.

In the meantime PRU-1 observes the program counter of PRU-0. When it 
reaches the XOUT instruction then PRU-1 resets the program counter of PRU-0 
(to a value of 1, 2, 3 -> test it out) and then graps the register file 
from the XFR interface and stores the samples in memory, before it again 
observes the PRU-0 program counter.

This solution will get you a burst of 16 lines/60 samples (or 8 lines/120 
samples) at 200 MHz. In continuous mode you'll have to deal with a one 
cycle gap for saving the register file.

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/c08a924d-7236-4091-a600-66f7aa94bef1o%40googlegroups.com.

[beagleboard] Re: Guide on configuring pins

[TJF]

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 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/6f62aec1-9119-43e5-9a73-fa610fe79201o%40googlegroups.com.

[beagleboard] Re: Guide on configuring pins

[TJF]

Yes, kernel pinmuxing is terrible. And when you use the config-pin tool in 
a bad manner on pins P9_41/P9_42 it can damage your CPU.

That's why I developed libpruio. It can do all pin-muxing from user space 
in a safe manner (headers P8, P9, JT and also SD-Card-slot or user LEDS). 
Ie you can 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 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/383087f8-294b-4c1c-acef-f28b2a39fd0eo%40googlegroups.com.

Re: [beagleboard] Re: Boot time optimization

[TJF]

-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 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b860d2e2-a387-4c82-9a72-4463543b316ao%40googlegroups.com.

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

[TJF]

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 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/36a108ce-e55c-4e00-8be6-482a88363fe1o%40googlegroups.com.

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

[TJF]

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.

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/45191737-96c5-43e2-8506-d3cbb59a740eo%40googlegroups.com.

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

[TJF]

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 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/aa43f8ac-e3ae-4071-8497-c3a3f7f695f9o%40googlegroups.com.

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

[TJF]

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
> WorkingDirectory=/opt/rad/virtual_sensor 
>

> *ExecStartPre=/bin/dash -c 'until [ -e /dev/uio5 ] ; do sleep 1 ; done*
>
ExecStart=/opt/rad/virtual_sensor/virtual_sensor
>
> [Install]
> WantedBy=multi-user.target
>

Since I always execute compiled programs, I start them as root. Perhaps for 
User=debian you'll have to implement that line in 
/etc/systemd/system/lippruio-lkm.service.

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/c303aa65-f3c7-4871-a772-c8d8a9572636o%40googlegroups.com.

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

[TJF]

Hi!

Forget about all that device tree trouble, use libpruio 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/index.html> 
instead. You can configure the pin and set the desired output state by a 
single function call in your programm running at user space (no sudo 
commands, no rebooting, ...)

gpio_setValue(Io, P9_15, 1) // configure and set high
>
gpio_setValue(Io, P9_15, 0) // set low
>
 
You'll have faster boot, less memory consumption, and your code executes 
much faster (compared with sysfs GPIO control).

You may want to check out some examples 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html>
.

Regards

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

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

[TJF]

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 OK for a blue LED, but 
too small for ie. an orange LED with 1V65 threshold / 6mA. This may damage 
the LED, or - most likely - the output line in the GPIO subsystem (= the BB 
CPU).

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/ddc54d9a-392f-4df4-a247-01e1d3346df1o%40googlegroups.com.

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

[TJF]

Am Donnerstag, 20. August 2020 20:27:41 UTC+2 schrieb andrew...@gmail.com:
>
> Sorry about that.
>

> My adc measurements are good and stable. My only issue now is that I can't 
> seem to enable the serial port under libpruio. I'll post my code here:
>

Apology accepted.

Fine, that ADC is OK. I hope your code calls the destructor pruio_destroy() 
at the end.
 

> I tried every mode from 0 to 7 and got the same result.
>

You configured the hardware, but I guess you didn't care about the 
software. Did you load the UArt kernel driver?

When you configure pins from a device tree blob the kernel also loads the 
matching driver. In contrast, libpruio doesn't inform the kernel about 
changes. It's under your control to make this happen.

If you're sure that you want Uart-1 on P9_24/P9_26, and that wont change, 
then it's best to install a custom device tree blob for 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>
 
to create that blob in folder /lib/firmware. Your configuration (edit in 
source and compile) should look like

M(P9_24) = CHR(0)
>
M(P9_26) = CHR(0)
>

Perhaps you also want to adapt the file name. When the .dtbo file is in 
place, edit /boot/uEnv.txt to load it and reboot.

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/dfa678c7-d2aa-48a0-94eb-38ce29718df3o%40googlegroups.com.

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

[TJF]

Am Mittwoch, 19. August 2020 22:40:03 UTC+2 schrieb andrew...@gmail.com:
>
> I get this error when running your code. I can read the adc just fine.
>
> AssertionError: P9_24 configuration failed (b'pinmux missing')
>
>
Your system is not prepared for pinmuxing (check error 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   16384  0
> uio_pruss  16384  0
> uio20480  2 uio_pruss,uio_pdrv_genirq
>

The command systemctl status libpruio-lkm.service should output something 
like

● libpruio-lkm.service - Load libpruio loadable kernel module
>Loaded: loaded (/etc/systemd/system/libpruio-lkm.service; enabled; 
> vendor preset: enabled)
>Active: active (exited) since Thu 2020-08-13 20:57:24 CEST; 6 days ago
>   Process: 420 ExecStartPost=/bin/chown root:pruio 
> /sys/devices/platform/libpruio/state (code=exited, status=0/SUCCESS)
>   Process: 384 ExecStart=/sbin/modprobe libpruio (code=exited, 
> status=0/SUCCESS)
>  Main PID: 384 (code=exited, status=0/SUCCESS)
> Tasks: 0 (limit: 4915)
>CGroup: /system.slice/libpruio-lkm.service
>

Usually this should happen after you installed the libpruio-lkm.deb package 
and made yourself a member of the pruio system group.

-- 
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/6765146c-9cba-4bf1-aba4-ff65c04fe190o%40googlegroups.com.

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

[TJF]

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


> I assume I should be able to do this:
> from libpruio import *
>
> io = pruio_new(PRUIO_DEF_ACTIVE, 4, 0x98, 0)
>
> pruio_setPin(io, P9_24, 0)
>

That should work. I used a different syntax (don't know why -- perhaps to 
be closer to the other languages syntax):

from libpruio import * 
>
...
>
io = pruio_new 
> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__c__wrapper_8bas.html#a8416fa1df27f053242d720949d22366f>(PRUIO_DEF_ACTIVE,
>  
> 4, 0x98, 0)
> try:
>## The pointer dereferencing, using contents member
>IO = io.contents
>if IO.Errr: raise AssertionError("pruio_new failed (%s)" % IO.Errr)
>
...
>
  if (IO.setPin(io, P9_24, 0)):
> raise AssertionError("P9_24 configuration failed (%s)" % IO.Errr)
> ...
>
  if (pruio_config 
> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__c__wrapper_8bas.html#a283d56d12a6fee85ae2f4920f22705e9>(io,
>  
> 1, 0, 0, 0)):
> raise AssertionError("config failed (%s)" % IO.Errr)
> ...
>
 

-- 
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/c754404d-4735-4fef-8fe7-87c6d8bc5ed0o%40googlegroups.com.

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

[TJF]

Am Dienstag, 18. August 2020 23:32:17 UTC+2 schrieb andrew...@gmail.com:
>
> I'm unable to use the config-pin:
> Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_24_pinmux/state
>

config-pin is based on the cape universal device tree blobs. They consime a 
lot of memory and slow down then boot process. You disabled them in uEnv.txt
.


> I know there is a way to configure gpios with the libpruio c library, but 
> I cannot find anything in the documentation about the uarts.
>

You can configure GPIOs, but also *any* other pin configuration. Set the 
required pins 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.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/5ccdaece-aecb-4c0a-995a-9db9aec84b60o%40googlegroups.com.

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

[TJF]

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 
> /sys/kernel/debug/pinctrl/44e10800.pinmux'"
> # Change user permissions to ensure user and group have read/write 
> permissions
> KERNEL=="44e10800.pinmux", PROGRAM="/bin/sh -c '/bin/chmod ugo+x 
> /sys/kernel/debug; /bin/chmod -R ug+rw 
> /sys/kernel/debug/pinctrl/44e10800.pinmux'"
>

and

# /etc/udev/rules.d/85-gpio-noroot.rules
> #
> # Corrects sys GPIO permissions on the BB so non-root users in the gpio 
> group can manipulate bits
> #
>
> SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
>

adapting the permissions. I wonder why they're not present in all systems. 
(Are they from the -bone flavour?)

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/f063a2ec-b43b-416f-af5f-823ae17a7d92o%40googlegroups.com.

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

[TJF]

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 terminators, they are all up to the 
> coder to 
> put in. 
>
> Personally -- I'd probably replace all the "print" calls with 
> equivalent sys.stdout.write() (inserting the proper line ending \n where 
> needed). For "deliverable" packages I tend to save "print" for 
> development/debug tracing information -- one can easily identify what is 
> to 
> be removed when delivering the package.
>

The target is not to create perfect python code!

The target is to get users started. And therefore I try to present similar 
code in the syntax of three different programming languages.

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/e83e34b0-5427-4d37-aa93-1a189d9430dco%40googlegroups.com.

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

[TJF]

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 pwm gpio
>

The system group pruio is missing. It gets created when installing the 
libpruio-lkm.deb packege.

debian@beaglebone:~$ sudo chown root:gpio 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
>
> debian@beaglebone:~$ sudo chmod 664 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
>
> debian@beaglebone:~$ sudo ls -l 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
> -rw-rw-r-- 1 root gpio 0 Jan  1  1970 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
>
> debian@beaglebone:~$ cat 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
> cat: /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins: Permission 
> denied
>

Obviously also the folder needs permissions. Here's the folder chain on my 
system

dr-xr-xr-x  12 root root 0 Aug 13 19:40 sys
> rwxr-xr-x   10 root root 0 Aug 13 19:40 kernel
> drwx--x--x  41 root root 0 Jan  1  1970 debug
> drwxrwxr-x   2 root gpio 0 Jan  1  1970 44e10800.pinmux
>
 
Regarding ADC the example 1.py works now in python 2 and 3:

debian@beaglebone:~$ sudo python3 src/pruio_examples/1.py
> F940 EBD0 F4A0 88C0 58A0 9EB0 B6C0 F1E0
> F960 EE70 F510 C170 9600 91A0 9990 F200
> F950 EE10 F530 C630 A400 A0A0 A1D0 F1E0
> F970 EE30 F510 C680 A640 A470 A680 F1F0
> F990 EE10 F4E0 C680 A6B0 A5C0 A910 F200
> F990 EE30 F500 C660 A6B0 A630 AA10 F1E0
> F980 EE00 F4F0 C680 A660 A5D0 A980 F1C0
> F980 ED90 F4E0 C640 A590 A520 A8D0 F1D0
> F950 ED90 F510 C5F0 A520 A470 A7B0 F1B0
> F940 EDC0 F500 C5C0 A4F0 A420 A6B0 F1D0
> F960 EDA0 F4D0 C5C0 A4B0 A3B0 A630 F210
> F940 EDC0 F500 C5B0 A450 A370 A5C0 F1C0
> F940 EDF0 F4F0 C5D0 A4E0 A3C0 A5F0 F1B0
>

But you don't have pinmuxing feature yet.

   1. Try to install libpruio-lkm.deb package (command groups should list 
   the system group pruio afterwards).
   2. Make yourself a member in this group.
   3. Fix the permissions in path 
   /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins.
   4. Make uEnv.txt *NOT* loading the cape_universal stuff.
   
Then the AssertionError: pruio_new failed ('parsing kernel claims') should 
disappear and all members of group pruio should have pinmuxing capability 
from user space.

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/5dad1c89-3390-40cf-8bc9-00a728afde8bo%40googlegroups.com.

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

[TJF]

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 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/d0824dc4-514d-4a97-bde2-6dc728319841o%40googlegroups.com.

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

[TJF]

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 grammar tables from 
> /usr/lib/python2.7/lib2to3/PatternGrammar.txt
> root: Generating grammar tables from 
> /usr/lib/python2.7/lib2to3/PatternGrammar.txt
> ... 
>
RefactoringTool: Files that were modified:
> RefactoringTool: test/1.py
> RefactoringTool: test/button.py
> RefactoringTool: test/button2.py
> RefactoringTool: test/io_input.py
> RefactoringTool: test/performance.py
> RefactoringTool: test/pruss_add.py
> RefactoringTool: test/pruss_toggle.py
> RefactoringTool: test/pwm_cap.py
> RefactoringTool: test/qep.py
> RefactoringTool: test/rb_file.py
> RefactoringTool: test/sos.py
> RefactoringTool: test/stepper.py
> RefactoringTool: test/libpruio/__init__.py
> RefactoringTool: test/libpruio/ctypesloader.py
> RefactoringTool: test/libpruio/pruio.py
> libpruio/src$ cd test/
> libpruio/src/test$ python3 1.py
> F8F0 EC10 F470 83C0 55B0 9D60 BC80 F2D0 
> F970 EF50 F560 C630 9C00 93F0 9C30 F2C0 
> F980 EF00 F500 CCF0 AE40 A6E0 A5D0 F2F0 
> F9A0 EE90 F510 CD50 B0D0 AC00 AB50 F2B0 
> F950 EE40 F500 CC60 B070 ACE0 AC80 F2B0 
> F990 EE70 F4F0 CC70 B060 ACC0 ACD0 F2D0 
> F960 EE70 F540 CCA0 B0C0 ACD0 AD60 F300 
> F930 EEF0 F560 CD00 B1D0 ADD0 AED0 F2F0 
> F950 EF30 F530 CD10 B230 AEE0 B000 F2C0 
> F970 EEE0 F4E0 CD00 B210 AEB0 B050 F2A0 
> F980 EE90 F510 CD20 B1C0 AF20 B050 F2D0 
> F980 EEC0 F540 CD00 B240 AEE0 B030 F2F0 
> F960 EF50 F5A0 CDA0 B350 B100 B1A0 F2E0 
>  
>
 
 Regarding the pinmux-pins file permission: I've no clue why they're 
different on your systems. But you can adapt them, ie by adding a line to 
file /lib/systemd/system/libpruio-lkm.service like

ExecStartPost=/bin/chown root:pruio /sys/kernel/debug/pinctrl/
> 44e10800.pinmux-pinctrl-single/pinmux-pins
>
 
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/2c9e79b6-b495-4688-81ba-8087a1213b6bo%40googlegroups.com.

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

[TJF]

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 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/cc0bf2f1-c7ff-4f15-90f6-91ec6acacc7ao%40googlegroups.com.

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

[TJF]

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 F300 
> F910 EEF0 F4E0 CDE0 B310 AEC0 AE50 F310 
> F960 EF00 F4D0 CDE0 B360 AF60 AFF0 F2F0 
> F980 EEF0 F500 CDC0 B340 B000 B0A0 F2E0 
> F960 EF20 F550 CE70 B4F0 B1F0 B330 F320 
> F950 EF00 F4E0 CED0 B530 B280 B480 F310 
> F980 EEE0 F4F0 CED0 B530 B300 B480 F2F0 
> F920 EEF0 F500 CE40 B4D0 B250 B410 F310 
> F940 EF00 F4D0 CE30 B450 B170 B340 F2C0 
> $ python3 1.py
> Traceback (most recent call last):
>   File "1.py", line 18, in 
> from libpruio import *
>   File "/home/debian/Projekte/libpruio/src/python/libpruio/__init__.py", 
> line 1, in 
> from pruio import *
> ImportError: No module named 'pruio' 
>
$ ls -l /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
> -rw-rw-r-- 1 root gpio 0 Jan  1  1970 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
> $ cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins
> Pinmux settings per pin
> Format: pin (name): mux_owner gpio_owner hog?
> pin 0 (PIN0): 481d8000.mmc (GPIO UNCLAIMED) function pinmux_emmc_pins 
> group pinmux_emmc_pins
> pin 1 (PIN1): 481d8000.mmc (GPIO UNCLAIMED) function pinmux_emmc_pins 
> group pinmux_emmc_pins
> pin 2 (PIN2): 481d8000.mmc (GPIO UNCLAIMED) function pinmux_emmc_pins 
> group pinmux_emmc_pins
> pin 3 (PIN3): 481d8000.mmc (GPIO UNCLAIMED) function pinmux_emmc_pins 
> group pinmux_emmc_pins
> ...
>

 python2 works, python3 doesn't.

The file pinmux-pins is acessable for users of group gpio on my system. In 
your output the lines containing ocp:Px_xx_pinmux indicate that the 
cape-universal device-tree blob is loaded and claims the pins. Try 
enable_uboot_cape_universal=0 in uEnv.txt.

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/a4264e52-28bb-4e6b-a43b-2c31f47b90f4o%40googlegroups.com.

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

[TJF]

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, 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/23b526fd-8e7d-454c-979c-19462a645e87o%40googlegroups.com.

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

[TJF]

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 "src/pruio_examples/1.py", line 25, in 
> if IO.Errr: raise AssertionError("pruio_new failed (%s)" % IO.Errr)
> AssertionError: pruio_new failed (parsing kernel claims)
>
> This seems to be a kernel issue. Does the command cat 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins print anything 
reasonable?
 

> debian@beaglebone:~$ python3 src/pruio_examples/1.py
> Traceback (most recent call last):
>   File "src/pruio_examples/1.py", line 18, in 
> from libpruio import *
>   File "/home/debian/src/pruio_examples/libpruio/__init__.py", line 1, in 
> 
> from pruio import *
> ImportError: No module named 'pruio'
>
> Here the python interpreter cannot find the file pruio.py in folder 
/home/debian/src/pruio_examples/libpruio/. But it should be present since 
python2 did find it. (Is there any difference between python2 and python3 
regarding module import? Sorry, I'm not keen on python.)

Regards

PS: Google groups is really strange, it's a desaster!



-- 
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/26fab7be-9df9-48bd-9cd3-a2f74ca889eeo%40googlegroups.com.

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

[TJF]

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 uio_pruss, or command ls -l /dev/uio* 
has no output). Or you don't have write access to that file.

In any case you need to load the adapted uEnv.txt (uboot_overlay_pru 
modification). And it's also recommended to remove cape_universal=enable 
from the cmdline in order to get free pinmux access to all pins from user 
space.

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/18e96c47-40b3-4915-b181-e2375cf9c486o%40googlegroups.com.

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

[TJF]

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

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/5bcad34f-b81f-45be-8d7c-956cc5997cbco%40googlegroups.com.

Re: [beagleboard] libgpiod on Beaglebone AI

[TJF]

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 may override changes on 
lines controlled by other software.

The second option is a convenient way to avoid that overriding. The 
registers GPIO_SETDATAOUT and GPIO_CLEARDATAOUT can be used to change only 
the masked pins. As long as only one register is necessary (ie all pins 
set, or all pins cleared) the change is at the exact same time. In contrast 
when performing mixed changes (some pins set, others cleared) you'll see a 
delay between the output changes depending on the L3 latency.

@Mark
In order to testing gpiod you should use mixed changes

while true; do 
gpioset 1 18=0 19=1
gpioset 1 18=1 19=0
done

Regards

BTW:
Changing multiple pins on the same chip all at once is supported in libpruio 
 since version 0.0 (2014, kernel 3.8).

-- 
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/dd89965b-ae8b-4d5a-b4f7-1d5c487261b7o%40googlegroups.com.

[beagleboard] Re: Python example of continuous analog in

[TJF]

Hi Mark!

Am Dienstag, 28. Juli 2020 23:25:15 UTC+2 schrieb Mark A. Yoder:
>
> The example also shows which device tree to edit to set the sampling rate 
> to 200k samples/second.


There's no need for manipulating device trees and rebooting, when doing ADC 
sampling by libpruio. All configuration 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 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/ad224950-e3c3-4440-97e6-dae9b218037bo%40googlegroups.com.

[beagleboard] Re: July 2020 GPIO Best Practices

[TJF]

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 looked promising, 
> but it seems to be out of date?  Is libgpiod preferable, if I don't need 
> the extra speed PRU appears to provide?
>

libpruio is not out of date. It builds and runs on each kernel since 3.8. 
And so does the users code compiled against libpruio.

The current BB repos don't contain the libpruio packages. They never 
contained libpruio packages (exept the LKM). So if you don't want to build 
from source, ask RCN or Jason Kridner. (Or switch back to Jessie for a 
comfortable binary installation by the package manager.)

libpruio provides extra execution speed. But the main advantage is the 
steep learning curve. It does all kind of pin-muxing. And if a pin is 
claimed by an other process it shows the process name in the error message. 
And if the user cannot (or temprary will not) resolve the conflict, 
libpruio can override the claim (admin privilegues).

Hardware configuration gets as easy as on the Arduino, but with the power 
of a full featured LINUX system.

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/7eed834a-fe44-4bc3-bb11-b7914d378cb2o%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[TJF]

@Andrew P. Lentvorski

You came in to point to your tri-state solutions. I also use a tri-state 
GPIO in my one-wire driver libpruw1 <https://github.com/DTJF/libpruw1>. But 
it isn't the topic in this thread.

Am Montag, 22. Juni 2020 09:23:35 UTC+2 schrieb Andrew P. Lentvorski:
>
> 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 libpruio architecture cold, but none of your documentation 
> explains it, at all.  So, the relationship between kernel module, system 
> groups, PRU, and user mode is not at all clear to newcomers who actually 
> try to look at your libpruio library.
>

I do my very best not just develping a unique solution, but also 
documenting it in a forein language. The docu may not be perfect, but it 
explains that relaionship. It's OK when you don't read that. But don't tell 
other that it isn't present.
 

> 3) The reliance on FreeBASIC is an absolute non-starter for a *LOT* of 
> people.  While I'm sure you find it to be a superior tool, most people 
> already find the BeagleBone forbidding enough.  Adding another unfamiliar 
> tool to the mix is not something most people are willing to do.
>

The library also includes bindings and examples for C and Python 
programming languages. Why do you see a reliance on FreeBASIC?
 

> Thanks.
>
> On Sunday, June 21, 2020 at 11:22:48 PM UTC-7, TJF wrote:
>>
>>
>>
>> Am Montag, 22. Juni 2020 07:45:44 UTC+2 schrieb Andrew P. Lentvorski:
>>>
>>> Neither userspace nor PRU can change a pinmux.
>>>
>>
>> Not correct. In a libpruio configuration all members of system-group 
>> 'pruio' can pinmux from user space. That's why libpruio development is as 
>> easy as Arduino development, but much more powerful.
>>
>
> *Because* you shunt the request through the custom kernel module. Telling 
> people that they can pinmux from userspace simply confuses people further 
> who are already probably plenty confused.
>

Yes, the library shunts requests. And that's why (only) libpruio users can 
do pinmuxing from user space single source in their code. There's nothing 
wrong with that statement.

You're right, one of us is confusing people.

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/0d14d536-6c54-4140-980c-b7c43c26deb5o%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[TJF]

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 system-group 
'pruio' can pinmux from user space. That's why libpruio development is as 
easy as Arduino development, but much more powerful.
 

> If you must have a pin that changes direction and you need to control it 
> from the PRU, you can use the digital I/O's on the IEP (industrial ethernet 
> peripheral).  I can confirm that this works.
>

Off-topic.


@ P B

You asked for GPIO. In order to control the flow rate, you could also 
control the pumps by PWM signals.

-- 
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/3cf28356-82c5-4843-a33d-6de389f5117do%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[TJF]

@ 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

Am Donnerstag, 18. Juni 2020 22:50:03 UTC+2 schrieb Dennis Bieber:
>
> On Thu, 18 Jun 2020 12:11:23 -0700 (PDT),
>
> >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! 
> > 
>
> I can only state then, that a quick perusal of the online 
> documentation 
> (in particular, the github readme) gives this one the impression that the 
> package provides a specific program running on a PRU which must be used, 
> and that a host application, via a library, talks to that PRU to perform 
> I/O. If setting the configuration and subsequent I/O performed without 
> involving a PRU, it is not readily apparent. The presence of that warning 
> about the PRU being able to access any memory reinforces this, as it 
> implies that a PRU could write to the pin-mux registers to change 
> configuration.
>

The warning applies to all PRU deployment. The only difference: libpruio 
users get informed.

IMHO you shouldn't try to create the impression that you're an expert with 
years of experience before you misread the short introduction of a project.

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/0c96b3fe-a70f-4eb7-973c-f41fa85b48cbo%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[TJF]

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 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/69a2faf4-cf66-4f4f-91d6-f3ec363e46eco%40googlegroups.com.

[beagleboard] Re: Problems Reconfiguring GPIO's

[TJF]

Hi!

Am Dienstag, 16. Juni 2020 00:08:18 UTC+2 schrieb P B:

> I'm a little stuck here.
>

Drop all than device tree and config-pin stuff. Instead use libpruio 
<https://github.com/DTJF/libpruio> for pinmuxing. Once installed you can 
configure the pins from user space in your 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-portal.de/tjf/Projekte/libpruio/doc/html/button2_8c.html#ae1a27401b7fb01ccb9a82dbddbb54eea>
, PRUIO_GPIO_IN_0 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__globals_8bi.html#a4d604dbec305f941aaa452cc0d01adeea661a5356f0da98015d241d42084a0f30>
)) {
  printf("GPIO P8_11 configuration failed (%s)\n", io->Errr); break;}
// Output
if (pruio_gpio_setValue 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__c__wrapper_8bas.html#ac5405314ef2c35a9604262a22378420d>
(io, P9_12 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/button2_8c.html#ae1a27401b7fb01ccb9a82dbddbb54eea>
, 0 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__globals_8bi.html#a4d604dbec305f941aaa452cc0d01adeea661a5356f0da98015d241d42084a0f30>
)) {
  printf("GPIO P9_12 configuration failed (%s)\n", io->Errr); break;}

Check the examples 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html>
 
for complete code. By default an output pin gets configured without 
restistor, but you can override by function pruio_setPin(io, P9_12, 7 + 
PRUIO_PULL_UP).

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/f5d00e94-c939-437b-8179-cdb6a2525229o%40googlegroups.com.

[beagleboard] Re: eqep2 problemss

[TJF]

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 configurations 
(without any device tree trouble).

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/f8785fb1-fcd4-4a12-b2f3-49165cb94e2do%40googlegroups.com.

Re: [beagleboard] config-pin for gpio output

[TJF]

Am Freitag, 5. Juni 2020 13:06:48 UTC+2 schrieb Drew Fustini:
>
> How does the library change the pinmux during runtime?
>

It contains a LKM (loadable kernel module) that can set any pin 
configuration (ie. PRU-GPIO with pull-[up,down] at SD card slot) at 
run-time. All members of system 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, 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/86e53921-2c86-43c9-8440-9e9e66be71dco%40googlegroups.com.

Re: [beagleboard] config-pin for gpio output

[TJF]

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 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/51c20752-2b74-4051-9bf1-a74ae551e455o%40googlegroups.com.

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

[TJF]

Am Samstag, 30. Mai 2020 02:14:25 UTC+2 schrieb Gerhard Hoffmann:
>
> Methinks that the BBB can have a SRAM-like 16 Bit bus interface. That 
> would be 
>
> very interesting for FPGA device registers, FIFOs, DMA buffers and such. 
>
> Reasonably wide single cycle acesses, but 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.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaTNT.html#SecPruGpio>
. 

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/3a839c88-64a2-4059-970b-46e5bfd077e0%40googlegroups.com.

[beagleboard] Re: Could PRU read this signals?

[TJF]

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 de-serialize the data, while the first PRU is 
fetching them. Meanwhile the ARM CPU can provide the data transfer over the 
network (or PRU IEP module?), or it can do simple evaluations like 
pre-selection of relevant data sections, or GUI output ...

-- 
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/8724af50-adc1-481c-8bad-09769a085f5b%40googlegroups.com.

Re: [beagleboard] Could PRU read this signals?

[TJF]

There're 17 input lines in each R31 (bit [0:16]). It'd be best if you use a 
set of eight (bit [0:7] or bit [8:15]), because the data to write would be 
only one byte.

Anyhow, the following ASM code is for word data (bit [0:15] range), written 
to DRam:

#define CLKB 5 // define the clock bit# for polling

...

  LDI  r0, 0   // counter init
HIGH:
  QBBC r31, HIGH, CLKB // wait for clk bit getting high
  SBBO r31, r0, 0, 2   // safe data
  ADD  r0, r0, 2   // increment counter
  QB?? ??, OUT // termination
LOW:
  QBBS r31, LOW, CLKB  // wait for clk bit getting low
  SBBO r31, r0, 0, 2   // safe data
  ADD  r0, r0, 2   // increment counter
  QB?? ??, HIGH// reverse termination
OUT:

// Note:
// In order to get higher frequency the SBBO + ADD instructions can
// get replaced by MVIW for buffering the data in the register file,
// but this is limited to 30*2=60 sets of data.

The main loop contains two similar sub loops, one starting after the clk 
line gets high, the other starting after the clk line gets low.
If the state of the clk line starts undefined, you've to add an initial 
QBB? before the main loop, in order to start at the right 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#sSecExaPruToggle>
 
defines an output line and loads firmware to toggle that line. You can 
adapt that code for your input lines.

-- 
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/caa54b14-4bf4-4731-a2a5-33bd6392e5f0%40googlegroups.com.

Re: [beagleboard] Could PRU read this signals?

[TJF]

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 and 28bit shift 
> Register), which confuses me. In your proposal, is Direct Input used? What 
> is the max speed at this mode, 100MHz?
> What is the difference between using Parallel mode and Polling, the 
> automatic clocking?
>

The shift register is limited to a single pin.

GPIO is limited to 0V or 3V3, you have to adapt the input voltage.

You've to use direct PRU-GPIO (up to 16 pins), in order to avoid L3 latency.

Polling the clock signal needs only one cycle -> 200 MHz, but reading the 
lines and writing to memory consumes three further cycles -> 50 MHz main 
loop. So it should run reliable up to 25 MHz.

In order to buffer the data you can use SRam (12 kB) or DRam (up to 16 kB).

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/d459c132-2f3d-4ec5-a4b3-02b91f961cd1%40googlegroups.com.

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

[TJF]

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 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/40c47ae9-5736-4f80-888c-84aa7507c42c%40googlegroups.com.

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

[TJF]

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 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/7c1536f3-e725-4fa5-90ba-7c6b8edd9fae%40googlegroups.com.

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

[TJF]

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 to continue. (I'm ready for 
supporting, if necessary.)

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/8137fe11-b28d-4643-815c-349588fd6457%40googlegroups.com.

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

[TJF]

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, needed by 
> /usr/lib/gcc/arm-linux-gnueabihf/8/../../../libpruio.so, may conflict with 
> libtinfo.so.6
>
> (4.19.94-bone44), buster.
>

This library isn't much important. It gets linked due to a single PRINT 
statement at the end of the destructor, sending a message to the error 
channel, if any. (Since the PruIo instance is destroyed after the DTOR, the 
variable Errr cannot get used in that case.)

It's much likely that you can ignore the linker warning.

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/4562aff2-01eb-4d8a-b52d-21e915494543%40googlegroups.com.

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

[TJF]

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 it worked just as if those pins had never been 
> changed!  I was like Wow!  Very impressive!
>

Fine! Note: the pinmuxing is only active in the time after the 
pruio_config() call and before the DTOR call to pruio_destroy(). The DTOR 
restores the original setting (by default). (A cosmetic note: I prefer 
calling pruio_pgio_setValue() before pruio_config() -> all start values get 
set simultaneously.)
 

> So when I do a show-pins -v
>
> μSD d360 fast rx  up  0 mmc 0 d3
>  mmc@4806 (pinmux_mmc1_pins)
> μSD d261 fast rx  up  0 mmc 0 d2
>  mmc@4806 (pinmux_mmc1_pins)
> μSD d162 fast rx  up  0 mmc 0 d1
>  mmc@4806 (pinmux_mmc1_pins)
> μSD d063 fast rx  up  0 mmc 0 d0
>  mmc@4806 (pinmux_mmc1_pins)
> μSD clk   64 fast rx  up  0 mmc 0 clk
> mmc@4806 (pinmux_mmc1_pins)
> μSD cmd 65 fast rx  up  0 mmc 0 cmd
> mmc@4806 (pinmux_mmc1_pins)
>
> this will always show uSD d0 and uSD d1 as mmc under pinmux_mmc1_pins even 
> when they are switched to GPIO mode briefly under libpruio control?  Just 
> asking out of curiosity?
>

I don't know the show_pins tool. What happens when you execute it in a 
second shell while your libpruio prog is running? Perhaps it lists the 
kernel setting, but ignores the hardware state. 

-- 
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/948e664e-38fd-4aeb-bfd1-3d7bb8f07508%40googlegroups.com.

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

[TJF]

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 error! Take a BBB! The webside says: "Boot Linux in under 10 
seconds ...":

http://beagleboard.org/black

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

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

[TJF]

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 blobs (resulting in faster booting time and less kernel-memory 
consumption).

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/6804a023-57cd-4498-9cad-0d9751bd1cda%40googlegroups.com.

[beagleboard] Re: PocketBeagle Boot Time

[TJF]

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

https://groups.google.com/d/msg/beagleboard/CN5qKSmPIbc/9yNlI-w1AQAJ


-- 
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/2a75d9fa-0cfa-4c4c-b29a-98c7a424caeb%40googlegroups.com.

[beagleboard] Re: segmentation fault PRU

[TJF]

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

Either change the permissions of the /dev/uio* devices or excute your 
program with sudo.

-- 
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/cf55890f-d1f6-4bc0-b2d0-3afbc5f74bb7%40googlegroups.com.

[beagleboard] Re: javascript / bonescript structure

[TJF]

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/tjf/Projekte/libpruio/doc/html/>.

Regards

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

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

[TJF]

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 your case just 
disable LAN and use USB-Serial instead.

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/ea83cb7f-4b49-4dfb-a692-f3a88bc7bb62%40googlegroups.com.

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

[TJF]

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 version of PGP that's binary 
incompatible (not backward compatible). I'm no expert in such topics. And 
ATM no time to test Buster, sorry.

Workaround: Download the packages under Jessie/Stretch, copy them to 
Buster, and install by
sudo dpkg --install *.deb
sudo apt-get -f install

 
>
>>
>> Find attached some files from the fast-boot system, hope that helps.
>>
>> $ systemd-analyze 
>> Startup finished in 1.067s (kernel) + 15.828s (userspace) = 16.896s
>>
> Hoping to get there, but you have a bbb. The files are interesting though. 
> Uenv looks the same although you have the universal cape disabled. But the 
> status shows me you have quite a few less services. Thanks.
>

Disabling all universal capes is a major step, saving ~10s kernel time (and 
a lot of kernel memory). You don't need them. Pinmux by libpruio, and load 
necessary kernel modules manualy by modprobe.
 

>
>> My first custom app starts as a systemd service after ~7s (solar-regler). 
>> A second one wait for the network to be ready (solar-fcgi).
>>
>> Regards
>>
> Best, Hans. 
>

-- 
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/9f464c41-f099-4163-9c71-be81470487e2%40googlegroups.com.

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

[TJF]

Kernel module timers are in the eCAP modules in the PWMSS subsystems. Three 
modules are present, but only two are wired to the big headers, the third 
is at JT or SDcard-slot (32 bit counters at 100 MHz --> maximal toggling 
time stamp = 42,9s).

Additional the TIMER[4-7] subsystems provide 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 
latency in a nano or even milli second range.

More accurate is the PRU-firmware I mentioned above, synchronised by a 
wired GPIO signal.  


-- 
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/49bfa6b2-567b-4fb4-9812-d3b12e4310c0%40googlegroups.com.

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

[TJF]

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) + 15.828s (userspace) = 16.896s

My first custom app starts as a systemd service after ~7s (solar-regler). A 
second one wait for the network to be ready (solar-fcgi).

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/51e7e421-2028-4f37-a6a3-07a49dba81d3%40googlegroups.com.
uname_r=4.14.146-bone29
enable_uboot_overlays=1
dtb_overlay=/lib/firmware/solar-00A0.dtbo
disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_adc=1
uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet 
video=HDMI-A-1:800x480M@60e cape_universal=disable init=/lib/systemd/systemd



systemctl.status
Description: Binary data


dmesg
Description: Binary data

[beagleboard] Re: Bluetooth Android App

[TJF]

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 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/2e925297-8700-475e-9c97-420b031820c3%40googlegroups.com.

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

[TJF]

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 pulse train
   2. PRU starts first, waits for the first PRU-1 pulse on a GPIO input, 
   and then sends synchronised pulses on a GPIO output.

The only problem is to get PRU-1 starting at the obtained timestamp by the 
ARM (linux) process.

-- 
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/4726a01c-b83b-4061-ac1a-e5ac086c539e%40googlegroups.com.

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

[TJF]

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 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. 
>
> We have Developers?


;-)


>
> I assume you've been testing and providing feedback on: 
>
>
> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Buster_Console_Snapshot


Not yet. My latest test is the above mentioned 4.14.146-bone29 kernel.


>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

I cannot spend often ten days making a new image usable.

Regards

PS: Is it possible to make the bone flavor images quick boot? 

-- 
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/4cce433c-0261-426b-bfda-fcc4e176f70e%40googlegroups.com.

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

[TJF]

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. Februar 2020 00:40:08 UTC+1 schrieb 
mikero...@hotmail.com:
>
>
> Maybe the IOT image isn't helping.  Is this the best place to get images? 
> https://beagleboard.org/latest-images  They are all dated 8/2019.
>
> 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/6c3eff94-20d8-411e-86e1-ca83e22e4be5%40googlegroups.com.

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

[TJF]

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 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/9f273942-6b51-4131-8895-eb4707de931d%40googlegroups.com.

[beagleboard] Re: Rotary encoder in CNC servo boucles

[TJF]

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 third one isn't wired to any header 
pin). Or you can use one of the four TIMER subsystems (24 MHz counters).

If you need a fourth direction/position sensor, there's a PRU firmeware in 
the BBBlue package.

-- 
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/869c82a2-1f63-4c83-89af-fffbc91a9f83%40googlegroups.com.

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

[TJF]

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 its overlays. Instead I 
developed and shared libpruio  and its 
pinmuxing. Your target is over the capabilities of the standard tools, but 
is well covered by the libpruio scope.

-- 
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/e5ec3da7-db00-423c-ac11-b3b84709a1d3%40googlegroups.com.

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

[TJF]

SS=subsystem -> chapter 25

Am Montag, 20. Januar 2020 07:12:34 UTC+1 schrieb Andrew P. Lentvorski:
>
> Okay, then I'm just missing something obvious.  What is a GPIO-SS?  What 
> unit and what register address?  I see no mention of "GPIO-SS" anywhere in 
> the AM335x Technical Reference Manual.
>
> Normally, I associate SS with "slave select" which means SPI.  I see that 
> you *can* turn around the CS lines on the McSPI subsystem, but you have to 
> switch from Master to Slave Mode.  That doesn't seem like what you are 
> suggesting.
>
> 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 
> (output enable) in the PRU docs.  I found one on the digio.  I also found 
> that TI used the IEP to implement the 1-Wire interface on the PRUCAPE.  You 
> were also implementing bidirectionality on a 1-Wire interface.  I drew an, 
> incorrect in retrospect, inference that people were using the IEP digio for 
> bidirectional and tri-state functions.
>

-- 
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/8f661786-a07a-4a81-9b76-5746ede999fd%40googlegroups.com.

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

[TJF]

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 your own H-Bomp. You can use the existing one

sudo apt-get install libpruio-modules-`uname -r`

Note: AFAIK RCN didn't update the source code, yet. That version uses a 
slightly different encoding than the LKM in the current libpruio-0.6.6. 
Check the source in RCNs build-farm.

Note: libpruio offers some safety features. Ie. it doesn't remux a pin 
claimed by an other system (, unless this feature gets disabled). Using the 
LKM without libpruio is at you own risc. Your code has to care about such 
issues.

-- 
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/5edeaf82-081f-4202-b460-bb7946bb95fb%40googlegroups.com.

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

[TJF]

Am Sonntag, 19. Januar 2020 09:20:58 UTC+1 schrieb Andrew P. Lentvorski:
>
> Well, sort of, except you omit the *EXTREMELY* important point that you 
> install a custom kernel module in order to expose the clock activation and 
> pinmux system to all users.
>

That's not correct. Only users with write access to the sysfs entry can 
pinmux. By default that're members of the pruio system group.
  

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

It was your idea to use the PRU-IEP module. I recommended to use a pin on a 
GPIO-SS. Yet, you didn't explain why the L3/L4 latency isn't aceptable for 
your target.

This means that config-pin has a fairly significant bug in not being able 
> to route the IEP pins.  Has that bug ever been filed anywhere?
>

config-pin isn't able to set lots of useful pin configurations, and has 
lots of bugs. Ie. you can set GPIO for P9_42 and P9_92 in oposite output 
states and damage the CPU. C. Steinkuehler didn't develop that tool with a 
standard solution in mind. At the 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 case.

-- 
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/fee39a14-8bb1-497e-8fcd-06e44a992cdb%40googlegroups.com.

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

[TJF]

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#af38ae7c5f55c73ea6b438c6806e5cf67>
, 6 | PRUIO_RX_ACTIV)) {
   printf("P9_18 configuration failed (%s)\n", io->Errr); break;}

-- 
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/76ffeab8-9afe-425a-a7e0-ea5430283dcf%40googlegroups.com.

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

[TJF]

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

In your case it needs a line at line number 110 like

if (io->setPin(io, P9_18 
<http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/pruio__pins_8bi.html#af38ae7c5f55c73ea6b438c6806e5cf67>
, 6)) {
   printf("P9_18 configuration failed (%s)\n", io->Errr); break;}
 

OR a resistor to the mode, if needed.

Regards

Am Samstag, 18. Januar 2020 08:14:52 UTC+1 schrieb Andrew P. Lentvorski:

> Is there a way to set the pinmux for a pin to the PRU Industrial Ethernet 
> Peripheral from Linux (for example: set pin P9_17 to pr1_edio_data_out0)?
>
> If not, what would be the recommended way to do so?
>
> Thanks.
>


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/acbe262e-019a-48f1-99af-0b37d634e594%40googlegroups.com.

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

[TJF]

There's no supervisor mode for the PRU.

There's no tri-state-mode for AM335x GPIO.

In order to change direction for a pin on a GPIO-SS, it needs a write 
access to its OE register. The PRU can do that.

Find an example at 
https://github.com/DTJF/libpruw1/blob/master/src/bas/w1_prucode.p, which 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 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/81daa29b-4795-41b4-a4b6-a7f18229639c%40googlegroups.com.