I have an FPGA cape (the Blank Canvas Cape), and I've been able to successfully enable SPI via a device tree overlay, talk over SPI and I2C, and even program the cape eeprom to provide autoloading of my dtbo.
Right now my SPI only works in the MOSI direction; the master gets all zeros when reading from the slave. I'm pretty sure it's a problem in the DTO, but I don't yet know how to fix it. Ian On Jun 7, 2013, at 3:08 PM, Charles Steinkuehler <char...@steinkuehler.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 6/7/2013 1:31 PM, David Bagby wrote: >> Hi, >> >> We (Steve Stallings and I) would like to let you know about a >> gadget we’re expecting to bring to Wichita: The K9 SmorgasBoard. > > Looks like a great board, and something folks here have been asking for. > > Just a few comments: > > In writing and testing my PRU code, the difference between using any > random GPIO pin for a task and using a direct PRU output pin is not > really that great. Yes, writing to the GPIO ports is a bit slower > than the direct output, with greater latency from the write to the > output showing up and more jitter, but when outputs are being updated > by a PRU task that is cycling every 1-10 uS, having about 100 nS > additional latency and a few 10s of nS of extra jitter isn't so bad. > For software step-gen, I don't think it matters which I/O pins you pick. > > My existing code is totally flexible on I/O pin assignment, you can > pick any GPIO from any of the 4 banks, and any native PRU output pin, > all by changing a hal parameter for that pin. So you can use anything > I've written to date with your board as long as you craft an > appropriate device tree overlay to get the pin muxing setup. > > I don't have anything (yet) that talks to any SoC hardware besides the > PRU and GPIO (ie: ADC, I2C, PWM, SPI, etc), and I don't even think TI > has drivers for the encoders (at least I didn't see them in the > device-tree overlay for the counters, where I would have expected them > to show up). Some of this is easily handled by user-mode code (ie: > ADC, I2C), but HAL drivers for PWM and the encoders is currently left > as an exercise for the reader. If I get my 3D stuff going, however, > you could probably talk me into helping! :) > > If you have any specific pinouts setup already, I can help with > crafting a hal_pru_generic configuration that will match up with your > board. The HAL configuration is _hopefully_ easy to understand, but > there's currently no documentation beyond the source code (it's on the > list, and will get done prior to the next SD card image release). > > Keep us posted! > > - -- > Charles Steinkuehler > char...@steinkuehler.net > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlGyL64ACgkQLywbqEHdNFyrqACgrcUPVciBKIBZp0D9zwT+nHQm > bkUAoKoeWKrDJxP3qslXyo008okkYtlE > =yveN > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
