mcp3202 spi on 28x1 HELP !!!!!
- Thread starter marky26uk
- Start date
demonicpicaxeguy
Senior Member
have a good read of the data sheet for the adc
it's a fairly simple one to interface to,
i'd be tempted to bit bang it using shift in/shift out
page 14 of the microchip data sheet is probably a good start
failling that i'm sure one of us could knock up some code for it
Edited by - demonicpicaxeguy on 25/06/2007 11:40:31
it's a fairly simple one to interface to,
i'd be tempted to bit bang it using shift in/shift out
page 14 of the microchip data sheet is probably a good start
failling that i'm sure one of us could knock up some code for it
Edited by - demonicpicaxeguy on 25/06/2007 11:40:31
demonicpicaxeguy
Senior Member
i haven't gotten hold of a 28x1 yet but i'll see what i can dig out code wise
demonicpicaxeguy
Senior Member
ok from what i can tell you'll need to use the spi mode that samples the input after the clock goes low and idle low
but here's the general gist of what need to happen - yes before anyone points it out
it this is a bad coding method i should use a loop.. but for testing puposes
<power on>
low cs
high dataout 'start bit
high clock
low clock
high dataout 'slg/diff bit
high clock
low clock
high dataout 'odd/sign bit
high clock
low clock
high dataout 'msbf bit
high clock
low clock
high clock 'null bit
low clock
bit11 = datain
high clock
low clock
bit10 = datain
high clock
low clock
bit9 = datain
high clock
low clock
bit8 = datain
high clock
low clock
bit7 = datain
high clock
low clock
bit6 = datain
high clock
low clock
bit5 = datain
high clock
low clock
bit4 = datain
high clock
low clock
bit3 = datain
high clock
low clock
bit2 = datain
high clock
low clock
bit1 = datain
high clock
low clock
bit0 = datain
high clock
then after that i think it's back to the top again
should work but you'll need to change the code to the correct pins.
but here's the general gist of what need to happen - yes before anyone points it out
it this is a bad coding method i should use a loop.. but for testing puposes
<power on>
low cs
high dataout 'start bit
high clock
low clock
high dataout 'slg/diff bit
high clock
low clock
high dataout 'odd/sign bit
high clock
low clock
high dataout 'msbf bit
high clock
low clock
high clock 'null bit
low clock
bit11 = datain
high clock
low clock
bit10 = datain
high clock
low clock
bit9 = datain
high clock
low clock
bit8 = datain
high clock
low clock
bit7 = datain
high clock
low clock
bit6 = datain
high clock
low clock
bit5 = datain
high clock
low clock
bit4 = datain
high clock
low clock
bit3 = datain
high clock
low clock
bit2 = datain
high clock
low clock
bit1 = datain
high clock
low clock
bit0 = datain
high clock
then after that i think it's back to the top again
should work but you'll need to change the code to the correct pins.
hippy
Ex-Staff (retired)
When the PICAXE Project Showcase site is up and running, that would make an ideal repository for interfacing code examples for various peripherals.
Ideally example code would be perfect, well tested and beautifully crafted and commented, but anything is useful in comparing datasheets to what people have done in reality.
I cannot see why such example code shouldn't be collated and form "PICAXE Manual 4 - Advanced Interfacing Code Examples" in PDF form and delivered with the Programming Editor. Getting one's name/moniker 'in print' should be a good reward to anyone taking the time to contribute.
A mechanism to be able to flag code that has been tested and confirmed to work by others would be very helpful.
Ideally example code would be perfect, well tested and beautifully crafted and commented, but anything is useful in comparing datasheets to what people have done in reality.
I cannot see why such example code shouldn't be collated and form "PICAXE Manual 4 - Advanced Interfacing Code Examples" in PDF form and delivered with the Programming Editor. Getting one's name/moniker 'in print' should be a good reward to anyone taking the time to contribute.
A mechanism to be able to flag code that has been tested and confirmed to work by others would be very helpful.
demonicpicaxeguy
Senior Member
is there any update on how that is going technical?
Hi all, this is what i have done so far:-
init:
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00000001)
hspiout (%10100000)
hspiin (bit11,bit10,bit9,bit8,bit7,bit6,bit5,bit4,bit3,bit2,bit1,bit0)
high 7
debug
goto main
Getting something out of it but it's not correct, this is proving to be ridiculous, why is this so difficult lol (i must laugh to stay sane)
Any ideas ?
Cheers,
Mark
init:
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00000001)
hspiout (%10100000)
hspiin (bit11,bit10,bit9,bit8,bit7,bit6,bit5,bit4,bit3,bit2,bit1,bit0)
high 7
debug
goto main
Getting something out of it but it's not correct, this is proving to be ridiculous, why is this so difficult lol (i must laugh to stay sane)
Any ideas ?
Cheers,
Mark
Marky26,
I may be wrong, but I don't think the hardware implementation of the SPI will work for you. There appears to be a byte Out and a byte In, but one of the big advantages of SPI is that it can send a byte and also receive a byte in the same byte timeframe. This gives SPI some added speed capability.
For the MCP3202, this is important. When the the second byte is output, the PICAXE should also be reading as these are the four most sig bits of the A/D result.
As I say, I may be wrong, but I don't think the 28X1 has this functionality.
My bit bang SPI_IO will work correctly. More code and slower.
PHA - http://www.phanderson.com
I may be wrong, but I don't think the hardware implementation of the SPI will work for you. There appears to be a byte Out and a byte In, but one of the big advantages of SPI is that it can send a byte and also receive a byte in the same byte timeframe. This gives SPI some added speed capability.
For the MCP3202, this is important. When the the second byte is output, the PICAXE should also be reading as these are the four most sig bits of the A/D result.
As I say, I may be wrong, but I don't think the 28X1 has this functionality.
My bit bang SPI_IO will work correctly. More code and slower.
PHA - http://www.phanderson.com
Hi all again,
I've got it working, not really sure how but it's working, the only thing is that i can only read from 1 channel, i can't get it to read from both.
Here is my code :-
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00000001)
hspiin (b1,b0)
high 7
debug w0
goto main
I've got it working, not really sure how but it's working, the only thing is that i can only read from 1 channel, i can't get it to read from both.
Here is my code :-
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00000001)
hspiin (b1,b0)
high 7
debug w0
goto main
This device should work with the hspi port, but is indeed tricky to use. You must study page 13 and page 15 of the Microchip datasheet carefully. Page 15 explains the issues with a fixed 8 bit SPI hardware port (as with PICAXE / PICs).
As defined on page 15 you need to hspiout two bytes to get the device started, in this exact format (figure 6.1)
hspiout (%0000000S, %XYZ00000)
where S = 1 = start bit
where X = sgl/diff bit
where Y = odd/sign bit
where Z = MS BF bit
you then hspiin in two bytes (e.g b0 and b1), which (between them) will contain the 12 bit result of a single channel. The 12 bit result will actually be 'padded' to 16 bits with 0's at the start or end, as defined by the MS BF bit (Z above). As Prof Anderson points out, the first hspiin byte in does occur at exactly the same time as the transmission of the second byte, but the internal PIC module actually automatically handles this for you.
The actual channel read and mode is defined by the other two bits (X and Y above)
As defined on page 15 you need to hspiout two bytes to get the device started, in this exact format (figure 6.1)
hspiout (%0000000S, %XYZ00000)
where S = 1 = start bit
where X = sgl/diff bit
where Y = odd/sign bit
where Z = MS BF bit
you then hspiin in two bytes (e.g b0 and b1), which (between them) will contain the 12 bit result of a single channel. The 12 bit result will actually be 'padded' to 16 bits with 0's at the start or end, as defined by the MS BF bit (Z above). As Prof Anderson points out, the first hspiin byte in does occur at exactly the same time as the transmission of the second byte, but the internal PIC module actually automatically handles this for you.
The actual channel read and mode is defined by the other two bits (X and Y above)
Hello again,
Technical is the mcp3202 definitely compatible with the hspi on picaxe 28x1 ?
My code is :-
init:
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00000001,%10100000)
hspiin (b0,b1)
high 7
debug
goto main
This is just not working properly, the value is all over the place as if some bits are going where they shouldn't be, am i missing something ?
Mark
Technical is the mcp3202 definitely compatible with the hspi on picaxe 28x1 ?
My code is :-
init:
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00000001,%10100000)
hspiin (b0,b1)
high 7
debug
goto main
This is just not working properly, the value is all over the place as if some bits are going where they shouldn't be, am i missing something ?
Mark
Even though you are not using PHA555's bit-banging code for SPI, you should read his article. It has a good explanation of the bits that are received and why your data might look a little wonky. My guess is you should be ignoring a few of the bits.
http://www.phanderson.com/picaxe/spi.html
http://www.phanderson.com/picaxe/spi.html
Hi, i have sorted this hspi problem, well a chap i know (Pete) from work helped me out.
Here's my code incase it's useful to anyone else:-
init:
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00001101) ' CH0
hspiin (b1,b0)
high 7
w0=w0/8
low 7
hspiout (%00001111) ' CH1
hspiin (b3,b2)
high 7
w1=w1/8
debug
goto main
It turns out i wasn't shifting the 3 bytes that had zero's in them, dividing by 8 sorted it out.
Works like a dream,
Mark
Here's my code incase it's useful to anyone else:-
init:
hspisetup spimode00, spimedium
main:
low 7
hspiout (%00001101) ' CH0
hspiin (b1,b0)
high 7
w0=w0/8
low 7
hspiout (%00001111) ' CH1
hspiin (b3,b2)
high 7
w1=w1/8
debug
goto main
It turns out i wasn't shifting the 3 bytes that had zero's in them, dividing by 8 sorted it out.
Works like a dream,
Mark
