[fpc-devel] "embedded" again

[Sven Barth]

Am 15.01.2013 12:01, schrieb Michael Van Canneyt:
>
>
> On Tue, 15 Jan 2013, Sven Barth wrote:
>
>> Am 15.01.2013 11:52, schrieb Michael Van Canneyt:
>>>
>>>
>>> On Tue, 15 Jan 2013, Michael Schnell wrote:
>>>
>>>> On 01/15/2013 11:22 AM, Henry Vermaak wrote:
>>>>> On Tue, Jan 15, 2013 at 10:45:29AM +0100, Michael Schnell wrote:
>>>>>> (c) seems the most appropriate way to allow for decent debugging
>>>>>> performance, but seemingly nobody yet decently tried (or wrote
>>>>>> instructions to) to get Lazarus running remote gdb via TCP/IP.
>>>>> One of the options in the lazarus debugger settings is "GDB debugger
>>>>> through SSH".
>>>> I'll try to find instructions on this and try to install the gdb 
>>>> "stub" on the QNAP and test this combination  ASAP. (SSH already is 
>>>> in place on the QNAP.)
>>>>> Remote debugging with gdb on the command line also works
>>>>> well for many years.
>>>> Do you mean independently of Lazarus and fpc ?
>>>>
>>>> I already did test this with C programming and I all the time use 
>>>> Eclipse to debug embedded software via a USB-JTAG adapter which 
>>>> AFAIK for gdb and the system that controls gdb (here: Eclipse, but 
>>>> could be Lazarus as well) is identically to remote debugging via 
>>>> ICP/IP..
>>>>> You're not "stuck".
>>>> Of course I am not really stuck. :-) :-) .
>>>>
>>>> The program already does work nicely on the Linux PC server and I 
>>>> suppose I in fact don't need to debug it  on the ARM. I just need 
>>>> to compile it. And here I have the choice to install fpc on the 
>>>> QNAP (should be possible: I already successfully did install gcc). 
>>>> But I understand that installing fpc on the ARM is done by 
>>>> cross-compiling the compiler on a PC. So it seems even easier to 
>>>> cross-compile the user program itself.
>>>
>>> So
>>>
>>> "Cross-compile app every time"
>>>
>>> is easier/better than
>>>
>>> "Compile cross compiler once and work natively as of then"
>>>
>>> ?
>>>
>>> That is a weird assumption. I would go for the second one, hands 
>>> down...
>>
>> I wouldn't if the second one is significantly slower than the first 
>> one. Otherwise I'd agree :)
>
> On old hardware, maybe, but these days ?
I still have an old arm development board with around 200MHz... and I 
also don't know (yet) how my new m68k/coldfire board performs (also 200MHz).

Regards,
Sven