printf( ), putch( ), and xc8

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello folks;

I'm coming up to speed with the AVR, MPLAB-X and the xc8 compiler package and I'm struggling with printf( ). I'm using an Arduino Uno along with the Snap debugger module. So far things are sweet. I've read in three places that printf( ) formats a character string and that a helper function putch( ) in the project folder is needed to output characters in the string, one at a time.

To make a start, I followed the references to write an init function that configures the usart for 8 bit, no parity, one stop bit at 9600 bps. I also followed references to write putch( ) and I can use the functions together to transmit individual characters... so I can see that the usart is working.

I've noticed that the classic hello world program pretty much compiles without issue, even without a putch( ) function provided. So, it appears that the trick is how to tell the compiler to actually use the putch( ) function that I provided... Please, I'm wondering what the secret handshake is.

Thanks in advance;

Krista

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you link your "putch" function to stdio using fdev_open() of FDEV_SETUP_STREAM() ?

See http://nongnu.org/avr-libc/user-manual/group__avr__stdio.html#stdio_without_malloc

 

Note that this is somewhat different than most ARM printf() implementations, where simply defining a putch() function with the correct name is (may be?) sufficient.

Be careful that you are looking at a tutorial for the AVR chips.

 

(This is avr-gcc info; I'm assuming that XC8 is the same, since it's been just a wrapper around avr-gcc.  But it's possible that XC8 uses slightly different libraries than the standard avr-gcc.  (OTOH, it's more likely that you're looking at XC8 documentation for PIC cpus, and that they use some other setup.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the tip, I've started digging in... In skimming stdio.h I found some useful information that's similar to what you're describing.

Krista

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Okay, at this point I have the "Hello World" program working. The text in stdio.h, which is actually for doxygen, contains useful comments along with an example program.

Thanks again westfw for the reference, it could be the doxyen output. FDEV_SETUP_STREAM is a macro used as an initializer for a FILE structure. The stuff is starting to make some sense...

Krista

Last Edited: Sun. Jun 23, 2019 - 03:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do know that you have the manual generated from that Doxygen on your HDD?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
(This is avr-gcc info; I'm assuming that XC8 is the same, since it's been just a wrapper around avr-gcc.
appears to be based on Microchip AVR GCC 3.6

How long this will be is a question as MPLAB XC8 v2 for PIC is

  • Clang
  • LLVM AVR may be complete late northern Summer '19 or early Fall

Advantage Clang is its license :

The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:

 

MPLAB Ecosystem Downloads Archive | Microchip Technology

(3/4 page)

Source Archives

MPLAB XC8 AVR

v2.05

[158MB]

Clang C Language Family Frontend for LLVM

https://github.com/llvm/llvm-project/blob/master/clang/LICENSE.TXT

Apache License 2.0 (Apache-2.0) Explained in Plain English - TLDRLegal

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've suspected that it's in there. The next time I look, I'll probably find the formatted file. Thanks, though...

Krista

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In looking at the file structure, for now xc8 is actually a package with two compilers... One for PIC and another for AVR. I'll take another look at avr-gcc, when I have a chance.

Krista

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I was thinking more along the lines that XC8 could using the avr-gcc compiler, but with some implementation of libc other than the current avr-libc; possibly a partial replacement.

"We want to have a shared model for IO streams between PIC and AVR, so we replaced the avr-libc stdio code with something that behaves differently."

 

 

Advantage Clang is its license

"Advantage" for whom?  A new AVR compiler based on Clang could be fully proprietary to Microchip, with no requirement that they ever release source code, right?
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
"Advantage" for whom?
a legal entity (Microchip Technology Inc.)

A guess is the benefit is low as Atmel AVR GCC was with AVR Studio 5 (don't fix what isn't broken)

westfw wrote:
A new AVR compiler based on Clang could be fully proprietary to Microchip, with no requirement that they ever release source code, right?
Yes

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

a legal entity (Microchip Technology Inc.)

While I am not the greatest fan of GPL for code that may be embedded into designs (because of the requirement to publish all the "derived work") it's actually a good thing that GCC is GPL as it means that people like Atmel/Microchip have to publish their changes for the open use of others. As far as I know the liberal Apache licence would not have this requirements so Microchip could presumably have "private/hidden" changes to support AVRs etc in source they have no obligation to share with others so if they then start to charge there is no open/free option. So, yeah, the change licence for LLVM may be an "advantage" for M'chip but not necessarily us, the customers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
(because of the requirement to publish all the "derived work")
and derived includes applications due to GPL "copyleft" unless the GCC run-time exception exists; some instances of GCC don't have the run-time exception.

An application in a separate memory space than GPL'd code can be proprietary via CPU with MMU or MPU.

clawson wrote:
... there is no open/free option.
The current LLVM AVR is up to XMEGA; the only unified memory AVR there are tiny102 and tiny104.

Microchip Clang AVR can differentiate simply by adding unified memory AVR (tinyAVR 0-series, tinyAVR 1-series, megaAVR 0-series)

LLVM Clang AVR would be freedom and open though with effort from the AVR community to add unified memory AVR.

 


https://github.com/gcc-mirror/gcc/blob/master/COPYING.RUNTIME

GCC RUNTIME LIBRARY EXCEPTION
 

Similar exceptions exist for an event framework that's GPLv3 :

https://www.state-machine.com/licensing/#Open

[Arduino, Raspberry Pi, arm Mbed]

https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AVR/AVRDevices.td#L221

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

and derived includes applications

No it doesn't.

 

https://www.gnu.org/licenses/gcc-exception-3.1.html

Last Edited: Mon. Jun 24, 2019 - 04:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only GCC instance I'm aware of that doesn't have the run-time exception :

Downloads - Adacore via GNAT Pro Comparison - Adacore

 

To restore the run-time exception for a subset of those :

GitHub - AdaCore/bb-runtimes: Source repository for the GNAT Bare Metal BSPs

contains

https://github.com/AdaCore/bb-runtimes/blob/community-2018/COPYING.RUNTIME

subset is mostly arm, RISC-V, and a wee bit for AVR (all without an OS)

 


http://web.archive.org/web/20170707110324/https://libre.adacore.com/tools/gnat-gpl-edition/faq/#licensing

 

"Dare to be naïve." - Buckminster Fuller