AVR Freaks

I suppose with something like an SPI you could do something like connecting MOSI to MISO if bit length really were configurable between 1 and 8 bits (not tiny/mega but some other designs) but what does that really buy you? You send out 5 bits (or whatever) to then have the same 5 come back in. Wouldn't an AND with a 0x1F bit mask have been easier? Forget the SPI.

But that's still byte-wise, not bit-wise isn't it? OP mentioned using the hardware to create a "bitstream".

The CPU still deals in bytes, yes. But the bytes are just convenient containers for the bitstream visible on the MOSI pin.

Steve

No, these interfaces just do the shifting in hardware straight to the output pin - the bit stream is not available to software.

ADDENDUM

In assembler, you can just shift & pick the next bit from the Carry flag

https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_LSL.html

https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_LSr.html

Even if you did something like wiring MOSI and SCK from an SPI back into two input lines so you could "see the bits" you still have no way to say "next bit" or "next 3 bits" or whatever. It's always going to be a case of "next 8". So in that case how does:

uint8_ buff[N];

...
  SPDR = buff[n];
  // grab the bits on IO
  bits = receive8();

actually help in any way? You might as well have just done:

bits = buff[n];

Anyway the nextbit() you propose is hardly rocket science:

uint8_t buff[N];

uint8_t nextbit() {
    static int idx = 0;
    static int bitpos = 0;
    uint8_t retval;
    
    retval = buff[idx] & (1 << bitpos);
    bitpos++;
    if (bitpos > 7) {
        bitpos = 0;
        idx++;
        if (idx > N) {
            // signal end of data somehow?
        }
    }
    return retval;
}

In that I increment bitpos so it will deliver buff[0].0, buff[0].1, buff[0].2 .... buff[0].7, buff[1].0 and so on. If it were preferred to have the bits "from the top down" as buff[0].7, buff[0].6, buff[0].5 .. buff[0].0, buff[1].7 then:

uint8_t nextbit() {
    static int idx = 0;
    static int bitpos = 7;
    uint8_t retval;
    
    retval = !!(buff[idx] & (1 << bitpos));
    bitpos--;
    if (bitpos < 0) {
        bitpos = 7;
        idx++;
        if (idx > N) {
            // signal end of data somehow?
        }
    }
    return retval;
}

Obviously this could all be optimised! Was it the performance of this code you were concerned about? I agree the 1 << bitpos in:

    retval = buff[idx] & (1 << bitpos);

is expensive. In which case:

uint8_t nextbit() {
    const __flash uint8_t masks[] = { 1, 2, 4, 8, 16, 32, 64, 128 };
    static int idx = 0;
    static int bitpos = 0;
    uint8_t retval;
    
    retval = buff[idx] & masks[bitpos];
    bitpos++;
    if (bitpos > 7) {
        bitpos = 0;
        idx++;
        if (idx > N) {
            // signal end of data somehow?
        }
    }
    return retval;
}

As I say I just scribbled this - no thought to optimisation.

I knew I'd seen some chips from Atmel with SPI that had variable bit length. Finally found it lurking in a UC3 datasheet...

But this still just has 4..8 bits going out to come back in again (assuming loopback wiring) so achieve nothing. At the time of Tx you know whether you just set it to send 5 or whatever (and it can't be shorter than 4 anyway).

If you feel the need for speed you can do horrible things in assembler and abuse the hardware.

A few years ago I needed to generate a video waveform. The chip (an original 90S2313) had a maximum speed of 10MHz, which meant I had exactly 4 clock cycles to update the output pin. Using the SPI was not an option as it didn't have one.

So I precomputed the output buffer of 12 bytes/96 bits and had a routine that wrote a register to a whole 8-bit port, on which only the bottom bit was used as the output pin. My output code was then 8 copies of this...

	out	video_port,reg_1	;[1] pixel 2
	lsr	reg_1			;[1]
	nop				;[1]
	nop				;[1]

...one for each bit. I still needed to manage the loop overhead and updating of the buffer pointer so all that code went into the two NOPs on each bit output giving me 16 cycles spread about the place to handle the overhead. Something like this...

do_it:
	ldi	counter,12		;[1]
	ld	reg_1,Y+		;[2]

_101:
	out	video_port,reg_1	;[1] pixel 0
	st	Z+,reg_1		;[2] save pixels into repeat buffer
	lsr	reg_1			;[1]
	out	video_port,reg_1	;[1] pixel 1
	lsr	reg_1			;[1]
	nop				;[1]
	nop				;[1]
	out	video_port,reg_1	;[1] pixel 2
	lsr	reg_1			;[1]
	nop				;[1]
	nop				;[1]
	out	video_port,reg_1	;[1] pixel 3
	lsr	reg_1			;[1]
	dec	counter			;[1] dec counter
	nop				;[1]
	out	video_port,reg_1	;[1] pixel 4
	lsr	reg_1			;[1]
	tst	counter			;[1] is counter zero?
	in	temp,SREG		;[1] save Z flag
	out	video_port,reg_1	;[1] pixel 5
	lsr	reg_1			;[1]
	bst	temp,1			;[1] move Z into T
	nop				;[1]
	out	video_port,reg_1	;[1] pixel 6
	lsr	reg_1			;[1]
	LD	temp,Y+			;[2] get next 8 pixels
	out	video_port,reg_1	;[1] pixel 7
	mov	reg_1,temp		;[1] put next 8 pixels ready
	brtc	_101			;[2/1] loop if not 12 times round
	nop
	video_low

The headache was that LSR affects all flags so doing any testing of counter values became 'interesting'.

So this technique could be used to make a rotate routine if you wanted to do something 'odd'.

The only reason I could see that a separate peripheral might help is if (a) the CPU were terrible at doing bit shifts (but it's not) and (b) something so CPU intensive is occurring (like video generation) that the CPU doesn't have even a handful of cycles for some shifting task.

Otherwise the CPU itself seems like the best designed "peripheral" in the entire chip for doing the job.

Write code that writes bytes into a buffer and can read back bit by bit. Example:

class BitStream
{
public:

	void writeByte(uint8_t b)
	{
		buffer[writeIndex++] = b;
	}

	uint8_t readBit()
	{
		uint16_t idx = readIndex++;
		uint8_t bufferIndex = (uint8_t)(idx / 8);
		return buffer[bufferIndex] & (1 << (7 - (idx % 8))) ? 1 : 0;
	}

private:

	uint16_t readIndex;
	uint16_t writeIndex;

	uint8_t buffer[16];
};

This is:

• Wildly inefficient
• Needs to be changed if you're going to use C
• Does not do any kind of error or bounds checking
• Does not care about overrun
• Should be re-done per your requirements
• Probably sucks, it was written in a few minutes

I'll leave those as a job for you to do.

I gave it a shot to type a bit more streamlined algorithm for you.

Here is what I came up with (untested):

class BitStream {
uint8_t buffer[ 16];
uint8_t bitIndex, byteIndex;

public:

void readInit( void) {
    bitIndex = 1;
    byteIndex = 0;
}

bool readBit( void) {
    bool bit;

    if( bitIndex & buffer[ byteIndex]) {        // Extract the bit.
        bit = true;
    }else {
        bit = false;
    }

    bitIndex <<= 1;                          // Recalculate indexes.
    if( bitIndex ){
        // Do nothing, still good.
    }else {
        // Overflow, Reinit parameters.
        bitIndex = 1;
        ++byteIndex;
        if( byteIndex > sizeof (buffer)) {
            byteIndex = 0;  // Oops, error, end of data, whatever. Prevent overflow.
        }

    }
    return bit;
}

};  // class BitStream

The idea to making it "fast" is not by using  less lines of code, but by only using constructs which can be easily translated by the C++ compiler to asm opcodes.

Using a few more lines to write your code on makes it a lot more easyer for "normal" humans to read & maintain the code.

Internally a "bool" is stored in a "byte".

You could benefit from using negative numbers.

For example not return a bool, but an int8_t you can code more information in your return type.

return 1;       // "true".
return 0;       // "false".
return -1;      // All bytes have been read, or error ...
return -3;      // We're gonne crash.

For real performance quantification you will want to look at the LSS output to verify the quality of the ASM code the compiler spitts out.

	ret = (curbyte & (1 << bitpos)) >> bitpos;  //selected bit will be in the LSB position

The second shift in that is expensive and unnecesasry. Try:

	ret = !!(curbyte & (1 << bitpos));  //selected bit will be in the LSB position