Is Atmel Start a good option to create the device drivers instead of writing raw code?

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

Hi AVRfreaks,

I've recently started working with Atmel Studio & came across Atmel start which is looking quite easy to use & I am feeling quite comfortable with it.

I am looking here some advise through good/really bad experiences if anybody had with the Atmel Start.

Just to give you some details about my project:

 

I am working with ATMEGA324PB on a custom designed PCB which will also have Wi-Fi module. So I am going to have drivers for ADC, USART, &  PCINT's.

 

Looking forward to have some decent thoughts.

  

Thanks in Advance,

 

Sam_vir 

#Learning AVR step by step

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

It's really just a question of what you want to learn. Do you want to learn how the bits and bytes work at the register level or do you want to spend the same time learning an API offered by a HAL (Harwdare Adpation Layer) software stack such as ASF3/ASF4(="Start"). an alternative you didn't mention (but that might be worth exploring) is "Arduino". There's bound to be a "core" for 324PB and it can be worth working with and learning the API that Arduino offers as it's universal and makes switching to other architectures easier (say you wanted to jump from 20MHz to 200MHz at some stage!)

 

As a luddite I tend to go bare metal myself but you can perhaps make more progress (as you aren't tied down learning things like what on earth do you have to do to get the UART to 7 bit!) if you use a HAL like Start which is bound to have some kind of uart_config() API already available.

 

One upside of "bare metal" is that you learned then wrote every last bit and byte that the code does so when it comes to debugging something that is not working you will understand every last bit of the code and what it is trying to achieve. If you use a HAL and it heads off into some provided API function you probably haven't got a clue what's going on "inside the black box". So using a HAL requires some amount of "trust" - you have to trust that the HAL writers didn't make any mistakes and that they have tested every last aspect of the interface they deliver. Sadly we sometimes see posts here that suggest someone is using some under-used part of some HAL and it turns out that it was also under-tested and there really is a fault. Atmel / Microchip engineers are just normal engineers and they are as likely to make errors as any of us.

 

To a certain extent that's what's nice about Arduino, it is so widely used that almost every alternative of every piece of functionality has probably already been explored, tested and fixed as a result by 500 people before you.

 

But I still feel you retain "ultimate control" if you do bare metal yourself.

 

BTW nothing you mention (ADC, UART, PCINT) sound like anything particularly complicated (esp in old style tiny/mega models like 324) so any competent programmer should be able to program the bare metal for those from scratch.

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

clawson wrote:
do you want to spend the same (sic?) time learning an API offered by a HAL

Of course, the API/HAL proponents would say that it takes less time to learn their API - but they would, wouldn't they?!

 

In principle, it should be true - you should be able to simply write stuff like

setup_uart( 9600, 'n', 8, 1 );   // Set UART to 9600 baud, No parity, 8 data bits, 1 stop bit

instead of having to calculate the baud rate divisor from oscillator frequency, prescalers, etc, and look up all the other registers for setting the other options.

 

Which is great, as clawson said, for the 95% of cases where you want a "common" set of settings - but no help when you come to a case that needs an "unusual" configuration or use-case that the API hasn't thought of.

 

nothing you mention (ADC, UART, PCINT) sound like anything particularly complicated

Indeed:  in the example above, it really isn't that hard to work out the baud rate divisor, etc - it's just a handful of 8-bit registers on an ATmega.

 

Where the HAL approach really comes in is for the chips with far more complex peripherals - where you may have to be setting many dozens registers, each of which has 32 bits to deal with.

 

My approach would be to start with the API - as that should at least get you something that works.

 

Then, if it meets all your requirements you're done.

 

If it doesn't meets all your requirements, then you can look into optimising or replacing it.

 

eg, see: https://community.atmel.com/comm...

 

This is where the learning curve "overhead" for APIs often comes in - as you have to try to understand what it's doing, and how you can adjust that to your specific requirements.

 

clawson wrote:
HAL (Harwdare Adpation Layer)

also sometimes known as, "Hardware Abstraction Layer".

 

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


Welcome to AVRFreaks!

 

HAL (9000)

Good Morning Dave!

ATMEL Start....   I'm sorry Dave, I can't do that! It's full of bloat and besides the AVR is such a simple chip to work with at the bare metal stage.  Perhaps we could sing a song? 

 

 

Ok, so maybe I've had too much caffeine this morning.  If you have no experience with AVR's, the Atmel start will produce some code for you that should work, but if not you will spend more time trying to understand the code it produces and thus a much longer time spent debugging why it's not working, then you would spend writing it yourself if you are an experienced C or C++ coder.

 

Good luck with your project

 

Jim

 

FF = PI > S.E.T

 

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

ki0bk wrote:
ATMEL Start....   I'm sorry Dave, I can't do that! It's full of bloat and besides the AVR is such a simple chip to work with at the bare metal stage.

 

Amen!

 

ki0bk wrote:
If you have no experience with AVR's, the Atmel start will produce some code for you that should work

Or not, as I have learned...the hard way.

 

ki0bk wrote:
but if not you will spend more time trying to understand the code it produces and thus a much longer time spent debugging why it's not working, then you would spend writing it yourself if you are an experienced C or C++ coder.

Even if you are not, the AVR is pretty easy to learn, and just start a thread about the peripheral you have questions on and we will help.

 

Creating your own 'drivers' is pretty simple to do.

 

Right Side Jim

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

And there is lots of help here if you get stuck!

 

Flyover Jim

 

 

 

FF = PI > S.E.T

 

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

Quick for example....

 

USART0, 9600 Baud, 8-N-1, 8 Megahertz System Clock, no RX or TX interrupt or buffers:

 

// USART0 initialization
// Communication Parameters: 8 Data, 1 Stop, No Parity
// USART0 Receiver: On
// USART0 Transmitter: On
// USART0 Mode: Asynchronous
// USART0 Baud Rate: 9600
UCSR0A=(0<<RXC0) | (0<<TXC0) | (0<<UDRE0) | (0<<FE0) | (0<<DOR0) | (0<<UPE0) | (0<<U2X0) | (0<<MPCM0);
UCSR0B=(0<<RXCIE0) | (0<<TXCIE0) | (0<<UDRIE0) | (1<<RXEN0) | (1<<TXEN0) | (0<<UCSZ02) | (0<<RXB80) | (0<<TXB80);
UCSR0C=(0<<UMSEL01) | (0<<UMSEL00) | (0<<UPM01) | (0<<UPM00) | (0<<USBS0) | (1<<UCSZ01) | (1<<UCSZ00) | (0<<UCPOL0);
UBRR0H=0x00;
UBRR0L=0x33;

 

You also need to set up the IO pins:

// Port D initialization
// Function: Bit7=In Bit6=In Bit5=In Bit4=In Bit3=In Bit2=In Bit1=Out Bit0=In 
DDRD=(0<<DDD7) | (0<<DDD6) | (0<<DDD5) | (0<<DDD4) | (0<<DDD3) | (0<<DDD2) | (1<<DDD1) | (0<<DDD0);
// State: Bit7=T Bit6=T Bit5=T Bit4=T Bit3=T Bit2=T Bit1=T Bit0=T 
PORTD=(0<<PORTD7) | (0<<PORTD6) | (0<<PORTD5) | (0<<PORTD4) | (0<<PORTD3) | (0<<PORTD2) | (0<<PORTD1) | (0<<PORTD0);

 

 

Instead of me posting the START way of doing things I created a project and only turned on the USART0 with the same parameters.  I have attached it for your review.  Get some Advil and keep it close

 

Right Side Jim

Attachment(s): 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

sam_vir wrote:
I've recently started working with Atmel Studio & came across Atmel start ...
ASF4; ASF3 is in Microchip Studio and a zip.

sam_vir wrote:
I am working with ATMEGA324PB on a custom designed PCB ...
Can browse ASF3 documentation on mega324PB.

sam_vir wrote:
... which will also have Wi-Fi module.
There's source code in ASF3 for the three Microchip WINC modules though for SAM.

 


Advanced Software Framework (ASF) | Microchip Technology

https://asf.microchip.com/docs/latest/search.html?device=atmega324pb (ASF3)

Release of Microchip Studio 7.0.2542 | AVR Freaks

 

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

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

sam_vir wrote:
I am working with ATMEGA324PB on a custom designed PCB

 

Make sure you understand the datasheet of that 324pb. It has some must-know areas. Between the low power crystal and the max current in the reduced number of ground pins on that part, I would recommend against it. It can only handle 100mA to ground, unlike most similar mega (e.g., 324p, 328p, 328pb). The low power crystal has tripped up several people (same on 328pb); look at the new AVR128DB datasheet guidelines for its high-speed crystal; that is also correct for the low power crystal layout.

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

gchapman wrote:
There's source code in ASF3 for the three Microchip WINC modules though for SAM.

 

With a bit of porting, WINC1500 works well with the larger AVRs (I've used it with a Mega644 to good effect), so I'm surprised the examples provided are SAM only.

 

WILC1000, on the other hand, would be a trifle harder, as it needs a ~170KB firmware blob and TCP/IP stack.

 

Steve

 

Maverick Embedded Technologies Ltd. Home of Maven and wAVR.

Maven: WiFi ARM Cortex-M Debugger/Programmer

wAVR: WiFi AVR ISP/PDI/uPDI Programmer

https://www.maverick-embedded.co...

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

First of all,

Thanks everyone for putting up your great deal of time in sharing your thoughts and knowledge. Feeling really enthusiastic and confident of my choice of going with AVR platform because of having so much help on hand.  

 

ron_sutherland wrote:

 

I would recommend against it. It can only handle 100mA to ground, unlike most similar mega (e.g., 324p, 328p, 328pb). The low power crystal has tripped up several people (same on 328pb); look at the new AVR128DB datasheet guidelines for its high-speed crystal; that is also correct for the low power crystal layout.

 

I did have some trouble with the low power crystal. For sure it is something I should look into and get it corrected in my design. I could go with 324p, but chip price is another issue, apparently 324p is dearer than 324pb.

 

 

sam_vir  

 

#Learning AVR step by step

Last Edited: Sun. Nov 15, 2020 - 11:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sam_vir wrote:
I could go with 324p, but chip price is another issue, apparently 324p is dearer than 324pb.
Wafer fab of mega324P hasn't completed the transition to larger wafers.

Tempe Fab 2, Gresham Fab 4 | AVR Freaks

GBNG-06LXXH156 | Product Change Notification | Microchip (mega324PB)

 


How to search for Microchip PCNs

 

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