Raspberry Pi or Beagle Board!!??

There's going to be an Open Source Hardware Panel Discussion at the upcoming DesignWest show in San Jose, California starring Jason Kridner (BeagleBoards) and Gert Van Loo (Raspberry Pi / Gertboard).  I sure hope it devolves into a Pi fight about whether RasPi is Open Source Hardware (oh yeah?  Let's see the Gerbers!  Tell me where I can get a BCM2835 in small quantities -- with a full tech ref!) and whether Open Source Hardware is a Good Idea (oh yeah? If OSH is so great, how come RasPi has sold 1M in one year and BBs have only sold 100K in 4.5?  huh?  huh?)

Actually, I doubt it'll be that much fun, but should be informative.  12 Noon PDT, 23 April 2013.  Expo Theatre shows are included in the free (as in beer) expo pass.

darn it, now I need to figure out how to get out to California because that looks very interesting!

I am also looking to make a choise. With Arduino you have everything under control and probably the best real time response as there is no OS involved. With both the PI and the Beaglebone the OS stays alive and as far as I can see the overhead of the OS is not verry deterministic. On the otherhand quit often you need to stay in touch with the world and both the PI and the Beagle Bone can help you in that area. I like the idea of the coporcessors on the Beagle Bone but I am not looking forward of programming them in assembler. (I hate it and I did some assembler and even witing micro code in my younger years.). I can live with for instance an Arduino as coprocessors. Did someone write communication software for this purpose either for the PI or for the Beagle Bone?

I believe this is an example of writing C code for the BeagleBone's PRU (embedded microcontroller):

http://elinux.org/ECE497_BeagleBone_PRU

For communicating with an Arduino, OpenROV is an example of Arduino + BeagleBone:

https://github.com/OpenROV/openrov-software

For Raspberry Pi and Arduino, check out simon.monk

http://www.raspberrypi.org/archives/1171

Drew,

    It's not clear to me what they are doing regarding programming the BeagleBone's PRU in C,

because the docs clearly state "PRU's are programmed in assembly."

http://elinux.org/Ti_AM33XX_PRUSSv2

So I guess the eLinux ECE497 doc describes using memory mapping to accecss the PRU:

http://elinux.org/ECE497_BeagleBone_PRU#How_the_C_Code_Works

But it does seem like the actual instructions run on the PRU are assembly.

I found the github repo for the blinker demo: https://github.com/millerap/AM335x_PRU_BeagleBone/tree/master/GPIO_PWM_PRU

Drew Fustini wrote:

 

So I guess the eLinux ECE497 doc describes using memory mapping to accecss the PRU:

 

http://elinux.org/ECE497_BeagleBone_PRU#How_the_C_Code_Works

 

But it does seem like the actual instructions run on the PRU are assembly.

 

I found the github repo for the blinker demo: https://github.com/millerap/AM335x_PRU_BeagleBone/tree/master/GPIO_PWM_PRU

Yeah, today's PRU code is written in assembly. There have been experiements with writing a C compiler for it and we'll have to see if those see the light of day.

I find following the Replicape project (https://bitbucket.org/intelligentagent/replicape) to be informative on PRU development.  He's done a loader in Python that helps communication to the PRUs: https://bitbucket.org/intelligentagent/pypruss.  In one of his examples, he shows toggling a GPIO with at 15ns duty cycle, though I think that 3rd cycle could be trimmed.

Drew Fustini wrote:

 

So I guess the eLinux ECE497 doc describes using memory mapping to accecss the PRU:

 

http://elinux.org/ECE497_BeagleBone_PRU#How_the_C_Code_Works

 

But it does seem like the actual instructions run on the PRU are assembly.

 

I found the github repo for the blinker demo: https://github.com/millerap/AM335x_PRU_BeagleBone/tree/master/GPIO_PWM_PRU

Yeah, today's PRU code is written in assembly. There have been experiements with writing a C compiler for it and we'll have to see if those see the light of day.

I find following the Replicape project (https://bitbucket.org/intelligentagent/replicape) to be informative on PRU development.  He's done a loader in Python that helps communication to the PRUs: https://bitbucket.org/intelligentagent/pypruss.  In one of his examples, he shows toggling a GPIO with at 15ns duty cycle, though I think that 3rd cycle could be trimmed.