Le 30/01/2015 15:43, Kustaa Nyholm a écrit :
> DIP unfortunately.
Yep... A more recent TQFP version would "just" require an adapter board...
But we're in real life, I know...
Sébastien Lorquet
--
Dive into the World of
On 30/01/2015 16:22, "M L" wrote:
>2015-01-30 14:03 GMT+01:00, Kustaa Nyholm :
>> First of all, I'm talking about existing code and hardware.
>>
>> The existing code (without the bootloader) already pretty much
>> fills the PIC18F4550.
>>
>> I can't just willy-nilly move to a bigger device, there
2015-01-30 14:03 GMT+01:00, Kustaa Nyholm :
> First of all, I'm talking about existing code and hardware.
>
> The existing code (without the bootloader) already pretty much
> fills the PIC18F4550.
>
> I can't just willy-nilly move to a bigger device, there is
> existing hardware on the field.
> I d
On 30/01/2015 14:15, "M L" wrote:
>Hi,
>I don't really get it, why You trying (so hard) use a bootloader which
>won't fit in boot block, so what?
>Bootloader can be with any size, just move user code to location
>after bootloader (to first free block of flash erase boundary).
>
>If size of user
Hi,
I don't really get it, why You trying (so hard) use a bootloader which
won't fit in boot block, so what?
Bootloader can be with any size, just move user code to location
after bootloader (to first free block of flash erase boundary).
If size of user code+bootloader won't fit into device - choo
> I'll try to give it a shot this weekend. If you are willing to help in
> testing (at least reporting what does not/no longer work once the changes are
> made ;-)), we should be able to find a solution here.
Hi Raphael,
that is brilliant! Sure I will help all I can.
br Kusti
Hoping to report
Hi Kusti,
I would have to look into extended instructions again.
I think the problem is that some of the design decisions taken by the PIC16
port (like placing local variables into the access bank) are directly
affected by the modified semantics of access to memory via the access bank
bank (0x00-0
