avr-gcc 4.9.2 doesn't seem to know that the address space wraps, so
that an rjmp in the last 2KB of the address space can reach code in
the first 2KB. The following code works fine with a jmp, but if I
change the jmp ResetVector to rjmp, I get:
(.bootloader+0x4): relocation truncated to fit: R_AVR
On Sun, Jan 3, 2016 at 1:22 PM, Georg-Johann Lay wrote:
> Ralph Doncaster schrieb:
>>
>> avr-gcc 4.9.2 doesn't seem to know that the address space wraps, so
>> that an rjmp in the last 2KB of the address space can reach code in
>> the first 2KB. The following code
On Sun, Jan 3, 2016 at 2:36 PM, Georg-Johann Lay wrote:
> Ralph Doncaster schrieb:
>
>> On Sun, Jan 3, 2016 at 1:22 PM, Georg-Johann Lay wrote:
>>>
>>> Ralph Doncaster schrieb:
>>>>
>>>> avr-gcc 4.9.2 doesn't seem to know that the addre
On a x86_64 linux box I successfully built a gcc RC-20150418 toolchain
including binutils-2.25 and avr-libc r2473(svn).
I noticed some warnings in the logs:
../../../source/gcc-5.0.1-RC-20150418/gcc/vec.h:1048: warning: invalid
access to non-static data member âvec::m_vecdataâ of NULL object
../.
I repeated the toolchain build I did for RC-20150418, this time with
the 5.1 release.
The texinfo build dependency bug that I noticed in RC-20150418 appears
to be fixed, and the code generated for a small (<300 line) program
was identical to the code generated by RC-20150418 and RC-20150412.
I mad
I wrote a small function to convert u8 to hex:
// converts 4-bit nibble to ascii hex
uint8_t nibbletohex(uint8_t value)
{
if ( value > 9 ) value += 'A' - '0';
return value + '0';
}
// returns value as 2 ascii characters in a 16-bit int
uint16_t u8tohex(uint8_t value)
{
uint16_t hexdigi
I tried compiling the following code with -mmcu=attiny13a -Os -flto
using 4.8 and 5.1:
#define NOT_A_REG 0
#define digitalPinToPortReg(PIN) \
( ((PIN) >= 0 && (PIN) <= 7) ? &PORTB : NOT_A_REG)
#define digitalPinToBit(P) ((P) & 7)
#define HIGH 1
#define LOW 0
inline void digitalWrite(int
