PDA

View Full Version : Where to store incoming data ?



f_lez
- 21st August 2006, 15:23
Ok imagine this set of non standard basic statements..........


dim a$ as char(50)

for x=1 to 50

mid$(a$,x,1)=serin(port something)

next x

I end up with at least 50 chars from the serial port in a$


Now that I have them, I can parse them.

Imagine I am looking for keywords in that string.....

(say 'feed the' 'dog' 'cat' 'bones' 'meat' 'water' 'milk')

So I parse for valid instructions, otherwise I would forget and starve them...

So an incoming data stream of

''ghdfkghkdFEED THElkjgdjfCATjdflgjMILKjsdfjfjsdljfl"

would mean to milk the cat, sorry give milk to the cat...

But...........

''ghdfkghkdFEED THElkjgdjfMILKjdflgjCATjsdfjfjsdljfl"

would be the same, 'feed the milk cat' while out of context is valid

'Feed the' is just a qualifier and once I have that I can look at the rest of the burst of data I'm getting........

I have used

SERIN portb.7,t1200,1000,comserr3,["FEED THE"]

and it works a treat but........

I cant follow it with

SERIN portb.7,t1200,1000,comserr3,["CAT"]

because it may be time to feed the dog....

If I time out waiting for the cat, the dog may have run past, IYSWIM..........




I bet lots of newbies ask ones like this.............

Pic control was so much easier when I could just wire a switch to a pin!

SteveB
- 21st August 2006, 16:28
dim a$ as char(50)

for x=1 to 50

mid$(a$,x,1)=serin(port something)

next x

I end up with at least 50 chars from the serial port in a$

Try something like:

Comm_Buffer VAR BYTE[50]
cnt VAR BYTE

FOR cnt = 0 TO 49
SERIN portb.7,t1200, Comm_Buffer[cnt]
NEXT cnt

Now that you have the data in the array, you can parse it out with whatever logic will ensure none of your pets go hungry :D.

You could try using SERIN portb.7,t1200,1000,comserr3,["FEED THE"] to initiate the capture of the data stream. Once found, use the array to capture the rest of the command and parse accordingly.

One issue you may run into is if the data stream is continuous. If it is, you may need to get bit more sophisticated (like using the hardware serial port, interrupts, a FIFO buffer, and continuously parsing the buffer). Or not, if the data is slow enough and the parsing loop is tight enough.

Additionally, what about the device sending all these instructions? Any way you can modify the data stream? Such as sending a special character proir to any key word?

Steve

mister_e
- 21st August 2006, 17:54
I'll second the idea of a special character. Parsing string is just too much code hungry and slow.

f_lez
- 22nd August 2006, 09:57
Thanks for all this help, I did discover the way to set up an array of combuf(50) but then found my input may hit large lengths, so went to combuf(90) even though that may still be a bit short.....

I tried a for z=1 to 90 :serin: next z but if I get a short stream it waits for ever.

I added a timeout so that was a fix.


It seems I can watch for a set pair of bytes and then store after that, but once again the lenght is sometimes above what I can store and I miss the end.

I have tried to use the SKIP command in conjunction with waitin, but I have not hit the right syntax for it yet.

I have found this a problem with the pb manual again and again, no examples of correct command syntax, well it has examples, but not a 'real' worked example.

Zaks Z80, now THAT was a manual.

mister_e
- 22nd August 2006, 16:29
Experience, internet and forum is usually better than any books. Unfortunately it create also lazy people.

One great example is some student on various forum who ask for copy/paste solution... Woooohooo ! Sure they may got their grade even if they don't have a clue of what they do... sad really sad. And that's we call evolution :(

f_lez
- 23rd August 2006, 08:07
Experience, internet and forum is usually better than any books. Unfortunately it create also lazy people.

One great example is some student on various forum who ask for copy/paste solution... Woooohooo ! Sure they may got their grade even if they don't have a clue of what they do... sad really sad. And that's we call evolution :(

Well that wasnt me! lol

I'm not that bad, but I must admit I have asked a few questions that could have been answered by a few hours of book searching, I'm rushing this little project through so I have to say thanks to all who have made suggestions.

If I had to write this in 'real basic' it would have took about 30 minutes to flesh out and an hour or two to add refinement.

But when I get this done, I'll be posting the whole thing on here for all those others who want a simple phone controlled house/car/boat/garage alarm.

Features on this not on others are....

V1 will/has
1) incoming phone number verification (5 max, master, slave, 3 peasants)
2) has output ports. (IE turn on lights, unlock doors)
3) has 'levels' of input for alarm (eg, door rattled is a low priority alarm, FIRE is a high)
4) ability to add / delete users without a PC
5) temp monitoring (upto 8 zones) (via ds16/ds18 hardware)
6) voltage monitoring (resistor divider)

V2 additions
7) USB connection to PC to read messages stored in phone
8) A PC side frontend to control it / configure it / send receive msgs

Hardware is 1 pic16f88 (2550 for V2) and a T68 / t681 / t610

Phone was chosen because (a) I have a t68 and a t610 (b) those phones were very commoon so are cheap anywhere on ebay and they dont need silly cables to make them run AT commands.