Thank you Troy, The device is ads1218. In datasheet in timing specification diagram the CS line is set low all the time - maybe this is not necessary, i will try. I tried to use one of gpio for the CS line and this solved the problem, but this is not so elegant...
Regards Klemen ________________________________ From: Troy Jacobson <[email protected]> To: Klemen Dovrtel <[email protected]>; Enhanced Machine Controller (EMC) <[email protected]> Sent: Tuesday, October 8, 2013 5:25 AM Subject: Re: [Emc-users] OT: BeagleBoneBlack - SPI I've been experimenting with SPI here as well, and was able to read the MAX31855 thermocouple interface. I don't have my BBB running currently, so I'm going a bit from memory here and doing my best to interpret the C code in from the python SPI module. The module isn't well documented, as you probably realize by now. I'm also assuming that you're not seeing inconsistent behavior on the CS line that would indicate a pin conflict or misconfiguration. Unfortunately, I don't have an answer for how to keep the CS asserted the whole time. That being said, I have to inquire if that is really necessary. First, the device being used may not require it. Second, if there is only one device on the bus, then the pin could be permanently pulled high, or set by software some other way. I believe that the cshigh method is a configuration setting for whether or not the CS line is active high or active low. >From the code, it looks like the xfer methods are used to send multiple >multi-byte messages. The code talks about the behavior of the CS line between >blocks, and I don't think that blocks==bytes here. Pass in a list of two >lists and see what happens with the CS line. Troy On Mon, Oct 7, 2013 at 2:09 AM, Klemen Dovrtel <[email protected]> wrote: Hello everybody, > >I am testing the BBB and spi. I set up the spi port and installed the spi >library as described at hipstercircuits >(http://hipstercircuits.com/enable-spi-with-device-tree-on-beaglebone-black-copy-paste/). > Now I would like to test a simple data exchange - send two bytes and after a >small delay read two bytes. The CS should be asserted during the whole data >exchange. The problem is that i can not force CE to be asserted the whole time. > >I sent the data using spi.xfer2, but after that the CE was de-asserted. I >tried to keep the CE asserted with spi.cshigh after the spi.xfer2, but this >still leaves a small glitch on CS line. Can someone please suggest how can i >control the CS line as required? > >BTW, i also noticed that there was no difference between spi.xfer and >spi.xfer2 even though the spi.xfer should send an array of bytes de-asserting >and re-asserting the CE with every byte - i could not see the CS de-asserting >and re-asserting with the oscilloscope. > >Best Regards >Klemen >------------------------------------------------------------------------------ >October Webinars: Code for Performance >Free Intel webinars can help you accelerate application performance. >Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >the latest Intel processors and coprocessors. See abstracts and register > >http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >_______________________________________________ >Emc-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/emc-users > > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
