On 1/19/2022 10:05 AM, Michael Kwasnicki wrote:
I am not sure if I got it right.
The linker is only involved until the .elf file has been created.
If the question is to pad out the content of the .hex file so it is
one continuous block then it can be done with :
avr-objcopy -j .text -j .data -
On 1/19/2022 7:13 AM, Michael Stocker wrote:
You are right.
-Wl,--undefined=signature
This will keep it in flash and not let the linker strip its value.
Also when preparing your .hex file for flashing you may need to
explicitly tell the sections you want.
avr-objcopy -j .text -j .data -j .my
PWM1_OCR = 192;
else
PWM1_OCR = 64;
}
}
And that shows random values (64 or 192, but in random arrangements, not
alternating...)
Obviously, this code is non optimal (my original code was an ISR), but I
thought I'd try to simplify to see if I could figure out the issue.
tree. Thus I have to close the bug report as not applicable.
Someone contributed something (avr-libc 1.8.0):
io.h:249-250:
#elif defined (__AVR_ATmega165__) || defined (__AVR_ATmega165A__)
# include
Thus, either m165.h needs a conditional inside, or a separate iom165a is
needed.
Jim
-
ne and using AVR GCC
Jim
--
Jim Brain
br...@jbrain.com
www.jbrain.com
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
On 5/3/2012 1:28 AM, Jan Waclawek wrote:
As the first step, I'd recommend you to use a proven toolchain, like
WinAVR20100110.
I am using just that toolchain. I will, though, download the below
linked toolchain as well.
with potentially other yet unknown problems. If you'd insist on that, I'd
Pardon my question if it's obvious, I've had quite a night casing
compiler issues.
Received this error tonight after enabling a new chunk of code to
compile on a MEGA168 target
I noticed some fixes in newer AVR GCC versions for things like this, so
I pulled GCC 4.7.0:
http://www.avrfreaks.
Jim Brain wrote:
Weddington, Eric wrote:
That's weird. Looking in the ld user manual I see that -O only
matters to ld if the value is non-zero. So there's no point in doing
-O9. Plus if you have your optimization flag that you are using for
the compile command line, just use the
t. Does ld provide any kind of error output when it "dies"? If
so, can you post it?
I can;t find any type of output, as all I get is "ld.exe has encountered
a problem and needs to close..." Windows dialog box. I looked at the
options to ld, but did not see one to generate mo
#x27;m happy to
send the entire prj (it's a small GPL app) to someone who might be
willing to help me find the root cause so I can file a bug report (or
just show me what I am doing wrong in the Makefile).
Jim
--
Jim Brain, Brain Innovations (X)
br.
David Kelly wrote:
Related to another thread: as to why *not* to use an 8051:
Doesn't have avr-gcc.
So true. Althought it's pointless to add to the recent Freaks "AVR vs
PIC" thread, this is one of the most significant reasons why I prefer
the AVR line. They are inexpensive, the programmer
lu...@proxima.alt.za wrote:
Interesting. I wonder why the standard deeemd it necessary to provide
an escape sequence for the question mark ?
Because there is a rather arcane way to represent characters in which
three question marks appear prominently. I recall now that it's
called "trigra
Spiro Trikaliotis wrote:
There is also a specific firmware available which can update the
bootloader itself.
I'm looking at the /xu1541/update-bootloader/ area on SF, but I don't
understand what I am looking at:
* Are you stating that this code will allow a firmware image to
update
Andy H wrote:
Yes this should be more than enough for data!
I am happy with "high" or anything that is not "far".
I am more than happy to be way off base, but the libraries looks to
already be using _far:
When I ported some code recently from M644(p) to M1281, I had to fix this:
#if FLASHEND
14 matches
Mail list logo
