lpcware

Receive is bonkers, but send works: UART, single byte, EA 1788 FTDI UART and functions

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by tylrtrmbl on Thu Oct 24 17:43:21 MST 2013
Hey all!

I promise that I searched for an answer to this before I asked it, but I have the simplest of all simple problems (I think). I am using the Embedded Artists LPC1788 developer board (and the "board" level functions of LPCOpen v1.03) to attempt to use the UART with simple polling.

Sending data, characters and strings, works like a charm! However, when I receive data, I'm not getting the bytes I expect. I type "j", and I'll get two bytes: "0x4c 0xe7" OR "0x6c 0xe7". I'm not sure why those are inconsistent, or why they are in that format at all. "a" gives me "0x02 0xe7".

Here is a mostly unhelpful screen capture of what I sent and received: [img]http://f.cl.ly/items/2s3D3e1D0L1c0Q131D0Y/Screen%20Shot%202013-10-24%20at%207.27.23%20PM.png[/img]
Along with the code:


//
//  main.cpp
//  blinky
//
//  Created by NXP, modified by Taylor Trimble
//  Copyright (c) 2013 Taylor Trimble. All rights reserved.
//

#ifdef __USE_CMSIS
#include "LPC177x_8x.h"
#endif

// Variable to store CRP value in. Will be placed automatically by the linker when "Enable Code Read Protect" selected.
#include <cr_section_macros.h>
#include <NXP/crp.h>
__CRP extern const unsigned int CRP_WORD = CRP_NO_CRP ;

#include "board.h"
#include <stdio.h>

#include "../../ribsy/include/pt.h"

// =============================================================================
// Globals
// =============================================================================

// =============================================================================
// Threads
// =============================================================================

// =============================================================================
// main
// =============================================================================

static int Event;

static int DriveEvents(struct pt *pt)
{
    PT_BEGIN(pt);
    Event = Board_UARTGetChar();
    if (Event != EOF) {
    Board_UARTPutChar(Event);
    }
    PT_END(pt);
}

static int A(struct pt *pt)
{
    PT_BEGIN(pt);
    PT_WAIT_UNTIL(pt, Event == 'a');
    Board_UARTPutSTR("AAAHH!\r\n");
    PT_END(pt);
}

static struct pt pt1, pt2;

void Setup() {
// General board initialization
Board_Init();

// Serial debug
Board_Debug_Init();

// Initialize protothreads
    PT_INIT(&pt1);
    PT_INIT(&pt2);
}

int main(void)
{
    Setup();

    Board_UARTPutSTR("Ready; let's do this.\r\n");

    while(1) {
        DriveEvents(&pt1);
        A(&pt2);
    }
}


Echo was enabled on my terminal emulator, so you see both what I typed and what was echoed. The program starts by printing "Ready; let's do this...". What follows is a single character typed by me, followed by two bytes of response.

For those of you who don't know what protothreads are, just imagine the threading code I've written above does essentially what it looks like I've asked it to (
PT_WAIT_UNTIL
is a "non-blocking" wait condition barrier, etc.)

I've looked into the
Board_*
functions and found them to be doing what they advertise: they're enabling my dev board's UART to work at the FTDI chip's baud rate, and my terminal emulator has been set to the right baud rate as well. I've actually tried this with a couple terminal emulators, and both had identical results. It's configured for 8-N-1 as well, so no obvious problem there.

I thought it might be a Unicode thing as well, but that turned out to be a wild goose chase for me as well. If any of you are willing to assist me with my probably simple puzzle and oversight, I'd appreciate you a lot right about now! Thanks a ton. :)

Taylor

Outcomes