Re: [beagleboard] Newbie question about I/O on the beaglebone black...
If you don't want to get into PRU programming ordinary sequential IO and a latched buffer might work for you. On Thu, Sep 25, 2014 at 11:36 PM, John Tonkin john.ton...@gmail.com wrote: hi there your project is a little mysterious, so it is hard to be specific but here are some thoughts based on my own recent research into using beaglebones to drive LEDstrips and a custom LCD array. from https://github.com/osresearch/LEDscape the beaglebone SOC has two PRUs (programmable realtime unit) which are designed for this sort of purpose. the TI AM335x ARM Cortex-A8 in the BeagleBone Black has two programmable microcontrollers built into the CPU that can handle realtime tasks and also access the ARM's memory. This allows things that might have been delegated to external devices to be handled without any additional hardware, and without the overhead of clocking data out the USB port. (I am actually using a fork of this library https://github.com/Yona-Appletree/LEDscape for driving LED strips, and am planning to modify this code for my other project) PRUs run at 200MHz and have very efficient access to some (more than the 16 bits that you require) of the GPIO pins (these need to be pin-muxed correctly - that is another can of worms / kettle of fish). you read / write to pins by reading / writing to specific PRU registers. so you can read/write 8 (or more) bits simultaneously. it's much more efficient than the more traditional Linux sysfs approach. there is a FAQ about using the PRUs stickied at the top of this group and lots more info on The internet's. Trammell Hudson, who developed the original LEDscape code, seems to have done quite a bit of interfacing beaglebones to old computing hardware. http://trmm.net/Category:Retrocomputing eg http://trmm.net/Mac-SE_video another example http://blinkenbone.com/projects/blinkenbone I've found a logic analyser (eg https://www.saleae.com) to be very useful when doing this sort of stuff. john -- 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.
[beagleboard] Newbie question about I/O on the beaglebone black...
hi there your project is a little mysterious, so it is hard to be specific but here are some thoughts based on my own recent research into using beaglebones to drive LEDstrips and a custom LCD array. from https://github.com/osresearch/LEDscape the beaglebone SOC has two PRUs (programmable realtime unit) which are designed for this sort of purpose. the TI AM335x ARM Cortex-A8 in the BeagleBone Black has two programmable microcontrollers built into the CPU that can handle realtime tasks and also access the ARM's memory. This allows things that might have been delegated to external devices to be handled without any additional hardware, and without the overhead of clocking data out the USB port. (I am actually using a fork of this library https://github.com/Yona-Appletree/LEDscape for driving LED strips, and am planning to modify this code for my other project) PRUs run at 200MHz and have very efficient access to some (more than the 16 bits that you require) of the GPIO pins (these need to be pin-muxed correctly - that is another can of worms / kettle of fish). you read / write to pins by reading / writing to specific PRU registers. so you can read/write 8 (or more) bits simultaneously. it's much more efficient than the more traditional Linux sysfs approach. there is a FAQ about using the PRUs stickied at the top of this group and lots more info on The internet's. Trammell Hudson, who developed the original LEDscape code, seems to have done quite a bit of interfacing beaglebones to old computing hardware. http://trmm.net/Category:Retrocomputing eg http://trmm.net/Mac-SE_video another example http://blinkenbone.com/projects/blinkenbone I've found a logic analyser (eg https://www.saleae.com) to be very useful when doing this sort of stuff. john -- 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.
[beagleboard] Newbie question about I/O on the beaglebone black...
I have a possible application for a number of BBBs and can't find a cogent answer... Perhaps the collective knowledge and experience of the group will provide the best answer... Can the BBB do bytewide I/O under C ?? Here's the situation... The project is to update an already deployed card cage based hardware system. It presently uses a proprietary Z80 based CPU board that was designed for the job 25 years ago. I envision a replacement CPU board that plugs into the existing proprietary socket - the card would be a designed-for-the-job mothercard with a BBB upside down so that the expansion headers plug into (onto ?) connector strips on the mothercard. At the moment, I envision that the BBB computing environment will be Ubuntu running both a web host and the custom applications program on startup. The BBB I/O required will be the ethernet, the host and client USB, the HDMI port, one I2C, and UART 0 (for debugging). I can see the custom application exclusively accessing the A-to-D, the second I2C, one SPI, and both UART 1 and 2. The mothercard would have a 5 volt regulator (the cage power is 12v), the necessary level converters (all of the backplane buss signals switch between 5 volt and ground), buffers / voltage dividers for the A-to-D lines, an Adafruit clock / calendar chip, perhaps sensors for temperature, humidity, barometric pressure (on an i2c buss)... Plus a few other items... a card ejector tab, a DB9F connector for the RS-232 debug port, front-facing HDMI, USB host and client connectors, etc. Now comes the zinger... the mothercard interfaces with the backplane data buss and it needs to look and feel like the existing CPU board (from the point of view of the other cards in the cage). The existing CPU board is self contained (CPU, RAM, PROM, EEPROM), except for two data strobes plus two ports of bytewide I/O. Things are easier if you want to always send a byte or always read a byte, but the bidirectional hardware to get bytes in to and out of the custom applications program might get tricky. One port is bytewide output-only and the other is a bytewide bi-directional port. One nibble of the first port is used as a 4-bit board select and the other nibble selects which data register on that particular board is to be accessed. Then a bytewide input / output port is used for the actual data transfer, by way of a write strobe or a read strobe that actually triggers the transfers of the data byte. The above can't be changed as we want the upgrade path for over 100 of these systems to be a simple case of having a non-techie walk up to the card cage, power it down, swap the CPU card, plug in the new RJ-45 cord, and power it back up. I know we can use two of the BBB GPIO bits through 5 volt drivers / buffers for the read and write strobes but how do I do the actual bytewide I/O ??? One possibility is bytewide I2C expander chips... The Microchip MCP23008 or MCP23S08 looks interesting. But before I go down that road I'd like to know if there is a better one. And I'd like to hear from anyone that has successfully done bytewide I/O, or has any suggestions on 5 volt level converters (unidirectional or bidirectional), or on a better clock / calendar chip, or i2c buss sensors for temperature, humidity and barometric pressure. The collective knowledge and experience of this group is impressive. Thanks in advance. Mike -- 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.
