Is it possible to interpret non-standard serial data with PicBasic (sample attached)

[CuriousOne]

Here is the complete code:

Include "modedefs.bas"  ' Include serial modes
   TRISA = %11111111       ' Set PORTA to all input
       TRISC = %00000000	    ' Sets all PortB pins to output
   ADCON1 = %10000101      ' Set PORTA analog and right justify result
   ADCON0=%00000000
   low portc.4
   low portc.5
   
X   VAR PORTC.4 

DEFINE LCD_DREG PORTB
DEFINE LCD_DBIT 4
DEFINE LCD_RSREG PORTB
DEFINE LCD_RSBIT 0
DEFINE LCD_EREG PORTB
DEFINE LCD_EBIT 1
DEFINE LCD_BITS 4 
DEFINE LCD_LINES 2
DEFINE LCD_COMMANDUS 1500
DEFINE LCD_DATAUS 44
DEFINE OSC 4

lcdout "test 2"
PAUSE 500

LABEL VAR WORD
DROEBITI VAR WORD


taki:
if portc.4=0 then
COUNT PORTC.4, 60, LABEL
endif
if label=0 then
goto taki
endif
LCDOUT $FE,$c0, DEC(LABEL), "          "
GOTO TAKI

I have source of signal (chip with name grinded off, but holtek logo is recognizable), which is connected directly to PORTC.4. Also, scope is connected to same pin.

As long as I introduce the statement "if portc.4=0 then"
If it is "=0" then pin is sunk to ground, so no pulses can be detected, and nothing can be seen on scope. If it is "=1", then pin gets driven high, and no pulses can be seen with scope or read too.

Chip is 16F870.

[pedja089]

 TRISA = %11111111       ' Set PORTA to all input
   TRISC = %00000000	    ' Sets all PortB pins to output
   ADCON1 = %10000101      ' Set PORTA analog and right justify result
   ADCON0=%00000000
   low portc.4
   low portc.5

Is there something strange here?

[Art]

Easy! It’s giving you a wider pulse duration at the start to qualify the incoming data.
From there you only need to sample 32 times at the correct interval.
So look for that, then read it in with a 32 step loop.

bitcode var byte[32]
count var byte
pulseduration var byte

pulseduration = time from peak to peak

for count = 0 to 31
bitcode[count] = inputpin
pause pulseduration
next count

Of course, better ways than reading into a 32 byte array, but quickest.

[CuriousOne]

You're omitting an important thing - MCU has own clock, wastes different time on program execution, but incoming data is sent async, so it can't wait for MCU to become ready, so my guess, how it all should work, is as follows:

As pulse arrives, we start recording it as fast as possible, after pulse sequence finished, we just count numbers of 1's and 0's recorded, and based on that, decide what to do with decoded data. Considering total sequence duration and speed, I guess, external sram or eeprom might be needed?

[Art]

That depends. You didn’t display the duration.
If it’s several uS duration pulses, the falling edge of the first longer pulse is the place to mark time,
then waste half a pulse duration before the for-next loop. If you can roughly synchronise from the first pulse (which is what it’s for),
it takes time for the two clocks to drift apart.

If you were to sample bits as fast as you can, you’d still want to do that from the falling edge of the first pulse.

[Art]

Does your hardware have the LCD that is in your code?

[Art]

That should get the 32 bits straight into a four byte array.

'
main:
@ clrwdt
'
if portc.4 = 1 then	‘ count initial pulse duration
leadcnt = leadcnt + 1
else
leadcnt = 0
endif
'
'
if leadcnt > expectedduration then' qualify initial pulse duration
burst:			' sync to initial pulse falling edge
if portc.4 = 1 then
@ clrwdt
goto burst
endif
'
for rotcnta = 0 to 3	' shift data into 32 bit buffer
databuffer = 0
for rotcntb = 0 to 7	‘ shift data to each byte
databuffer.bit0 = portc.4
databuffer = databuffer << 1
dataarray[rotcnta] = databuffer
pauseus peaktopeakduration
next rotcntb
next rotcnta
‘
leadcnt = 0
endif
'
goto main
‘