soft spi assembler code 20-bit opcode+address tx/rx data length
Greetings bit bangers,
My query deals with bit banging 20 bits via spi protocol through soft-spi as the pic16f88's hardware-spi module ony does 8bits.
Any suggestions and/or pointing in the right direction would be greatly appreciated.
SPI is super easy to bit-bang once you understand how it works. It is a very simple standard.Originally Posted by Mechatron3000
That's a really confusing post... If it only does 8 bits at a time you send two bytes to get 16...
"Because I be what I be. I would tell you what you want to know if I
could, mum, but I be a cat, and no cat anywhere ever gave anyone a
straight answer, har har."
Thanks futz,SPI is super easy to bit-bang once you understand how it works. It is a very simple standard.
I am somewhat familiar with SPI protocol, only thing is, its an 8 bit PIC and its 5bit op code followed by 15 bit opcode parameters. which means 20 nasty bits of binary action.
I have concluded the best way about this is to
a) send op code but limit loop (shifter) to five bits, disregarding the rest of the byte
then
b) split the opcode parameter into 2 bytes disregarding the last bit
does this sound like a plan set for success?
Just transmit the first 16 bits normal, the last 4 you would zero pad the four unused bits there and just have your receiver code drop the last four bits on reception. I doubt you're going to miss 4 bits worth of bandwidth on an SPI bus.
"Because I be what I be. I would tell you what you want to know if I
could, mum, but I be a cat, and no cat anywhere ever gave anyone a
straight answer, har har."
Not confusing at all. He wants to send 20 bits at a time - not 16. SPI can be easily written to send any number of bits in a packet. Some of the hardware SPI units, especially in the smaller MCUs, are somewhat inflexible that way, so bit-banging is the only way to go.
It's not the only way to go, in fact I think it would be a criminal waste of MCU resources. Just send all 24 bits, zero pad the 20 bit data and drop the last 4 bits on reception. Trying to eck out an exact packet size is a waste of time. There are no 20 bit registers so he's already either using zero padded data or he can mask them out on the send side.
Last edited by Sceadwian; 3rd April 2009 at 02:58 PM.
"Because I be what I be. I would tell you what you want to know if I
could, mum, but I be a cat, and no cat anywhere ever gave anyone a
straight answer, har har."
Yeah, as I am new to this forum format my lingo and expression of technical matters requires refining.
I understand that 2 x 8 equals 16. The issue I have is that I am to send 20 bits and then receive 20 bits.
16 does not equal 20, nor does 24 or 32.
can you guide me in the right direction please?
That'll work too.I'm a criminal. I waste resources all the time. There's more there than I need anyway.
Is this solution via the hardware SPI?
I like this forum stuff, it's the ultimate in real time peer review!
That's what he's suggesting. It'll work fine. I've done it that way too.
Last edited by futz; 3rd April 2009 at 03:07 PM.
I have chips without SSP or MSSP so your way would rock and roll in all cases. I gather, unless I am in a resource critical situation, it would be even stevens. Many thanks for your respective times and suggestions.
That only works if he has access to both master and slave. Some slaves require odd addressing schemes.
I'm surprised the PIC does not have a bit transfer number selection in it's hardware SPI. Usually SPI blocks will let you select the number of bits to send/receive per transfer. So for an 8 bit MCU you would cut it down to 5 and do 4 transfers for a 20bit value. I've had to do two 5bit transfers for 10bit addressing with a hardware slave.
EDIT: sorry, I'm confused with sending op-codes and crazyness. I'm assuming he's talking to a hardware SPI slave that requires 20bit addressing/data, but it looks like that's not the case.
Last edited by DirtyLude; 3rd April 2009 at 03:56 PM.
Mark Higgins
That's what I was kind of getting at. If his SPI target device can't live with the extra 4 bits then bit-banging is going to be necessary. But if it will ignore them, or can be programmed to ignore them, then hardware SPI would be fine.
The ARMs (and, I assume other bigger MCUs) allow varying numbers of bits per transfer (ARM7 allows any number from 8 to 16 bits per transfer), but smaller MCUs like PICs/AVRs aren't so flexible.
In my example of a 10 bit transfer I'm using an 8 bit uC. My 8 bit uC allows an adjustable 1 thru 8 bit transfer select. (Z8 Encore). If I was using an ARM, the SAM7 allows 8 through 16 bit transfers, so I would have just used a single 10 bit transfer. I would have thought at least the AVR would have had an adjustable transfer length, but I guess not.
Mark Higgins
Reply With Quote
