Longmove in spin
Anyone can explain me a little why the longmove(@cs, @cspin, 4) is used and how that relates to the pins that get assigned at the start.
I set my pins too 15, 12, 14, 13
isn't it easier to just write directly to a pin?
`
var
long cs ' chip select
long clk ' clock
long mosi ' master out slave it (to MCP3208)
long miso ' master in slave out (from MCP3208)
pub start(cspin, clkpin, mosipin, misopin)
stop
longmove(@cs, @cspin, 4) ' copy pins
outa[cs] := 1 ' output high (disable)
dira[cs] := 1
outa[clk] := 0 ' output low
dira[clk] := 1
`
Comments
The longmove is a more compact/efficient way to copy a set of long variables to another set of long variables.
longmove is given three parameters, the first parameter is the address pointer of the destination long variable(s), the second parameter is the address/pointer of the source variable(s), the third parameter is the number of longs to be copied.
Note: In order for this copy method/style to work, the source variables need to be consecutive in memory, likewise for the destination variables.
Instead of doing the longmove, you could do this instead:
Your code snippet appears to be from one of the drivers for the MCP3208 ADC. I believe that driver includes the use of PASM code, which needs to have the four pin parameters passed to it. So the driver has the set of pin values copied to another set of longs to be passed to the PASM routine.
Hopefully the above answers your question.
Yes, thanks a lot for replying, and yes you are correct about the MCP3208.
I am editing it to read from 3 consecutive 3208s in one pass.
All the best to you
No, it's a simple Spin1 driver, but I do need to save the pins so they can be used by the readx() method (see attached).
You could just use three copies of the driver with shared SCLK, MOSI, and MISO pins -- THE CS pins would be unique to each (six pins total for 3x chips). Then you could put a simple method like this in your application:
This reads three consecutive devices in one pass without having to create an entirely new object. SPI bus pins, other than CS, are designed to be shared.
You could also create a macro method that treats your three 8-channel ADCs as one 24-channel ADC.
The point here is that a we should use methods to cover specialty cases when a generic object handles the heavy load.
Thanks for your reply Jon,
Actually I like this idea, not sure exactly of the code requirement as I am not so familiar with spin. Basically just changing the chip select according to channel sets required. This would then be infinitely scalable.
No clue why the case ch 0..7 etc.. ended up outside the code block, maybe Monday morning blues :-)
then continue with the usual readx code.
I also to make the code less complex set the mux with a simple addition 24 to the value of the channel
mux := 24+ch
Then the result can be stored in arrays by ch,
Jon, if the array is based on longs will those values be available to other cogs.
say for example
As I stay thinking, the registers are 32 bits wide I understand and and we only use 12 bits. Almost worth using a register to store two channel value in bits 0-17 and 18-31, of course that would also get messy with 3 ADC's. With 4 it would be neat but I wonder with the additional code if anything would be saved.
Andy,
For block code, use three backticks on a line by itself (before and after the code)
code here
(I added spaces in between the backticks just for illustrative purposes; there shouldn't be any spaces between them when you use them)
Cheers
EDIT: nevermind... it interprets it anyway. Imagine these are backticks:
'''
code
'''
Really? This is the output I get doing the proper mux calculation (2nd column) vs your "less complex" version (3rd column).
No, it isn't. If you next decide you want a 32-channel ADC object, you need a new object with another start() method parameter for the new CS pin. If you use the method I shared above, then it doesn't matter how many channels you have; you can scale that method as required and use pin constants from your application.
I think it's a waste of time creating a 24-channel version, but if you're going to do it, I suggest the read() method do something like this. Of course, you would have passed the individual chip select pins through the start() method.
Note that the proper calculation of mux truncates unused bits that your mux := 24 + ch does not. And, FWIW, even if you did this (which would work):
...it's not as obvious to newcomers using your code what's going on. Code should always be easy to understand. The compiler sees 24 and %11000 as the same thing, but using binary notation and named constants will help new people when the look up the mux bits
I tried that, but actually it does not always appear to work, maybe a firefox thing I get smiley faces instead.
It took
Thank you for the input.
In the end I will just have an object that loads the values from the ADC's into arrays, it is all I want to do with it.
Like GetADCValues, how I share the array values to other cogs I have no idea yet but will find how to do that too. This is what I was doing for a few minutes:
Fader=0 CS=1 Channel=0 MUX=11000
Fader=1 CS=1 Channel=1 MUX=11001
Fader=2 CS=1 Channel=2 MUX=11010
Fader=3 CS=1 Channel=3 MUX=11011
Fader=4 CS=1 Channel=4 MUX=11100
Fader=5 CS=1 Channel=5 MUX=11101
Fader=6 CS=1 Channel=6 MUX=11110
Fader=7 CS=1 Channel=7 MUX=11111
Fader=8 CS=2 Channel=0 MUX=11000
Fader=9 CS=2 Channel=1 MUX=11001
Fader=10 CS=2 Channel=2 MUX=11010
Fader=11 CS=2 Channel=3 MUX=11011
Fader=12 CS=2 Channel=4 MUX=11100
Fader=13 CS=2 Channel=5 MUX=11101
Fader=14 CS=2 Channel=6 MUX=11110
Fader=15 CS=2 Channel=7 MUX=11111
Fader=16 CS=3 Channel=0 MUX=11000
Fader=17 CS=3 Channel=1 MUX=11001
Fader=18 CS=3 Channel=2 MUX=11010
Fader=19 CS=3 Channel=3 MUX=11011
Fader=20 CS=3 Channel=4 MUX=11100
Fader=21 CS=3 Channel=5 MUX=11101
Fader=22 CS=3 Channel=6 MUX=11110
Fader=23 CS=3 Channel=7 MUX=11111