| Author |
Message |
|
|
 Posted: May 27, 2011 - 02:27 AM |
|
Joined: Jan 23, 2004
Posts: 9820
Location: Trondheim, Norway
|
|
Brilliant Eric! Glad to hear it, as I'm sure the Arduino folks will be too (they pull from WinAVR for their Windows environment, correct?). The Atmel toolchain works fine for me, but is missing mfile and the GNU tools associated with it that I and many others rely on for making external makefiles outside of Studio.
- Dean  |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 04:23 AM |
|
Joined: Mar 28, 2001
Posts: 20325
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
Quote:
I'm sure the Arduino folks will be too
Don't know about that. Their latest version 0022 still uses WinAVR-20081205!!
...don't ask how I know, too painfull to recall...but it's a job. |
_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 05:43 AM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
js wrote:
Their latest version 0022 still uses WinAVR-20081205!!
...don't ask how I know, too painfull to recall...but it's a job.
Please, tell (not about your pain, only the raw reason  ).
Just let me guess first. They overwrite the PATH without warning. But isn't it the way how WinAVR's installer works, too? This IMHO deserves a bit of thought...
(...add my usual b***ing about lack of changelog ... and other documentation... like why can't there be a toolchain documentation, and why is avr-libc's documentation seen as substitute... now comes Joerg saying "oh yeah and what of that is YOU going to do... I shut up now...)
Jan |
|
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 06:18 AM |
|
Joined: Mar 28, 2001
Posts: 20325
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
Don't want to derail the thread with Arduino stuff now.  But it seems a perfect environment for brain dead people who don't want to know anything about the hardware or the software and just make lights blink.
Should we start another thread for the firefight? 
[yes + 1 ] |
_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 10:24 AM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
js wrote:
Don't want to derail the thread with Arduino stuff now. But it seems a perfect environment for brain dead people who don't want to know anything about the hardware or the software and just make lights blink.
Should we start another thread for the firefight?
To discuss what?
The technical merits and shortcomings of Arduino/environment, or the mental shortcomings of their proponents and users?
I'd love to hear more on the former from a professional's viewpoint. I don't Arduino and I don't dig the idea, but I love to hear about others' failures...
Jan |
|
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 10:27 AM |
|
Joined: Jul 18, 2005
Posts: 62227
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
Just let me guess first. They overwrite the PATH without warning. But isn't it the way how WinAVR's installer works, too?
Wrong I'm afraid. Arduino happily co-exists with other WinAVRs - it does not touch the PATH. I guess it knows where it's installed and just invokes its own local WinAVR utilities absolutely. |
_________________
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 10:36 AM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
clawson wrote:
Quote:
Just let me guess first. They overwrite the PATH without warning. But isn't it the way how WinAVR's installer works, too?
Wrong I'm afraid. Arduino happily co-exists with other WinAVRs - it does not touch the PATH. I guess it knows where it's installed and just invokes its own local WinAVR utilities absolutely.
Okay, I lost, I pay. Which bar today, Cliff?
Jan |
|
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 11:23 AM |
|
Joined: Sep 05, 2001
Posts: 2496
|
|
WINAVR wish list:
Is it possible to add a method to define structs inside the Flash?
E.g.:
Code:
typedef struct{
char __ATTR_PROGMEM__ *name;
uint8_t (__ATTR_PROGMEM__ *func)();
}comm_struct;
comm_struct __ATTR_PROGMEM__ comm_tab[] = { // command table
"REM", remote,
"LOC", local,
"STAT", status,
"", NULL // end of table
};
Peter |
|
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 11:30 AM |
|
Joined: Jul 18, 2005
Posts: 62227
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Eric,
Actually Peter's request makes me wonder where GCC is with generic multi-memory space support?
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 01:11 PM |
|
Joined: Dec 20, 2002
Posts: 7276
Location: Dresden, Germany
|
|
> where GCC is with generic multi-memory space support?
Ask Georg-Johann. |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 07:36 PM |
|
Joined: Mar 01, 2001
Posts: 4952
Location: Rocky Mountains
|
|
|
dl8dtl wrote:
> where GCC is with generic multi-memory space support?
Ask Georg-Johann.
Actually, last I heard is that it was being worked on internally. I'll be finding out the status of various work on the toolchain in about 2-3 weeks. |
|
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 07:43 PM |
|
Joined: Mar 01, 2001
Posts: 4952
Location: Rocky Mountains
|
|
As to the Arudino topic:
I understand that there are engineers that work in the embedded field that don't think highly of the Arduino environment, and I can understand their reasoning.
However, the Arduino boards and programming environment has done more to get people involved in doing something with embedded systems than anything else, and ultimately it should not be disparaged. Everyone at some point had to go along the engineering learning curve with embedded systems. The Arduino environment represents just part of that spectrum. It gets people excited about doing something with embedded systems, and that's a good thing, not a bad thing.
So if you don't like it, then go change the channel and ignore the talk about it. |
_________________
Eric Weddington
Marketing Manager
Open Source & Community
Atmel
|
| |
|
|
|
|
|
|
Posted: May 27, 2011 - 08:10 PM |
|
Joined: Dec 16, 2005
Posts: 3086
Location: Bratislava, Slovakia
|
|
|
mckeemj wrote:
documentation might come a near second, however, where there are specific requests for clarification ( I've personally found the avr-libc documentation sufficient ).
Do you mean the documentation documents sufficiently avr-libc's functionality; or you mean that the status-quo of avr-libc documentation documenting the whole toolchain is adequate?
I beg to disagree with the latter.
Jan |
|
|
| |
|
|
|
|
|
|
Posted: May 28, 2011 - 12:05 AM |
|
Joined: Mar 28, 2001
Posts: 20325
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
|
|
|
|
|
Posted: May 28, 2011 - 12:16 PM |
|
Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux
|
|
|
EW wrote:
Quote:
[named address spaces]
Actually, last I heard is that it was being worked on internally. I'll be finding out the status of various work on the toolchain in about 2-3 weeks.
Is there a development branch in the repository? Would make sense that. For collaboration.
danni wrote:
Is it possible to add a method to define structs inside the Flash?
That's already possible today by means of PROGMEM or section attribute.
The only thing that does not work as intended in your example is placement of string literals. But even with named address spaces I do not know if it is possible in a consistent way to treat a literal like the following example:
Code:
const char __pgm * p = "A"
It's clear what the intention is, but "A" will be in RAM and p point to a flash location. There is no way like suffix to say where "A" should be placed; so it is always in the generic address space aka. RAM. This is in contrast to
Code:
const char __pgm q[] = "B"
where "B" will end up in flash.
Then note that the address space support is done for C and limited to intrinsic address spaces, I see nothing that does an extention for C++ except the note
DTR 18037 wrote:
Named address space support could be added to C++ only as an extension; it would not be implementable within the class library. Such an extension would not conflict with existing features of C++.
A solution to put "A" (or in more complex cases like struct initializer) in flash would be pragma, so that code could look something like
Code:
#pragma avr progmem
const struct foo =
{
"C", bar
};
#pragma avr
Pragma support would not be restricted to C and is easier to implement than intrinsic named address spaces. GCC only supports intrinsic named address spaces at the moment; afaik there is no work in progress to support other flavours of named addresses.
mckeemj wrote:
At the moment it is functional, but it does have distinct ( and visible ) drawbacks. Perhaps the programmers that run into the issues should choose another approach, but it is never good to see things that you know could be "right" but aren't. A place I see the same issue in the avr-libc support is ( at least last I checked ) 64-bit arithmetic. People who attempt to use it are likely to get a large ( in many ways ), and quite unpleasant surprise.
Anyone who works or did work on avr-gcc is well aware of that. If the code is not as good as could be, that has basically two reasons:
- If just a tenth of the effort that is put into, e.g. arm-gcc, would be put into avr-gcc, avr-gcc would be much better off.
- GCC is a complex software and teaching it things is [i]hard[/]. Gernerally, when looking at code produced by the compiler it is easy to put the finger on a particular spot and say: "what a dumb compiler, I see immediately how good code would look like, why isn't the compiler producing it?".
It's two completely different things to see that the code is not optimal and to actually fix that in a consistent, maintainable, efficient, generic way. So if something is not implemented, like more efficient 64-bit support, it's because that is beyond resources. Comments like "it's no problem, just replace LDS by LPM" are in crass discrepancy to an actual implementation.
mckeemj wrote:
I haven't played around in the GCC internals sandbox yet but I'd be happy to help in any way possible.
Half the way is doing a fix/extension, another half is pure bureaucracy (GPL, coding convention, SVN, ...) and yet another half is to convince a maintainer to approve the work.
So you could start with the annoying second point, because without some formalities the work might be unused and thus frustrating.
From the technical aspect, starting points are reading the internals and tying to get the big picture how GCC works and how a backend hooks in in order to accomplish its needs.
Learn how to build GCC so that it incorporated you changes and learn about ways to debug GCC and how testsuite is run.
Pick an issue, e.g. from bugzilla, that appears to be easy to fix and try to understand what's going wrong, how it can be improved and why the improvement is correct for any other input source code that is imagineable.
EW wrote:
ABI changes are much bigger and long-term. I don't think that this should be done for a WinAVR release [...]
ACK for the last point. ABI change is independant of release cycle.
But note that avr-gcc uses/changes some resources; there is the example of T-flag. Without saying a word about that users could stumble because without any documentation one might conclude that the thing is unchanged.
Similar for RAMPZ: you would expect that at beginning of main it has it's reset value or the value you assigned in some constructor or .init-function, but actually it is undefined because startup code might clobber it.
So even if it's not labeled "ABI change/extention", it should be documented. A place could be avr-libc which takes the burdon of documenting many stuff that is actually beyond avr-libc.
Without being clear about such things, on the one hand, users are confused or mislead or produce buggy code without having the chance to know that beforehand, and on the other hand tool developers have no idea how a bug report like PR44940 has to be treated: is the report invalid? or is there a bug? what part of the chain is reposible for the bug?
Doing nothing about that is not the best option, imo. |
|
|
| |
|
|
|
|
|
|
Posted: May 28, 2011 - 03:35 PM |
|
Joined: Sep 05, 2001
Posts: 2496
|
|
Wish list part 2:
- 64 bit support not so enormous ressource gulping.
- double float support
Peter |
|
|
| |
|
|
|
|
|
|
Posted: May 28, 2011 - 05:53 PM |
|
Joined: Jul 16, 2009
Posts: 1578
|
|
Hi,
danni wrote:
Wish list part 2:
- 64 bit support not so enormous ressource gulping.
- double float support
Peter
I agree, both of these would be awesome.
Here is the 64 bit div: 3306 bytes!
00000696 00003306 T __udivdi3
Thanks,
Alan |
|
|
| |
|
|
|
|
|
|
Posted: May 28, 2011 - 07:39 PM |
|
Joined: Jul 18, 2005
Posts: 62227
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| If there aren't enough volunteers to even fix the bugs who do people think will be implementing these "wishlist" items that could actually represent many man months of (free) development time? Even if there were engineering resource available surely there'd need to be some kind of prioritisation? In reality how many people using AVRs really need (not just want!) to use things like uint64_t or double? |
_________________
|
| |
|
|
|
|
|
|
Posted: May 28, 2011 - 10:25 PM |
|
Joined: Jun 26, 2006
Posts: 625
Location: San Luis Valley, Colorado ( 2,318m )
|
|
A few comments:
@wek - yes, my documentation comment was directed at avr-libc functionality, not the tool chain. However, much of the tool chain, in my experience, is documented ( sparsely and somewhat cryptically perhaps ) "somewhere"; it simply is not written up cleanly and in a central location. But... and I think this is the biggest issue, the tool chain represents an amalgam of projects and thus almost demands this separate documentation. Does it make sense to create an entire AVR specific binutils manual ( or similar )? I think that is asking a bit much.
@SprinterSB - I've already started looking over the internals manual and I've joined the avr-libc-dev list, so hopefully I'll be able to get up to speed in the next couple of weeks to do something useful.
As for my reference to 64-bit arithmetic... I do not want to imply that avr-libc needs an improved implementation - the current implementation works. I also cannot argue that those who have worked with avr-libc for a time will recognize the issues involved with it 64-bit numbers and avoid them unless absolutely required. What I have seen, here on AVRFreaks, however, is people coming to this with little or no experience and then running away just as quickly when they find out how "bloated" their code is with certain features ( including 64-bit arithmetic ). This is similar to the let down that, currently, doubles are the same size as floats. The float / double, situation, however is documented; except for possibly ( I have not checked ) bugzilla, the 64-bit unoptimized status is not ( documented that is ).
Granted, we cannot expect many people to "rush to the documentation" ( either before or after trouble strikes ). But an acknowledgment of "this is the current state of this piece, take it or leave it ( or even, here's why )", goes a long way toward making the software seem more stable and usable. This does not belong in the functional documentation, of course, as any potential future improvements in the underlying code should not change the functionality, but something in the form of a development road map or project status diagram ( beta, stable - unoptimized, stable - optimized, etc. ) would condense the information into an easily usable ( and maintainable ) form.
Martin Jay McKee |
_________________
As with most things in engineering, the answer is an unabashed, "It depends."
|
| |
|
|
|
|
|
|
Posted: Jun 01, 2011 - 09:17 AM |
|
Joined: Jul 18, 2005
Posts: 62227
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Note that at Jan's request I have split the intricate discussion about improving uint64_t support from this thread and into a separate one.
http://www.avrfreaks.net/index.php?name ... p;t=107472
(BTW I could do the same for the vtables "tangent" too )
Cliff |
_________________
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
