Hi guys, thanks for the replies. If I get back to this project at some point I'll definitely try what you suggest. The hardware is still lying on my desk in front of me so I might give it a shot later toda.
Cheers. On Tuesday, January 14, 2014 9:59:12 PM UTC, [email protected] wrote: > > > > On Sunday, May 26, 2013 1:53:01 PM UTC-4, [email protected] wrote: >> >> I'd like to find a good and detailed source of information on how to >> create a well-integrated BBB Cape design. I have put together a bare-bones >> cape which is just an EEPROM chip running off the BBB's 3.3v line. The >> EEPROM contains my correctly formatted data and does indeed appear to be >> recognised in the output from *dmesg*. However, I am now a bit stuck. >> >> Following a couple of articles on the web I managed to bodge together a >> working ".dtbo" file and this appears to work. My prototype board does >> show up in `cat /sys/devices/bone_capemgr.9/slots` after a reboot, which is >> great :). >> >> But I'm at a bit of a loss as to what I should do next. I'd like to put >> an ATMega microcontroller onto my shield (running from the BBB's 3.3v rail) >> and have it talk to the BBB using two IO pins to form a simple TX/RX uart. >> The ATMega side of this is no problem, I've done this many times, but the >> BBB side is unknown to me. >> >> > Take a look at the BB-UART1 DTS script (in /lib/firmware), it shows how to > configure UART1 for use. Once you've compiled the .dtbo for your cape and > put it in /lib/firmware, if you have the right part # and revision info in > the EEPROM, then the capemgr should properly load the .dtbo and you'll see > a device /dev/ttyO1 (for UART1). At this point, you can test it by running > minicom and configuring the port to use /dev/ttyO1 (with 115200,8,N,1 with > no flow control etc) and you should be able to talk to your ATmega. > > NOTE: There's a 60 delay when the capemgr tries to load your dtbo as > there's a race condition with the eMMC cape (which contains the root > filesystem!) and it hangs for 60 seconds before giving up, loading the eMMC > cape which allows filesystem access. At that point, it does retry your > cape and will load the .dtbo, but the 60s hang is **very** annoying. There > were some patches applied a while ago, but I don't know if they have shown > up yet. Besides, changing the 60 timeout requires a custom kernel. > > The only other option to skip the 60s delay is to compile your dtbo into > the kernel -- I haven't yet figured out how to do this! > > Hope this helps, > > > -W > > > -- 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/groups/opt_out.
