util/setbaud.h incompatible with new avr/iom*.h files

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
MattRW
MattRW's picture
Level: Resident
Joined: Thu. Feb 14, 2019
Posts: 730 View posts
Location: Los Angeles area
#1
Posted by MattRW: Mon. Nov 25, 2019 - 03:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

 

Tthe recent device packs have include files that use the symbol "BAUD" for a struct member.   This makes the 'historic" use of BAUD as a #defined variable incompatible.

 

/opt/local/bin/avr-gcc -mmcu=atmega4809 -DF_CPU=3333333UL -Os -I.. -I../../ -B/opt/local/avr/packs/mega-1.3.300 -DBAUD=9600UL -c main.c -o main.o
In file included from /opt/local/avr/include/avr/io.h:578,
                 from main.c:3:
<command-line>: error: expected identifier or '(' before numeric constant

 

Here is a snip from avr/iom4809.h:

typedef struct USART_struct
{
    register8_t RXDATAL;  /* Receive Data Low Byte */
    register8_t RXDATAH;  /* Receive Data High Byte */
    register8_t TXDATAL;  /* Transmit Data Low Byte */
    register8_t TXDATAH;  /* Transmit Data High Byte */
    register8_t STATUS;  /* Status */
    register8_t CTRLA;  /* Control A */
    register8_t CTRLB;  /* Control B */
    register8_t CTRLC;  /* Control C */
    _WORDREGISTER(BAUD);  /* Baud Rate */
    register8_t CTRLD;  /* Control D */
    register8_t DBGCTRL;  /* Debug Control */
    register8_t EVCTRL;  /* Event Control */
    register8_t TXPLCTRL;  /* IRCOM Transmitter Pulse Length Control */
    register8_t RXPLCTRL;  /* IRCOM Receiver Pulse Length Control */
    register8_t reserved_0x0F;
} USART_t;

and in my code I use

  USART0.BAUD = BAUDRATE;

where I use -DBAUDRATE=9600UL as avr-gcc argument and no longer include util/setbaud.h.

 

Is there a convention for dealing with this now?

 

Tags:

Tools, Compilers and General Programming
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 102557 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 25, 2019 - 03:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
Is there a convention for dealing with this now?
Push an update to AVR-LibC via the Bugzilla

Top
MattRW
MattRW's picture
Level: Resident
Joined: Thu. Feb 14, 2019
Posts: 730 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 04:40 PM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

MattRW wrote:

Is there a convention for dealing with this now?

 

Push an update to AVR-LibC via the Bugzilla

 

Good idea.  Savannah is down right now, but I will do that.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 102557 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 25, 2019 - 04:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By rights you know, anything in LibC *should* have a "_" for the very reason of preventing name pollution (of course one might argue that "BAUD" within "USART_t" is also "owned" by the C lib and so actually everything in the headers should all be _BAUD, _USART_t and so on, in which case making the component parts of my setbaud.h all have underscores too would not actually help). But as a short-term solution it may work as I doubt the io*.h files are suddenly going to spring "_" prefixes all over the place!

 

(one of the few things in AVR-LibC that actually adheres to the convention of _ prefix to avoid name pollution in fact are _delay_ms() and _delay_us() !)

Top
MattRW
MattRW's picture
Level: Resident
Joined: Thu. Feb 14, 2019
Posts: 730 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 06:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Submitted to savannah as #57299.

Top
MattRW
MattRW's picture
Level: Resident
Joined: Thu. Feb 14, 2019
Posts: 730 View posts
Location: Los Angeles area
Posted by MattRW: Mon. Nov 25, 2019 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So my solution is not right.  One still has to compute the register value from F_CPU and BAUDRATE, but the equation for the AVR-0 series is different than that for, say, the 328P.

 

I'm trying to get something working on my microchip curiosity nano w/ atmega4809, without success so far.

 

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 5015 View posts
Location: SF Bay area
Posted by westfw: Mon. Nov 25, 2019 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is from code that works on a Curiosity Nano.  Needs some of the symbols set appropriately beforehand, but might be a useful model:

 

#define BAUD_SETTING_16 (((16000000/6)*64) / (16L*BAUD_RATE))
#define BAUD_SETTING_20 (((20000000/6)*64) / (16L*BAUD_RATE))

    MYUART_TXPORT.DIR |= MYUART_TXPIN; // set TX pin to output
    MYUART_TXPORT.OUT |= MYUART_TXPIN;  // and "1" as per datasheet
#if defined (MYUART_PMUX_VAL)
    MYPMUX_REG = MYUART_PMUX_VAL;  // alternate pinout to use
#endif
    if ((FUSE_OSCCFG & FUSE_FREQSEL_gm) == FREQSEL_16MHZ_gc) {
	MYUART.BAUD = BAUD_SETTING_16;
    } else {
	MYUART.BAUD = BAUD_SETTING_20;
    }
    MYUART.DBGCTRL = 1;  // run during debug
    MYUART.CTRLC = (USART_CHSIZE_gm & USART_CHSIZE_8BIT_gc);  // Async, Parity Disabled, 1 StopBit
    MYUART.CTRLA = 0;  // Interrupts: all off
    MYUART.CTRLB = USART_RXEN_bm | USART_TXEN_bm;

 

Top