• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 21 subscribers
  • Views 884 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question about to serial C files in the demo project from LPC2138 NXP

Gary Olson

I am trying to run the NXP LPC2138 UART sample bundle code. I was having trouble since there is
a serial.c and a retarget.c file. If I added them both into a project I would get a error because both files have sendchar functions and they conflict. So I then removed the retarget.c
file and it appeared to compile but I was getting stuck at software Interrupt. Searching I saw
some discussion that this error could be caused by not having a retarget.c file in the project.

So I removed the serial.c file and placed the retarget.c file into the project. Then the project
ran properly. Just like a echo program. My question is if there was a reason for there to be
two separate Serial C files.

How would you be able to use the serial.c and not get the SWI interrupt? Basically I just
wondering why it was included in the example code.

Retarget.c has a pragma about no semihosting and the serial.c does not.

  • 0

    Serial.c uses UART1. Retarget.c uses UART0.
    int main (void) enables and disables the interrupt of UART0.

    I believe Retarget.c is for something like this:
    http://www.keil.com/uvision/db_sim_prf_uart.asp
    A Serial Window in uVision.

    Serial.c is for common serial communication.

  • 0 in reply to John Linq

    retarget.c deals with the software hosting for the console STDIO, which could use serial or SWV, etc. It replaces code that the "OS" would provide via SWI which you don't have, and has the #pragma to tell the compiler/linker it's going to replace that.

    serial.c deals with the specific hardware you want the IO to go through, on a specific chip, on a specific board

    I condense this into a single block of code in my main.c, but there are dozens of ways to do it. If you have multiple definitions in your code, you should evaluate why you need the routines outside of serial.c, and whether you duplicating the same code, or outputting data some place else. This would need to be a judgement call on your part.