Quick Question on Conventions

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

Hi all, first post here.

 

I've come to a new position, and have inherited several projects form a dev who is no longer here. I've never worked with AVR before, just a bit of dabbling with a PIC. 

 

I have a lot of questions, and I'll get to them eventually after I google enough, but I just need some bearings for right now. 

 

I'm trying to write up a MODBUS interface for a USART port over RS485, and while I'm gathering my wits on how to specifically implement that, one thing keeps bugging me. In the code below, which is a snippet from the USART_400.h file, what is the difference between the capital lettered variable, and the lowercase variable, and what is the union doing in this scenario?

union {
    const unsigned long                  ner       ;//0x0044
    const avr32_usart_ner_t              NER       ;
  };

I know, on a macro level, that they are all tied to the special function registers in the micro and serve as interfaces to designated registers (RHR springs to mind). I could probably do a better job of researching this, if I just knew what I was actually looking for was actually called. 

 

Thanks in advance.

This topic has a solution.
Last Edited: Tue. Nov 19, 2019 - 05:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Show a bit more context - is that union standlone (in which case it is "anonymous") or is it part of a struct? (GCC allows anonymus struct members). Anyway this is basically saying that the same thing can be accessed in two ways. If you access ".ner" it will be of time "const unsigned long" and if it is ".NER" then it will be treated as "const avr32_usart_ner_t" (which I rather suspect may be typedef'd as const unsigned long anyway!)

 

BTW the "avr32" in this maybe suggests you are not talking about AVR (that is the 8 bit family of micros) but "UC3" which was Atmel's rather failed attempt to make a Cortex_M beater.

 

If this about UC3 and not "normal" AVRs I can move this to a more appropriate forum (except that there won't be that many eyeballs and most of the world gave up on AVR32 a long time ago).

 

EDIT: a quick google suggests you are really talking about:

 

https://github.com/vegarwe/avr32/blob/master/common/include/avr32/usart_319.h#L1294

 

So I will move the thread.

 

EDIT2: now we know the context you can see at line  1361 that this "NER" is just a small part of avr32_uart_t so there's probably something somewhere like:

#define USART *(avr32_uart_t *)0x123456

then later you can access:

UART.ner = 456;
UART.NER = 789;

This will both write to the same 32 bit register offset from the 0x123546 base address (whatever that is in real life). The comments say " // 0x000044" so one could assume that when you write to UART.new (or UART.NER) you are writing to the 32 bit word at 0x123465 + 0x000044, that is 0x123500 in my example.

Last Edited: Tue. Nov 19, 2019 - 04:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I've never looked at UC3 as they seem to be completely irrelevant in the modern era but just picking a datasheet at random I see:

 

 

So your register at offset 0x44 from the block base for UART is the "number of errors register" so I guess you read .ner/.NER to pick up the number of errors rather than ever actually writing to it (unless you might write to clear it?).

 

I just skimmed 4 different "datasheet" documents on the website and I just can't see what the USART register file base address is (the equivalent of 0x123456 in my example) - I guess this is why the chips never caught o nas they made simple info too difficult to find!! With "real" AVRs details like this are easy to find.

 

EDIT: just spotted "read-only" so, no, you don't write "NER" to clear it - I'm guessing it is reset by a control bit in one of those other registers. So I guess you just use:

errors = USART.ner;

or something?

Last Edited: Tue. Nov 19, 2019 - 05:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The thread title is "Conventions".

 

In 'C' programming (not specific to Atmel or AVR or UC3), the convention is that names in ALL UPPERCASE are preprocessor definitions.

 

So the posted code is not following that convention!

 

clawson wrote:
there won't be that many eyeballs [as] most of the world gave up on AVR32 a long time ago

 

See: https://www.avrfreaks.net/commen...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, thank you. I really didn't know the difference. The UC3 thing hasn't come up yet, so I was on the assumption that AVR was, well, relevant. But there it is, in the Device: "AVR UC3...". As I said, I inherited this project from a previous team, and I don't know when or why they chose the UC3 for this one. 

 

it is in a struct, for avr32_uart_t. And looking up, I do see a bitwise structure that seems to assign the bit assignments for the NER register, whatever that is. 24 bits of nothing, and 8 bits for an error. 

 

typedef struct avr32_usart_ner_t {
    unsigned int                 :24;
    unsigned int nb_errors       : 8;
} avr32_usart_ner_t;

Though, still a bit confused as to which one to use, when writing or reading from the relevant register; caps or lower.

 

Edit: Ya'll are quick on the keyboard! Info is hard to find on this, especially stuff that's not completely stuffed with jargon and abbreviations, so I appreciate the explanation. It does make more sense now, when you put it in terms of offset.

Last Edited: Tue. Nov 19, 2019 - 05:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh right that bit struct starts to make more sense so you are going to use:

uint32_t complete_num_errs = USART.ner;
// OR
uint8_t count_8bit_errors = USART.NER.nb_errors;

In effect it looks like only 8 bits are relevant and you have the option of reading it as a complete 32 bit word or as just an 8 bit field from it.

 

On 32 bit micros they are actually more efficient when it comes to reading (4 byte aligned) full 32 bit words usually. Picking out just 8 or 16 bits from a 32 bit register involves special half or quarter word access instructions so I guess these two names for the same thing give you the opportunity to go either way?

Last Edited: Tue. Nov 19, 2019 - 05:06 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

erenard wrote:
still a bit confused as to which one to use, when writing or reading from the relevant register

The datasheet extract which clawson posted said the register is read-only - so you wouldn't write to it at all ?

 

The difference, as clawson explained, is that ner (lowercase) just gives it as an unsigned long (the whole 32 bits), whereas NER (uppercase) gives it as a avr32_usart_ner_t - which allows to you separate the nb_errors byte from the other 24 bits.

 

Maybe those other bits are not guaranteed to be zero - so that just saves you having to mask them out?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

The thread title is "Conventions".

 

clawson wrote:
there won't be that many eyeballs [as] most of the world gave up on AVR32 a long time ago

 

See: https://www.avrfreaks.net/commen...

 

 

How long is long? I think, development on this started in '12, and only now did the whole mess get put in my lap. Going forward, I hope to pick something sensible.

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

erenard wrote:
Info is hard to find on this

Indeed.

 

Again, see: https://www.avrfreaks.net/commen... and clawson's comment about the limited number of eyeballs ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


As I say I think this is more of a "32 bit thing". It's whether you want to make word/(half-word)/quarter word access to 8 bits within 32.

 

 

One would need to read the rubric at the top of the data sheet to know what they imply by "-"

 

The final comment is interesting - so that is how you clear it!

Last Edited: Tue. Nov 19, 2019 - 05:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

erenard wrote:
How long is long?

I don't think it ever took off in a big way - so there has never been a large "eyeball count"

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I picked NER at random, as an example of the convention I was seeing. All the SFRs look like it. THR, RHR, etc.

 

Also, that explanation is lovely. That makes a lot more sense. The NER should just return 8 bits, not the whole long of ner. 

 

Edit: of ner, not or ner. Geez, self. 

Last Edited: Tue. Nov 19, 2019 - 05:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I edited #10, so yeah, NER is really 8 bits of interest stored in 32 bits (as all SFRs will be on a 32 bit micro).

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

"Hope you got that the first time, 'cos I'm not repeating myself"

-NER Register

 

Heh heh.

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

So back to "conventions" ...

 

whoever wrote this seems to have come up with their own convention that:

  • lowercase, eg ner, is the full, unabridged 32 bits;
  • uppercase, eg, NER, is a struct/bitfield which separates the used bits from the unused bits.

 

IMO, it's bad to have names which are distinguished solely by case - would have been far better to have descriptive names ...

 

But then, hindsight is a wonderful thing.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or, at very very least, add a comment to the top of the page to describe what's going on. I wish I knew who wrote this, though it seems like it's a built-in from IAR, from whom documentation is already difficult to find.

 

This forum has been very helpful so far. Thank you guys, again. 

 

Though, now I suddenly have to worry about these chips going EOL and what to do about replacements and writing entirely new code for said replacements. I'm already concerned about replacing the PIC12C's we have kicking around in older designs.

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

erenard wrote:
Or, at very very least, add a comment to the top of the page to describe what's going on.

Indeed.

 

seems like it's a built-in from IAR, from whom documentation is already difficult to find.

Oh dear - that's another "reduced eyeball count" option!

 

 

 

This forum has been very helpful so far. Thank you guys, again. 

You're welcome

 

worry about these chips going EOL

gchapman  posted a link to Microchip's "Product Change Notifications" list here: https://www.avrfreaks.net/commen... - that might give you something to go on ...

 

what to do about replacements and writing entirely new code for said replacements

Worth looking at the SAM D parts - they certainly seem to have inherited some IP from the AVR32 ...

 

If the existing code is well-structured, it shouldn't be too hard to replace just the low-level driver stuff - and higher-level stuff should be agnostic to the underlying hardware.

 

If the existing code is not well-structured, the first step might be to make it so ...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Nov 19, 2019 - 05:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

replacing the PIC12C's 

That's a blast from the past.  PIC18 is much nicer to work with (if you must work with pic).

 

Do you even need a 32 bit AVR?  A lot of times something like that just gets thrown in without much real planning, other than it sounds progressive.  Often a better algorithm can make more of a difference than the processor size.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Oh, I'm not debating that fact! One of my favorites is a PIC16F19155, on account of its built in EEPROM. This is just an extremely legacy design. 

 

As to whether I need a 32 bit AVR, I don't know. The only reason I can think of that we do is for a bootloader that's incorporated, or to drive a non-character LCD. The decision was made long before I got here, and it's been in production long enough that I'd need a really good reason to do an overhaul.

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

or to drive a non-character LCD

If you are doing graphics, that might be a decent reason  (generating fonts, gui, etc)....but I've done that with pic18 too!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

erenard wrote:
The only reason I can think of that we do is for a bootloader that's incorporated, ...
Secure Boot may be a system or software requirement.

Revision 3 UC3 (UC3C, UC3L) add :

  • Secure State (FlashVaultTM)
  • FPU (UC3C)

Some UC3 are in Microchip's automotive catalog at 125C.

Might be able to find an arm Cortex-M that has ArmV8-M TrustZone and reaches 125C.

Some Microchip competitors added secure boot to Armv7-M.

 

32-bit AVR UC: Technicall Reference Manual via AT32UC3C0512C - Microcontrollers and Processors

AT32UC3C1512C-AUTOMOTIVE - 32-bit PIC Microcontrollers

TrustZone for Cortex-M – Arm

Create Secured IoT Endpoints with the First 32-bit MCU to Feature Robust, Chip-level Security and Arm TrustZone Technology | Microchip Technology

 

edit :

Most of the AVR ONE! pieces are EOL; if require instruction tracing then consider PIC32 and arm, or, acquire AVR ONE! with spares.

AVR ONE!

https://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=ATAVRONE

Atmel AVR ONE! Debugger (FREE) | AVR Freaks

 

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

Last Edited: Tue. Nov 19, 2019 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PIC32MZ EF has some graphics capability.

Maybe the re-spun PIC32MZ DA-series will obtain an automotive classification as these have a 2D GPU, in-package DDR2 DRAM, and instruction tracing (though MPLAB REAL ICE is NRND)

 

565 LCD Adapter Graphics Card

32-bit Automotive Microcontrollers | Microchip Technology

PIC32MZ2064DAS176 - 32-bit Microcontrollers

HUGE Memory MCU | AVR Freaks

 

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

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

 

gchapman wrote:
PIC32MZ EF has some (sic?) graphics capability

Or, "groundbreaking" graphics capabilities - as Microchip would have it ...

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...