libpruio (BB D/A - I/O fast and easy)

[Dinosaur]

Hi TJF

My concept of loop timing is probably way different than yours.
In all my programs I don't hang around anywhere, no do-loops, no pause's no waiting for input.
I look for the result the next time I get there, and I get into every major routine once every program loop.
But it includes setting outputs, reading inputs and any delays that usb I/O causes.

Basically I record the start time of 100 loops and calculate the individual loop time from that.
It changes during mouse movement for a few uSec's and file reading /writing at the start of the program.

Confirmation of the stability is the displayed looptime (it is always shown and updated) and test conducted by square wave generation
and checking stability on a oscilloscope.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I have sort of resigned myself to the fact that I will have to design a cape for the BBB and for the last few days have searched for
the right components. I am hoping to put all 32 I/O onto it, but reserving about 12 of them for input.
Will group pwm so that they have a separate common, but won't bother with the A2D channels.
If the board is designed right it will allow another cape to be plugged onto the top of it which will have the use of pins I didn't use.
Fast opto-couplers are the problem for inputs if isolating the inputs is to be achieved.
Outputs don't need opto's and like the chip you are using, there are plenty of options.(smd power Fet's)

Regards

[TJF]

I have sort of resigned myself to the fact that I will have to design a cape for the BBB and for the last few days have searched for
the right components.

That sounds reasonable.

If the board is designed right it will allow another cape to be plugged onto the top of it which will have the use of pins I didn't use.

Which pins? There are 31 pins free on the BBB. Beaglebone White or Green have no HDMI, and therefore more free pins.

Will group pwm so that they have a separate common, but won't bother with the A2D channels.

Do you plan to use the PWM output from the ARM CPU? Which one (PWM, CAP, TIMER)? Mind the pin positions on the headers!

I am hoping to put all 32 I/O onto it, but reserving about 12 of them for input.

Universal GPIO pins you can make switchable (ie. by DIP-switch or jumper). Mind the PRU GPIO pins (ie. pr1_pru0_pru_r30_1 and pr_pru0_pru_r31_1). They're important for high-speed GPIO.

Outputs don't need opto's and like the chip you are using, there are plenty of options.(smd power Fet's)

Each IO line loves galvanic isolation, even ADC! Note: The digital BBB outputs are max. 6 mA@3V3. Too less for direct driving of most power chips.

Note: there's also an UART subsystem on the PRUSS, which you can use to drive your external USB board. But the latency is bigger, compared with direct PRU-GPIO.

Regards

PS: Your loop timing concept isn't much different then mine. The main difference is that in my concept the controller loop is the one and only task for the processor (no GUI, network, ...).

[Dinosaur]

Hi TJF

Which pins?

All other pins that I am not using, lcd , MMC1, AIN etc.
There is no cost involved and it would be irresponsible to not allow for some future piggy back board to get to those pins.

Do you plan to use the PWM output from the ARM CPU?

No, but I may as well allow for it.

Note: The digital BBB outputs are max. 6 mA@3V3

The TPL7407L 40-V 7-Channel Low Side Driver takes logic input (voltage not current) and allows upto 600mA output current.
That's enough to drive solenoids directly and the coils of larger relays (if needed).
However I never use mechanical relays, only ever SSR such as 3 phase and phase angle firing for power control to vibratory feeders.
This is one of the uses for the PRU's. Reading an input to detect zero cross of AC power and then after a delay firing the SSR.

Will test one device on breadboard and then spend time working out which pins to group as what function.

REgards

[TJF]

All other pins that I am not using, lcd , MMC1, AIN etc.

I assumed you'll use stacking headers (you can find less expensive).

Do you plan to use the PWM output from the ARM CPU?

No, but I may as well allow for it.

How much PWM outputs do you need at which frequencies? Must the output get synchronized?

The TPL7407L 40-V 7-Channel Low Side Driver

Looks interesting. Thanks

This is one of the uses for the PRU's. Reading an input to detect zero cross of AC power and then after a delay firing the SSR.

The delay puts thermal load on the SSR. And that's lot of work. Why not SSR with inbuild zero-circruit, like S202T02 (needs 50 mA)?

Regards

[Dinosaur]

Hi TJF

How much PWM outputs do you need at which frequencies? Must the output get synchronized?

I have no idea, just thinking ahead as I dont want to build another board later.

The delay puts thermal load on the SSR. And that's lot of work. Why not SSR with inbuild zero-circruit, like S202T02 (needs 50 mA)?

I have a very long history with this type of application. The last time (with a Fitlet and usb to 4-20 i/f board) I used a 4-20mA input SSR like Crydom 10PCV2415.
But the resolution is not that good, and does not have accurate control over the power output.
Can't use zero-cross relays, as the idea is to delay the relay coming On (n) mSec after the zero cross.
Then the relay stays On for the rest of the AC half cycle.
Prior to using the Crydom relays, I used an ISA i/o board with fpga that got 1.5 vac input to determine zero cross. The software communicated
with the fpga and modified the delay time. This was very successful but the ISA boards went into history.

Regards

EDIT: I am finding conflicting pin information, but it may be related to the mode in which they are used.
What is the mode you use in the library to take advantage of the PRU >
EDIT2: It is obvious I have to do a lot more reading, but the RB mode you refer to, is that mode 5 or 6, as this decides which pins I use as inputs
and which as outputs.

[TJF]

Can't use zero-cross relays, as the idea is to delay the relay coming On (n) mSec after the zero cross.
Then the relay stays On for the rest of the AC half cycle.

That sounds like you're controlling the power of the feeder by sending just a part of the half wave to the coil. This is the microscopic way. What about the macrosopic (= sending every second, third, fourth ... complete half or better full wave)? A vibration feeder should be sluggishly enough to get controlled that way.

I am finding conflicting pin information, but it may be related to the mode in which they are used.
What is the mode you use in the library to take advantage of the PRU

I don't get this question. It's the user who tells libpruio what pinmux mode to use.

It is obvious I have to do a lot more reading, but the RB mode you refer to, is that mode 5 or 6, as this decides which pins I use as inputs
and which as outputs.

The libpruio RB mode is the ring buffer mode, where accurate timed ADC samples get transferred in to a ring buffer continually. (In contrast in MM mode the measurement stops after the FIFO buffer is full. And in IO mode there is just a one sample buffer and no accurate timing.) This mode is not related to the pinmux modes of the CPU balls (= header pins).

Regards

[Dinosaur]

Hi TJF

That sounds like you're controlling the power of the feeder by sending just a part of the half wave to the coil. This is the microscopic way. What about the macrosopic (= sending every second, third, fourth ... complete half or better full wave)? A vibration feeder should be sluggishly enough to get controlled that way.

The Feeders are half wave devices.

Before I get to involved in the software I need to identify which pins I can design into the cape.
I know if I guess at which pins to use I will have to remake the board again later.
So, I rather take advantage of your experience on this.
The idea is to allow at least the following.
PWM x 2
PRU outputs x 14
PRU inputs x 7

Would you suggest I join another forum to get support on this ?
I notice you are contributing on some others.

Regards

[TJF]

The Feeders are half wave devices.

That's no reason against macroscope power control.

The idea is to allow at least the following.
PWM x 2
PRU outputs x 14
PRU inputs x 7

No way, sorry. You can have up to 17 inputs at one PRU, or up to 16 of them as outputs. Find a table in the docs. Most of them are at header pins that are used by the system, ie. the HDMI pins or the uSD card slot. If you really need 21 fast GPIOs, you'll have to use both PRUSS (= drop libpruio -> bitbanging the CPU registers directly). I guess most of your lines can be normal GPIO (overall input/output latency less then 10 cycles@100MHz -> more than 10,000 times faster than your current USB solution).

Would you suggest I join another forum to get support on this ?

Feel free to ask whomever you want. In my docs there's the header pins picture for BBB, which I use for pin setup. The brown pins are used by the system, avoid them if possible. Start with blue pins for fast PRU GPIO and PWM. Them use the remaining pins for normal GPIO.

Before I get to involved in the software I need to identify which pins I can design into the cape.

Unfortunately this doesn't work. Your software has to have different design if you use fast PRU GPIO or normal GPIO (either directly or over libpruio).

Regards

[Electrumpet]

Hi TJF

I have been looking for an example of 'background ADC measuring' and an old example from 2017 helped me a lot:
viewtopic.php?t=22501&start=212
I tested it on the pocket beagle and it worked. I would like it in the examples.... One remark though: in the original it states that Step 9 is connected to AIN-0 while the code connects it to AIN-1...

Furthermore and this is also a question to TJF. When using mm_mode you will have to wait till the measurement is finished before you can do anything else. Whereas when you use rb_mode you can do other stuff while measuring these particular inputs in a timed manner.

It would be nice in my case if I could combine the rb_mode (a little faster then the example that I attached) with the possibility to interrupt the measurement. Furthermore I was wondering if it is possible to measure the ADC's without using libprio while libprio is running in rb_mode. The PRU should stop running when a certain condition is met on the ADC's. If that can be done using libprio that would be fine as well. In my case I would use four ADC's and measurement should stop when they are all (back to) zero (or under a certain value considering inaccuracy).

The tested code for rb_mode:

Code: Select all

#include "unistd.h"
#include "stdio.h"
#include "libpruio/pruio.h"
#include "time.h"

int main(int argc, char **argv)
{
  int i = 0;
  int j = 0;

  pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 0x98, 0, 0);   //Create a new driver structure
  pruio_adc_setStep(io, 9, 1, 0, 0, 0);    //Step 9, AIN-1
  pruio_adc_setStep(io, 10, 2, 0, 0, 0);   //Step 10, AIN-2

  if (pruio_config(io, 10, 3<<9 , 1000000000, 4)){    // upload settings: 10 samples, 1 Hz, 16 bits
                              printf("config failed (%s)\n", io->Errr);}
  else {
    if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); // start measurement   //Starts in rb_mode

    else{
      for(j=0;j<10;j++){
        printf("doingOtherStuffWhileMeasurementGoesOn\n");
        usleep(1000000);
      }
      printf("adc1*************\n");   //Print the value of the AIN-1
      for(i = 0; i < io->Adc->Samples; i += io->Adc->ChAz)
        printf("%i \n", (io->Adc->Value[i] / 16));

      printf("\n adc2*************\n");   //Print the value of the AIN-2
      for(i = 1; i < io->Adc->Samples; i += io->Adc->ChAz)
        printf("%i \n", (io->Adc->Value[i] / 16));
    }
  }
  pruio_destroy(io);        /* destroy driver structure */
  return 0;
}

[Dinosaur]

Hi TJF

Firstly No I dont need that many fast i/o pins, but will design the cape for the maximum I can get.
I know I am testing your patience, so let me ask questions that are more general which I can't seem to find an answer for.

You can have up to 17 inputs at one PRU, or up to 16 of them as outputs.

1: For each PRU can you have mixed I/P and O/P on the same PRU.
Your statement above seem to indicate that I have to assign the I/P's to one PRU and the outputs to another.

2: Do the library functions allow the use of both PRU's at the same time ?
ie: Can I read my inputs on say PRU0 and write my outputs on PRU1

3: I guess the General GPIO pins can be set as input or output and will be used by the library as such.

From the pins coloured on your chart I have 20 x GPIO's and 11 PRU pins
Therefore looking at the charts and seeing how many PRU0 pins there are versus PRU1, will allow me to decide
which pins to use for input or output.

EDIT: The pru's are certainly the most difficult to understand, as an example:
P8-15 is shown on your colour chart as GPIO.
The pin charts show that pin, in Mode 6, as Pr1-Pru0-pru-r31-15 indicating it is an input bit 15.
If I wire this pin as an O/P are you able in the library to convert that to an O/P.

I am not trying to understand the PRU from a programming point of view (your library handles that) but trying to avoid hardware mistakes.
Regards
PS: I do appreciate your efforts on this.

[Electrumpet]

Sorry TJF,

I can of course use io->DRam[0] to look at the actual 'recording' position within the array and use that to probe for actual samples while sampling continues.

Is this perhaps the best solution when some of my analoge inputs are more 'classical' sensors where I only need the value in the moment and others have to record continuously during a 'phrase'?
I mean to have the PRU continuously recording and either for some pins look back in time when a phrase is finished (the example) and on the other hand just sample in the moment for analogue inputs that do not have to record anything.

For the moment only seven analoge channels seem to be supported. Analog7 on the pocket beagle is activated as an analog input (I can check that through the BeagleBone-UI monitor) with this line of code in the terminal: sudo i2cset -y -f 0 0x24 9 5

I have looked for a permanent solution for analog7 but can't find it. Probably have to do it in a startup script.

Is libpruio deliberately limited to max 7 because of the beaglebone black perhaps? If so is it possible to lift the restriction?

Thanks a lot and also for all the good work.

Best, Hans.

[TJF]

Hi Electrumpet, welcome to the forum! And sorry, I've overseen your first post.

I have been looking for an example of 'background ADC measuring' and an old example from 2017 helped me a lot:
viewtopic.php?t=22501&start=212
I tested it on the pocket beagle and it worked. I would like it in the examples.... One remark though: in the original it states that Step 9 is connected to AIN-0 while the code connects it to AIN-1...

Correct, the code uses AIN-1 and AIN-2 at step 9 and 10. See it as some kind of user test :-)

Similar code is already in the examples (triggers.bas), but since C programming language doesn't have standard graphics I don't know how to make such an example work on every system (and want to avoid all the description text in the docs).

Furthermore I was wondering if it is possible to measure the ADC's without using libprio while libprio is running in rb_mode. The PRU should stop running when a certain condition is met on the ADC's. If that can be done using libprio that would be fine as well. In my case I would use four ADC's and measurement should stop when they are all (back to) zero (or under a certain value considering inaccuracy).

In libpruio you have full access to the TSC_ADC_SS registers. You can configure the steps and send the samples to two different buffers. By default libpruio uses FiFo-0, so the other system can use FiFo-1 (but you can also adapt libpruio to use FiFo-1 instead, see file src/pruio/pruio_adc.p).

I can of course use io->DRam[0] to look at the actual 'recording' position within the array and use that to probe for actual samples while sampling continues.

Is this perhaps the best solution when some of my analoge inputs are more 'classical' sensors where I only need the value in the moment and others have to record continuously during a 'phrase'?
I mean to have the PRU continuously recording and either for some pins look back in time when a phrase is finished (the example) and on the other hand just sample in the moment for analogue inputs that do not have to record anything.

Yes, DRam[0] is designed to synchronize the evaluation on the ARM CPU. I cannot state if this is the best solution, since I don't know much about your target. There're three possible solutions: IO mode (with sloppy ADC timing), RB mode as you're describing it, and MM mode (started in a thread that waits for the end of measurement, while an other thread is doing some evaluation). The best solution also depends on the other software you want to run in parallel.

I have looked for a permanent solution for analog7 but can't find it. Probably have to do it in a startup script.

Is libpruio deliberately limited to max 7 because of the beaglebone black perhaps? If so is it possible to lift the restriction?

I've no Pocket Beagle, so I cannot test. From libpruio there's no restriction. AIN-7 should work as any other AIN channel.

Regards

[TJF]

Hi Dinosaur!

Firstly No I dont need that many fast i/o pins, but will design the cape for the maximum I can get.

When you're sure you wont need other features (like CAP, QEP), that's the best solution.

You can have up to 17 inputs at one PRU, or up to 16 of them as outputs.

1: For each PRU can you have mixed I/P and O/P on the same PRU.
Your statement above seem to indicate that I have to assign the I/P's to one PRU and the outputs to another.

Sorry if I was unclear. You can mix input and output GPIO on each PRU. You can have up to 17 inputs, but only up to 16 outputs.

2: Do the library functions allow the use of both PRU's at the same time ?
ie: Can I read my inputs on say PRU0 and write my outputs on PRU1

The library libpruio needs one PRU for its main loop, so there is only one PRU left. (Special case: you can use libpruio only for hardware configuration, and then override the PRU SRam with your custom firmware, in order to use both PRUSS -> no libpruio main loop.)

3: I guess the General GPIO pins can be set as input or output and will be used by the library as such.

Yes, each can get configured as input or output. Once configured, you can read or write the state either by libpruio, or by your custom firmware running on a PRU.

From the pins coloured on your chart I have 20 x GPIO's and 11 PRU pins
Therefore looking at the charts and seeing how many PRU0 pins there are versus PRU1, will allow me to decide
which pins to use for input or output.

Yes, decide which pins and also which PRU to use for your firmware. Since you need HDMI, it seems to be best to use PRU-0 for your firmware (allows for 6 further fast pins at the uSD slot).

EDIT: The pru's are certainly the most difficult to understand, as an example:
P8-15 is shown on your colour chart as GPIO.
The pin charts show that pin, in Mode 6, as Pr1-Pru0-pru-r31-15 indicating it is an input bit 15.
If I wire this pin as an O/P are you able in the library to convert that to an O/P.

That's a special case caused by the TI design of the CPU. While pr1-pru0-pru-r31-15 (input) is at P8_15, the related pr1-pru0-pru-r30-15 (output) is at P8_11. Most other PRU GPIOs have input and output at the same pin.

I am not trying to understand the PRU from a programming point of view (your library handles that) but trying to avoid hardware mistakes.
Regards
PS: I do appreciate your efforts on this.

This is an important phase of your project. Mistakes will be costly at the end. (Unfortunately I don't feel like having enough information about your systems to give good advices.)

Note: When you aim to use fast PRU GPIOs you'll have 'to understand the PRU from a programming point of view'. But you can start the development by using those pins as normal GPIO and later switch to PRU GPIO, when your PRU firmware is ready.

Regards

[Dinosaur]

Hi TJF

Got it, thanks

Regards

[Dinosaur]

Hi TJF

Sorry , one more question.
On your colour chart you show P9-14,16,21,22 & 42 as Multi Feature Digital, which I assumed means they are attached to a PRU.
However, neither one is shown on the mode charts as PRU.
They are shown as various uses depending on Mode.

On P8-7,8,9,10 (Timers 4-7) are also not shown as assigned to a PRU.

Would I class them as standard GPIO ?

So far the only pins free and available I have found assigned to PRU0
P8-11,12,15 & 16
P9-24,25,27 & 30

Regards