Where to store incoming data ?


Closed Thread
Results 1 to 6 of 6
  1. #1

    Default Where to store incoming data ?

    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!

  2. #2
    Join Date
    May 2006
    Location
    Del Rio, TX, USA
    Posts
    343


    Did you find this post helpful? Yes | No

    Default Store your data in an Array

    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:
    Code:
    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 .

    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

  3. #3
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    I'll second the idea of a special character. Parsing string is just too much code hungry and slow.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  4. #4


    Did you find this post helpful? Yes | No

    Default

    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.

  5. #5
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    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
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  6. #6


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by mister_e
    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.

Similar Threads

  1. Using Nokia LCD
    By BobP in forum mel PIC BASIC Pro
    Replies: 300
    Last Post: - 3rd May 2018, 05:47
  2. Nokia 3310 display text
    By chai98a in forum mel PIC BASIC Pro
    Replies: 0
    Last Post: - 26th August 2007, 04:39
  3. Big characters on HD44780 4x20
    By erpalma in forum mel PIC BASIC Pro
    Replies: 23
    Last Post: - 7th January 2007, 03:21
  4. LCD + bar graph
    By DynamoBen in forum mel PIC BASIC Pro
    Replies: 13
    Last Post: - 5th October 2005, 15:50
  5. Sinus calculating !
    By Don Mario in forum mel PIC BASIC Pro
    Replies: 29
    Last Post: - 29th November 2004, 00:56

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts