I just thought I'd toss this out there though. Over the last 2-3 months I've been working on a project that Involves socketCAN, and forming NEMA 2000 fastpackets from socketCAN frames in real time. Then pushing the data in the form of JSON out a webserver ( web sockets ), in real time as well.
So up until last night I was working on all this in a quad core 4 GB RAM virtual machine( virtualbox ). canplayer was eating up around 58% CPU on a single core, while my two processes were taking around 8% between the two. quad cores - 3Ghz. Imagine my surprise last night that canplayer only uses 2% CPU, and the two processes I'm working on use 0% - In fact, the webserver only shows up in atop about half the time- heh. My point is: The beaglebone may not have but 1/3 the CPU frequency, and a LOT less memory. It may also do some things such as compile large projects slower, or even sometimes a lot slower. But do not let it fool you. It is still a beast. On Wed, Aug 5, 2015 at 1:55 PM, William Hermans <yyrk...@gmail.com> wrote: > Hello again Lenny, > > Yeah I have not looked into uboot very deeply. But it does have at least > some Ethernet, USB, and Serial functionality. I say "some" because I'm not > sure how extensive it is. For example with the builtin ethernet stuff, you > can boot over TFTP and NFS, but beyond that . . . not sure what can be done > with it. Also I'm pretty sure there is some I2C functionality built in too. > NO personal hands on with it though . . . > > Anyway, yeah, I'd listen to Charles, and Robert, as they've probably both > had their hands into the lower level stuff more than I have. I was just > tossing some things out there for you to read on when and if you got the > time . . . As I was kind of in the same boat you are in - But a couple > years ago. I was also thinking maybe super low level baremetal, but decided > a good long while ago that it was not really worth it for me. PRU's ? Sure, > but baremetal Sitara . . .Yeah not for me hehe > > On Wed, Aug 5, 2015 at 1:12 PM, Lenny <leonhard.neuh...@gmail.com> wrote: > >> Thanks for your post William, >> the idea to start an executable from uboot sounds very close to what I >> want i guess. My question here would be which document is equivalent to the >> PruReferenceGuide, such that I can find out how to talk to the various >> hardware pieces such as memory and inputs/outputs and the NEON core etc., >> and which compiler I would have to use (in the best case a C compiler with >> inline assembler support). And if available, a library with some useful >> functions such as a accessing serial port (USB) and maybe even Ethernet >> (though i guess that would require interrupts and all sorts of other >> overhead) would be just perfect! >> >> But actually I have just now looked into starterware ( >> http://processors.wiki.ti.com/index.php/StarterWare_02.00.01.01_User_Guide#Serial_Peripherals), >> and it really looks amazingly close to what I had in mind. There are lots >> of examples and I guess i'll start testing some of them. >> >> @Charles: Thanks for the warning :) Im still still a noob when it comes >> to processor architecture. The application I have in mind (FIR filter) is >> computationally intensive, but does not need a huge data throughput (few >> MSps would be enough, which I know I can delegate to the PRU if necessary). >> I found the idea of using the main processor appealing as I read somewhere >> about its SIMD capability (doing 16 or 32 multiplications and accumulates >> simultaneously, which would theoretically allow something like 16-32Gflops, >> right?), and floating point arithmetics. >> >> So if you confirm that all those advantages are lost somewhere in the >> communication between core and dedicated modules, that would be a pity but >> indeed save me a lot of time :) >> >> And for curiosity/ease of later implementation/number of available >> input-output ports: What delay and number of necessary instructions can I >> expect for exchanging one or multiple bits between the main processor and a >> GPIO port? More than 10 cycles? >> >> Thanks so much for your suggestins and help! >> >> >> >> >> -- >> 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. >> > > -- 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.
