hspiin and Bisync

kenmac

Member
Hi folks,
I have been working on code to read Bisync messages by "bit banging".
However, I notice the command hspiin seems to read the data the same way as Bisync.
It can read the data bits at the leading edge of the clock pulses - that is mid data bits (mode 00).
So, is it possible to use this command to read Bisync messages which are sourced from a non-spi device?(serial clock/data lines)
Working in bytes is much easier than the "bit banging"method, and quicker.
The bit periods of the message are approx. 50uS.

Kenmac
 

hippy

Technical Support
Staff member
The PICAXE is always an SPI master, which means it generates the clock pulses, even when receiving. I am guessing the bisync device sends data and clock when it's transmitting.

It does appear that the on-chip hardware would accept being clocked externally but you would likely need to use PEEKSFR and POKESFR to do that.
 

westaust55

Moderator
You do not indicate which PICAXE chip you are using.

Note that the Hspiin (aka shiftin) command is only for the X1 and X2 parts.
 

kenmac

Member
I am currently trying a 28X2 running at 16mHz.
From what Hippy says, there will probably be a conflict of Clocks, so that idea fails.
So, it is back to "bit banging" I suppose.
The bits are 50uS so the programming needs to be pretty fast to stay in sync.
I was intending using the Scratchpad for storing the data - the test message is only about 250 bytes long.
Is it possible to do this in Basic?

Kenmac
 

inglewoodpete

Senior Member
I am currently trying a 28X2 running at 16mHz.
From what Hippy says, there will probably be a conflict of Clocks, so that idea fails.
So, it is back to "bit banging" I suppose.
The bits are 50uS so the programming needs to be pretty fast to stay in sync.
I was intending using the Scratchpad for storing the data - the test message is only about 250 bytes long.
Is it possible to do this in Basic?

Kenmac
I think you're on a hiding for nothing trying to use a PICAXE for your project. "The bits are 50uS" means that a PICAXE could not successfully complete a tight loop that reads the clock edges, assembles a byte and saves it to the scratchpad.
 

hippy

Technical Support
Staff member
From what Hippy says, there will probably be a conflict of Clocks, so that idea fails.
There wouldn't be a conflict if the hardware were set up right. It's just that you couldn't use SPIIN / HSPIIN to achieve that.

I must admit I am not at all familiar with bisync, and nothing I've looked at seems to say exactly who generates the clock. It's described as synchronous, but it's not clear what it synchronised to.

Any links to any documents you have might help.

So, it is back to "bit banging" I suppose.
You might be able to get by with that but I would have expected bit-banging to require higher than 16MHz operation, and I am not entirely convinced you could do it even then.

The advantage of using the on-chip SPI hardware is that you would only have to grab a byte every 8 clock pulses, every 400us, and that should be achievable.
 

kenmac

Member
Hippy,
Bisync is an old IBM protocol for series synchronous comms.
Basically there are two lines , data and clock.
The clock is generated by the sender and the receiver reads the data at mid-data bit, triggerred by the clock leading edge, similar to the SPI 00 mode.
The reason that I am dabbling in this is that we used to have a DLM5 data analyzer unit which was used to monitor the Bisynch messages.
Unfortunately this unit no longer works, and so I was looking at finding another method of doing the job.
I have now discovered that there is a chip available that should perform the actions required.
It is a Philips developed chip type SCN2651CC1N28 - I have ordered one and will have to wait for delivery.
Looking at the datasheet, it seems that this chip can be used under the control of a Picaxe chip.
So, that is the way I will proceed now.
Thanks for your input.

Kenmac
 

hippy

Technical Support
Staff member
I have now discovered that there is a chip available that should perform the actions required.
It is a Philips developed chip type SCN2651CC1N28 - I have ordered one and will have to wait for delivery.
That does look like it's the best option. What I would be tempted to have is a two PICAXE solution. The SCN2651 interfacing PICAXE which just grabs bytes received and sends them out using HSEROUT. That gives a main PICAXE, using background receive, plenty of time to handle what it receives with less worry about missing data.
 

Buzby

Senior Member
The 28X2 device ( maybe others, I've not checked ) has an enhanced UART which can support an external synchronous bit clock.

http://ww1.microchip.com/downloads/en/DeviceDoc/40001412G.pdf see section 16.5.1.7

Also, the MSSI module has an external clock mode when configured as a Synchronous Slave, see section 15.2.4

So it does look like a PICAXE could do it, if the SFRs can be tweeked. ( I'll leave that to hippy. :) )

A two chip solution would be my choice also, but whether the second chip is a SCN2651 or another PICAXE is up to you.

Cheers,

Buzby
 

hippy

Technical Support
Staff member
Is it possible to access the UART in the 28X2 as Buzby suggests?
It certainly seems possible, in fact I'm sure I even used synchronous mode once but cannot find any details on doing that. From what I can recall it was over a decade ago using an 18X.

If one doesn't use any PICAXE commands which touch the on-chip hardware one can usually use that hardware exactly as a PICmicro would through using PEEKSFR and POKESFR.

You may need to set the I/O pin directions how the on-chip hardware wants them but enabling hardware sometimes override whatever the PICAXE has them set as anyway. That was the case for using the UART on the 18X. Sometimes the PICAXE firmware will keep resetting I/O which thwarts an idea but often not.

It may even be possible to leverage PICAXE commands, such as setting up background receive then changing UART hardware settings to be synchronous. That way you could have your synchronously received bytes automatically placed in the ScratchPad.

The main issue there would be whether the PICAXE firmware pulls the rug out from under your feet, resets things to other than how one would like, when it's left to do something. Do it all yourself and it hopefully won't.

The big limitation with synchronous serial on a PICAXE is it can only be input or output; has a shared RX/TX pin plus CLKIN/CLKOUT pin. That would complicate things if you wanted serial in and out. You could however use SPI for sending, synchronous UART for receiving.

The only real way to find out if it can work or not is to try it.
 

kenmac

Member
Hippy,
Although it does seem possible, there remains too many unknowns, so I'll stick with using the SCN2651 chip feeding a Picaxe.
Thanks for your info - it has been informative!

Kenmac
 
Top