printf folly

[lpcware]

Content originally posted in LPCWare by js-nxp on Thu Dec 08 22:58:17 MST 2011
I managed to get the uart example finally working, the keystrokes are echoed correctly.

Added stdio and printf("hello world!"); before the echo loop ASS_U_MEing that printf would default to the solitary uart in the LPC1114 as some compilers do for other devices.

Compiled and started debug without problem but no cigars with printf, echo still works ok so the terminal program is still working.

After an hour or so trying things I realised the the string was being printed to the "console", what the.......? How? There is no connection between the pc and the uart except the terminal. Do I need to set up some "stream" for printf as it is the case with some other compilers? If so how? I tried a search here but did not get much help.

And the final rant: Why do I need to include a zillion files for even the simplest led flashing program? Can't I just include the LPC11xx header file which should have all the relevant definitions and use standard C to set up and control I/O ports etc rather than the obscure code red syntax? ie PORT0 |= 1<<LED_BIT; lots of errors when I try this.

Yestarday I was all excited at the ARM seminar, I thought I could just master the M0 but it seems that the simplest thing is to convoluted to achieve. Maybe ARMs are out on my reach.:(

[lpcware]

Content originally posted in LPCWare by rmteo on Wed Dec 14 08:20:38 MST 2011
Have never used any of the stdio.h functions in an actual application.  They only time I ever use anything similar is during debugging where I will use the virtual console services and semi-hosting support that my IDE provides.  In this situation, using the equivalent debug_fprintf (formatted write) function uses only about 170 bytes.

[lpcware]

Content originally posted in LPCWare by js-nxp on Wed Dec 14 02:54:14 MST 2011

---

Quote:
You're doing something wrong.

---

You don't say. :o

---

Quote:
With newlib, there is also the iprintf() family

---

I'll check this out later on. I'm very happy with the progress I have made in the past few days. Thanks to all the helpers.

I should be able to post a small video on Vimeo of the display in action in the next day or so.

Most of the stuff is now working correctly, I'll have to experiment with the timers as I have a kludged delay routine to use in the init phase only. (1ms increments)

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Dec 14 02:12:04 MST 2011
With newlib, there is also the iprintf() family, which is an integer only version of printf() and so doesn't bring in all the floating point code.

There are also some notes on integer version of printf in redlib
http://support.code-red-tech.com/CodeRedWiki/redlib_v2_notes#printf

[lpcware]

Content originally posted in LPCWare by Rob65 on Wed Dec 14 00:32:47 MST 2011

---

Quote: js-nxp

So obviously I'm doing something wrong I guess.

From another thread I need to use NEWLIB as it supports strnlen which I also need. http://knowledgebase.nxp.com/showthread.php?t=2698

---

Obviously you did not try small_printf - it is available somewhere from the LPCXpresso support pages at NXP's website.

You're doing something wrong. I just created a new project (for an lpc1769 but that won't change the code that much) using the "C project" project wizard:

[LIST]
[*]* With "Redlib (semihost)" libraries: [COLOR=Red][B]2684 [/B][/COLOR]bytes of program text (I'm using csmis 2.0 also).
[*]* Adding a simple [COLOR=Red]printf()[/COLOR] increases my code to [COLOR=Red][B]11520 [/B][/COLOR]bytes.
[*] * Using the optimized version for [COLOR=Red]small_printf[/COLOR] (without floating point support) and "Redlib (none) libraries my program is just [COLOR=Red][B]1676 [/B][/COLOR]bytes of code. Please note that I am just using snprintf() and I did not include a routine to write to the uart.
[/LIST]

And regarding strnlen, I don't think that should be too hard to find yourself:

int strnlen(char *s, int maxlen)
{
    int i;
    
    for(i=0; (i <= maxlen) && *s; i++, s++);

    return i;
}

In real small embedded apps you want to rely as less as possible on those standard libraries that take in all kinds of functionality you do not need.

As an example; the printf() function is able to print out float and double as well as standard int, string etc. That means that even when you are not using any floating point variables or math your code grows with a few kB

Regards,
[INDENT]Rob
[/INDENT]

[lpcware]

Content originally posted in LPCWare by js-nxp on Tue Dec 13 19:19:55 MST 2011
More folly! :confused:

By just adding stdio (I need sprintf) the code size jumps from 12K to 47K, which of course will no longer fit the chip. This is with -Os so fully optimised.

From compilers for other chips this should be no more than about 2K (1.5K for simple printf).

So obviously I'm doing something wrong I guess.

From another thread I need to use NEWLIB as it supports strnlen which I also need.

---

Quote:
string.h of NEWLIB is including strnlen, so changing library to NEWLIB should include strnlen :)

---

http://knowledgebase.nxp.com/showthread.php?t=2698

[lpcware]

Content originally posted in LPCWare by js-nxp on Sat Dec 10 18:59:30 MST 2011

---

Quote: CodeRedSupport
The debugger 'hosts' these functions by executing them on the host; so from your embedded application you can read and write files on the host.

---

I just want to use stdio with the hardware ie uart in this case, sorry, no idea of "semihosting". :)

As far as I'm concerned the debugger should just be there to download code, set breakpoints, look and modify registers, variable etc., do signle step and the "usual" debugger things. This it seems to be doing well as I get used to it's way of doing things.

Obviously a learning curve somewhat steep for me. Just found out that "compiler default" doesn't seem to be C99 as it is complaining about some code I'm porting.
I tried to set the dialect to C99 but broke something, now I'm back to default mode. Also debug defaults -O0, ok now that I know.

Anyway I'm reasonable happy that I got a "flashing led" (not the demo version) program running both in debug and release mode.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Sat Dec 10 14:29:51 MST 2011

---

Quote: js-nxp
Again I would hope that an IDE which supports a heavy duty processor like an ARM would have full stdio functions but maybe not.

---

LPCXpresso [B]does[/B] support 'full stdio' functionality. In the ARM world, this is known as [B]semihosting[/B] and is enabled just be using the standard C functions and linking with the 'Semihosting' library variants (newlib or redlib). The debugger 'hosts' these functions by executing them on the host; so from your embedded application you can read and write files on the host. These are also retargetable so you can 'host' them somewhere else. Standard semihosting requires a debugger to be connected, but by re-targeting, you can remove this requirement.

[lpcware]

Content originally posted in LPCWare by js-nxp on Sat Dec 10 13:47:33 MST 2011

---

Quote:
I use snprintf() instead, just print to a string and then hand the string to your communications channel.

---

Again I would hope that an IDE which supports a heavy duty processor like an ARM would have full stdio functions but maybe not. I can use fprintf with a small 8 bit processor.

---

Quote:
you'll find all the details about GPIO and pin configuration you are looking for.

---

I think I got that part now, ports are part of a structure. Got a "traditional" flashing led program going yesterday by starting a simple LPCXpresso C project.

Thanks for your help. Now on porting some code across to the LPC1114, see what wall I hit. :eek:

[lpcware]

Content originally posted in LPCWare by Rob65 on Sat Dec 10 05:56:31 MST 2011

---

Quote: js-nxp
I would hope that stdio includes fprintf which allows communication to any stream like differnt uarts, files if the hardware is there, LCD etc.

I'll have to start another thread on how to send 8bit data to a port and set pin direction, pullup resistors etc. I think. After 30+ years with this stuff I feel like I'm going back to kindergarten.:(

---

I use snprintf() instead, just print to a string and then hand the string to your communications channel.
Using the small_printf you could also provide your own write function.

Prepare to study different parts of the user manual in detail, there you'll find all the details about GPIO and pin configuration you are looking for.

Rob

[lpcware]

Content originally posted in LPCWare by js-nxp on Sat Dec 10 02:20:42 MST 2011

---

Quote:
It is just too bad that they are introducing all kinds of strange function instead of just addressing the registers of the chip.

---

That's what I say.:)

---

Quote:
IMHO these sample programs should quickly show you how to use the [I][B]chip[/B][/I] not introduce a complete library of silly functions to obfuscate what is happening.

---

I have no idea why they get so complicated. Atmel has been introducing the so called "Software framework" which I have refused to download. From other peoples comments it's a nightmare.

---

Quote:
Printf could even print to an LCD screen instead -

---

I would hope that stdio includes fprintf which allows communication to any stream like differnt uarts, files if the hardware is there, LCD etc.

I'll have to start another thread on how to send 8bit data to a port and set pin direction, pullup resistors etc. I think. After 30+ years with this stuff I feel like I'm going back to kindergarten.:(

[lpcware]

Content originally posted in LPCWare by Rob65 on Sat Dec 10 00:01:04 MST 2011

---

Quote: js-nxp
Can't I just include the LPC11xx header file which should have all the relevant definitions and use standard C to set up and control I/O ports etc rather than the obscure code red syntax? ie PORT0 |= 1<<LED_BIT; lots of errors when I try this.

---

Thanks, I though I was the only one thinking this way

If you just include the LPC11xx header file then it is as easy as:

LPC_GPIO0->DIR |= (1 << LED_BIT); // Set port as output
LPC_GPIO0->MASKED_ACCESS[(1<<LED_BIT)] = (0<<BIT_POS); // LED is off
LPC_GPIO0->MASKED_ACCESS[(1<<LED_BIT)] = (1<<BIT_POS); // LED is on

---

Quote:
Yestarday I was all excited at the ARM seminar, I thought I could just master the M0 but it seems that the simplest thing is to convoluted to achieve. Maybe ARMs are out on my reach.:(

---

Nope, it is not out of your reach.
The whole idea of the LPCXpresso environment and tools is that you get a real quick start with NXP's ARM chips. It is just too bad that they are introducing all kinds of strange function instead of just addressing the registers of the chip.
IMHO these sample programs should quickly show you how to use the [I][B]chip[/B][/I] not introduce a complete library of silly functions to obfuscate what is happening.

So the Blinky example would be a nice example to show how to use the masked access - a very nice feature.

---

Quote:
After an hour or so trying things I realised the the string was being  printed to the "console", what the.......? How? There is no connection  between the pc and the uart except the terminal. Do I need to set up  some "stream" for printf as it is the case with some other compilers?

---

There is one connection between the LPCXpresso module and the debugger which is always there: your debugger port.
As you may have read there is a special protocol developed by ARM to standardize a way of printing debug information: semi-hosting.
This is the only standardized communication channel but it is of course only usable when using special semi-hosting libraries.
Unfortunately there is no other standard communications channel. Most microcontrollers have multiple UARTs and it depends on the system which UART is being used as a standard (debug) channel connected to a terminal. So you always have to provide your own low level __write() function. Printf could even print to an LCD screen instead - you never know...

Rob

[lpcware]

Content originally posted in LPCWare by js-nxp on Fri Dec 09 15:38:07 MST 2011
Yep, ol' monkey trying to learn new tricks here. :)

So it look like I should stay away from semihosting stuff unless I know what I'm doing...which may be never with ARM. :(

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Fri Dec 09 15:31:27 MST 2011

---

Quote:

...what makes IDE makers think that in a microntroller environment anyone using printf doesn't want to talk to the REAL chip hardware...

---

Cortex is a modern chip with modern stuff :rolleyes:

---

Quote:

This is useful because development hardware often does not have all the input and output facilities of the final system. Semihosting enables the host computer to provide these facilities.

---

See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205f/Bgbjjgij.html

[lpcware]

Content originally posted in LPCWare by js-nxp on Fri Dec 09 15:22:46 MST 2011
Oh the Foolish Asinine Questions.....;) Thanks for that.

At the moment I feel like someone being dropped in the middle of nowhere and landed on his head. After a day messing around with the Xpresso I have gained as much knowledge as an old monkey who has overdosed on overipen babanas.

Had dowloaded the update version on Code Red yesterday (had 3.6) and the example I had used had already changed.

That must be the strangest version of printf I have even seen in my life, what makes IDE makers think that in a microntroller environment anyone using printf doesn't want to talk to the REAL chip hardware, being a uart, lcd or whatever?

I  hope that I can simply redirect printf to the hardware I need to sent messages to in the "usual" fashion by using fprintf. We'll see once I mess around with the sample code.

Thanks again.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Dec 09 03:58:42 MST 2011
Did you read the FAQ:
http://support.code-red-tech.com/CodeRedWiki/UartPrintf