> I was wondering if the problem described in the thread "problem with > converting from at91_spi to atmel_spi (AT91RM9200)" from last May > was ever solved, as I'm currently running into the same trouble. > at91_spi works nicely with an at25-driven EEPROM on CS0, but atmel_spi > doesn't - it just blocks whatever thread is using it.
Andrew Victor had partial success after updating the platform setup code appropriately. I don't know what the status of that patch is. > While that's no problem in the EEPROM case, a customer wants to use > SPI basically as a very fast UART between two AT91RM9200 based boards > now, on which only CS0 is available. Is there no other chance than > converting the layout to use another CS instead? Unfortunately CS0 on rm9200 seems especially full of trouble; from what I've seen and heard, using another chipselect would be good just on the basis of the number of CS0-specific errata. Of course, if you just want UART-ish behavior, you might also be able to use one of the SSC channels. The SPI stack aims to handle master/slave style communication, not peer-to-peer. When you're modeling a bidirectional byte stream, that's the wrong model. Plus, you'd have fewer chip errata to cope with. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
