3 Replies Latest reply on Jun 16, 2016 12:19 AM by TonyMontes

    Variable frame size using UART on quark MCU

    smokytrace

        I received my Intel Edison board today and was looking around for information on using the quark micro-controller for implementing a protocol that uses a variable frame size (perhaps it would have been wise to look into this prior to getting the hardware).  All I found were some API calls for setting up the UART and reading / writing a known amount of bytes -- no DMA buffers or interrupts or anything.

       

      I was wondering if anyone has successfully done any bare-metal programming of the mcu?

       

      Just for kicks I compiled a small do nothing program I made and disassembled it to see what was happening under the hood, this is what I found:

      1.  It looks like execution starts at 0x2d8 with a relative call.

      2.  Ultimately system level functions appear to be implemented as a software interrupt 0x7e

           There is a single bare function (no stack frame save and restore) that invokes the interrupt and returns

                (wonder why that's not inlined considering the machine code for int 0x7e is cd 7e and the relative call and return are 6 bytes?)

           Parameters are passed on the stack followed by the function code.

      I have no idea where the software interrupt is implemented or what it does to manipulate the UART (memory mapped registers?  IO ports?).

       

      I remember using 16550 based UARTs on x86 based hardware using IO ports starting at 0x3f8 (for COM1) perhaps this is also a 16550 emulated hardware or a variant with larger FIFO buffers?

       

      I've also used an ARM based Cortex-M3 with UART's that implemented a receiver time-out with a bit-time resolution (could also trigger an interrupt), although a character time resolution would be fine.

        • 1. Re: Variable frame size using UART on quark MCU
          Bylos

          Hi Smokytrace,

           

          I have not been as far as you regarding disassembling an mcu application but this is what I've found out about UART with MCU (at least for UART1 that I'm trying to use with an XBEE module) :

           

          First it seems that reading only one byte on the port is never blocking, however reading multiple bytes is always blocking.

          If there is no data on the port the value returned for a one byte read is 0x00

          I used that to implement a protocol that uses a variable frame size, by sending first the length of the frame.

          On the mcu side I keep polling on the port with a one byte read (which is non-blocking) and then read the entire frame when this one byte is not nul (which means my frame has arrived).

          Below is a simple echo example (this echoes only the frame content, not its length)

           

          #include "mcu_api.h"

          #include "mcu_errno.h"

           

          unsigned char buf[64];

          unsigned char length;

           

          void mcu_main() {

               uart_setup(1, 115200);

               while(1) {

                    uart_read(1, &length, 1);

                    if (length != 0) {

                         uart_read(1, buf, length);

                         uart_write(1, buf, length);

                    }

               }

          }

           

          anyway officially UART1 is currently not supported, cf. MCU API documentation, but still this is working

           

          hope this helps !

           

          Regards

          • 2. Re: Variable frame size using UART on quark MCU
            smokytrace

            Thanks Bylos,

             

              That technique could work in cases where you have control over the protocol and can prefix a length.  If you experience data corruption in the form of invalid frame lengths or insane messages you could re-sync by sending the maximum valid frame size of 0x00 byte messages.  In my scenario I need to detect an inter-character delay of 4 bit-times @ 115200 baud which is ~34.7 microseconds and the data can contain 0x00's (seems odd that the uart read function returns an int so it could use a negative number to indicate no bytes available instead of 0).

             

              After spending some time searching for documentation it seems like low-level documentation is hard to come by on this platform.

            • 3. Re: Variable frame size using UART on quark MCU
              TonyMontes

              Hello, I want to use the MCU to drive an XBee and transfer the data to a Linux application using ttymcu0. So far, I have tried the code the Bylos has posted and using another xbee to test it by sending frames from XTCU. When I send variable frame sizes, it seems when they are shorter than 122 bytes, they are buferred and there is no reply until a second frame is sent. Then, the reply includes the first frame and the truncated second frame. The remaining bytes are included on the next response and so on..

               

              Im pretty new on C and pointers, if I understand correctly, the line uart_read(1, &length, 1); reads one byte and stores it at &length address, if the byte us not 0, then it reads the incoming frame , I do not  understant the length argument in line uart_read(1, buf, length); it is suposed to be the length of buf, which was declared as 64, but is supposed to be variable and previous line had stored the incoming first byte at this variable. Could someone explain me this please?