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