[fpc-devel] [fpc-pascal] ENC28J60 Ethernet Controller AVR/ARM Driver

[Dimitrios Chr. Ioannidis]

Hi Jeppe,

   Wow, what can I say.
   In a weekend you fix / resolve issues that they were stalled for a 
long time. Really appreciated.

On 2019-06-02 17:46, Jeppe Johansen wrote:
> On 6/1/19 3:37 PM, Dimitrios Chr. Ioannidis via fpc-pascal wrote:

< snip >

>>   First and more important, in the new FPC version, will the AVR
>> platform review / resolve the following issues :
>>     "AVR - incorrect stack error checking"
>> (https://bugs.freepascal.org/view.php?id=35332 [3])
>  It should work now. Looking into whether it will make sense to just
> use up all the space of non-data as suggested in the related issue.

Nice ! Now I can continue to work feeling safer avoiding unnoticed stack 
heap collision.

>>     "AVR - Assembler routines for 8, 16 & 32 bit unsigned div
>> (code contribution)" ( https://bugs.freepascal.org/view.php?id=32103
>> [4] )
>  Fixed as well.

Kudos to Christo Crause and thank you very much Jeppe that took the time 
to review it.

< snip >

>>     and add support for the avrxmega3 subarch, atmega 3208,
>> 3209, 4808, 4809 ( from Christo Crause's repository
>> https://github.com/ccrause/freepascal.git [7] ) ?

Any news, plans for those mcu's ( I don't want to push my luck ... )?

>>   Except from Laksen's ethernet stack (
>> https://github.com/Laksen/fp-ethernet.git [8] ) is there other, more
>> lightweight, ethernet stack library written in Object Pascal ?
>  Not sure, but I doubt it. But how much more lightweight do you need
> it to be? ;)

:-0 ! Ohh !

Just realized that the Laksen and Jeppe is the same person …

It's embarrassing ! :$ !

>>   As I'm not a compiler guy, is the "volatile" intrinsic supported
>> in AVR platform ( I didn't find it in intrinsics unit ) ?
>  It's supported, but it does not do anything at all. At least not now,
> and I don't think that will change. All global variable or pointer
> accesses are considered volatile to my knowledge.
> 
> But volatile in FPC does not guarantee any atomic access. So this
> would need to be by you. If what you need is just atomic access, then
> simple functions like these generate optimal code: procedure
> AtomicWnrite(var value: word; new_value: word); inline;
>  var
>    b: Byte;
>  begin
>    b:=avr_save;
>    value:=new_value;
>    avr_restore(b);
>  end;
> 
>  function AtomicRead(var value: word): word; inline;
>  var
>    b: Byte;
>  begin
>    b:=avr_save;
>    AtomicRead:=value;
>    avr_restore(b);
>  end;
> 
>>   In FPC embedded world/platforms, is the Object approach more SRAM
>> hungry ( my tests are inconclusive ) from the procedure / function
>> approach ?
>> 
>>   What's more embedded "friendly" ?
>  If used sensibly they should be more or less equal in size, but you
> will see some extra overhead with objects. Mostly due to needing
> passing the pointer to the object as an argument. But you also gain
> some level of abstraction. So it's a tradeoff.

Some valuable hints there.

Thank you Jeppe for your time and work.

regards,

-- 
Dimitrios Chr. Ioannidis