Am 21.04.24 um 10:08 schrieb Wolfgang Hospital:> Dear all,>
Is there a test scaffold for the functions from lib1funcs.S,
correctness, size&speed over the variety of 8-bit AVR cores?
Size is the easiest one: Just determine the size of, say
-nodefaultlibs -nostartfiles against a respective comp
Am 24.09.23 um 03:48 schrieb Ricardo Cosme:
Hi,
I have a question regarding the reordering of statements involving a
builtin function and extended asm volatile expressions in avr-gcc.
Consider the following code snippet:
//C++
{
asm volatile(/* template plus operands */);
__builtin_avr
Browsing the GCC source, I found this in gcc/config/avr/avr.c
if (AVR_HAVE_RAMPZ
&& TEST_HARD_REG_BIT (set, REG_Z)
&& TEST_HARD_REG_BIT (set, REG_Z + 1))
{
emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD,
treg);
}
I wont pretend to full
Am 23.04.23 um 22:57 schrieb Royce Pereira:
Hi,
I just tried avr-gcc 12.1.0 on an old project, and got some new warning
I can't explain.
The code is:
PORTC &= 0xFE ; //clear bit 0.
and the warning is:
warning: array subscript 0 is outside array bounds of 'volatile
uint8_t[0]' {aka 'vol
Hi,
I've dug about in the sourcecode of gcc and gas, in order to understand
how it works.
in particular, in gas
avr_patch_gccisr_frag (fragS *fr, int reg)
There is behaviour, specific to AVR that allows binutils to analyse the
compiler output for interrupt routines, and causes it to generate
s
Royce Pereira schrieb:
Hi,
The problem continues.
it compiles without error once I delete all the generated files, but the
next time (even with 'make clean all' I get the same error from make:
"make": *** No rule to make target `c\:\avr-gcc\avr\include\avr\io.h',
needed by `MIXER-72x75-0920.o'
Am 31.03.20 um 15:50 schrieb Peter Sommerlad (C++):
Hi,
as a newbie to AVR programming, I am porting Arduino Core code to modern
C++17. I wanted to get rid of ugly large lookup tables that in PROGMEM
that require separate assembly macro magic to access by normal C++ code.
My naïve assumption
Benoit Steinmetz schrieb:
hi all
I have written a function in AVR assembler that returns an 8-bit
result. The
function is called from C, so it should respect the avr-gcc ABI.
I am a bit confused as to whether the function is required to
zero/sign-extend the 8-bit result to 16 bits or not.
On 09.11.2017 17:49, Szikra Istvan wrote:
Hi David,
What is exactly wrong with my code?
Thanks by the way for __get_PSP and all your help.
This is what it looks like on my end:
__STATIC_INLINE uint32_t __get_PSP(void)
{
register uint32_t __regProcessStackPointer __ASM("psp");
Assuming th
Szikra Istvan schrieb:
Hi all,
I have this interesting test case for you guys, and girls.
#include
unsigned int GetStackPointer()
{
volatile unsigned int sp = (SPH << 8) | SPL;
There is "SP" for you. Ne need to hamper with bytes.
uint16_t GetStackPointer (void)
{
return SP;
}
Georg-Johann Lay schrieb:
On 15.06.2017 14:43, Georg-Johann Lay wrote:
https://gcc.gnu.org/PR20296
is about speeding up "small" ISRs, and is open for 12 years now...
Anyone familiar with avr-gcc knows that a fix would be high effort and
risk, and that's the major reason for
On 15.06.2017 14:43, Georg-Johann Lay wrote:
https://gcc.gnu.org/PR20296
is about speeding up "small" ISRs, and is open for 12 years now...
Anyone familiar with avr-gcc knows that a fix would be high effort and
risk, and that's the major reason for why PR20296 is still
Erik Christiansen schrieb:
Reply-To: avr-gcc-list@nongnu.org
On 15.06.17 14:43, Georg-Johann Lay wrote:
https://gcc.gnu.org/PR20296
is about speeding up "small" ISRs, and is open for 12 years now...
Anyone familiar with avr-gcc knows that a fix would be high effort and risk,
and
https://gcc.gnu.org/PR20296
is about speeding up "small" ISRs, and is open for 12 years now...
Anyone familiar with avr-gcc knows that a fix would be high effort and
risk, and that's the major reason for why PR20296 is still open (and
even classified "suspended").
In some forum discussion (a
Georg-Johann Lay schrieb:
Juergen Harms schrieb:
We need to upgrade the AVR GCC cross-compiler package of the Mageia
distro, the present package uses GCC-4.8.1.
Simply packaging the latest available GCC release would be a naive
approach, as illustrated in last years ML thread on "GCC
Juergen Harms schrieb:
We need to upgrade the AVR GCC cross-compiler package of the Mageia
distro, the present package uses GCC-4.8.1.
Simply packaging the latest available GCC release would be a naive
approach, as illustrated in last years ML thread on "GCC 6.1.0, strings
and PROGMEM": a yea
Pitchumani Sivanupandi schrieb:
On Friday 05 May 2017 06:02 PM, Georg-Johann Lay wrote:
On 05.05.2017 12:07, Pitchumani Sivanupandi wrote:
On Friday 05 May 2017 02:42 PM, Georg-Johann Lay wrote:
On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
On Wednesday 03 May 2017 08:01 PM, Georg
On 05.05.2017 12:07, Pitchumani Sivanupandi wrote:
On Friday 05 May 2017 02:42 PM, Georg-Johann Lay wrote:
On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
Hi, the devices in $subject are not yet supported by the tools, mainly
On 05.05.2017 07:53, Pitchumani Sivanupandi wrote:
On Wednesday 03 May 2017 08:01 PM, Georg-Johann Lay wrote:
Hi, the devices in $subject are not yet supported by the tools, mainly
because of missing Binutils support.
Are there plans to add the needed emulation to Binutils?
These devices are
Hi, the devices in $subject are not yet supported by the tools, mainly
because of missing Binutils support.
Are there plans to add the needed emulation to Binutils?
Johann
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org
On 15.04.2017 19:15, Victor Aprea wrote:
Hey all,
I'm working on porting a library and I've run across an unfortunate
surprise (or I'm just doing it wrong).
Can someone confirm that avr-gcc 4.8.1 doesn't (implicitly)
define __STDC_VERSION__ as suggested by
https://gcc.gnu.org/onlinedocs/cpp/Sta
On 16.03.2017 12:12, David Brown wrote:
It would be interesting to know if clang/llvm could generate better code
for the AVR. gcc has a few fundamental problems with the port. In
particular, gcc expects its targets to have registers capable of holding
an int - in this case, 16 bits. So the AVR
On 19.12.2016 22:24, Thomas Watson wrote:
Hello all,
A frequent need in my code is to combine two 8 bit variables into a 16 bit
variable. I am trying to determine the optimal way to do this. The naïve way
and a more clever way both generate extra instructions that could be optimized
away. I i
Marcin Godlewski schrieb:
Dear all,
Thanks for the reply to David. However I'm not trying to find a solution for
the described issue. What I'm trying to say in this e-mail is that this part of
Atmel documentation:
http://www.atmel.com/webdoc/AVRLibcReferenceManual/optimization_1optim_code_reo
On 30.11.2016 15:32, Paul "LeoNerd" Evans wrote:
On Wed, 30 Nov 2016 18:18:11 +0530
Senthil Kumar Selvaraj wrote:
Diogo Martins Silva writes:
Hello all.
The avr-gcc wiki (https://gcc.gnu.org/wiki/avr-gcc) lists 24 bits
(u)ints as an extension since version 4.7. How do I use them?
Use __ui
On 30.11.2016 08:40, Diogo Martins Silva wrote:
Hello all.
The avr-gcc wiki (https://gcc.gnu.org/wiki/avr-gcc) lists 24 bits
(u)ints as an extension since version 4.7. How do I use them?
Thanks
Diogo
You can use it basically like any other integer type, for example:
__uint24 mul24 (unsigne
On 24.11.2016 08:14, Pitchumani Sivanupandi wrote:
On Friday 18 November 2016 04:46 PM, Georg-Johann Lay wrote:
Some of the more recent avr devices support reading from flash by LD
instructions. The flash memory can be accessed by a virtual address
(VMA) which is offset by a specific value
Some of the more recent avr devices support reading from flash by LD
instructions. The flash memory can be accessed by a virtual address
(VMA) which is offset by a specific value from the load address (LMA).
For example, on ATtiny40 (a reduced Tiny with only 16 GPRs) the offset
is 0x4000, and
Paul "LeoNerd" Evans schrieb:
((TLDR: PROGMEM on compound-literal arrays is silently ignored.
Please either implement or make it a noisy warning/error.))
If I define a function that takes a byte array, e.g.
void i2c_write(size_t len, const uint8_t *data);
I find it nice to be able to cal
On 02.08.2016 03:09, Eric Tang wrote:
Hi avr-gcc mailing list,
I think I have discovered a minor bug. I get the "initializer element is
not constant" error when I try to compile the following code with avr-gcc.
If I remove the cast, the code compiles without issue. However, its
presence does not
On 13.07.2016 19:10, Georg-Johann Lay wrote:
Currently progmem attribute works the same way on the reduced core (no LPM, 16
GPRs) and on the ordinary cores (with LPM, 32 GPRs).
As we have a linearized memory model on reduced core and flash memory is
visible in the RAM address range (starting at
Currently progmem attribute works the same way on the reduced core (no LPM, 16
GPRs) and on the ordinary cores (with LPM, 32 GPRs).
As we have a linearized memory model on reduced core and flash memory is
visible in the RAM address range (starting at 0x4000), it would make sense if
the compile
Am 08/11/2015 um 12:04 PM schrieb Klaus Rudolph:
can someone explain how interrupt vectors are handled in gcc internally?
ISR functions are implemented as function attributes, i.e. there are
avr-specific function attribute (__interrupt__, __signal__) which turn an
ordinary function into an IS
Am 04/21/2015 um 03:24 PM schrieb Georg-Johann Lay:
Without fat LTO objects, the compiler just puts gimple IR into the objects,
there is no asm code. Built-in functions are represented by their decls as
provided by targetm.builtin_decl(). This means there is no expansion of tree
to rtl.
That
Am 04/21/2015 um 09:17 AM schrieb Sivanupandi, Pitchumani:
Hi,
Test gcc.target/avr/torture/builtins-error.c is failed in gcc-4.9 and trunk for
-Os -flto options.
This test expects error for compile time constant. Option flto delays the
builtin expand
(to link time??) and there is no error. Can
Suppose an installation of avr-gcc with device-specs folder installed in a
read-only path. What's the recommended way to supply support to, say, device
'mydev'? Using -B to add a local directory containing the spec files?
Johann
___
AVR-GCC-lis
Paul "LeoNerd" Evans schrieb:
I'm writing code for an ATtiny (tiny84 specifically).
I currently have an array and a function defined thus:
static struct {
uint8_t state;
uint8_t v1;
} leds[3];
uint8_t led_state(uint8_t i) { return leds[i].state; }
Elements of this array are 2 by
Alistair Gadd schrieb:
Hi Guys,
I'm trying to use GCC-AVR to set up the clock prescale on an ATmega32U4,
using the clock_prescale_set() function as outlined in the "avr/power.h
" header file.
If I call:
clock_prescale_set(clock_div_1)
or
clock_prescale_set(0);
where clock_prescale_se
Am 02/23/2015 um 05:21 AM schrieb Senthil Kumar Selvaraj:
On Fri, Feb 20, 2015 at 12:56:59PM +0100, Georg-Johann Lay wrote:
avr-gcc is still broken and fails to compile trivial programs:
$ avr-gcc-5.0 -mmcu=atmega8 main.c
/local/gnu/install/gcc-5.0/lib/gcc/avr/5.0.0/../../../../avr/bin/ld
avr-gcc is still broken and fails to compile trivial programs:
$ avr-gcc-5.0 -mmcu=atmega8 main.c
/local/gnu/install/gcc-5.0/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: cannot
find dev/atmega8/crt1.o: No such file or directory
/local/gnu/install/gcc-5.0/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: c
Am 12/03/2014 10:11 PM, schrieb Andreas Höschler:
Hi all,
I am close to tearing my hair out. After having established the avr tool chain
I tried out a very simple C-program (see below) on an SainSmart Mega2560 board
programmed into the chip by making use of
/Applications/Arduino.app//Contents
Am 11/09/2014 10:00 PM, schrieb Joern Rennecke:
On 8 November 2014 00:32, Szikra István wrote:
Hi everyone!
My problem in sort: I’m getting
in r24, 0x18
ldi r25, 0x00
andir24, 0xEF
out 0x18, r24
instead of
cbi 0x18, 4
.
I’m try
Am 11/09/2014 05:35 PM, schrieb Joern Rennecke:
On 8 November 2014 00:32, Szikra István wrote:
Unfortunately GCC support for AVR (among other things) is not always
flawless. And it changes from versions to version (and not always for the
better).
regression tests can help to catch instances
Am 10/14/2014 04:07 PM, schrieb Joern Rennecke:
atexit.c has several issues which are fixed by the patch below:
i)
Issuance of calls to functions as registered by atexit() is located in
section .fini6a. As the current linker description does not handle that
section it's treated as orphan and lo
atexit.c has several issues which are fixed by the patch below:
i)
Issuance of calls to functions as registered by atexit() is located in section
.fini6a. As the current linker description does not handle that section it's
treated as orphan and located conflicting with other sections:
$ avr
Buildling / installing current avr-gcc from trunk, same for avr-libc, yields
for any program:
INSTALL/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: cannot find
dev/atmega128/crt1.o: No such file or directory
INSTALL/lib/gcc/avr/5.0.0/../../../../avr/bin/ld: cannot find
dev/atmega128/libdev.a: No s
Am 10/13/2014 11:57 PM, schrieb Andreas Höschler:
Hi all,
doing my first cautious steps in C on an Arduino I try to convert a string read
over the serial interface to a uint32_t.
So what's wrong with strtoul from stdlib.h ?
[snipped bulk op code]
Johann
p.s.
You started this new threa
Am 09/09/2014 11:31 AM, schrieb Sivanupandi, Pitchumani:
-Original Message-
From: Georg-Johann Lay [mailto:a...@gjlay.de]
Sent: Tuesday, September 09, 2014 2:10 PM
To: AVR GCC List
Cc: Sivanupandi, Pitchumani
Subject: config.status: error: cannot find input file:
`avr/lib/avr25/ata5272
Hi. I am getting the above error message while configuring avr-libc. Any ideas?
avr.gcc is 4.9.2. (prerelease) which supports ata5272.
avr-libc is up-to-date SVN 2450.
config.log:
$ ../../source/avr-libc-1.8/configure --host=avr
--prefix=/local/gnu/install/gcc-5.0
...
configure:4824: che
Royce Pereira schrieb:
Hi,
What is the differenence between:
__flash const char myString[] = "Hello There!" ;
myString is a const array in flash that's initialized with "Hello There!".
and
__flash const char *myString = "Hello There!" ;
myString is a non-const pointer in RAM that holds a
Am 06/12/2014 12:23 PM, schrieb Royce Pereira:
Hi,
I recently updated WinAVR to a newer version of the AVR-GCC toolchain,
downloaded from the Atmel site.
My version is this:
avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 4.8.1
My code was compiling without errors before, but with this version,
Am 06/13/2014 12:06 PM, schrieb Royce Pereira:
Hi all,
Continuing with the latest avr-gcc, and playing with the new '__flash'
qualifier, I'm facing some new warnings, not seen before.
I have this:
//===
void func1(void)
{
//
}
//===
void fu
Am 03/27/2014 12:58 PM, schrieb S, Pitchumani:
Ping!
Please review the patches and comment.
Hi Pitchumani,
some remarks on the work:
1) It might be useful to builtin-define macros so that user code can
test for
availability of these instructions, similar to __AVR_ERRATA_SKIP__ or
__AVR_HAVE
Am 03/18/2014 06:33 PM, schrieb Senthil Kumar Selvaraj:
Hi,
I see that the avr_rtx_costs_1 function returns relative costs for a
variety of RTL codes, but only for non-DImode operands. For DImode,
it returns false, and gcc uses its idea of the cost plus the costs of
operands (found by recursing
Am 03/12/2014 06:59 PM, schrieb S, Pitchumani:
Please review the patches and comment.
Hi Pitchumani,
some remarks on the work:
1) It might be useful to builtin-define macros so that user code can test
for
availability of these instructions, similar to __AVR_ERRATA_SKIP__ or
__AVR_HAVE_MUL__.
Am 02/25/2014 01:05 PM, schrieb S, Pitchumani:
Hi,
Few AVR Xmega devices have specific instruction support than the architecture
it belongs to. For example atxmega128b1 device has RMW instructions (XCH,LAC,
LAS and LAT) support, but not all avrxmega6 devices have.
Now, avr-gcc passes architectu
dfx schrieb:
Hi,
often in code written by 'gurus' I find expressions of the type
# if defined (__AVR_ATmega168__), but looking at the code I can not
find the definition anywhere.
The question is: where these symbols (with double underscore) are defined?
These are built-in defines, some of
Klaus Rudolph schrieb:
I want to have debug infos in my assembler output files.
I tried with
avr-gcc -Wa,-gstabs,-D -xassembler-with-cpp -mmcu=atmega32 -nostdlib $< -o eins
But if I use:
avr-gdb eins
(gdb) list
1 /tmp/ccUMCsnQ.s: No such file or directory.
Generated s files are temorary
Erik Christiansen schrieb:
On 19.10.13 19:48, Georg-Johann Lay wrote:
Dhakshinamoorthy, Soundararajan schrieb:
I am trying to update the linker scripts, with the start address of
boot section, which is different for each device (or atleast i don't
seem to find a way to compute it based o
Dhakshinamoorthy, Soundararajan schrieb:
Hi all,
Can someone advise a way to support device specific linker scripts in
binutils for our AVR port. Currently bintuils is based on device
architecture and not device as i understand.
This is a reasonable approach. Just imagine what a device-specif
David Brown schrieb:
On 01/10/13 09:41, Simon Kirby wrote:
Hello!
How difficult would it be to convince avr-gcc to not re-zero r1 instantly
after mul, but delay it until a zero is actually needed? For example,
see this actual avr-gcc output:
Vneutral = (uint16_t)Vbus * t >> 8;
->
Weddington, Eric schrieb:
-Original Message- From: Georg-Johann Lay
[mailto:a...@gjlay.de] Sent: Saturday, June 08, 2013 6:36 AM To:
Weddington, Eric Cc: Thomas D. Dean; avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] How to use pgmspace.h in a library
source without warning
Weddington, Eric wrote:
computers get faster every year
Computers don't get faster.
It's just the case that the not-so-fast computers are declared as scrap,
and thrown away an then replaced by a-bit-faster computers; again and
again and again...
I don't think that things should get more c
Thomas D. Dean schrieb:
On 06/07/13 09:53, Georg-Johann Lay wrote:
Suppose the following include in a library source.c:
#include
and the source compiled with, e.g. -mmcu=avr5 or -mmcu=avr35 etc.
This throws a warning like:
$ avr-gcc -mmcu=avr5 source.c -c
In file included from INSTALL/avr
Suppose the following include in a library source.c:
#include
and the source compiled with, e.g. -mmcu=avr5 or -mmcu=avr35 etc.
This throws a warning like:
$ avr-gcc -mmcu=avr5 source.c -c
In file included from INSTALL/avr/include/avr/pgmspace.h:88:0,
from source.c:1:
INSTAL
Bastien ROUCARIES a écrit:
Could you share the patch queue (against upstream) ? For last 4.7 and this 4.8 ?
Sorry, I am not providing such diffs. Please find out these diffs yourself.
The toolchain is provided "as is", there is no extra patches or hacks or
whatever.
Johann
___
Georg-Johann Lay schrieb in
http://lists.gnu.org/archive/html/avr-gcc-list/2012-09/msg00024.html
GCC 4.7 has just been released, and I decided to provide a MinGW32 build
of avr-gcc-4.7.2.
Many people feel uncomfortable with building the tools to run under MS
Windows, so here they are
Sean schrieb:
I've been attempting to compile and link an Ada programme for the
Arduino.
I have managed to get a simple programme compiled linked and running
on an AtMega328p board. But when I start to use some of the more
complex functions I obviously had to start using avrlibc.
I've down
Senthil Kumar wrote:
On Thu, Mar 14, 2013 at 10:09 AM, larry barello wrote:
[...]
Would you please use plain text messages on the lists? Thanks.
And please, don't quote email addresses on the lists.
No issue here, but list archives like from gcc@, gcc-help@, etc. will
cite you complete mai
larry barello schrieb:
1. How do I specify a long call from my application to jump into the
boot-loader (which resides at 0x2). This is my solution:
case SMB_GOTO_BOOTLOADER:
EIND = 1; // HACK HACK
((void (*)(bool bCalled))((BOOT_SECTION_START)
Thomas, George schrieb:
Some of the doubts about the patch are :
1. If __flash5 is used then for placing the code we get only 0x5
to the rest of the flash for storing code (.text) . How can we make use
of the space before in a case where __flash1 - 4 are absent ?
You can also use a home-
Senthil Kumar Selvaraj wrote:
>> Granted, the (saved memory) reward for the effort is small, but if the
>> user would specify the number of the highest used vector, then gas
>> conditional assembly, in a "bad vector" macro does handle the task:
>
> Ah, but right now, the vector table is defined i
Massimiliano Cialdi wrote:
> I want to upgrade my toolchain.
> In the past I compiled binutils 2.20.1 patched with
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/patch-newdevices
> as explained here:
> http://www.nongnu.org/avr-libc/user-manual/install_tools.html
>
> these
Felipe Morato schrieb:
I've got an attiny4 and can't compile the code for it. I'll describe bellow:
[...]
If I run "avr-gcc --target-help" the attiny shows up accordingly.
Nope, attiny4 is neither supported by 4.7.2 nor listed with
--target-help nor with --help=target nor is it reported in
Senthil Kumar Selvaraj wrote:
Like the others said, the patch does not change the default behavior
for unhandled interrupts - they still branch to __bad_interrupt. The
user would have to explicitly use the --shrink-ivt option to change
that - at which point, I guess he should be knowing what he
Jonathan Geisler schrieb:
I'm encountering a strange error with avr-gcc 4.6.3 and 4.7.2 using
the timer interrupt. The code I'm using is attached. As you can see,
I was trying to tie in to the Arduino environment (with Eclipse) so
that I could help my students wean off that set of functions to
Weddington, Eric wrote:
> I open to suggestions on such a feature, but let's talk about it in AVR
> community first and leave the binutils mailing list out of it until we
> arrive at a consensus.
Agreed, in general it is not helpful to cross-post several mailing lists.
Johann
__
Weddington, Eric wrote:
>
> Senthil_Kumar Sent:
>>
>> Hi,
>>
>> This patch tries to shrink the interrupt vector table by deleting unused
>> entries at the end of the table as part of linker relaxation.
>>
>> The motivation for this patch is that, currently, the full interrupt
>> vector table
I answered to this on the GCC list:
http://gcc.gnu.org/ml/gcc/2013-02/msg00129.html
Please f'up there.
S, Pitchumani a écrit:
Hi,
I was analyzing an issue for avr target (gcc-4.7.2).
Issue is that already clobbered register is used after the transformation
in post reload pass.
insns after
Erik Christiansen schrieb:
On 17.12.12 15:01, Erik Christiansen wrote:
I'll outline the benefits of a more structured linker script, mirroring
the desired memory model, in another post.
As Johann is demonstrating, the old linker script architecture, burdened
by a monolithic .text output sectio
Erik Christiansen schrieb:
On 14.12.12 23:00, Georg-Johann Lay wrote:
The 64-bit ranges come from the ELPM instruction that takes the
___^^
16-bit or 64KiB, of course
16-bits of Z-reg and concatenates RAMPZ as bits 16..23 to get a
24-bit address.
The common computer terms "
Erik Christiansen schrieb:
The goal now seems to be to let .text grow contiguously across pages, if
not obstructed by a __flashN page occupied by .progmemN.data. That means
that any occupied __flashN must be higher than _etext, to avoid overlap.
(And aligned to the 0x1 page boundary.)
Alignm
Erik Christiansen schrieb:
Here are two test cases based on one source code example compared with
Johann's requirements for the script behaviour.
Here is more torture. Assemble with, e.g.
$ avr-gcc flash.sx -o flash.elf -DSTUBS=10 -DP1=0x200 -DTEXT=0x2
-mmcu=atmega2560 -Wl,-Map,flash.ma
is a bit long. (Grab a coffee ;-)
On 11.12.12 17:47, Georg-Johann Lay wrote:
[Beautifully explanatory example of AVR memory paging snipped]
This puts x into input section .progmem1.data and expects that this section is
located appropriately, in particular that &x div 2^16 = 1
It allow
Erik Christiansen schrieb:
Hi Johann,
Hopefully my detailed reply to your beautiful explanatory example and
description of requirements, sent yesterday, has arrived. (Although it
still hasn't appeared on list. I'll post it there again, if it doesn't
show up after a full 24 hrs. I sent a copy to
Erik Christiansen wrote:
> On 10.12.12 23:33, Georg-Johann Lay wrote:
>> Basically #26365 addresses similar issues like PR14406 with the
>> difference that the compiler already supports everything needed for data
>> in __flash1 or higher, as avr-gcc calls is.
>>
>&g
Bastien ROUCARIES wrote:
>>
>>> I meeans the atmel patchqueue here
>>> http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1.830/avr/
>>> have been merged upstream ?
>> That's no patches, it's a complete dump of their source trees.
>
> Not there is a patch queue see
> http://distri
Bastien ROUCARIES wrote:
> I meeans the atmel patchqueue here
> http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1.830/avr/
> have been merged upstream ?
That's no patches, it's a complete dump of their source trees.
IMO, trying to work out what PRs are involved and contribute
Jan Waclawek schrieb:
Georg-Johann Lay wrote:
* PR13812 .trampolines location in linker script cause "internal
error: out of range error"
Dunno if this is still an issue resp. can be solved by a better
default linker script. Maybe a user-specific ld script is needed
Bastien ROUCARIES schrieb:
I wish to package avr binutils then gcc for debian.
What is the current patch queue against binutils upstream (2.23) ?
What do you mean with "curent patch queue"?
There are
* PR14406 Support .progmem.data sections in the default ld script
No patch available
Paul Sokolovsky schrieb:
Googling led me to
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html , and
after checking that this list is also hosted on nongnu.org, I thought
it's the authoritative manual. And it doesn't list "n". Is there more
up-to-date avr-gcc manual?
"n" is vanilla G
Paul Sokolovsky wrote:
> Hello,
>
> Georg-Johann Lay wrote:
>
>> Paul Sokolovsky wrote:
>>>
>>> I'd like to reimplement __builtin_avr_delay_cycles() function in
>>> inline assembly. The reason is that __builtin_avr_delay_cycles() has
>>>
Paul Sokolovsky wrote:
> Hello,
>
> I'd like to reimplement __builtin_avr_delay_cycles() function in inline
> assembly. The reason is that __builtin_avr_delay_cycles() has
> too-early operand checking, so for example
>
> static __attribute__((__always_inline__)) my_delay(int cycles)
> {
> _
Please notice that with TOFU style, readers will soon lose track of the
conversation. It is in your own interest that readers don't lose track
of the conversation.
Juergen Harms schrieb:
Versions:
The newly installed glibc and avr-gcc are 1.7.1 and 4.7.2
glibc??? You mean AVR Libc, don't
Buchmann Lucien wrote:
> Hi,
> Thanks for your suggestion. Unfortunately it didn't solve the problem.
> (btw my avr-gcc version is 4.5.3)
Nobody here can compile your text, it's not a valif C module...
Look at the generated code, for example with -save-temps added and looking at
*.s and check tha
Juergen Harms schrieb:
Some weeks ago I finally replaced an outdated tarball-installed
version of avrgcc by an rpm installed recent version (avrgcc-4.7.2).
What AVR Libc does it use?
Surprisingly, this replacement brought a change of the bit-field
packing order (my application is a distribute
David Brown wrote:
> Georg-Johann Lay wrote:
>> Thomas, George schrieb:
>>>
>>> I checked the patches of the fix in PR53448
>>>
>>> Even when the requested alignment in greater than the
>>> BIGGEST_ALIGNMENT (considering it to be 2 for Xmeg
Hi, would you avoid TOFU style in the lists? Thanks.
Otherwise we will soon lose track of a conversation.
Thomas, George schrieb:
Hi,
I checked the patches of the fix in PR53448
Even when the requested alignment in greater than the
BIGGEST_ALIGNMENT (considering it to be 2 for Xmega and 1 for
Weddington, Eric wrote:
>
>>
>>> Section 20.13.7 of the Xmega manual speaks about the requirement of 16
>>> bit alignment.
>>>
>>> http://www.atmel.com/images/doc8331.pdf
>>>
>>> As the MAXIMUM_ALIGNMENT in avr.h is set to 1, it throws an error when
>>> trying to compile.
>>>
>>> I have atta
Thomas, George wrote:
> Section 20.13.7 of the Xmega manual speaks about the requirement of 16 bit
> alignment.
>
> http://www.atmel.com/images/doc8331.pdf
>
> As the MAXIMUM_ALIGNMENT in avr.h is set to 1, it throws an error when
> trying to compile.
>
> I have attached a patch which sets it
1 - 100 of 359 matches
Mail list logo
