Hi, The servo control sounds like a job for the PRU. PRU I/O is also suitable for interfacing OV7670. Here is a rough but working example for Beaglebone White: https://github.com/dinuxbg/pru-gcc-examples/tree/master/ov7670-cam/pru . Note that the example loader uses Linux and uio_pruss driver instead of Starterware.
Regards, Dimitar понеделник, 27 април 2015 г., 16:28:40 UTC+3, Bill M написа: > > Greetings all, > > > I'll apologize for the big lead up, I just want everyone to know where I'm > coming from. I also apologize if I posted this to the wrong place or > reposted it. I'm new here and still finding my way around. > > > I am considering getting a BBB to use with my Robotis robot kit to replace > the CM-5 and CM-530 I've been using, and was hoping people here could give > me help/advice/guidance, or direct me to those who can, as I have a million > questions. I will start to list them here. Any help greatly appreciated in > advance. > > > I've already written firmware for both the CM-5 (which is Atmega128 > powered) and the CM-530 (which uses an STM32F103, an ARM Cortex M3), You > can see the source for these here: > http://sourceforge.net/projects/bioloidfirmware/ Obviously these are bare > metal firmware given that the extremely limited platform in both cases > couldn't practically support an OS. I would like to port my code to the > BBB. I want to stick with the bare metal approach, so I can go real time > without having to use a patch for the OS or Xenomai, and since I won't be > interested in a good part of the functionality of the board initially (also > I'm kind of a big Linux noob). I have already downloaded StarterWare and > started poking around. The big draw for me to BBB is the processor clock > speed (the CM-5 is just 16Mhz, the CM-530 not much better at 72), the huge > memory (for the controllers I'm using now, we're measuring in Kb), and the > huge number for GPIOs (the CM-5 has none, the CM-530 only has a few). So > here are some of my initial questions: > > > •Is anything special required to use the full 512MB memory? In other > words, can I directly address all the available memory without having to go > through any special procedures? Could I theoretically declare a really big > structure (iike a MB or 2) or array and be able to handle it in code like I > always have? > •With the code I've written thus far, the servos are updated 128 times a > second. I have everything for doing that interrupt driven. I have a timer > fire an interrupt every 8ms that calculates the next servo target positions > and creates a packet to put in a buffer that feeds the shift register of > the serial bus. The serial bus is also interrupt driven. When the buffer is > loaded, an interrupt is enabled that fires whenever the shift register is > empty. Every time it fires, it loads the next byte from the buffer. If the > buffer is empty, it disables the interrupt. Receiving bytes is handled > similarly, firing an interrupt every time a byte is received to put it in a > buffer and empty the shift register. This allows the packets to be consumed > as quickly as the 1Mb serial bus can consume them. Could I do something > comparable on the BBB? > •My third, and heaviest question, is one of the main motivators for > considering the BBB (and moving away from the above mention controllers). I > would like to get into vision processing, so I would like to hook a camera > (maybe two) to the BBB. I don't want to use the camera cape (since I want > to be able to position the camera somewhere else on the robot). Could I use > something like the OV7670 hooked up to some GPIO pins? I was thinking > something along the lines of having one pin output a clock to the camera > (along with a pin for power and ground), and then have an input pin for the > HREF, VSYNC, and pixel clock, and have the pixel clock pin set to fire an > interrupt that would read the input pins that D0-D7 from the OV7670 are > connected to and push them into a big buffer in memory. I figure for a 640 > x 480 RGB565 image at 15 FPS, it would be about 9MB a second, and even if > every byte was taking 20 to 30 clock cycles to handle (I think each > interrupt could be handled much more quickly than this), it would only eat > up at most 200Mhz a second (I've seen some posts talking about using the > PRU for doing this). Does this sound totally off the wall? What would I > need to interface the pins from the camera to the BBB GPIO pins? > > I apologize for the long windedness of this. Like I said, I'm not really > sure even where to start, or how applicable what little experience with ARM > I already have is to this. Again, any help appreciated! > -- 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.
