Bit-bashing experiment...

[Grogster]

Hi-de-hi.


First off, I have to ask: What actually IS bit-bashing?
I hear it being mentioned around the forums and in other technical documents, but I still don't know what it is, or what it does better then just a standard input or output pin.

Looking at the 4D SOMO module that WestAust55 kindly linked me to in another thread(http://www.picaxeforum.co.uk/showthread.php?p=113484#post113484), they even mention it in their product PDF: - although they refer to it as bit-banging...

All commands are composed of single word (16-bit) data that must be clocked into the module in a serial fashion. (MSB first) The clock-rate is approximately 2.5KHz which lends itself to even the slowest micro bit-banging two I/O ports to achieve this simple communication.

So, to get a head start while I wait for the SOMO module to arrive, I want to try to get a better grasp of what bit-bashing/bit-banging actually is, how it works, how you setup the PICAXE to do it etc.

For my first question on this thread: - If the clock interface speed of the SOMO module is about 2.5KHz, how do you translate that to a serout baud rate, and how do you actually send the commands on the data bus?

OK - two questions...

 

[BeanieBots]

I believe the more common term is "bit banging".
Say you wanted to put out a word using a single IO line.
You could use a serout command but that might not be possible and you might not want the start/stop or other bits that come with regular serial.

The alternative is to "bit bang" the word out.
You put the first bit of the word on the IO line, then pulse a another IO line which acts as a 'clock' to tell whatever you are sending to to read the data.
Then you put the second bit on the IO line and 'clock' that bit through.
And so on and so on until all your sixteen bits of the word have been 'clocked' out bit by bit.

 

[Grogster]

AHHHHHHHHHH

I comprehend.


So it's pretty much exactly the same concept as clocking a shift register as I was posting about in another thread - you put a high or a low on the PICAXE output pin to represent the data bit from the word you want to send(8, 16, 32 - whatever), clock the shift register with a pulseout command, put the next bit on the data line, clock the register, put the next bit on the data line, clock the register...

Sounds like that is exactly the same concept, if I understand things correctly now.

How do you go about calculating the clock-speed then for this kind of thing?

 

[hippy]

Yep, that's it. As to clock speed, that comes down simply to how quickly you can manipulate the bits, pulse a clocking pin. A more practical measure is how many bits or bytes the software can bang or bash out per second, or how long it takes to put each out.

 

[BeanieBots]

Yep, just like it was explained in your other thread together with rough guidance on speeds.

 

[Grogster]

I'm a little out of practice with conversion of HEX to decimal or BCD, but here is how I think I do it:

- With large numbers, like FFFFh it is dead easy - 16 1's in a row!

- With smaller numbers such as 0009h, this is 1001 in binary, so I guess that to keep correct alignment in a register or when clocking into a device such as the SOMO, I clock in 12 zero bits(starting from the MSB) for the unused bits in the word - 0000000000001001 - correct?

I think I have it right, but if I don't do it that way, my thoughts are that I would end up with 4800h(18432 decimal) or some variation of that, which is not what we want.

IE: I must clock-in the leading-zero's from the MSB's point of view, even if the binary value is LESS then 16 bits in length - correct?

 

[MartinM57]

All correct - just make sure you read the data sheet of the device so that you're sure whether to send:
- MSB first
- LSB first

EDIT - a good debugging aid is a LED+R on each of the bit-banged output pins and to put, say, PAUSE 1000 statements in between the "bangs" and then you should be able to see it all happening and be able to check that it all looks OK - and the device you're sending to should still respond correctly as well...

 

[Grogster]

Excellent idea, thanks - I will most likely do that on the breadboard to test it.

 

[Grogster]

Another wee thought: When you a sending serial data like this using a data-line and a clock-line, does baud-rate and clock speed not really matter?

By comparrison, serial-comms require that both ends of the link be correctly setup to talk, and it is critical that the baud-rate be correct or comms will be garbled.

With data and clock lines, and with the example device having a clock speed of up to 2.5KHz, so long as you don't EXCEED that speed when clocking-in the data, the device should be able to see each and every clock-pulse for incoming data bits, and so data transfer speed can actually be quite slow, as the device will still easily see and respond to the clock pulses?

I'm on a bit of a learning-bender here, as I have only ever used serin and serout with sometimes different baud rates to keep things simple - never experimented with bit-banging before...

 

[westaust55]

Somo 14d

Looking at the SOMO 14D audio-Sound module datasheet section 7.1, the data is sent as MSb (bit 15) first.

When you a sending serial data like this using a data-line and a clock-line, does baud-rate and clock speed not really matter?

It is not super critical in the mode used.
There are some minimum timing data given in the datasheet at section 7.1.
clock cycle time 400us (minimum)
data hold time 100us (minimum)
start bit low = 2ms (minimum)
stop bit high = 2ms (minimum)

for a typical PICAXE at 4MHz clock speed where instructions are of the order of 250us each, the program will:
- output the data bit
- pulse the clock line
- loop back for next bit
so the program loop to bit-bash/bang is going to take around 750uS and maybe longer so PICAXE timing at 4MHz is okay.
You will need to set the data line high in advance and at the end of the data transfer so taht the start and stop bits work correctly.

 

[BeanieBots]

The only thing you need to worry about is getting the sequence right.
You can do it really slow with a few LEDs to show what is going on as suggested by Martin.

In general, when data is clocked with a seperate line, it is the clock which sets the rate and both sides will be syncronised by it. With the RS232 style serial comms like 'serout', the rate is important because the receiver uses it's own 'clock' to know when to sample the 'data' line.