If Then Array Oddity

[Bruce]

My guess would be it never = $80. Standard ASCII is from $00 to $7F. Extended ASCII starts at $80.

[atillotson]

That was what i thought as well, However I have used 3 different Communication capture programs and am able to determine that it is infact $80 Even PBP will say its $80 as long as I use a different way to compare than the one shown. again if its > $7f and < $81 - it will work. Or i can use select case and that works fine as well
But it doesn't work if I compare with the = sign with an array in my If Then condition.
ash

[Bruce]

And what happens if you do something like this?

Main:
    hserin 5000,Waiting,[hex serdata[0],hex serdata[1]]
    IF serdata[0] = $80 then
     hserout ["Got ",ihex serdata[0]," ",ihex serdata[1],13,10]
    ENDIF
    goto Main   
    
Waiting:
    hserout ["Waiting",13,10]
    Goto Main

[atillotson]

It did work.
Hi Bruce,
I do have some difficulty in this logic that I think is due to too much info comming from my serial display or a lack of complete understanding of the onboard eusart. Just FYI Im communicating to a Crystal Fonts 633 serial display. " http://www.crystalfontz.com/products/633/index.html " I have no problems talking to it, although the crc routine that it requires was a bit of a bugger. But only because Im used to LRC. So every time I send the display any Information like (display data), (Contrast Values), (Backlight Values) or anything else, it sends my an acknologment. Normally this is fine, and easy to deal with. But if you look at the Their specs you will find that their Packets have little "common" structure. Their is no (start Byte Char) or (end Byte Char) in the packet and their is no (standard packet length). Some packets are as little as 5 bytes in total packet size and some are as great as 20 bytes in total packet size. The only thing that i have to work with is the 2nd Byte (length of data) and the last 2 bytes are the crc. But screw the receive CRC, I dont think that i have enough time for the added calculations even though the crc routine is easily usable. Not to mention the display is only 1 inch away from my 18f2620. I just feel like i hardly need soo much structure when im not cableing my communication across a room. The part Im currently working on is the built in keypad in the display, Its really Cool!
So Basically the keypad receive packets look like this:
(Command,Length of data,Data,CrcLo,CrcHi) so if I press and release the (down key) on the display keypad I get
Down Key Pressed ($80,$01,[dont care],CrcLo,Crchi) Im trying to ignore this Packet when down
Down Key Released ($80,$01,$08,CrcLo,Crchi) Only care if released.

My controler is very busy with Pid algorithems plus Im communicating with a PC on seperate pins as well as a few I2C devices on my i2c bus.
Because of all of this activity I'm attempting to use my Hardware serial input without a pause for the LCD.

I have thought about using a seperate 12f683 As my "LCD Menu controller" and then using my 18f2620 to communicate via i2c with my own simple protocol. That way the 12f683 can work its butt off parsing whats needed and taking the necessary time to do so.

From your experience, do you have any suggestions as to the best way to parse this data?
Do you like or favor the idea of a seperate pic like the 12f683 do to my requirements?

Your Ideas will be graciously appreciated.

thanks Ash Tillotson

[Bruce]

Hi Ash,

If you have that much going on, your best option short of a dedicated keypad controller is probably a state machine type approach with prioritized tasks.

I know it's not BASIC, but have a look at the logic in this C example of a simple multitasking state machine, and how he prioritizes individual tasks with different time slices. The technique itself applies to any compiler.

http://www.microchipc.com/Hi-Tech_C_multitask.htm

The hardware USART will buffer up to 2 characters in the background. You just have to unload this buffer before the stop bit of the 3rd byte is received.

You have the time it takes to receive several bytes of data before servicing or removing the data from the USART buffer.

If you have the option of slowing the data rate, that may help if other tasks need more time before servicing the USART.

You also have the RCIF flag that indicates there is data in the USART buffer, so an occasional test of this bit can be used to extend time in other task sub-routines & let you know there is data waiting in the buffer.

Then you have the option of interrupts. MeLabs has a couple USART routines http://www.microengineeringlabs.com/...es/samples.htm that will buffer data in the interrupt service routine.

If interrupts just are not an option, and you don't have the time to manage all tasks with a single controller, then the dedicated keypad buffer just might be the best route. Especially if your PID routine is eating up all your overhead.