Calliper Interfacing - Need help

[jyb]

hello everybody
2 questions
i am using a picaxe 28x2
1°
i need to input serial data and its serial clock on picaxe and i can' t reach to do it
may be some senior could tell me what command to use
i had try spiin clk,data,etc... but i think in this case clk is a clock generated by the picaxe

2°
is it possible to include in picaxe basic programs ,assembler routines
like others systems

thanks
jyb

 

[westaust55]

1. Can you please give preferably a link to the device (or is it PICAXE to PICAXE?) or as a minimum some further expalnantion of what device you are trying to input data from, so that we can clearly understand what data you are trying to input.
In virtually all cases,with say the SERIN and SPIIN commands for example, the PICAXE will be acting as the “master” and generate the clock pulses to clock the data into itself.

2. in short NO.
There is no way to include an assembler code segment within a PICAXE BASIC program (as can be done with some other systems).

 

[jyb]

chinese calliper

sorry i forgot the main part
what i want is connecting a calliper to a picaxe 28x2
the calliper outputs two signal : 1st = 90khz clock and 2nd = data
data is in binary form so i must shift in data synchronized by the 90khz clock onto the picaxe
Reading picaxe manual 2, i can't find a basic command which correspond to my need : a command like "shiftin/spiin" where picaxe is slave and accept an external clock
i think may i don't understand correctly some explanations in picaxe manual2

on other part ,somebody on this forum gave me this adress above http://www.compendiumarcana.com/caliper/
he use a 12c509 and work in "c"language that offers differents possibilties
jyb

 

[chigley]

If you post a link to the datasheet of the calliper you're trying to interface with, it'll be easier for people to try to help you.

 

[Dippy]

First, are you sure it is the cheapo 90kHz method?
Checked with a 'scope?

Looks more like ASM to me.

Can you use a Shiftin type command? It looks like a synch serial.

Maybe some useful info here.
http://www.yadro.de/dro/scale-debugging.html

Have you made an electonic interface part yet?
Not much point the Forum spending hours on code for you if the electrical part isn't done.

 

[hippy]

A 90kHz clock will mean a bit every 11us which is far too fast for a PICAXE to software bit-bang receive.

Depending on the data format it may be possible to coerce some PICAXE on-chip hardware to receive the data or to create an external shift register which can then be read once data has arrived but it does depend on the data and its format and each would require further research.

If the link in post #3 describes the data format of the calipers ( 48-bits of data, but can use just 24 of those bits ) it seems a shift register setup would work though it would be easier to use a micro as described. Alternatively, a FIFO, a set of shift registers (SIPO-latch-PISO) or a micro could churn data in at full-speed and deliver the same bit-stream out at a speed a PICAXE can handle through bit-banging.

Configuring HSerIn background receive and poking on-chip SFR's to achieve synchronous receive would seem to the most likely way forward but would require further investigation and testing with no guarantee that it will work.

A description, scope or logic analyser trace of the exact data format, would be a prerequisite.

 

[hippy]

Using synchronous receive looks possible.

The attached code is proof of concept for the 20X2. It bit-bangs out 64-bits as Data and Clock and captures those using background serial receive. The receiver configuration is set to synchronous mode by poking the relevant SFR after issuing a HSERSETUP command.

In synchronous mode there are no start and stop bits framing the serial data, it's effectively SPI input - 8 clock pulses push in 8 data bits. Using the background receive mode of the PICAXE each received byte is automatically placed in the scratchpad so all data is captured. This is probably the only way of achieving SPI Mode Background Receive.

While a byte is being received a previous byte can be moved to scratchpad so it should work up to fairly high clock rates. This demo runs about 10 times slower than 90kHz so whether it works at that speed is not known. It may also be necessary to configure HSERSETUP and shuffle captured data to get the original bit-stream into a format that is easy to process.

 

[jyb]

to hippy

hello hippy
i just read at this time ,your last post about calliper and i just copy the file joined not yet try it
i loaded some document found on the forum
http://www.compendiumarcana.com/caliper/
http://www.yadro.de/dro/scale-debugging.html
were i found my vernier s'documents and some helps

i have some questions on the picaxe and programming editor

first :
is really program editor a compiler that load onto the picaxes assembler programs?
after testing syntax, the used bytes number displayed seems to indicate yes that is asm as it is so very low if it was interpreted basic
the pic18F25K20 (picaxe 28x2)notice from microchip says this core can run up to 16MIPS
as 16 millions instructions per second which give theoreticaly
0,0625µs / for one instruction (with 64Mhz clock)
i think that if the picaxe speed is not too altered by programming editor, it may be possible to find a solution , of course best solution will be without any other ttl or cmos chip :it's my challenge, a kind of "graal"
jyb
ps i have all time i need : iam retired...

 

[BeanieBots]

I'm sure hippy will give a much explanation later, but meanwhile...
The PE does not convert BASIC to assembler in the way a compiler does. It produces tokenised BASIC which is how it produces such small code size. The chip has an interpreter built in. The down side of this is that tokens must be un-packed and interpreted. This is why a PICAXE runs much slower than a PIC programmed in assembler.

 

[hippy]

BeanieBots is correct. It is not a compiler so programs run slower than assembler would though not as slow as may often be thought ( it all depends on what one is comparing ).

Even so it's too slow to do bit-banging at the 90kHz being considered.

Synchronous serial looks the best bet as this will handle the 90kHz speed and, because it's hardware buffered, the PICAXE only has to deal with one byte received every 100us. As the firmware handles those bytes that will be quick and should therefore be able to handle the data stream. As the concept works on the 20X2 it should also work on the 28X2.

 

[jyb]

to hippy

hello hippy
i downloaded the program you send and i try it on the picaxe 28x2
it seems run but what i get is dot ,cr,lf, continuously
so i try to understand your idea and there is some things i don't
1° i can't find which command operate pin c.0 tx/ck
"HSerSetup B9600_64, %011" ? i think not..
2° where may i find more details on SFR flags because i can't decode this below
more probably this operate the clock input c.0
what are bit 7 and bit 4?
PeekSfr $AC,b0 what is AC adress pointing to?
bit7 = 0 ' TXSTA:<CSRC> = 0
bit4 = 1 ' TXSTA:<SYNC> = 1
PokeSfr $AC,b0

thanks a lot
jyb

 

[hippy]

The program probably hasn't been modified to use the 28X2 hardware correctly. The attached proof of concept code works on a 28X2. For details of SFR usage you need to read the Microchip datasheets for the underlying PICmicro the PICAXE is based upon ( www.microchip.com ).

 

[jyb]

thanks to hippy

i loaded your file and it run fine
many thanks for your help
i can go a step more toward my target until next problem!
thanks again
jyb