Hi William, Thanks for the suggestion. Actually, I had looked a little bit at Xenomai, and also Chibi-OS and a couple of other RTOSes. I was worried about adding complexity for myself, not really having experience in compiling kernals and not having much experience programming within Linux or using other tools within Linux. Also, I'm kind of a control freak. But I do like to try to learn something new with each project I work on, so I'll probably fight with the bare metal a little while longer, and then seriously consider moving to an OS based environment. Since Linux controls a lot more of the world than most people give it credit for, I really should try to get fluent with it (I could add it to my resume then). It would also be nice to abstract away other things that an OS already has code for. For example, I would like to add a wireless USB NIC to the BBB, and if there is one that already has a driver and I can just write code to use it, that would be awesome.
On Monday, June 15, 2015 at 11:22:00 AM UTC-4, William Hermans wrote: > Hey Bill, > > If you're needing deterministic, and *if* you decide to run Linux( or > maybe just experiment ), You can always look into Xenomai. > > Now keep in mind that I have no hands on personally. But it could be as > easy as writing a current image to sdcard, and apt-get install-ing one of > the latest xenomai kernels. Followed by learning about Xenomai of course . > . . something I've been wanting to do myself, but have no gotten around to. > > On Mon, Jun 15, 2015 at 7:33 AM, Bill M <[email protected] <javascript:> > > wrote: > >> Greetings All, >> >> Wow, I'm glad this has generated so much conversation. Thanks to everyone >> who has chimed in. >> >> To Rick M, one of the things that attracted me to the BBB was that it has >> several available UARTS, but I also need things to run in a deterministic >> fashion since I need to control an array of servos and updating needs to >> happen 128 times a second, which means a several dozen byte packet going >> out that frequently. After reading through a bit more in the TRM about the >> PRU UART, I don't think a PRU UART will be feasible since it looks like >> they top out at around 300Kbs, and I need a megabit. I'm hoping things will >> be sufficiently deterministic since I'm running bare metal, and will drive >> the update loop with a timer interrupt and have the UART just feed things >> out as fast as the line will consume it. I know things will run more slowly >> if I don't use caching, but if I disable caching, does that eliminate any >> pipelining? I'm a noob when it comes to pipelining and caching, since I've >> only ever hacked on AVR microcontrollers and a Cortex M3, where those >> weren't considerations. I'm a line of business programmer in my day job :(. >> >> Matthijs, does EDMA offer that big a performance boost? Most of my >> background up to this point has been just coding things for handling >> hardware and timer interrupts and UART communication. I'm an extreme noob >> when it comes to the more involved hardware stuff like DMA. Does going from >> the PRU to DDR pass over the L3 interconnect whether it's DMA or regular >> DWORD by DWORD assignment? I'm figuring this will have to pump 9 MB a >> second to DDR, but with each write being a DWORD, this should only be one >> write every 455 clock cycles for the main core (assuming my math is >> correct). I have to admit, my head is swimming with some of what you wrote, >> so I definitely need to crack the books harder. If you know of any good >> references on MMUs, caching, and pipelining for beginners, let me know (I >> also need to educate myself more on kernel programming). I just imagine >> there has to be some good way to get good throughput from the PRUs to the >> rest of the system, otherwise the PRUs wouldn't be very useful to the rest >> of the system, but again, I may just be naïve. >> >> In the meantime, right now I'm just finishing getting my development >> environment set up for everything, since I'm using GCC and am using Eclipse >> for my IDE (up til now while learning my way around Starterware and the PRU >> tools, I've just been using notepad and the command line >_<). I've got it >> set up now to build the PRU code, convert it to C header files, and include >> it in my main code, which it can compile for the final bin and use memcpy >> to load and start the PRU at run time (primitive, but it works for my >> purposed right now). Now I'm going to start writing code to start trying to >> read the camera, and I'll report back my results. Maybe I'll eventually >> take the dive into Linux (I've waded in until this point). >> >> Thanks, again to everyone! >> >> >> >> >> >> On Sunday, June 14, 2015 at 7:36:46 AM UTC-4, Matthijs van Duin wrote: >> >>> On Wednesday, 10 June 2015 20:03:22 UTC+2, Charles Steinkuehler wrote: >>>> >>>> In addition to the other thread, I'd suggest looking at the >>>> BeagleLogic code. It's possible to move _large_ amounts of data >>>> through the PRU to the DRAM, but it requires some finesse. >>>> >>> >>> My first intuition would be using EDMA. >>> >>> >>> On Thursday, 26 March 2015 23:51:02 UTC+1, Charles Steinkuehler wrote: >>>> >>>> on the ARM side you won't ever see any changes unless you're careful >>>> about your cache management (typically using kernel-mode code and the same >>>> sort of memory semantics required when doing DMA transactions). >>>> >>> >>> Mapping the memory as uncacheable and using appropriate barriers >>> suffices (privilege is not needed, though typically baremetal code tends to >>> run privileged anyway). >>> >>> >>> I'd recommend just using the PRU data memory space for anything like >>>> semaphores or mailboxes. The memory is already mapped with the proper >>>> access flags to avoid ARM side caching issues, and the PRUs can access >>>> the memory without stalling. >>> >>> >>> Well in a baremetal application nothing is "already mapped". In fact an >>> issue here is that the PRU memory space resides within the same 1MB section >>> as peripherals, so if both are accessed from the A8 you'd need to set up a >>> page table for that section to make PRU memory space normal uncacheable >>> while making the peripheral space device-type. (Well, you don't *have* to, >>> but if you care about performance...) >>> >>> I do agree with having the PRUs stick to PRU memory as much as possible. >>> >>> >>>> I looked at your TI post, but it doesn't make much sense to me. I'm >>>> not >>>> very familiar with starterware, or with the spinlock register you refer >>>> to. I can say that the ARM atomic bus transactions are unlikely to >>>> work >>>> properly between the PRU and the ARM if you're using the PRU shared >>>> memory, but there are many other synchronizing constructs you can use. >>>> >>> >>> I'm pretty sure that ARM atomic bus transactions (neither the old locked >>> SWP nor the newer load/store-exclusive) will not accomplish anything >>> useful, if they get anywhere beyond the CPU boundary at all. >>> >>> TI is however referring to the hwspinlock peripheral which (along with >>> the mailbox peripheral) is specifically intended for inter-core >>> synchronization. I personally would not be eager to use hwspinlock though. >>> >>> I'd also try to go for unidirectional messaging like you're saying. The >>> mailbox peripheral looks quite reasonable for inter-core notification, >>> especially if this is infrequent and you want to avoid polling, though I >>> think you also may be able to do that purely with the rather elaborate >>> PRUSS interrupt controller. >>> >>> When writing from the A8 to uncacheable memory, do remember to finish >>> off with a memory barrier instruction since the A8 is allowed to (and >>> *does*) buffer writes indefinitely otherwise. >>> >> -- >> 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] <javascript:>. >> 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.
