I can have a look at the GCC side of this. Should I wait until the definitions
are done?
Ron Kreymborg
-Original Message-
From: Eric Weddington [mailto:invalid.nore...@gnu.org]
Sent: Saturday, 26 February 2011 11:36 AM
To: Eric Weddington; Ron Kreymborg; avr-libc-dev@nongnu.org
Subject
Did anything ever proceed from this?
Ron Kreymborg
-Original Message-
From: Anatoly Sokolov [mailto:invalid.nore...@gnu.org]
Sent: Monday, 13 April 2009 12:11 AM
To: Anatoly Sokolov; Ron Kreymborg; avr-libc-dev@nongnu.org
Subject: [patch #6805] Numeric interrupt vectors
Follow-up
After unfortunately being out of it for many months, I am looking again at
AVRs. Lots of patch/bug activity - is there a release coming up? I submitted
this patch about a year ago (http://savannah.nongnu.org/patch/?6805). Rather
exotic I know, but is there a chance it could be included? Is
Despite it not being as cool, does anyone have any
objections to calling
the project AVR Core Library (avr-corelib)? Eric, you can
still call it The
Core :)
Cool, another vote! I'm good with AVR Core Library (avr-corelib).
I'm happy with avr-corelib. I use SVN here so this is
Well, I hate to be a stick in the mud on this issue, but if it's not
the BSD license, the exact same that is on avr-libc, then I cannot
contribute to it, and it's very unlikely that it will be distributed
with WinAVR. The BSD license is very liberal, in that it allows anyone
to do anything
Some thoughts on a library.
Let me start with a library that manages just the processor's internal
peripherals: best practise would have all data structures the code requires
declared as private (static). Data in, data out, exceptions and status would
all be accessible only via public functions
Follow-up Comment #2, patch #6805 (project avr-libc):
Good idea - a more complete implementation that mine (which was based on
Marek's original). I assume it will use the number for the vector and not the
handler_name (the C++ requirement).
Just curious - what is an example of (2)?
Ron
URL:
http://savannah.nongnu.org/patch/?6805
Summary: Numeric interrupt vectors
Project: AVR C Runtime Library
Submitted by: ronkrem
Submitted on: Sun 12 Apr 2009 05:26:05 AM GMT
Category: None
Priority: 5
Follow-up Comment #3, bug #25300 (project avr-libc):
I have attaced a newly generated patch against HEAD
vector now have number in the following format:
X_vect_num 4
X_vect _VECTOR(4)
pin definition looks like:
#define XX_DDRDDRD
#define XX_PORT
If you want a sneak preview of what it will look like, heads toward:
http://code.google.com/p/avr-drv/source/browse/trunk/avr_mod/
http://code.google.com/p/avr-drv/source/browse/trunk/avr_mod/iom128.h
it contains a modified copy of the include/avr directory of avr-libc
Some devices are
/* External Interrupt Request 5 */
#define INT5_num 6
#define INT5_vect _VECTOR(6)
#define SIG_INTERRUPT5 _VECTOR(6)
Note that SIG_ and _vect are not always aligned. _vect
and
_num however are always aligned.
Good news... I finished(or so I think) the modification to the script.
I have include two files. First is a XML generated by the first part of
the script. It use the AVR Studio XML file to do so. Second file is the
actual ioxxx.h to witch vector patch and pin definition patch have been
The SoftFloat for AVR demo is now on the web at
http://www.jennaron.com.au/avr/SoftFloat.html. While not that useful in
itself, it could be a jumping off point.
Ron
E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.11410
I have implemented for AVRs the 32-bit single precision and 64-bit double
precision floating point types from John Hauser's SoftFloat package
http://www.jhauser.us/arithmetic/SoftFloat.html. This is a full IEC/IEEE
implementation and provides all arithmetic functions including square root.
While
A quick look at AVR Libc for 20081205 still lists doubles as only 32-bit. Is
this so? If yes does anyone know of a 64-bit double library? I am pointing
heliostats and 32-bits are just not enough.
Ron
E-mail message checked by Spyware Doctor (6.0.0.386)
Database version: 5.11380
To: Ron Kreymborg
Subject: Re: [avr-libc-dev] 64-bit doubles
You might want to repost your request to the list. It came across as
noname.txt attachment.
Heliostats is for Sun tracking? Why would that take 64 bits?
On Sat, Dec 20, 2008 at 7:03 AM, Ron Kreymborg r...@jennaron.com.au wrote
-Original Message-
From: Weddington, Eric [mailto:ewedding...@cso.atmel.com]
Sent: Sunday, 21 December 2008 6:00 AM
To: Ron Kreymborg; avr-libc-dev@nongnu.org
Subject: RE: [avr-libc-dev] 64-bit doubles
-Original Message-
From:
avr-libc-dev-bounces+eweddington
A patch to add an argument to the signal attribute has been proposed over on
the avr-gcc-list. This is based on an original proposal by Marek
Michalkiewicz which in turn was based on an msp430 version of gcc. The
intent is to link the jump vector to the interrupt function address rather
than
Using the asm keyword in C++ code to directly vector interrupts to a class
handler (as in the CLASS_IRQ macro discussed earlier on this list) still
leaves the mangled name which avr-gcc subsequently flags as a misspelled
signal handler. The gcc manual provides for a negative warning form -Wno-
to
IMHO the only way is to define the interrupt method in the class with
interrupt attributes and then alias the mangled name to the AVR vector
so the compiler can find it during global name reconciliation. This
would be very neat and simple if we could develop a simple name
mangling macro.
What about a friend method? There must be a way of specifying the ISR
as a
friend to the CTimer0 class, allowing it access to the private data.
- Dean
Yes, making the interrupt a friend works exactly as I want. It solves the
problem of an interrupt not having a this pointer. The overhead
The macro:
#define CLASS_ISR(vector, ...) { vector(); } ISR(vector)
when used in the class method:
void CTimer0Interrupt::TIMER0_OVF_vect(void)
CLASS_ISR(TIMER0_OVF_vect, ISR_BLOCK)
{
TCNT0 = TIMER0_TIMEOUT; // restart the timeout
Timer0.SetOverflowFlag();
}
becomes:
which was another line of thought for me. My solution:
#define CLASS_ISR(vector, ...) { vector(); } ISR(vector, __VA_ARGS__)
That can be applied to any member function in the C file, of any name.
Thanks Dean. This looks like it solves all my problems. In fact it can be
even more concise:
I did not want to call the interrupt myself. My intent was to make the
interrupt method private (and so essentially hidden) and with access to
private class data. Both of our versions fail in the latter
requirement. The method I listed in earlier mails does what I want but
I am still looking
including the makefile I
can email to anyone interested. It is easily run in AVRStudio.
Ron Kreymborg
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
above.
CLASS_ISR(CTimer0, 7, TIMER0_OVF_vect, 11)
{
Having to define the lengths means I am still far from automatic however.
Ron Kreymborg
___
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
26 matches
Mail list logo
