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

[ssl]

So I now managed to get the linking to work by manually loading the libstdc++.so library, but now I'm getting a segmentation fault. I think it might not be as easy as I thought.

Problem is that I don't know much about C and this low-level programming, this is why I wanted to stick to Java...

BTW: Do you have an IRC channel where you hang around? I'd like to chat a little (in German perhaps ;) )

[TJF]

Problem is that I don't know much about C and this low-level programming, this is why I wanted to stick to Java...

Mee too, I want to stick to FreeBASIC. Luckily it's close to C and transforming code is doable. Anyway, I also had to deal with stuff like this to get it running.

BTW: Do you have an IRC channel where you hang around? I'd like to chat a little (in German perhaps ;) )

I never used IRC and I don't like it. It breaks my concentration like a phone call. I prefer to use boards like this one or direct Email.

[TJF]

It looks like you'll need to add a temporary fb_CpuDetect() function (for example in fbc.bas) to allow the link to work, or bootstrap by cross-compiling with a host fbc build from Git.

When I add in file fb.bas at line 20 the following code

Code: Select all

FUNCTION fb_CpuDetect CDECL( ) AS ULONG
  RETURN 0
END FUNCTION

I get

...
FBC src/compiler/obj/fb.o
src/compiler/fb.bas(20) error 4: Duplicated definition in 'function fb_CpuDetect cdecl( ) as ulong'
src/compiler/fb.bas(20) error 125: Too many errors, exiting
make: *** [src/compiler/obj/fb.o] Fehler 1

For me, this seams reasonable since the code in rtl-system.bas defines this function. (Or am I wrong?)

[dkl]

Maybe this will work:

Code: Select all

function override_the_default_fb_CpuDetect cdecl alias "fb_CpuDetect"( ) as ulong
	return 0
end function

The tables in the src/compiler/rtl-*.bas are just data - information that is used to populate the symbol tables when compiling FB code. fb_CpuDetect() is one of these built-in functions (in "old" compiler versions always, in Git only for x86 but not ARM), hence the duplicate definition when trying to re-declare it.

Overall, using the new rtlib with the old fbc is probably a bad idea, because there may be more incompatibilities. It's better to do things in this order:
1. build the new fbc (before building the new rtlib), using whatever working FB installation you have
2. build the new rtlib
3. combine the new fbc & new rtlib into a new FB installation
4. build a new fbc (again), but this time using the new FB installation

This way, the compiler version (used to compile FB programs) always matches the rtlib version (that FB programs will be linked with).

[TJF]

Thanks for further help!

The ALIAS did the trick and the linker is happy now (make compiler works). But when I test the executable (build with my fbc-0.90 version and my rtlib-0.90), I get

fbc -version
This program requires at least a 486 to run.

I run out of time. I still can do some more testing, if you've further ideas. But I cannot search for solutions by myself.

[dkl]

Yea, it looks like there are too many problems when mixing the old fbc with the new rtlib. I think it may be better to follow the bootstrapping steps I mentioned above. Thanks for testing so far. I'm going to try to cross-compile an FB toolchain to run on ARM from scratch, so let's see how that goes. (luckily Ubuntu offers arm-linux-* cross-compiler toolchains)

Edit: here's another idea: return a "proper" value instead of 0, to pass the CPU check:

Code: Select all

function override_the_default_fb_CpuDetect cdecl alias "fb_CpuDetect"( ) as ulong
	return &hFFFFFFFF
end function

Or alternatively, remove the -e from the fbc options in the FB makefile - -e is what causes fbc to generate the x86 CPU check.

[ssl]

Ok I managed to get it working, but don't ask how complicated that was...

With an infinite loop and querying the pruio.value data I am getting about 200kH sampling rate, but at 100% CPU consumption.
Perhaps MM is the better choice for me. But then again, if I understand correctly, in MM I can only access a given number of samples AFTER they are collected in entirety? Also, is it right that once the given number of samples are stored, I need to restart MM, thus loosing some samples inbetween?

Perfect solution for me (perhaps for others too) would be like MM but with a ringbuffer that I can read out whenever I want. Do you plan on implementing such a feature? It'd be really nice to have the samples ringbuffered!

The PRU would do the timing, so my CPU can do other stuff and once every couple milliseconds the CPU can fetch the last couple hundred/tousands of samples in a batch and let the PRU continue it's work. I'm aiming for infinite sampling, so I don't have to specify a number of samples nor seconds.

Greetings, ssl.

PS: The reason I asked about IRC was that I'm having a couple of minor questions I'd like to pose you that aren't worth a forum post/email.

[TJF]

Ok I managed to get it working, but don't ask how complicated that was...

Congrats! You've been faster than me, writing the code ...

Perfect solution for me (perhaps for others too) would be like MM but with a ringbuffer that I can read out whenever I want. Do you plan on implementing such a feature? It'd be really nice to have the samples ringbuffered!

libpruio uses a ring buffer for the pre-trigger samples in MM. Its size is limited to the size of the DRam-[0,1] (up to nearly 16 kB = 8 kSamples) and can be customized by the number of pre-trigger samples. It's undocumented, but you can use this buffer since the PRU reports the position of the last value stored (@DRam[0]). It needs a trigger event that never happens to run it in an endless loop.

The code is prepared to use the complete external memory (up to 8 MB, default it 512 kB) as a ring buffer. I'll think about that, it needs some effort to write the API and documentation. Thanks for the hint.

... I am getting about 200kH sampling rate, but at 100% CPU consumption.

200 kSamples/s is the maximum ADC speed (for one channel).

PS: The reason I asked about IRC was that I'm having a couple of minor questions I'd like to pose you that aren't worth a forum post/email.

Each question at a forum helps others to understand more details. (But feel free to use PM.)

[ssl]

The code is prepared to use the complete external memory (up to 8 MB, default it 512 kB) as a ring buffer. I'll think about that, it needs some effort to write the API and documentation. Thanks for the hint.

Do you plan on releasing a new version with this included? I'll rather wait for that than to put double effort and make up a hacky solution myself.

[TJF]

Yes, I'm working on a new release. But currently there're other issues on top:

• modular structure (completly new code base)
• fixing the pinmux bug
• supporting PWM output in IO
• (not sure about eCAP / eQEP)

When I have left some time at the end, I'll think about a ring buffer mode. You can support the implementation by writing a specification:

• How should this feature look like from the user point of view (which functions are necessary)?
• Which parameters to pass at start (samples in buffer, active steps, sampling rate, bit mode, ...)?
• Which information is needed while running (last writen value as pointer or index, ...)?
• Should it run in combination with IO mode (that's a lot of effort)?
• How can an example demonstrate this feature (< 200 LOC)?
• ...

[ssl]

I experimented a bit, wrote my own little osziloscope and did some tests.
I've attatched a simple voltage divider between the 1.8V and ADC ground to get a solid 0.9V into the ADC Channel 0. Then, I sampled this one at 1000 samples per second and plotted the result to the screen, one horizontal pixel beeing one sample and the vertical pixel beeing one value from the ADC samples. Ideally, I expected the curve to sit straigt on the middle line, corresponding to an input value of 2048 (half of the 12 bit resolution). Of course, there is always some distortion and noise, but it seems quite correlated, which is bad. Look at the attatched image (and zoom a little if needed with [ctrl]+[mouse wheel]).

http://i.imgur.com/KDxvFyS.png

You can see that most of the samples are lying on the powers of two lines in the positive and the power of two minus one lines in the negative part. I did a little histogram which you can see at the bottom of the image and it clearly shows some correlation. Now of course I don't know where this is coming from, but since the values like to align to powers of two, I tought it might be a software issue. What do you think on this?

[TJF]

That's the way it is. ADC samples flicker (no software issue in libpruio, full sure).

Check out AIN7 (step 8). It's connected to the (half) board voltage and should output 1.65 V. You'll also see 2 or 3 bits flicker, depending on the current weather situation.

You can play a bit with the step configuration (open delay and avaraging) to minimize it.

[rvega]

Hi TJF, me again :)

I'm having an issue while trying to use the internal pullups/pulldowns in gpio pins. I've tried the following code:

Code: Select all

  x->io = pruio_new(0, 0x98, 0, 1);
if (x->io->Errr) {
   error("%s/input: Initialisation failed (%s)", LIBRARY_NAME, x->io->Errr);
}
if(pruio_gpio_set(x->io, P9_11, PRUIO_IN_1, PRUIO_LOCK_CHECK)) {
   error("%s/input: Pin configuration failed (%s)\n", LIBRARY_NAME, x->io->Errr);
}
if(pruio_gpio_set(x->io, P9_12, PRUIO_IN_1, PRUIO_LOCK_CHECK)) {
   error("%s/input: Pin configuration failed (%s)\n", LIBRARY_NAME, x->io->Errr);
}
if(pruio_gpio_set(x->io, P9_13, PRUIO_IN_1, PRUIO_LOCK_CHECK)) {
   error("%s/input: Pin configuration failed (%s)\n", LIBRARY_NAME, x->io->Errr);
}
if(pruio_gpio_set(x->io, P9_14, PRUIO_IN_1, PRUIO_LOCK_CHECK)) {
   error("%s/input: Pin configuration failed (%s)\n", LIBRARY_NAME, x->io->Errr);
}
if(pruio_gpio_set(x->io, P9_16, PRUIO_IN_1, PRUIO_LOCK_CHECK)) {
   error("%s/input: Pin configuration failed (%s)\n", LIBRARY_NAME, x->io->Errr);
}
if(pruio_gpio_set(x->io, P9_21, PRUIO_IN_1, PRUIO_LOCK_CHECK)) {
   error("%s/input: Pin configuration failed (%s)\n", LIBRARY_NAME, x->io->Errr);
}
if(pruio_config(x->io, 0, 0x1FE, 0, 4, 0)){
   error("%s/input: Config failed (%s)", LIBRARY_NAME, x->io->Errr);
}

//...

digital_value = pruio_gpio_get(x->io, pin);

If I leave those pins unconnected, I get these values:

Code: Select all

P9_11 1
P9_12 1
P9_13 1
P9_14 0
P9_16 0
P9_21 1

As you can see, it's as if pins 11, 12, 13 and 21 were using a pullup and pins 14 and 16 were using a pulldown. Connecting a cable from those pins to 3.3V or GND also work as if they were using the pullups/pulldowns as mentioned.

Changing the constants in my code from PRUIO_IN_1 to PRUIO_IN_0 or PRUIO_IN don't change this behavior. Could you please help me figure out what I'm doing wrong when trying to set the pulldowns/pullups?

Thanks in advance!

[TJF]

Could you please help me figure out what I'm doing wrong when trying to set the pulldowns/pullups?

Nothing you're doing wrong. It's me who made a conceptual misstake. Pinmuxing doens't work as descriped in libpruio versions 0.0.x, since the PRU cannot write the pad configuration registers in the CPU Control Modul. Sorry for your trouble.

I'm working on a new release to fix that issue (and add new features to libpruio).

As of now, I can just recommend to do the pinmuxing -- before executing your libpruio code -- with external solutions like a custumized device tree overlay or the universal device tree overlays from Charles Steinkuehler and his config-pin tool.

Again, sorry for this trouble.

[rvega]

I made a device tree overlay as explained here: https://www.youtube.com/watch?v=wui_wU1AeQc and now everything works as expected. Thanks!! :D