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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can adjust the incoming data any way you want once you get it, what would be the point of sending custom widths? If you have less than 8 bits of data send you 0 pad it, the receiver needs to expect the zero padding but that's a protocol issue even if you set custom bit widths both transmitter and receiver would need to know about it, if they already know about it why not use the standard 8 bit width with the zero padding? I seriously think you guys are discussing a problem which doesn't exist. 20 bits? Sure no problem, send two 8 bit bytes zero pad the 4 bits send it and your reciever is happy.
You are assuming that he is writing the programming for both master and slave. The point of custom widths is that there are SPI slave devices like ADC's that have odd bitwidths to send or receive, and sending blank data makes no sense, since bus traffic is important. If he's writing code for both master and slave, then just sending padded data is fine.
I assumed the original poster was interfacing with a slave device he did not write code for, because interfacing two uC's with SPI seems like a waste of pins and his question seems to answer itself if he has control of both ends.
The Master Synchronous Serial Port (MSSP) module is
a serial interface useful for communicating with other
peripheral or microcontroller devices. These peripheral
devices may be serial EEPROMs, shift registers,
display drivers, A/D converters, etc. The MSSP module
can operate in one of two modes:
You have enlightened me, it is my clarity or lack there of that may have caused the initial confusion Sciadwian was speaking of.
I am looking at communicating with a special IC that uses SPI protocol.
The 16f88 will be the master and the special IC is the slave.
Only, the special IC's opcode and opcode parameters that are tx'd/rx'd are a total of 20-bits long.
To make the SPI data be 5 bits and sending 4 lots sounds groovy too!
but I'm not sure if this chips SPI module allows this, must investigate.
I am keen to check out those uC's that do.