ASF and ATmega

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

The last time I looked at ASF I thought that the claim that it covered the ATmega devices was a bit overblown since it had but a few simple things for it.

What it would need to have for any kind of completeness would be a set of libraries with functionality much like Pascal Stang's library.

What I want to know is that the plan? Has ASF added ATmega functions and is there an effort to make it complete or is the ATmega part of ASF just marketing blather?

My reason for asking is that I'd like to see something like Pascal's libraries upgraded and maintained with a better license and if ASF is going to do this, the other folks won't have to.

Smiley

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

Joe,

So far about the only thing for tiny/mega is some ADC code. It looks like they started then stalled. I wonder if this is because they could see the Arduino "writing on the wall"? Or even because they didn't want to be seen to compete with Arduino?

BTW it's never been clear to me exactly who ASF is aimed at anyway? A lot of professionals would prefer to write their code from the ground up for reasons of maintainability so is it beginners they are targetting? In the Mega world Arduino has kind of got the beginners covered already.

Oh and should I move this to the ASF forum so that someone like "sma" is more likely to see it?

Cliff

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

Quote:
so is it beginners they are targetting?
Search me!! I'm hoping that someone may convince me at the ATOT that ASF is a good thing, everything seems to be buried in layers upon layers of stuff.

NXP seem to do the same thing with their "example projects", it does everything except clarify the issue one wants to learn about.

Hey but I'm an old "grumble bum" (Ted Bullpit for people who don't know :-) )

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

NXP seem to do the same thing with their "example projects", it does everything except clarify the issue one wants to learn about.

That's interesting - I found NXP library code with Xpresso to be pretty good on the whole.

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

clawson wrote:
Oh and should I move this to the ASF forum so that someone like "sma" is more likely to see it?

Cliff

There's and ASF forum? Whoa, I need to start paying more attention. Yes, please move it.

Smiley

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

Quote:
I found NXP library code with Xpresso to be pretty good on the whole.
And so that we don't get in troubles with this I better not go any further. :-)

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I like the ASF for UC3 micros. They're complex enough that I don't really want to write my own code for each peripheral, it'd take forever. Granted, some of the earlier ASF code was pretty bad, but I just looked through some of the 3.5.0 code, and it's pretty nice. Nice enough that I think I'll actually spend some time porting one of my projects from an earlier 3.X ASF to the new 3.5, which will be a fairly involved rewrite, but result in far cleaner code since ASF is a lot more polished.

Regarding Mega/XMega/etc, I tend to just write my own libraries, or find examples on the forums (or Pascal's stuff) if I'm totally lost. But the 8 bit stuff is a *lot* simpler.

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

Ted Bullpit, funny John. So how is the kingswood ?

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

I'm not sure if I'm allowed to mention this here but I've just been reading the datasheet for an LPC800 and they've taken the library code thing one step further. The chip itself now contains some ROM as well as the flash and as well as containing a UART bootloader the ROM provides user level API routines for I2C and UART. Things like uart_setup(), uart_init(), uart_get_char(), uart_put_char(), uart_get_line(), uart_put_line() and so on.

Now THAT is a nice development! Wonder if we'll ever see tiny/mega/xmega doing something like that?

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

How do you address those functions that are provided in ROM?
Of course such an approach may save flash if reusage is possible.
Might be restricted to HW access that does not need OS awareness.

I prefer to have such bsp functions available in both programs:
bootloader and application
(and compiled from source code, like done if you're using the ASF)

It's more flexible if the application is functional without the need to first execute a bootloader. And libraries are often outdated soon. I do not prefer to compile my Linux system all the time like using gentoo. But I like to have control over most of the code I'm using on my AVR32 micro, best all (mos tlatest) code and only if necessary.

By the way, on ARM systems it's quite usual to perform initialization
on Clocks, UARTs, SD-Card and even Ethernet with a bootloader, for instance using "Das UBoot". It may start Linux or any other OS / program, during development even via tftp.

Also a ROM bootloader is quite common that mostly provides a boot strategy.
E.g. SAM AT91 eval boards initially run a ROM first level bootloader that gives you the opportunity to place UBoot on a SD-Card or in NAND, or to start a USB Update process, etc.

-sb

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

Quote:

How do you address those functions that are provided in ROM?

In a word "fuction pointers" (well, OK that's two words). The chip has a pointer hard coded at address 0x1FFFFFF8 which itself then points to a list of pointers. There's one for I2C, one for UART and so on - that one is at + 0x24 from the base. Then it in turn points to a table of 32 bits words which are the pointers to uart_get_mem_size, uart_setup, uart_init and so on (in that order). The chip also exposes bootlaoder "in application programming" functions in the same way.

The LPC800 and especially the $0.39 one in 8pin DIP running Cortex M0+ at 30MHz looks like being a hobbyists dream with 2 UART, SPI, I2C, IO, timers, analog comp etc. You pick which ones of those peripherals you actually want to connect to the pins (after Gnd/Vcc you obviously have just 6 to choose from) so you can kind of make your own chip for any occasion.

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

Quote:
The chip itself now contains some ROM as well as the flash and as well as containing a UART bootloader the ROM provides user level API routines for I2C and UART.

Blatantly copied from TI/Luminary (?), which has been putting much of "stellarisware" in ROM on their Cortex ARMs for years...
From a software perspective, it bugs me a bit. You're either at the mercy of whatever version of firmware is in your ROM, or you face significant "sudden bloat" when you discover that you need to link in a newer version of the libraries. Not that this really matters for an embedded product with no update path, but...

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

"a hobbyists dream" - I agree

-sb

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

...maybe of not much use for a non hobbyist..

Can we split any non topical posts into another thread?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Not necessary to split since my original question was never answered, that is a good enough answer for it.

Smiley

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

yep, asking for a "library" is a kind of rhetorical question but you are right, a public ASF roadmap would be nice. what is your problem about the ASF's license?

-sb

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

Quote:

what is your problem about the ASF's license?

I read the OP as "with a better license [than Pascal Stangs]".

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Atmel may not be willing or want to show their hand early.
My guess is Atmel's 8-bit roadmap is XMEGA-centric with some ATtiny and ATmega (new RF megas) exceptions.
So off into Atmel Spaces we go.
Result's kinda the same (integration via Atmel Studio; all hail Atmel Studio!)

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