In that case I assume that SPI would have the best drivers given that it's the "official" serial interface for the RPi?domesday wrote: But at the end of the day I think for the proposed application that is to read sensors on a robot arm I believe then there is little to choose between them other than how well implemented the OS drivers are.
Take a look at the bottom of this diagram of the GPIO connector.morphy_richards wrote:If you are saying I don't need to worry about the clock and "DIN", as the kernel provides them, then how do I do the manual wiring up bit? Surely there needs to be a clock input from, somewhere on the Pi, but where does it come from? And if it's part of the Pi's SPI (Or A2D if I use that method) how do I seperate it out to feed to the appropriate pin?
Looking at the pin layout for a ADS7830 I see 2 pins, A0 and A1 which in the data sheet are tied to ground. I see these are referred to as "slave address". Would these be what you are referring to? You can use these to set up to 4 "slave addresses" for this particular model.Gert van Loo wrote: The part where I am rather unhappy with is the I2C identifier system. What I read from it, it is rather broken in that most of the devices your are dependent on the ID set by the manufacturer. You can add one or two ID bits but that is it. There are some 'agreement' on I2C device types but that seem rather ad-hoc.
Yes and no I briefly read the posts above and I assume that you are talking about the SPI interface. Chip select in SPI terms really physically uses one dedicated line/signal/pin for each slave device. So with two pins you can select two different slave devices. What you are suggesting can of course be done but you need some logic circuits connected after these two pins then to make your binary math stuff. Secondly you'll definitively would need to change the SPI driver in the linux kernel so that it would be aware of your new number of available "chip select pins". But if you really want to go there then it is probably easier to use some of the other GPIO pins as chip select. Again that would probably mean that the SPI driver needs some work.domesday wrote:I would imagine that the 2 slave address pins could be configured to give 4 distinct addresses, as they will be binary selectors i.e numbers 0,1,2,3.
Some I2C devices provide for additional address bits by allowing more than two options for the address input on the device: for example, the address input might be left floating OR connected to ground OR connected to the supply rail. Another variant I have seen is to allow the address inputs to be connected to I2C SDA OR SCK OR ground OR supply.domesday wrote:I would imagine that the 2 slave address pins could be configured to give 4 distinct addresses, as they will be binary selectors i.e numbers 0,1,2,3.
I think this is some misunderstanding. Bypass caps of this caliber are usually applied to the power supply pins of a device. In this case maybe also the Vref pin. In your case, with very slowly changing values, using 1uF caps on the analogue inputs will probably not hurt anything, and may indeed help with filtering out transients, but be aware that they will affect measurement of even moderate frequency signals. To what degree will depend on the signal source impedance and frequency.morphy_richards wrote: Firstly, for the analogue inputs on pins 1 to 8 the datasheet recommends using a 1uF bypass cap (which I've added on my diagram, is that correct with them tied between the input and ground like that? Secondly, given that the values I'm using are going to be changing very slowly... glacially slow in fact, are they even necessary?)
Users browsing this forum: No registered users and 8 guests