Prefered Board Support

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

Putting together a board support for a custom board, it is not clear what code or libraries should be used for processor internal peripheral support.
 

There is a profusion of include files for the AVR processors and it is hard to know which one is best supported.  The ASF files are really complicated and cluttered.  #include <atmel_start.h> seems incomplete.  There are older include files, but they seem to be broken.  Since the reorganization of the online files, things have gotten messier, as the links to documentation have been broken.

 

What support / include files are prefered?

This topic has a solution.

Last Edited: Thu. Mar 1, 2018 - 10:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never seen any evidence that "older include files are broken". I use them all the time. Yes, it will take a bit before some of the really new Mega 0-series devices make in into the include file system, but they will.

 

All you need to do is:

 

#include <avr/io.h>

Then, you tell the IDE which board you are using and it is all taken care of.

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

The thread title says board support, but the OP talks about chips. Clearly, these are separate things.

 

Doesn't ASF just use the "old" (sic) headers anyhow?

 

Clearly, if you use ASF, then you will use the ASF headers.  If you don't use ASF, there's not point.

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

If this is about ASF I will move it to the ASF forum - please clarify.

 

Moderator

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

The original question was, "What support / include files are prefered?"

 

There is: #include <atmel_start.h> which has issues.

 

Using the include proposed by ka7ehk.

 

#include <avr/io.h>

 

Is an way to get register definitions.
However, it is not the only one.

 

Is this method the most prefered and supported way to use as a foundation for chip/board support?

Last Edited: Tue. Feb 27, 2018 - 01:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trivet wrote:
Is this method the most prefered and supported way to use as a foundation for chip/board support?

For chips, Yes - but nothing to do with boards.

 

As noted, if you are using ASF - then that will do it for you.

 

If you use some other framework, it will probably do it for you -RTFM for details

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:

If you use some other framework, it will probably do it for you -RTFM for details

 

And choosing AVR code support is enigmatic; as there are so many options and non seem to be well documented.

This is compounded by finding TFM to read is not such an easy task. https://www.avrfreaks.net/forum/d...

 

For example: The one technically useful response in this thread

 ka7ehk wrote:
 #include <avr/io.h> 

had no reference to were the related documentation is or could be found.

Last Edited: Tue. Feb 27, 2018 - 01:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trivet wrote:
had no reference to were the related documentation is or could be found.
It's on your hard drive - did you look at the Help in AS7 at all?

 

While this might be for a slightly different version the AVR-LibC user manual is always online at:

 

http://www.nongnu.org/avr-libc/u...

 

Among many other things that documents:

 

http://www.nongnu.org/avr-libc/u...

 

The manual also has this to show which devices are supported:

 

http://www.nongnu.org/avr-libc/u...

 

But it's still not clear to me what it is you are trying to achieve. Are you trying to use ASF? Are you trying to use Start? Which model of AVR are you actually talking about?

 

(if you are using ASF or Start they each will probably have just a single include like <asf.h> or <atmel_start.h> or something and those in turn will be (among other things) including <avr/io.h>)

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

and ASF Documentation: http://asf.atmel.com/docs/latest/

 

When I said "some other framework", that meant other than ASF.

 

Clearly, if you want to use some other framework, then finding its documentation will be the first part of your task...

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: 1

The OP seems to suggest that there are choices where there are (effectively) none. The use, again and again, of the term "code support" is also a bit puzzling. And the OP seems to mis-understand the need for some of the #includes. Here is how >>I<< understand things.

 

A. #include <avr/io.h> gives you register and memory definitions, plus a few "secondary" things like device signature. This is really not just one file but a whole chain of files that are automatically accessed according to the MCU type that specify when creating a new project (there are some other ways to do this, also). That is ALL that <avr/io.h> does. It is supplied by Atmel/Microchip. The whole set of files is automatically installed as part of the Atmel Studio installation. Personally, I do not consider this optional. Use it or inflict huge pain upon yourself. 

 

B. There is the set of libraries that are part of avr-libc which is NOT a "framework". These are (mostly) a third party effort. Many of the libraries implement standard c-language functions like strlen() or strcat(), to name just two of many. These are also part of the standard Atmel Studio installation. you add various capabilities through specific includes, such as #include <stdlib.h> or #include <string.h>. You can find out about avr_libc at https://www.nongnu.org/avr-libc/... (as given, above). Use is totally optional though I would have a really hard time working without <avr/interrupt.h> and a few others. 

 

C. ASF IS a framework. It is aimed, as I understand it, mostly at the SAM series chips though it has a little support for XMega devices and even less for standard Mega chips and maybe none for standard Tiny. This is totally, as far as I understand, a product of Atmel/Microchip.

 

D. Start, which I know VERY little about, appears to be another framework (but I could be very wrong). It seems to have more support for the 8/16 bit devices. There have been a few threads about use of this framework. It, again, appears totally to be a product of Atmel/Microchip. I get the feeling that some of the  structure of Start is borrowed, a bit, from Arduino, and has explicit support for the various "Xplained" boards though it appears to work on (nearly) any board.

 

But none of this deals with "code support". What is it that you are really asking, here? It all seems to be a big puzzle?

 

Jim

 

 

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Feb 27, 2018 - 05:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
avr-libc ... is NOT a "framework".

I would agree.

 

Maybe the OP has a different interpretation of "framework", but I was not including avr-libc when I spoke of "frameworks".

 

C. ASF IS a framework.

I would agree.

 

This is totally, as far as I understand, a product of Atmel/Microchip.

Agree.

(the licence terms specifically forbid its use on non-Atmel parts)

 

 

D. Start, which I know VERY little about, appears to be another framework (but I could be very wrong).

I also know next to nothing about Start.

 

From what I've seen, it seems to be a code-generation wizard to write your startup code for you.

 

AIUI, The code it generates uses ASF.

 

 

What is it that you are really asking, here? It all seems to be a big puzzle?

Indeed!

 

 

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

trivet wrote:

Putting together a board support for a custom board, it is not clear what code or libraries should be used for processor internal peripheral support.

...

What support / include files are prefered?

awneil wrote:

What is it that you are really asking, here? It all seems to be a big puzzle?

ka7ehk wrote:
 Indeed!

 

Perhaps there there is a disconnect in language (these are taken from the wiki internet encyclopedia).

  • Board support is the software that provides virtual abstraction to hardware and often includes basic services, such as a boot loader.
  • Software framework, in computer programming, is an abstraction in which common code providing generic functionality.
  • A board or printed circuit board (PCB) mechanically supports and electrically connects electronic components or electrical components using conductive tracks, pads and other features etched from one or more sheet layers of copper laminated onto and/or between sheet layers of a non-conductive substrate.
  • Code or source code is any collection of computer instructions, possibly with comments, written using a human-readable programming language, usually as plain text. 
  • An integrated circuit or monolithic integrated circuit (also referred to as an IC, a chip, or a microchip) is a set of electronic circuits on one small flat piece (or "chip") of semiconductor material, normally silicon.

 

In this context chip is referring to the AVR microprocessor, which has a complex set of on die peripherals, such as oscillators, timers, serial ports, USB, GPIO, et cetera.  These peripheral components have defined register interfaces and need software support to configure and operate them.

 

As for my essential question, I have a custom hardware design, and code ported to the AVR processor to perform the required functions.

The existing code was developed with a minimum of dependencies on external code or libraries (e.g. hand coded references to registers as defined by the data sheets).

 

As part of diligence, I am looking to leverage existing code support for the AVR device by using standard 'whatever it is called' for things like register definitions and possibly basic functions, such as boot loader.

 

To be more clear, the request is in regards to common practices in terms of basic software support for the AVR processor.

 

It seems that the answer is:

#include <avr/io.h>

 

Apologies, if my clumsy use of language has caused confusion.

Last Edited: Wed. Feb 28, 2018 - 03:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trivet wrote:
 hand coded references to registers as defined by the data sheets

That seems just silly - a waste of time & effort. But, worse than that, the  chances of errors creeping in with manual transcription tend to 100% !!

 

surprise

 

As Jim noted earlier, the Atmel-provided headers are auto-generated form the chip's design data - so the chance of errors is very much lower.

 

 

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

Trivet wrote:
The existing code was developed with a minimum of dependencies on external code or libraries (e.g. hand coded references to registers as defined by the data sheets).
Then why are you even considering ASF / Start ? The fact is that probably the vast majority of AVR programs written in avr-gcc rely on very little more than <avr/io.h>. Sure there are other associated headers that come with the libc:

 

http://nongnu.org/avr-libc/user-...

 

So if you planned to use interrupts you'd likely also use <avr/interrupt.h> and if (for example) you planned to use the EEPROM you would use <avr/eeprom.h> and so on. But what's offered there is a fairly extensive set of "all you need" to write the vast majority of AVr programs.

 

Sure if you hit some peripheral that looked so complex you couldn't work out how to operate it by just programming the registers directly you *might* look to use a library like ASF or Start (or perhaps Fleury or Stang code?) but most tiny/mega peripherals are so simple you can just hit them directly with no "help" from 3rd parties.

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

clawson wrote:

Trivet wrote:
The existing code was developed with a minimum of dependencies on external code or libraries (e.g. hand coded references to registers as defined by the data sheets).
Then why are you even considering ASF / Start ? The fact is that probably the vast majority of AVR programs written in avr-gcc rely on very little more than <avr/io.h>

Prior to this thread, I had not seen in the Studio examples or various document references to io.h, hance the origin request in this thread for recommendations.

 

As for errors, hand coding provides complete visibility into the code..  Hand coding take a little more time and does require diligence in testing.  Vetting large blocks of code can be difficult.

 

The last time I used an AVR was 20 years ago.  Back then finding a C compiler that generated reliable code was a breath of fresh air.  There were was not much in the way of support, beyond basic tools.  That project went from scribbles on a napkin to a product, ready for high volume production, in a matter of a few months.  

There was not a lot in terms of support files and what was available was - messy.  Hand coding the registers and memory map by hand was quick and reliable.  If there were problems, they would be catastrophic, so easy to recognize.  The code had no problems through QA and after release, the only issue I was made aware of was an analog hardware issue; which yielded to a half day consultation.

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

If it is "board support" you want, the champion model MUST be Arduino. There MAY be  something along these lines in ASF and Start. Start, particularly, "knows" about  Xplained boards. 

 

Many of us, here, will argue that "software support" is between you and the spec sheet. There ARE some handy wizards out there, particularly for fuses and timers. There are quality libraries for things like SPI, TWI/I2C, serial  comms, LCD interfaces, and such. But, unless you go to Arduino, there is no one unified package that works with Tiny, or Mega, or Xmega chips. ASF does that, or some of that, but its reach down into the 8/16 bit range is limited, at best.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

ka7ehk wrote:
If it is "board support" you want, the champion model MUST be Arduino.

XMega For Arduino · GitHub

https://github.com/XMegaForArduino

is alive and well though with several bugs, not a complete set of libraries, and not all XMEGA.

 

An alternative to the Arduino framework is an RTOS or an event framework though not much for XMEGA in those.

 

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

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

ka7ehk wrote:
There MAY be  something along these lines in ASF

Atmel Studio "knows" about the XPlained boards, and will create specific examples for each one.

 

Part of that is a header (or headers) that define the board-specific features.

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...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

We have had a week of dialog, dozen posts and the primary useful information was to #include <avr/io.h>.

​For the instant project, at best a lateral move from the hand coded include file that was working just fine.

The module is passing data to the host.
The current inquiry needs to close.

 

Thanks to everyone for their efforts.