libpruio (BB D/A - I/O fast and easy)
Re: libpruio (BB D/A - I/O fast and easy)
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 ;) )
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 ;) )
Re: libpruio (BB D/A - I/O fast and easy)
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.ssl wrote:Problem is that I don't know much about C and this low-level programming, this is why I wanted to stick to Java...
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.ssl wrote:BTW: Do you have an IRC channel where you hang around? I'd like to chat a little (in German perhaps ;) )
Re: libpruio (BB D/A - I/O fast and easy)
When I add in file fb.bas at line 20 the following codedkl wrote: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.
Code: Select all
FUNCTION fb_CpuDetect CDECL( ) AS ULONG
RETURN 0
END FUNCTION
For me, this seams reasonable since the code in rtl-system.bas defines this function. (Or am I wrong?)make compiler wrote:...
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
Re: libpruio (BB D/A - I/O fast and easy)
Maybe this will work:
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).
Code: Select all
function override_the_default_fb_CpuDetect cdecl alias "fb_CpuDetect"( ) as ulong
return 0
end function
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).
Re: libpruio (BB D/A - I/O fast and easy)
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
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
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.fbc -version
This program requires at least a 486 to run.
Re: libpruio (BB D/A - I/O fast and easy)
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:
Or alternatively, remove the -e from the fbc options in the FB makefile - -e is what causes fbc to generate the x86 CPU check.
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
Re: libpruio (BB D/A - I/O fast and easy)
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.
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.
Re: libpruio (BB D/A - I/O fast and easy)
Congrats! You've been faster than me, writing the code ...ssl wrote:Ok I managed to get it working, but don't ask how complicated that was...
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.ssl wrote: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 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.
200 kSamples/s is the maximum ADC speed (for one channel).ssl wrote:... I am getting about 200kH sampling rate, but at 100% CPU consumption.
Each question at a forum helps others to understand more details. (But feel free to use PM.)ssl wrote: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.
Re: libpruio (BB D/A - I/O fast and easy)
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 wrote: 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.
Re: libpruio (BB D/A - I/O fast and easy)
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)
- 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)?
- ...
Re: libpruio (BB D/A - I/O fast and easy)
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?
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?
Re: libpruio (BB D/A - I/O fast and easy)
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.
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.
Re: libpruio (BB D/A - I/O fast and easy)
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:
If I leave those pins unconnected, I get these values:
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!
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);
Code: Select all
P9_11 1
P9_12 1
P9_13 1
P9_14 0
P9_16 0
P9_21 1
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!
Re: libpruio (BB D/A - I/O fast and easy)
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.rvega wrote:Could you please help me figure out what I'm doing wrong when trying to set the pulldowns/pullups?
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.
Re: libpruio (BB D/A - I/O fast and easy)
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