Getting a data frame into PIC18F4550

[brucelee2]

Hi all,

Im working on a personal project for my room. I have a HMI(Human Machine Interface), its a 800*480 Screen. It works of various commands that you send to it( I communication protocal and a dataframe) using standard serial connection.


Now:

The screen sends a data frame to the microcontroller at a specified Baud rate. This data frame looks something like:

0xAA(start) 0x73(touch screen coord.) (16 bit X coord.) (16bit Y coord) 0x33 0x3C 0xC3

So there are a fare amount of bits moving when i push the touch screen.

THE PIC ONLY HAS A 8 BIT REGISTER IN THE UART MODULE I GUESS. SO HOW CAN I GET THIS MANY BITS INTO A VARIABLE?(MAINTAINING BAUD RATES ECT...)


Maybe interrupts? Im using MIKROELECTRONIKA MikroC compiler. There is a simple UART Library bit seems to be 8 bits at a time......




Look forward to hearing from you guys!


Cheers,

Bruce

 

[wp100]

Hi,

As the Pics Usart modules are fixed at 8 or 9 bits only and the x/y coordinates are being sent as 16 databits then the only way I can see it could be done is to write your own software serial link.

If you search for Bit Banging you will find some examples where chips have run out of USART ports, or simply don't have any usarts, so software usarts have be written to fill the gap.
They will probably all be in 8 bit mode, but sure it will guide you as to how to make it acceprt 16 bits.

 

[brucelee2]

Ok thanks for the tip. I see Mikroelectronica's MikroC has a software UART library, but again only 8 bits handeling :-( .. I think ill have to try some ''bit banging'soon . Think its going to be pretty tough for large data frames ....



IF any one has some nice example (s) in C please may i have a copy.

 

[wp100]

Hi,

This sensor uses spi serial and sends 12 bit data steams across.
On the right of this page are some C code examples that might prove helpful.
( use the sensor myself but in Assembler only)
https://www.sensirion.com/en/01_humidity_sensors/02_humidity_sensor_sht11.htm

 

[brucelee2]

Does any one know how to approach bit banging?

Should it be somthing like:

1. Generate external interrupt when start bit occurs.
2. Start a timer to sample pin at 1/3 * 1/baudrate ie. 3 times per bit.
3.Dissable the interrupt during this time.
4. shift the bits into variables
5.check for stop bit
6.disable time and re-enable external interrupt


How does this sound?

 

[wade_hassler]

It may be that the device returns not a 16-bit value but two sequential 8-bit values, meant to be concatenated into 16-bits.

 

[brucelee2]

its sends it in 0x?? 8 bit hex values but a large stream at once at a specified baud rate. so i cannot process this with the pics UART Module, but rather have to inplement some software to do it. Bitbanging. But how to do bitbanging is what i have to figure out. A process diagram of proceedures/events would help i guess

 

[wade_hassler]

So this HMI uses a 'standard serial connection' but not a standard serial protocol, i.e.,
no start-bit, stop-bit framing.
How about a part-/model-number?

 

[brucelee2]

It uses 8N1, so 8data bits, stop and start bit, no parity bit.

I guess where im confused is that it will send a large data frame. But will the MCU stop the HMI sending the next byte if the register has not yet been read by my source code? Or will the HMI continue....

:|

 

[FvM]

Or will the HMI continue....

Yes, unless both peers can use hardware handshake. A uP shouldn't have problems to read a burst of data to a buffer and process them later or even process it on the fly - with suitable programming. Receiving the data in an UART interrupt is the usual method.

 

[brucelee2]

There is a hand shake command sent to the HMI, but this is not hardware. sending 0xAA 0x00 0x33 0xC3 0x3C; where the ''0x00'' is the hand shake part the rest is the frame structure. there are only 3 connections to the HMI--> Rx Tx Gnd. Naybe using interrup routunes on the Tx pin will work!

 

[wade_hassler]

Pseudo-code:

Receive-interrupt:
    if received character is 'AA'
         Store in buffer
         Buffer_pointer++
     else
         Buffer_pointer = 0
         Message_received = 0

      if Buffer_pointer== length_of_message + 1
            turn off receiver
            Message_received = 1

      end interrupt

... the reply part seems straightforward enough not to require interrupts, but it would be easy to do, once the receiver is figured out.

 

[brucelee2]

yes some thing like that i guess