megaAVR ADC driver - request for comments

Log in or register to post comments
Go To Last Post
38 posts / 0 new
Author
Message
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
#1
Posted by alohre: Tue. May 24, 2011 - 11:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am currently working on a megaAVR ADC driver for the AVR Software Framework, and would like to get some feedback from those who will use it:

is this is the kind of driver you would want to see for a megaAVR peripheral in ASF ? If you'd use it: would it be as is, or would you copy/paste the bits you need ?
Are there any other examples that should be included ?

I'm hoping both experienced users and beginners will comment on this, as the two have quite different perspectives.

As a small motivator there will be three JTAGICE mkII given to three posters in the thread before May 27th 09:00 CET where the following criteria has been met:

    on-topic comment positive or negative feedback alike, elaborate on why you like/dislike it.

There are four examples included in the attached archive:

    example1. measure an ADC input, as easy as possible.

    example2. ADC free running mode, single channel average.

    example3. Measure internal bandgap voltage and calculate AVCC from the measurement.

    example4. Free running mode that scan all singleended ADC channels.

Note that this is not finished and reviewed code - there might be typos or bugs in it, but hopefully not :)

The attached archive contains AVR Studio 5 project files. If you are using AVR Studio 4, you need to add the directories in the src/asf folder to a new project manually. The projects have the ATmega2560 set as part, but you can change this to any of the
other supported devices and recompile. the driver itself is located in the src/asf/mega/drivers/adc/adc.h

Andreas

Attachment(s): 

File preliminary megaAVR ADC driver

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, ATmega2560
Last Edited: Tue. May 24, 2011 - 11:54 AM
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. May 24, 2011 - 11:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand your poll. Why do those things have to be mutually exclusive? I want all 3 options please.

(BTW are you sure about example 4? Free running and multi-channel seldom mix well because of the channel switch "lag")

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Tue. May 24, 2011 - 11:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I don't understand your poll. Why do those things have to be mutually exclusive? I want all 3 options please.

you're right; added an "all of the above" option to the poll.

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Tue. May 24, 2011 - 12:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
(BTW are you sure about example 4? Free running and multi-channel seldom mix well because of the channel switch "lag")

This is handled in the ISR: storing channel n, n+1 is in progress and you set the mux to n+2.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. May 24, 2011 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

storing channel n, n+1 is in progress and you set the mux to n+2.

Yes, nasty indeed!

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39515 View posts
Location: Wisconsin USA
Posted by theusch: Tue. May 24, 2011 - 01:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

example4. Free running mode that scan all singleended ADC channels.

"We" (veteran 'Freaks) will discourage that approach. People get confused, and there are at least possibly some races and edge conditions. I'm not even going to go into them, since I use a non-free-running with MUX change in the conversion-complete ISR.

A "driver", eh? I don't see how one-size-can-fit-all based on my experience. Some apps will need smoothing to eliminate jitter on the real-world signal. Some need to act on the latest conversion value. Some need as many ksps as practical; some don't really care if the conversion rate is high. Some have low-impedance signals so mux changes can be made with impunity; some are high impedance and two or more conversions need to be done on a channel to get a good result.

Whatever you do, don't have a lot of |= and &= on ADMUX--it drives me nuts seeing those and it is a very short trip.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Tue. May 24, 2011 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've voted for 'ease of use'. (Actually the first vote cast, looking at the results)
As a hobby user (and relative beginner) the simpler something is to use the better I am able to understand it.
Although, I could have just as well picked 'portability across mega devices' as I build boards based on many of your product lines.
I look forward to trying your code when I'm at home and have a little time :)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Tue. May 24, 2011 - 02:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

theusch wrote:
Quote:

example4. Free running mode that scan all singleended ADC channels.

"We" (veteran 'Freaks) will discourage that approach. People get confused, and there are at least possibly some races and edge conditions. I'm not even going to go into them, since I use a non-free-running with MUX change in the conversion-complete ISR.

I notice that both you and clawson have strong oppinions on this. I have tested the current implementation on multiple devices and speeds, and it works; but there might be corner conditions that I have yet to see.

are there are any other users out there who are doing this in their code, and if so, do you find that it is worth the extra complexity ?

Quote:

A "driver", eh? I don't see how one-size-can-fit-all based on my experience. Some apps will need smoothing to eliminate jitter on the real-world signal. Some need to act on the latest conversion value. Some need as many ksps as practical; some don't really care if the conversion rate is high. Some have low-impedance signals so mux changes can be made with impunity; some are high impedance and two or more conversions need to be done on a channel to get a good result.

I agree to a certain degree, but I also believe that you can have a driver that abstracts and makes it easy for new users, but also provides handy "helper functions" that provide a value for more advanced users as well.
The current driver doesn't do much else than abstract away the register access and providing a read function that blocks until the transfer is complete; but at the same time this should cover quite a lot of users need.

the quirks with smoothing, high-impedance sources are IMHO best suited for examples, and not implemented in the driver itself. This is also why I wanted to know if any of you are missing examples where these kind of user cases are demonstrated.

Quote:

Whatever you do, don't have a lot of |= and &= on ADMUX--it drives me nuts seeing those and it is a very short trip.

There are some cases of this, as if you have a adc_set_mux(mux) you would like it to actually do that; so it's impossible to avoid it completely.
At the same time, you will probably not use this in many other cases than initialization when setting up f.ex an interrupt capture.

the adc_read_8bit and adc_read_10bit are implemented to avoid a read/modify/write to ADMUX when doing a simple conversion.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. May 24, 2011 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a general comment but unlike ASF for Xmega/UC3 don't make this thing so complex you need a degree in logical positivism to use it.

Instead think "Arduino". The traffic on here suggests that the kind of folks who want to use "library code" rather reading a datasheet, understanding a peripheral and then writing their own support code are more likely the beginners who just want to get something going.

An Arduino user would write something like:

int analogPin = 3;     // potentiometer wiper (middle terminal) connected to analog pin 3
                       // outside leads to ground and +5V
int val = 0;           // variable to store the value read

void setup()
{
  Serial.begin(9600);          //  setup serial
}

void loop()
{
  val = analogRead(analogPin);    // read the input pin
  Serial.println(val);             // debug value
}

(I started to write an example but it ended up that the Arduino documentation for analogRead() had something almost identical!)

They don't care how this is implemented or how bloaty or slow it is (a lot of Arduino code is very inefficient, slow and bloaty). The key thing is "instant results" that simply works on all supported CPUs.

The only other API is analogReference(type) where

Quote:
type: which type of reference to use (DEFAULT, INTERNAL, INTERNAL1V1, INTERNAL2V56, or EXTERNAL).

I'm not suggesting you provide C++ (such as Serial.begin()) but, to satisfy the kind of people who need the "crutch" of library code, focus on ease of use and hide every last implementation detail that you can.

The famous Stang and Fleury libs (though admittedly trying to cater for a wider range of AVRs) show that too much configuration just confuses the very people you are trying to cater for.

A further advantage that Arduino users have is that they don't need to #include this, that and the other to get access to the library code. In fact they don't #include ANYTHING though that's maybe pushing it slightly too far (as it would require you to wrap main() like they do) but make the entire library work with a single #include like #include when writing Windows programs or #include when writing avr-gcc programs (mostly). Forcing them to:

#include
#include #include

is a recipe for disaster. Maybe just:

#include

Oh and then there's the issue of actually getting access to the library functions. There's no end of threads here about Stang where the user has failed to realise they must add x.c, y.c and z.c to their own list of files to be built.

While it would be a runtime nightmare doing libraries "the proper way" with a single libasf.a and hence a single -lasf at link time it would be far and away the best way to do it. But that obviously needs run time determination of AVR model and resultant changes to register addresses. The overhead (like Arduino) probably isn't important to the beginner but it'd be a nightmare for you the author. I guess you will need to have them add a .c file to the project. But how about a single asf.c and a command line -DUSING_ADC which causes it to #include the relevant C source files or something? The Stang/Fleury alternative of having them add adcinit.c, adcread.c adcchannel.c (or whatever) to their list of source files (in the right place on the disk!) is otherwise fraught.

Above IMAO.

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Tue. May 24, 2011 - 03:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, there is 'dumming it down' and then there is 'dumming it down'.
You are correct that many Arduino users don't give a toss as to what is actually happening behind the scenes of analogueRead(pin). But to suggest that readers of this forum would have difficulty in organising a few #includes is going a little far?
A real beginner, is probably already using Arduino and frequenting their site. An advanced beginner (using native AVR's), is probably looking at this site for guidance and assistance and should be more than capable of #including several headers to enable various peripheral libraries.

Then again, I often assume 'smarts' where none exist :(

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39515 View posts
Location: Wisconsin USA
Posted by theusch: Tue. May 24, 2011 - 03:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

There are some cases of this, as if you have a adc_set_mux(mux) you would like it to actually do that; so it's impossible to avoid it completely.

We've seen it over and over again on this board. It is faster and less error prone and doesn't introduce any possible RMW races if you rebuild ADMUX each time, from settings for reference selection, ADLAR and other options, and the channel selection. True, your driver approach may introduce another "fetch" of those settings where my apps would probably have it fixed. But it still eliminates any RMW situations where it is fussed with in the mainline and in the ISR.

Quote:

I have tested the current implementation on multiple devices and speeds, and it works; but there might be corner conditions that I have yet to see.

Don't you want your "driver" to be bulletproof?

LIST WHAT YOU THINK YOU ARE GAINING WITH MULTI-CHANNEL FREE-RUNNING.

Consider a fast-running ADC, say 15ksps. Conversion-complete every 66us or thereabouts. ADC ISR is relatively low priority. When it fires there is (say) a USART interrupt being serviced. So far no problem. Then two quadrature interrupts fire on pin-change or external interrupts. Those will get done first. Your ADC ISR is delayed, say, 60us and then it fires.

Just when you get into the ISR, you store the free-running result for your supposed channel and change the mux and expect that to be the next channel. But in the middle of this ADIF is raised again. Now you are off for at least one conversion. And now say that it is my "trip now" value and it is spurious.

I just say "No!" to fighting this kind of thing. Round-robin single conversions work just fine for me, thank you. I've got scores and scores of production apps that use multi-channel ADC over the last 10 years. Is my old-bit-pusher, keep-it-simple experience pertinent? I'll leave that to you.

[Why do I need a "driver" to do

//
//	ANALOG INPUTS
//	=============
//
#define FIRST_ADC_INPUT 0
#define LAST_ADC_INPUT 3

// (index into adc_raw[])
#define	ADC_CH1			3
#define	ADC_CH2			2
#define	ADC_CH3			1
#define	ADC_CH4			0

#define	ADC_CHANNELS		4 // four current sensors


// VREF
// ====
//	Note that in ADMUX, bit 7 is REFS1; bit 6 is REFS0

//	REFS1:0		ADMUX Mask		Description
//	------- 	----------		-----------
//	0 			0x00			External AREF
//	1			0x40			Use Vcc as Aref
//	3			0xc0			Internal 1.1V bandgap
#define	ADC_VREF_VCC	0x40
#define	ADC_VREF_AREF	0x00
#define	ADC_VREF_BG		0xC0


#define ADC_VREF_TYPE ADC_VREF_VCC

...
// ADC initialization
// ADC Clock frequency: 57.600 kHz
// ADC Voltage Reference: AREF pin
// ADC Auto Trigger Source: None
// Digital input buffers on ADC0: Off, ADC1: Off, ADC2: Off, ADC3: Off
// ADC4: On, ADC5: On
DIDR0=0x0F;
ADMUX=ADC_VREF_TYPE; // start "dummy" converion on channel 0
ADCSRA=0xCE;

...
//
// **************************************************************************
// *
// *		A D C _ I S R
// *
// **************************************************************************
//
// ADC interrupt service routine
// with auto input scanning
interrupt [ADC_INT] void adc_isr(void)
{
// Read the AD conversion result
	adc_raw[ad_index] = ADCW;

// Select next ADC input
	if (++ad_index > (LAST_ADC_INPUT-FIRST_ADC_INPUT))
		{
		ad_index=0;
		}
	ADMUX = ADC_VREF_TYPE + FIRST_ADC_INPUT + ad_index;

// Start the AD conversion
	ADCSRA |= (1 << ADSC);

}

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Tue. May 24, 2011 - 03:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice example, thanks Lee. (I shall definately be borrowing this :) )

Quote:
Why do I need a "driver" to do
Perhaps to avoid situations like...

#define   ADC_VREF_VCC   0x40 
#define   ADC_VREF_TYPE ADC_VREF_VCC 
// ADC Voltage Reference: AREF pin

I know it's only a non-updated comment, but thats enough to throw a learner a curve ball.

;)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Last Edited: Tue. May 24, 2011 - 03:15 PM
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. May 24, 2011 - 03:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greg,

We'll have to agree to disagree then. Something like an ADC is fairly trivial and a "knowledgeable" programmer will just read the d/s and implement the code. It's not rocket science. If someone needs the "crutch" of library/driver/support code I'd suggest they ARE at the Arduino level, maybe at the just-beyond-Arduino-and-looking-to-use-real-C stage?

Heck we even get people starting threads here asking for "driver code" for SPI - I mean, come on - if you can't work out how to set 3 registers to make something happen you are SEVERELY in need of help.

The point of complexity where I think anyone starts to benefit from pre-written tried, tested code probably is something like HD44780. Obviously something like ENC28J60 requires a lot of support code that anyone might benefit from getting something pre-written. But a timer doing a CTC interrupt or an ADC making one channel reading or an SPI sending (and receiving!) one byte? If you are looking for "driver code" for these simplistic things you want it pretty darned simple!

I also think an ASF for tiny/mega is going to be somethign different to that for Xmega and UC3. Those are "grown up" MCUs with quite a bit of complexity that even professionals could do with a "hand holding" to use. Setting up events to DMA from an ADC to a port or something probably isn't a case of setting 3 registers. So for that a "BSP"/driver style package is justified. But the reason people start with AVR8s is that, on the whole, everything is so darned simple and the "customer" for support software has a different profile.

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Tue. May 24, 2011 - 03:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, you are of course correct. I assume too much of people. Perhaps when people ask for this VERY basic level of help and support, they should be directed to www.arduino.cc ? :) Just joshing with you! Of course, they should be directed to the tutorial's forum.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. May 24, 2011 - 03:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

they should be directed to

This perhaps:

http://code.google.com/p/avr-drv/

I wonder how many people knew of that's existence? Did the ASF writers at Atmel? How about a bit of "joined-up-development" here?

One of the key things there (compared to Stang) is the BSD, not GPL licence (just in case this ever makes it out of the hobbyists bedroom).
I actually found that when looking for Joe's "Arduino-alike" which I though ws on code.google? That's another software tree headed in the same direction and really focussed on getting the Arduino users over the Arduino to C transition.

When I search "Joe Pardue" on code.google all I hit is:

http://code.google.com/p/beavr/

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Tue. May 24, 2011 - 03:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://code.google.com/p/avr-drv/
Yes, I was aware of that one :) I see it's 'getting near completion.' :)
I didn't know of 'beavr' however.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Top
indianajones11
indianajones11's picture
Level: Raving Lunatic
Joined: Sun. Nov 28, 2004
Posts: 3978 View posts
Location: San Diego, Ca
Posted by indianajones11: Tue. May 24, 2011 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What I like about it is that beginners can learn how it's done correctly, because there are ALOT of threads about using the ADC and many times the problem's about coding something the wrong way. For me, I would copy / paste whatever I might find useful / educational to an ADC module file that I've been working on for my AS4 projects. If nothing else it saves me time.

alohre wrote:

are there are any other users out there who are doing this in their code, and if so, do you find that it is worth the extra complexity ?
Not for mega class MCUs, but if it makes dealing with the AVR32 class easier , then maybe... it depends on how complex the complexity is !

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Wed. May 25, 2011 - 08:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

LIST WHAT YOU THINK YOU ARE GAINING WITH MULTI-CHANNEL FREE-RUNNING.

Consider a fast-running ADC, say 15ksps. Conversion-complete every 66us or thereabouts. ADC ISR is relatively low priority. When it fires there is (say) a USART interrupt being serviced. So far no problem. Then two quadrature interrupts fire on pin-change or external interrupts. Those will get done first. Your ADC ISR is delayed, say, 60us and then it fires.

Just when you get into the ISR, you store the free-running result for your supposed channel and change the mux and expect that to be the next channel. But in the middle of this ADIF is raised again. Now you are off for at least one conversion. And now say that it is my "trip now" value and it is spurious.

I just say "No!" to fighting this kind of thing. Round-robin single conversions work just fine for me, thank you. I've got scores and scores of production apps that use multi-channel ADC over the last 10 years. Is my old-bit-pusher, keep-it-simple experience pertinent? I'll leave that to you.

Thank you for this input, i agree on the KISS principle and I will reconsider this example.

To all of you who have commented so far - thank you! it is great to get this kind of feedback. I really appreciate you guys taking the time to share your opinions.

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Wed. May 25, 2011 - 08:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

http://code.google.com/p/avr-drv/

I wonder how many people knew of that's existence? Did the ASF writers at Atmel? How about a bit of "joined-up-development" here?

One of the key things there (compared to Stang) is the BSD, not GPL licence (just in case this ever makes it out of the hobbyists bedroom).
I actually found that when looking for Joe's "Arduino-alike" which I though ws on code.google? That's another software tree headed in the same direction and really focussed on getting the Arduino users over the Arduino to C transition.

When I search "Joe Pardue" on code.google all I hit is:

http://code.google.com/p/beavr/

I did not know about that project and will check it out. It also led me to this topic: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=84072
that had a lot of interesting posts. Thanks for the pointer

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. May 25, 2011 - 09:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

that had a lot of interesting posts

There was a really interssting one in there I thought - where someone suggested having something like the Codevision Codewizard which dynamically generates peripheral support code according to the choice of AVR the user made.

Have you heard of "Atman AVR"? http://www.atmanecl.net/atmanavr/ That's something very similar but for GCC, not CodeVision. Perhaps Atmel should just buy "Atman" and incorporate their IPR in AS
?

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39515 View posts
Location: Wisconsin USA
Posted by theusch: Wed. May 25, 2011 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Thank you for this input, i agree on the KISS principle and I will reconsider this example.

But answer:
Quote:

LIST WHAT YOU THINK YOU ARE GAINING WITH MULTI-CHANNEL FREE-RUNNING.

If you have no "gain" in that approach, but there are obvious (keeping track of the previous) and perhaps subtle (races) "negatives", then why are you bent on using it?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Wed. May 25, 2011 - 03:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Quote:

But answer:
LIST WHAT YOU THINK YOU ARE GAINING WITH MULTI-CHANNEL FREE-RUNNING.

If you have no "gain" in that approach, but there are obvious (keeping track of the previous) and perhaps subtle (races) "negatives", then why are you bent on using it?

I am not bent on using it; I was agreeing with you that there is no gain in providing the example.

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Wed. May 25, 2011 - 05:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have one observation which regards F_CPU in conf_clock.h
If you wrapped the define with a ifndef, it would eliminate the possible multiple define error which could occur as it stands. Adding a compiler warning if this include does define it, might make it easier to fix for a user and to serve as a reminder to set the clock up properly.
Apart from that minor niggle, I like the library (sorry, driver) :)

If this is covered in you 'project' settings somewhere, I apologise. I don't use Studio (as such) as I'm a Mac user ;)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Top
Mongooose
Mongooose's picture
Level: Hangaround
Joined: Thu. Sep 25, 2008
Posts: 139 View posts
Location: Alabama Gulf Coast
Posted by Mongooose: Thu. May 26, 2011 - 02:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First of all I am curious as to what exactly is the difference between a diver and a library?

I would also suggest to not "abstract away" the registers. In my newbie approach I would prefer what I understand to be more of a library (or maybe template?) that can teach me how to do something. Then if no "driver" is available for a different mega/tiny/at32/orwhatever I may be using I can still make it work.

I do like example programs, especially when commented to explain what is being done, even if they show a method or process that is not typically accepted.

I probably need to explore the software framework to see what it has to offer, as I did not realize there was one for 8 bitters. So far data sheets, these forums, and Fluery's LCD library have worked fine for what I have done so far, albeit not as fast as I would always like.

I have an idea as to what I think ( from a relative newbie perspective) would be helpful. I will try and get an example done to show my idea and post it soon.

Top
rledyard
rledyard's picture
Level: Hangaround
Joined: Tue. Feb 25, 2003
Posts: 114 View posts
Location: SW Virginia, USA
Posted by rledyard: Thu. May 26, 2011 - 06:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

couple of comments as a hobby user

1. I like clawson's suggestion of a wizard inside the framework to spit out some template code, like CodeVision does. I have a feeling that is a real selling point for that compiler. Whether that is within the scope of what your are doing here is an entirely different matter, perhaps.

2. Perhaps also not in the scope of this, but a driver/library for text LCD's would also be nice. Or again, a wizard to set up some template code to get the new user up and running quickly from AVR Studio, without having to bolt a commercial compiler onto it. Now that Atmel is using Visual Studio, a wizard as an add-in should be a fairly trivial thing.

@clawson - you were asking about Joe's latest project - its called avrtoolbox, and is found here: http://code.google.com/p/avrtoolbox/

Top
smileymicros
smileymicros's picture
Level: Raving Lunatic
Joined: Wed. Nov 17, 2004
Posts: 6320 View posts
Location: Great Smokey Mountains.
Posted by smileymicros: Thu. May 26, 2011 - 09:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rledyard wrote:
@clawson - you were asking about Joe's latest project - its called avrtoolbox, and is found here: http://code.google.com/p/avrtoolbox/

Please note that I'm doing this is much for my own learning as to provide a useful product. I've been writing articles for Nuts&Volts on this and the first things I needed to do was settle on standards. I think it is standards more than anything that keep many open source projects from moving forward. I've seen folks willing to spend huge amounts of time arguing about where to put brackets but not seem to be able to get something as simple as SPI finished. I've written up my standards for C coding, documentation with Doxygen, creating libraries, using Tortoise SVN and etc. One of my goals, once I've learned enough and produced enough code is to see if any of this is suitable for the avr-core in avrlibc. I've consulted some with Eric and he has shared some code.

So far I've produced an Arduino-like serial library, ring and usart libraries based on some old code of mine and some newer code from Eric. At the moment I'm finishing up a usart library. It is all a bit chaotic at the moment, but I'm hoping to have a done deal in a few months with all the processes and procedures in place and example libraries for SPI, serial, ring, usart, adc, and pin based I/O (Arduino-like).

One of the things that I'm bringing to the table is that in addition to having all the source code available written to a defined process, I will have all the code tested for the Butterfly (ATmega169), Arduino board(ATmega328, and an ATmega644, all of which should provide a basis for others wanting to port the code to different AVRs.

Some of the Nuts&Volts articles related to this are in my www.smileymicros.com\blog under avrtoolbox. And I haven't yet put the newest stuff on google code, so until you see libavr in the trunk, it isn't synchronized with my current work. I'll try to run SVN tonight since avrtoolbox is becoming topical.

I think I said back in 09 that it seems like everybody is doing this and reinventing the wheel, but since it is an for my personal learning and writing, then I don't mind so much duplicating the work of others.

I should probably start posting some more of the standards and code here to get gut ripped and maybe improved a little.

[edit]
Sorry, this was a bit of a hijack - just ignore what I said. I'll start a new thread when I'm ready.
[/edit]

Smiley

Last Edited: Fri. May 27, 2011 - 03:04 AM
Top
zbaird
zbaird's picture
Level: Raving Lunatic
Joined: Sun. Aug 13, 2006
Posts: 7472 View posts
Location: Bellingham, WA - USA
Posted by zbaird: Thu. May 26, 2011 - 10:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess my priorities are that the thing work, that it's fast, easy to use, and portable, in that order. If it doesn't work then all bets are off; if it isn't fast enough, likewise. The learning curve only has to be climbed once (well, once every so often for us elderly). I don't personally find portability that much of an issue, although I realize others will.

I like the way your examples go from simple to complex. One thing I'm missing, not only here but overall, is the big picture of the software framework and exactly how it serves the developer's needs. I had pretty much ignored the forum topic after it was set up, but even now I don't find the manager's summary that might explain what all the fuss is about. Obviously a standardized, self-documenting, etc. style is good, but there's a lot of packing materials surrounding those few lines of precious code. It would be nice to know why.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Fri. May 27, 2011 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregsmithcts wrote:
I have one observation which regards F_CPU in conf_clock.h
If you wrapped the define with a ifndef, it would eliminate the possible multiple define error which could occur as it stands. Adding a compiler warning if this include does define it, might make it easier to fix for a user and to serve as a reminder to set the clock up properly.
Apart from that minor niggle, I like the library (sorry, driver) :)

If this is covered in you 'project' settings somewhere, I apologise. I don't use Studio (as such) as I'm a Mac user ;)

This is actually a mistake from my side. I was considering an example that was using the avr-libc delay functions, but didn't as it's not portable to IAR; as the conf_clock is not used, it shouldn't be there at all.

In regards to the driver/library naming: the way it is done in ASF is to name code that controls a peripheral/functionality a driver; that's just the naming convention.

(you will then typically have services on top of that that can use one or more drivers to perform some actions, ie FAT filesystem and so on.)

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Fri. May 27, 2011 - 01:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mongooose wrote:
First of all I am curious as to what exactly is the difference between a diver and a library?

see my post above - assuming that you are referring to driver and not a ocean diver; that difference might be slightly larger :)

Quote:

I would also suggest to not "abstract away" the registers. In my newbie approach I would prefer what I understand to be more of a library (or maybe template?) that can teach me how to do something. Then if no "driver" is available for a different mega/tiny/at32/orwhatever I may be using I can still make it work.

I do like example programs, especially when commented to explain what is being done, even if they show a method or process that is not typically accepted.

In the current implementation it's not really that much abstracted; it's simply hidden away behind a more user friendly name. You can easily pick up what is being done from looking at the driver source.

Quote:

I probably need to explore the software framework to see what it has to offer, as I did not realize there was one for 8 bitters. So far data sheets, these forums, and Fluery's LCD library have worked fine for what I have done so far, albeit not as fast as I would always like.

I have an idea as to what I think ( from a relative newbie perspective) would be helpful. I will try and get an example done to show my idea and post it soon.

The ASF is included with Studio 5, but you can also download it for standalone use here: http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4192 . The easiest way to get a quick overview is the new example project wizzard in Studio 5, where you can sort on device to see all the 8 bit example projects (the major part being xmega).

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. May 27, 2011 - 01:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the major part being xmega

There are tiny/mega ones too? I thought ASF so far was only for Xmega+UC3 ?

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Fri. May 27, 2011 - 02:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson: you're right, the ASF 2.4.0 that is shipped with Studio 5 beta 2 is xmega/UC3 only.

correct to: "All 8-bit examples are xmega"

Top
alohre
alohre's picture
Level: Moderator
Joined: Fri. Feb 3, 2006
Posts: 54 View posts
Location: Trondheim, Norway
Posted by alohre: Fri. May 27, 2011 - 02:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And we have the winners for the JTAGICE mkII draw! (All the posters where included in the draw)

theusch
Mongooose
indianajones11

Please send me a PM with your address and I'll get them shipped.

Again, thank you all for your input; it's really appreciated.

Andreas

Top
Mongooose
Mongooose's picture
Level: Hangaround
Joined: Thu. Sep 25, 2008
Posts: 139 View posts
Location: Alabama Gulf Coast
Posted by Mongooose: Thu. Jun 9, 2011 - 04:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wooo Hooo! I received my JTAGICE mkII today! Will be trying it out this evening! I really appreciate it Atmel!

Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29026 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
Posted by js: Thu. Jun 9, 2011 - 11:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Most important part of a megaAVR driver
It MUST be written in assembler like the rest of the "framework" :?

(can moderators abuse their privileges and add bits to polls? 8) )

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
indianajones11
indianajones11's picture
Level: Raving Lunatic
Joined: Sun. Nov 28, 2004
Posts: 3978 View posts
Location: San Diego, Ca
Posted by indianajones11: Thu. Jun 9, 2011 - 11:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:D I received mine today also ! :D I'll put it to real GOOD use ( I just did a debug session of my mp3 player using an xmega16A4... Too nice !! ) ! Thank you Atmel !! :mrgreen:

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97007 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jun 10, 2011 - 08:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I received mine today also

You received a "megaAVR ADC driver"? (subject of this thread).

Top
gregsmithcts
gregsmithcts's picture
Level: Raving Lunatic
Joined: Thu. Nov 4, 2010
Posts: 2098 View posts
Location: Bristol, UK
Posted by gregsmithcts: Fri. Jun 10, 2011 - 08:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pedant!

:)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29026 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
Posted by js: Fri. Jun 10, 2011 - 09:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You received a "megaAVR ADC driver"?
And was it in assembler or BASIC or Pascal? Otherwise, really, the ASF is of not much use to the vast majority of users is it? :mrgreen:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top