[beagleboard] Using GPIO pins and scratchpad of the PRU with C

2016-02-09 Thread lucas 
Hi,

I am building an application based on the PRU_Hardware_UART example of the 
"Programmable Real-time Unit (PRU) Software Support Package release 4.0" 
from TI. And I am using the TI C compiler v2.1.2. The UART works great.

I am able to use the GPIO pins by declaring "volatile register uint32_t 
__R30;" in my C source code. Then I can simply set the value of the 
variable "__R30" and the register value and the output pins reflect this 
value. This seems a bit like magic to me, how does the compiler know that 
__R30 is supposed to be the GPIO register? There doesn't seem to be macro 
expansion or similar going on.

Is there a similar declaration I can use for the scratchpad registers and 
then access them from PRU0 as well as PRU1?

Thanks a lot,

Lucas

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Enable PWM on BBB Debian 4.1 Jessie

2016-02-09 Thread Mark A. Yoder 
Robert:
  I tried it.  What should I see?  It looks like I get yet another ordering 
of the aliases.

# universaln
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip0 -> 
../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip0
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip2 -> 
../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip4 -> 
../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip4
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip5 -> 
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip6 -> 
../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6


# cape-emmc
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip0 -> 
../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip1 -> 
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip2 -> 
../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip2
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip4 -> 
../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip4
# 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip6 -> 
../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6

# New universaln (4.1-ti-pwm)
# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip0 -> 
../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip0
# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip2 -> 
../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2
# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip4 -> 
../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip4
# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip5 -> 
../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip5
# 0 lrwxrwxrwx 1 root root 0 Feb  9 08:57 pwmchip7 -> 
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7

--Mark

On Monday, February 8, 2016 at 7:58:39 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Feb 8, 2016 at 6:50 PM, Robert Nelson  > wrote: 
> > On Mon, Feb 8, 2016 at 6:36 PM, Mark A. Yoder  > wrote: 
> >> Yup, here's the mappings depending on which dts file is used: 
> >> 
> >> # universaln 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip0 -> 
> >> ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip0 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip2 -> 
> >> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip2 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip4 -> 
> >> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip4 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip5 -> 
> >> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:32 pwmchip6 -> 
> >> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6 
> >> 
> >> 
> >> # cape-emmc 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip0 -> 
> >> ../../devices/platform/ocp/4830.epwmss/48300100.ecap/pwm/pwmchip0 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip1 -> 
> >> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip1 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip2 -> 
> >> ../../devices/platform/ocp/4830.epwmss/48300200.ehrpwm/pwm/pwmchip2 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip4 -> 
> >> ../../devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/pwmchip4 
> >> # 0 lrwxrwxrwx 1 root root 0 Feb  8 19:01 pwmchip6 -> 
> >> ../../devices/platform/ocp/48304000.epwmss/48304200.ehrpwm/pwm/pwmchip6 
> >> 
> >> Yes, the addresses are there, so I need to find a place that maps the 
> >> addresses to the header pin numbers. 
> > 
> > We could also add the alias to the am33xx.dtsi: 
> > 
> > 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am33xx.dtsi#n20
>  
> > 
> > like: 
> > 
> > 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70f97128a158a596aeb82140ffacc8c18657baee
>  
>
> give this a shot: 
>
>
> https://github.com/RobertCNelson/dtb-rebuilder/commit/27b496e93853a210fb79bc95681c54e69f20d494
>  
>
> git clone https://github.com/RobertCNelson/dtb-rebuilder 
> cd ./dtb-rebuilder/ 
> git checkout origin/4.1-ti-pwm  -b tmp 
> make 
> sudo make install 
>
> sudo reboot 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Using GPIO pins and scratchpad of the PRU with C

2016-02-09 Thread Soapy Smith 
There is a manual for the C compiler and the assembler:

http://processors.wiki.ti.com/index.php/PRU-ICSS

The links are on the right side of the page.

Some of the PRU hardware specific registers are accessed via a large union 
in a header file.  It uses structs with "bit fields" so you can easily 
access individual bits in the register.
Look for a header file called pru_cfg.h.  But specifically to your 
question, I'm still trying to figure out how the PRU input and output 
registers R30 and R31 are done in C, as I
don't see those called out in the header file (in information overload at 
this point!).

Regarding the scratchpad, I believe it can't be accessed via C.  However, 
you can embed assembler codes into C source code.
If you go here:

https://training.ti.com/sitara-processors-building-blocks-for-pru-development-summary

Download the firmware development slides and look at page 8.

Regards,
Greg

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Using GPIO pins and scratchpad of the PRU with C

2016-02-09 Thread Soapy Smith 
OK, I see they extended the C language for R30 and R31!

I haven't found any good examples were C and assembler are mixed.  I have 
seen statements which say there are multiple ways to accomplish it.
It looks like the simplest is to inject assembler code directly into the C 
code.  See page 76.  There is also a section on "Intrinsics" on page 89.  I 
think that might be what you are looking for.

On Tuesday, February 9, 2016 at 7:56:44 AM UTC-5, lucas wrote:
>
> Ah, thank you. These are excellent resources. I think I found the answer 
> to my first question in the PRU Optimizing C/C++ Compiler v2.1 User Guide:
>
> Section: 5.7.2 Global Register Variables
>
> The C/C++ compiler extends the C language by adding a special convention 
>> to the register storage class specifier to allow the allocation of global 
>> registers. This special global declaration has the form: register type 
>> regid The regid parameter can be __R30 and __R31. The identifiers _ _R30 
>> and _ _R31 are each bound to their corresponding register R30 and R31, 
>> respectively. These are control registers and should always be declared as 
>> volatile. 
>
>
> I am still a bit uncertain about the scratch pad. I have a value stored in 
> a C variable, but how could I copy that value into inline assembler - so 
> that I can write it to the scratch pad?
>
>
>
> On Tuesday, February 9, 2016 at 1:37:14 PM UTC+1, Soapy Smith wrote:
>>
>> There is a manual for the C compiler and the assembler:
>>
>> http://processors.wiki.ti.com/index.php/PRU-ICSS
>>
>> The links are on the right side of the page.
>>
>> Some of the PRU hardware specific registers are accessed via a large 
>> union in a header file.  It uses structs with "bit fields" so you can 
>> easily access individual bits in the register.
>> Look for a header file called pru_cfg.h.  But specifically to your 
>> question, I'm still trying to figure out how the PRU input and output 
>> registers R30 and R31 are done in C, as I
>> don't see those called out in the header file (in information overload at 
>> this point!).
>>
>> Regarding the scratchpad, I believe it can't be accessed via C.  However, 
>> you can embed assembler codes into C source code.
>> If you go here:
>>
>>
>> https://training.ti.com/sitara-processors-building-blocks-for-pru-development-summary
>>
>> Download the firmware development slides and look at page 8.
>>
>> Regards,
>> Greg
>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Using GPIO pins and scratchpad of the PRU with C

2016-02-09 Thread lucas 
Ah, thank you. These are excellent resources. I think I found the answer to 
my first question in the PRU Optimizing C/C++ Compiler v2.1 User Guide:

Section: 5.7.2 Global Register Variables

The C/C++ compiler extends the C language by adding a special convention to 
> the register storage class specifier to allow the allocation of global 
> registers. This special global declaration has the form: register type 
> regid The regid parameter can be __R30 and __R31. The identifiers _ _R30 
> and _ _R31 are each bound to their corresponding register R30 and R31, 
> respectively. These are control registers and should always be declared as 
> volatile. 


I am still a bit uncertain about the scratch pad. I have a value stored in 
a C variable, but how could I copy that value into inline assembler - so 
that I can write it to the scratch pad?



On Tuesday, February 9, 2016 at 1:37:14 PM UTC+1, Soapy Smith wrote:
>
> There is a manual for the C compiler and the assembler:
>
> http://processors.wiki.ti.com/index.php/PRU-ICSS
>
> The links are on the right side of the page.
>
> Some of the PRU hardware specific registers are accessed via a large union 
> in a header file.  It uses structs with "bit fields" so you can easily 
> access individual bits in the register.
> Look for a header file called pru_cfg.h.  But specifically to your 
> question, I'm still trying to figure out how the PRU input and output 
> registers R30 and R31 are done in C, as I
> don't see those called out in the header file (in information overload at 
> this point!).
>
> Regarding the scratchpad, I believe it can't be accessed via C.  However, 
> you can embed assembler codes into C source code.
> If you go here:
>
>
> https://training.ti.com/sitara-processors-building-blocks-for-pru-development-summary
>
> Download the firmware development slides and look at page 8.
>
> Regards,
> Greg
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: debian testing: 2016-02-07 (WiFi AP)

2016-02-09 Thread Hilmar Lapp 
And of course reboot to have the changes take effect.

-hilmar

Sent from away

> On Feb 9, 2016, at 12:20 AM, Robert Nelson  wrote:
> 
> cd /opt/scripts/tools/
> git pull

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Using GPIO pins and scratchpad of the PRU with C

2016-02-09 Thread lucas 
Greg, thanks a bunch. It seems like page 89 of the user guide does the 
trick! I am not yet sure how to debug both PRUs at the same time, but I can 
write to the scratch pad from one PRU and read it back. 

example code:

void testScratchPad(){
static unsigned int test = 0;
test++;
unsigned int* testPtr = 
 __xout(10, // Scratch pad bank 0
  0, // base register 0
  0, // remapping false
  testPtr // object
 );
 unsigned int test2;
 unsigned int* test2Ptr = 
 __xin(10, 0, 0, test2Ptr); // value is now in test2
}

So maybe this works :) 

On Tuesday, February 9, 2016 at 2:13:51 PM UTC+1, Soapy Smith wrote:
>
> OK, I see they extended the C language for R30 and R31!
>
> I haven't found any good examples were C and assembler are mixed.  I have 
> seen statements which say there are multiple ways to accomplish it.
> It looks like the simplest is to inject assembler code directly into the C 
> code.  See page 76.  There is also a section on "Intrinsics" on page 89.  I 
> think that might be what you are looking for.
>
> On Tuesday, February 9, 2016 at 7:56:44 AM UTC-5, lucas wrote:
>>
>> Ah, thank you. These are excellent resources. I think I found the answer 
>> to my first question in the PRU Optimizing C/C++ Compiler v2.1 User Guide:
>>
>> Section: 5.7.2 Global Register Variables
>>
>> The C/C++ compiler extends the C language by adding a special convention 
>>> to the register storage class specifier to allow the allocation of global 
>>> registers. This special global declaration has the form: register type 
>>> regid The regid parameter can be __R30 and __R31. The identifiers _ _R30 
>>> and _ _R31 are each bound to their corresponding register R30 and R31, 
>>> respectively. These are control registers and should always be declared as 
>>> volatile. 
>>
>>
>> I am still a bit uncertain about the scratch pad. I have a value stored 
>> in a C variable, but how could I copy that value into inline assembler - so 
>> that I can write it to the scratch pad?
>>
>>
>>
>> On Tuesday, February 9, 2016 at 1:37:14 PM UTC+1, Soapy Smith wrote:
>>>
>>> There is a manual for the C compiler and the assembler:
>>>
>>> http://processors.wiki.ti.com/index.php/PRU-ICSS
>>>
>>> The links are on the right side of the page.
>>>
>>> Some of the PRU hardware specific registers are accessed via a large 
>>> union in a header file.  It uses structs with "bit fields" so you can 
>>> easily access individual bits in the register.
>>> Look for a header file called pru_cfg.h.  But specifically to your 
>>> question, I'm still trying to figure out how the PRU input and output 
>>> registers R30 and R31 are done in C, as I
>>> don't see those called out in the header file (in information overload 
>>> at this point!).
>>>
>>> Regarding the scratchpad, I believe it can't be accessed via C. 
>>>  However, you can embed assembler codes into C source code.
>>> If you go here:
>>>
>>>
>>> https://training.ti.com/sitara-processors-building-blocks-for-pru-development-summary
>>>
>>> Download the firmware development slides and look at page 8.
>>>
>>> Regards,
>>> Greg
>>>
>>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: CAN-CAPE TT3201 CAN/CANBUS on BeagleBone Black Redux

2016-02-09 Thread kevinlang . ca 
Can I get the  package with instruction?

Thanks,
Kevin

On Thursday, October 8, 2015 at 3:16:17 PM UTC-6, Alessandro Zummo wrote:
>
>
> Hi!
>
> Debian is now supported and you don't need any particular kernel, we give 
> a package
> with full drivers sources and a script that does it all.
>
> A git repository with the drivers is available but we found out that
> customers makes less mistakes when we give them a package with 
> instructions.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Protect eMMC/eMMC flasher Data

2016-02-09 Thread Julien 
Joshua Datko :
>
> I'm not sure what solution would work for the pi that can't also be 
> used for the BBB. 
>
> I referred to this discussion without answer :
https://groups.google.com/forum/#!topic/beagleboard/LD4UPN-GIYM

Joshua Datko :
>
> You should know that anybody can walk up to any BBB, overwrite the MLO 
> and boot their own image. The SoC doesn't verify the boot image. 
>
> What's your threat model? Are you worried about people having physical 
> access to the BBB? Then perhaps put it in a tamper evident/responsive 
> container. Otherwise, yes, you hold the USR_BOOT button and boot from 
> the SD card. 
>
> Does the application need an automated way to get the key to unlock the 
> file system? Can it get the key from a server? from a human? 
>
> Otherwise, you need to store/derive the key somehow on the BeagleBone. 
>
>  
I need propose a factory restore procedure and the only solution is an µSD 
card with flasher...

The best solution is that of Dieter with Ecryptfs although I would have 
preferred to avoid it, because i need to move my application files to the 
home folder and change more script

Thanks for all help
Julien.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Use GPIO as non-root user?

2016-02-09 Thread TJF 
libpruio is PRUSS assembler code to control the subsystems GPIO, ADC, 
PWM/CAP. An API is available to control that assembler part from host CPU 
(ARM), written in FreeBASIC. Also a C wrapper is shipped in the package.

When you say Python fits well, why do you think FreeBASIC doesn't? It 
combines a steep learning curve (like Python) with the advantages of a real 
compiler.

Some years ago I tried to use SWIG. From my point of view it's not 
flexible, not really well documented and much too complicated to use. 
Finally I wrote a similar tool (h_2_bi) from scratch, in order to meet my 
needs.

In April 2015 Benoit Clouet and me made a libpruio Python binding based on 
ctypes for his browser controlled tank project 
. Find the source code and 
additional information in this post 

.

Anyway, I just tried to share experiences from other libpruio users and 
myself in order to minimize your development costs. If you feel like 
replacing one difficulty by another, then I need not spend my time in 
posting here.

BR

-- 
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.
For more options, visit https://groups.google.com/d/optout.