Denis Chertykov wrote:
> 2011/11/29 Georg-Johann Lay:
>> For devices with 8-bit SP reading the high byte SP_H of SP will get garbage.
>>
>> The patch uses CLR instead of IN SP_H to "read" the high part of SP.
>>
>> There are two issues with this patch:
>>
>> == 1 ==
>>
>> I cannot really test it be
Joerg Wunsch wrote:
> As Georg-Johann Lay wrote:
>
>> Then avr-mcus.def adopted this bug from the manual for ATtiny4313 at least:
>>
>> AVR_MCU ("attiny4313", ARCH_AVR25, "__AVR_ATtiny4313__", 1 /* short_sp,
>> should
>> be 0 ? */, 0, 0x0060, "tn4313")
>
> Not unlikely.
>
> I just ordered one.
As Georg-Johann Lay wrote:
> Then avr-mcus.def adopted this bug from the manual for ATtiny4313 at least:
>
> AVR_MCU ("attiny4313", ARCH_AVR25, "__AVR_ATtiny4313__", 1 /* short_sp, should
> be 0 ? */, 0, 0x0060, "tn4313")
Not unlikely.
I just ordered one. Hopefully, it will be here by tomorrow
Joerg Wunsch wrote:
> As Georg-Johann Lay wrote:
>
>> There is ATtiny4313 (and maybe others) that have 8-bit SP and 0x100 RAM.
>> As RAM starts at 0x60, I wonder what the meaning of SP is?
>
> I think this is simply a bug in the datasheet. The device description
> XML file of the ATtiny4313 ment
As Georg-Johann Lay wrote:
> There is ATtiny4313 (and maybe others) that have 8-bit SP and 0x100 RAM.
> As RAM starts at 0x60, I wonder what the meaning of SP is?
I think this is simply a bug in the datasheet. The device description
XML file of the ATtiny4313 mentions an SPH register, and it wou
Georg-Johann Lay wrote:
> For devices with 8-bit SP reading the high byte SP_H of SP will get garbage.
>
> The patch uses CLR instead of IN SP_H to "read" the high part of SP.
>
> There are two issues with this patch:
>
> == 1 ==
>
> I cannot really test it because for devices that small runni
2011/11/29 Georg-Johann Lay :
> For devices with 8-bit SP reading the high byte SP_H of SP will get garbage.
>
> The patch uses CLR instead of IN SP_H to "read" the high part of SP.
>
> There are two issues with this patch:
>
> == 1 ==
>
> I cannot really test it because for devices that small runn
For devices with 8-bit SP reading the high byte SP_H of SP will get garbage.
The patch uses CLR instead of IN SP_H to "read" the high part of SP.
There are two issues with this patch:
== 1 ==
I cannot really test it because for devices that small running test suite
does not give usable results.