Re: [fpc-devel] Is target mips-embedded possible / planned?
On 05/22/2013 10:31 PM, Michel Catudal wrote: Without the PE you need to program a word at a time. There is no way that you can compete in speed with Microchip's PICKit or ICD without this. ... unless you recreate what the PICKit (rather the ICD3) does with a homebrew device (e.g. using PICKit hardware) and driver that communicates with the PC in a way you define (receiving blocks of data to be programmed) and handles the chip's interface appropriately. Since Microchip will not release information on their proprietary debugging we need to use debugger that support MIPS debug mode. Does this not help ? http://ww1.microchip.com/downloads/en/DeviceDoc/51242a.pdf Another way (without creating hardware) would be to find out how MPLABX interfaces PICKit or ICD3. I am convinced that they do use gdb in some way, but I did not easily find out more on this. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On 05/22/2013 10:31 PM, Michel Catudal wrote: I don't recall seeing debugging in the source code released for the PICKit. Correct me if I am wrong. In fact I did not take a look there, but I understand that with PICKit the lines are toggles vie USB and thus no such intelligence is necessary in the adapter. OTOH, I understand that ICD3 has built-in Intelligence to provide better performance with debugging and Flash programming. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On 05/22/2013 10:59 PM, Michel Catudal wrote: Not true. When debugging an AVR32 gdb is called avr32-gdb, a pic32 gdb would be called pic32mx-gdb. avr32-gdb talks to avr32gdbproxy for debugging and avr32program for programming. You could have a gdb version that talks directly thru jtag if you would spend the time writing it. You cannot use the on board gdb to debugger a foreign processor. That in fact is exactly what I meant to say. AFAI understand, these are cross-gdbs, running on the PC, but compiled for supporting a foreign arch via some kind of interface (e.g. a programming adapter). But they are full gdb's being accessed by a command line interface. OTOH a gdb-server (or stub) runs on the target device (that might be a different arch) and is to be accessed via a pipe interface by a full gdb program on a PC that - again - provides the command line interface that can be accessed by a Terminal or by Eclipse and friends. gdb has to be compiled for the target otherwise it will only support local opcodes . Yep. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Library announcement: Generics.Collections
Sorry for ugly e mail. I do not have much experience with mailing lists. Waiting for testing and suggestions. I've added a zip to download: https://code.google.com/p/fpc-generics-collections/downloads/list 2013/5/22 Maciej Izak hnb.c...@gmail.com Hi Free Pascal community! I'm pleased to announce the generic library, compatible with Delphi Generics.Collections (almost ;) ). Homepage https://code.google.com/p/fpc-generics-collections/ SVN http://fpc-generics-collections.googlecode.com/svn/trunk/ -- Regards. HNB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On Thursday 23 May 2013 10:10:05 Michael Schnell wrote: That in fact is exactly what I meant to say. AFAI understand, these are cross-gdbs, running on the PC, but compiled for supporting a foreign arch via some kind of interface (e.g. a programming adapter). But they are full gdb's being accessed by a command line interface. OTOH a gdb-server (or stub) runs on the target device Or the gdbserver runs on the PC and communicates with a debug interface hardware. MSEide uses this approach to debug AVR32 code with the AVR ONE! debugger and ARM chips (for example Energy Micro Tiny Gecko) with the Segger J-Link debugger which is built-in in the inexpensive demo board. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Library announcement: Generics.Collections
Am 22.05.2013 21:44, schrieb Maciej Izak: Hi Free Pascal community! I'm pleased to announce the generic library, compatible with Delphi Generics.Collections (almost ;) ). Homepage https://code.google.com/p/fpc-generics-collections/ SVN http://fpc-generics-collections.googlecode.com/svn/trunk/ Nice. Now I know where all those bug reports come from :P I have no knowledge of FPC compiler design, so i need a little help... First thing : To finish my work I need critical compiler magic functions/feature. At first look mayby there is no sense for this functions but during work on Generic library it's necessary: Are those available in Delphi as well? If not I see no use in them. function GetReferenceToValue(Value: T): Pointer; // for string types return @s[1] or nil for empty string for Int32 return @i etc. returns a reference to the value, as Consider this code: === code begin === procedure SomeProc(aValue: Int32); var p: Pointer; begin p := GetReferenceToValue(aValue); end; === code end === The value stored in p will be of no significant use for you to be stored in the longterm, because aValue will be located on the stack and thus the pointer will no longer be valid once the function exits. This will also be the case for strings, arrays, records, etc. No compiler magic will change this. measured by human/programmer function GetValueSize(Value: T): Integer; // for string types return Length(s), for Int32 returs 4 etc. You should not store the string's content, but only the reference to the string. If you use assignment operators the RTL will take care of the rest. Second thing: Bugs. Look at Critical - fix is needed to perform compatibility with Delphi and proper work. http://bugs.freepascal.org/view.php?id=24283 (CRITICAL! Very Important!) I don't consider nested specializations as critical. It's likely that I will fix this after I've fixed other generic problems... http://bugs.freepascal.org/view.php?id=24282 (CRITICAL! Very Important!) The underlying problem is also the source of some other bugs... I'm happy when I've fixed this, but it's not highest priority... (keyword: partial specialization) http://bugs.freepascal.org/view.php?id=24254 (CRITICAL! for TArray.SortT) I don't consider this critical. It's a missing feature that needs to be implemented and will be implemented when time permits (though I'm looking forward to having this feature available :) ) http://bugs.freepascal.org/view.php?id=24287 (Very Important!) http://bugs.freepascal.org/view.php?id=24072 (Very Important!) Also part of partial specialization http://bugs.freepascal.org/view.php?id=24097 (Important!) Forward declarations are encountered seldomly enough so that I don't consider this as important. http://bugs.freepascal.org/view.php?id=24064 (Important!) Considering that your example does not compile in Delphi either and the way generics and units work I consider it as unlikely that I'll fix that. http://bugs.freepascal.org/view.php?id=24071 (Important!) http://bugs.freepascal.org/view.php?id=24285 (Important!) http://bugs.freepascal.org/view.php?id=24286 similar to 24285 http://bugs.freepascal.org/view.php?id=24458 http://bugs.freepascal.org/view.php?id=24098 (Frustrating) That comes when Borland decides to use ... for generic parameters... I could still kill them for that decision -.- This won't be fixed for quite some time. http://bugs.freepascal.org/view.php?id=24073 http://bugs.freepascal.org/view.php?id=24463 Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On 05/23/2013 10:50 AM, Martin Schreiber wrote: Or the gdbserver runs on the PC and communicates with a debug interface hardware. MSEide uses this approach to debug AVR32 code with the AVR ONE! debugger and ARM chips (for example Energy Micro Tiny Gecko) with the Segger J-Link debugger which is built-in in the inexpensive demo board. I see. I did not expect that someone would be inclined to go this way, as you need to implement the (published but rather internal) gdb-gdbserver pipe protocol, and additionally you need to do the arch-dependent interpretation in your own software rather than have gdb do this and provide the results via it's well-understood command line pipe interface. But obviously you did have good reasons to do so. (Can you provide a short explanation, why ?) What kind of interface does AVR ONE! provide ? Does it come with a gdbserver type of driver on the PC ? BTW.: can you say anything regarding the PIC32 debugging issue ? Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On Thursday 23 May 2013 11:06:52 Michael Schnell wrote: On 05/23/2013 10:50 AM, Martin Schreiber wrote: Or the gdbserver runs on the PC and communicates with a debug interface hardware. MSEide uses this approach to debug AVR32 code with the AVR ONE! debugger and ARM chips (for example Energy Micro Tiny Gecko) with the Segger J-Link debugger which is built-in in the inexpensive demo board. I see. I did not expect that someone would be inclined to go this way, as you need to implement the (published but rather internal) gdb-gdbserver pipe protocol, and additionally you need to do the arch-dependent interpretation in your own software rather than have gdb do this and provide the results via it's well-understood command line pipe interface. But obviously you did have good reasons to do so. (Can you provide a short explanation, why ?) You misunderstood. The chain is MSEide-gdb-gdbserver-debughardware-target. What kind of interface does AVR ONE! provide ? AFAIK debugWIRE, PDI, aWire, JTAG, Nexus. Does it come with a gdbserver type of driver on the PC ? Yes. BTW.: can you say anything regarding the PIC32 debugging issue ? I don't use PIC32, sorry. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Library announcement: Generics.Collections
Nice. Now I know where all those bug reports come from :P :D It's my pleasure. Aren't you happy? Are those available in Delphi as well? If not I see no use in them. Consider this code: === code begin === procedure SomeProc(aValue: Int32); var p: Pointer; begin p := GetReferenceToValue(aValue); end; === code end === The value stored in p will be of no significant use for you to be stored in the longterm, because aValue will be located on the stack and thus the pointer will no longer be valid once the function exits. This will also be the case for strings, arrays, records, etc. No compiler magic will change this. Yes, I know that. I need this only for shortterm. In that case for safety maybe we should remove System.Addr? ;) In Delphi they do that by special interfaces created for each type (lost of time and memory). First, I can't implement this by Delphi way because we have still a lot of generics bugs. Secondly, I think that we can do much more better implementation of Generics. This is not C#, in Pascal we have better access to pointers. Now I'm using (I hope temporarily): === code begin === TValueAnsiStringHelper = record helper for AnsiString function GetValueSize: Integer; inline; function GetReferenceToValue: Pointer; inline; end; function TValueAnsiStringHelper.GetValueSize: Integer; begin Result := Length(Self) * SizeOf(AnsiChar); end; function TValueAnsiStringHelper.GetReferenceToValue: Pointer; begin if Length(Self) 0 then Result := @Self[1] else Result := nil; end; === code end === Etc. for other basic types. I, really need this for custom comparers and equality comparers, for example: === code begin === while AComparer.Compare(AValues[I].GetReferenceToValue, P.GetReferenceToValue, AValues[I].GetValueSize, P.GetValueSize) 0 do // ... if FEqualityComparer.Equals(AKey.GetReferenceToValue, LItem.Pair.Key.GetReferenceToValue, AKey.GetValueSize, LItem.Pair.Key.GetValueSize) then === code end === measured by human/programmer function GetValueSize(Value: T): Integer; // for string types return Length(s), for Int32 returs 4 etc. You should not store the string's content, but only the reference to the string. If you use assignment operators the RTL will take care of the rest. But with generics code for some types i don't have predefined operators (for example: records), and here is the problem with Generics Dictionary. GetValueSize and GetReferenceToValue is in the same level as System.SizeOf and System.Addr. I think it's a natural evolution System.SizeOf and System.Addr for Generics (to operate on values). There is no other language as FreePascal and it would be wrong to introduce something stupid to such an important system functions. If my thinking is wrong, please, any hint of an alternative. Without it, I'm completely stuck. http://bugs.freepascal.org/**view.php?id=24283http://bugs.freepascal.org/view.php?id=24283(CRITICAL! Very Important!) I don't consider nested specializations as critical. It's likely that I will fix this after I've fixed other generic problems... As critical error I mean - hardcore incompatibility with Delphi version of Generics.Collections. With critical error you can't compile Delphi code as is with this library. -- Regards, HNB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Library announcement: Generics.Collections
Am 23.05.2013 12:22, schrieb Maciej Izak:
Nice. Now I know where all those bug reports come from :P
:D It's my pleasure. Aren't you happy?
Depends. On the one hand I'm happy that someone stresses the generics
implementation to its limits (like JC Chu does as well), but on the
other hand it means work in - in case of generics - a bunch of
headaches... ;)
Are those available in Delphi as well? If not I see no use in them.
Consider this code:
=== code begin ===
procedure SomeProc(aValue: Int32);
var
p: Pointer;
begin
p := GetReferenceToValue(aValue);
end;
=== code end ===
The value stored in p will be of no significant use for you to
be stored in the longterm, because aValue will be located on the
stack and thus the pointer will no longer be valid once the
function exits. This will also be the case for strings, arrays,
records, etc. No compiler magic will change this.
Yes, I know that. I need this only for shortterm. In that case for
safety maybe we should remove System.Addr? ;) In Delphi they do that
by special interfaces created for each type (lost of time and memory).
First, I can't implement this by Delphi way because we have still a
lot of generics bugs. Secondly, I think that we can do much more
better implementation of Generics. This is not C#, in Pascal we have
better access to pointers. Now I'm using (I hope temporarily):
=== code begin ===
TValueAnsiStringHelper = record helper for AnsiString
function GetValueSize: Integer; inline;
function GetReferenceToValue: Pointer; inline;
end;
function TValueAnsiStringHelper.GetValueSize: Integer;
begin
Result := Length(Self) * SizeOf(AnsiChar);
end;
function TValueAnsiStringHelper.GetReferenceToValue: Pointer;
begin
if Length(Self) 0 then
Result := @Self[1]
else
Result := nil;
end;
=== code end ===
Etc. for other basic types.
I, really need this for custom comparers and equality comparers, for
example:
=== code begin ===
while AComparer.Compare(AValues[I].GetReferenceToValue,
P.GetReferenceToValue, AValues[I].GetValueSize, P.GetValueSize) 0 do
// ...
if FEqualityComparer.Equals(AKey.GetReferenceToValue,
LItem.Pair.Key.GetReferenceToValue, AKey.GetValueSize,
LItem.Pair.Key.GetValueSize) then
=== code end ===
I still see no need for this. I would simply do
=== code begin ===
if FEqualityComparer.Equals(AKey, LItem.Pair.Key) then
...
=== code end ===
Why fall back to pointers for something like this if we can use static
types?! And if that means that the comparer needs to be implemented for
each type, then so be it (you could implement a default generic
comparer, which uses the normal = operator, maybe some others for
basic types like strings and a TObject.Equals based one and the other
comparators should be supplied by the user). You can't do things as
equality tests in a general way anyway (best example: case sensitive vs.
case insensitive comparison of strings). If your concern is performance
then you could declare the two parameters as constref so that they are
passed by reference and not by value.
measured by human/programmer
function GetValueSize(Value: T): Integer; // for string
types return Length(s), for Int32 returs 4 etc.
You should not store the string's content, but only the reference
to the string. If you use assignment operators the RTL will take
care of the rest.
But with generics code for some types i don't have predefined
operators (for example: records), and here is the problem with
Generics Dictionary.
If your implementation of Generics.Dictionary needs certain operators
than the type with which the dictionary is specialized needs to
implement these operators. If the type does not: bad luck.
GetValueSize and GetReferenceToValue is in the same level as
System.SizeOf and System.Addr.
I think it's a natural evolution System.SizeOf and System.Addr for
Generics (to operate on values).
I see no need for a context sensitive SizeOf and your
GetReferenceToValue is simply flawed, because you can't capture the
correct location of a parameter passed by value as this is just a copy,
no @Self will result in the correct value here. E.g.:
=== code begin ===
{$mode objfpc}
type
TLongIntHelper = type helper for LongInt
function GetSelfAddress: Pointer;
end;
function TLongIntHelper.GetSelfAddress: Pointer;
begin
Result := @Self;
end;
var
l: LongInt;
procedure TestProc(aValue: LongInt);
begin
Writeln(hexstr(aValue.GetSelfAddress));
Writeln(hexstr(l.GetSelfAddress));
end;
begin
l := 42;
Writeln(hexstr(l.GetSelfAddress));
TestProc(l);
end.
=== code end ===
=== output begin ===
0040B000
0140FE4C
0040B000
=== output end ===
There is no other language as FreePascal and it would be wrong to
introduce something stupid to such an important system functions. If
my thinking is wrong, please, any hint of an alternative.
Re: [fpc-devel] Library announcement: Generics.Collections
In our previous episode, Sven Barth said: https://code.google.com/p/fpc-generics-collections/ SVN http://fpc-generics-collections.googlecode.com/svn/trunk/ Nice. Now I know where all those bug reports come from :P While playing a bit with this code using some minor stuff I have on top of delphi containers, I noticed something small: TListT obscures TList if generics.collections is imported after classes. It doesn't in Delphi. I used tthreadlist in generics.collections using code, and needed to declare a local (normal) tlist for it. The code itself didn't compile because of a lot of not really clear gendef errors. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Library announcement: Generics.Collections
Am 23.05.2013 12:59, schrieb Marco van de Voort: In our previous episode, Sven Barth said: https://code.google.com/p/fpc-generics-collections/ SVN http://fpc-generics-collections.googlecode.com/svn/trunk/ Nice. Now I know where all those bug reports come from :P While playing a bit with this code using some minor stuff I have on top of delphi containers, I noticed something small: TListT obscures TList if generics.collections is imported after classes. It doesn't in Delphi. I used tthreadlist in generics.collections using code, and needed to declare a local (normal) tlist for it. Yes, cross unit type overloading is still a problem in FPC. I've done some preparations to solve this (the compiler now keeps track whether a symtable contains a generic), but I've yet to implement the final lookup system for this. The code itself didn't compile because of a lot of not really clear gendef errors. I already have fixed the gendef problems you reported locally, but I need to find the time to write a nice commit message, because I've changed the complete implementation of constraints. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross compiling x86_64 - ARM (RPi) | EABI mis-match.
On 23 May 2013, at 05:54, Bruce Tulloch wrote: I built FPC 2.7.1 from trunk to cross compile as: make crossall crosszipinstall \ CPU_TARGET=arm OS_TARGET=linux \ CROSSBINDIR=/usr/local/opt/binutils/bin \ BINUTILSPREFIX=arm-linux- \ OPT=-XX -CX -dFPC_ARMHF When using this cross compiler to build my code (also with - dFPC_ARMHF) I get this error at the end of the link: /usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/cprt0.o has EABI version 0, but target a.out has EABI version 5 which suggests the RTL was not built with EABI 5. cpr0.o is not generated by the compiler from Pascal code, but directly from assembler. The code in that file is not specific to any ABI. The Makefile does not appear to pass the proper parameters to the assembler when processing that file during a compilation for the ARMHF target, so it doesn't get the proper markers. I'm not even certain whether the Makefile can easily determine that we are compiling for ARMHF. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross compiling x86_64 - ARM (RPi) | EABI mis-match.
Okay, thanks, so I should be able to simply patch the makefile in my copy of the fpc source to apply the correct assembler parameters when (re)building the RTL to fix this problem, right? If so, I'll look into doing this when I've resolved the cthreads issue. -b On Thu, May 23, 2013 at 10:29 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 05:54, Bruce Tulloch wrote: I built FPC 2.7.1 from trunk to cross compile as: make crossall crosszipinstall \ CPU_TARGET=arm OS_TARGET=linux \ CROSSBINDIR=/usr/local/opt/**binutils/bin \ BINUTILSPREFIX=arm-linux- \ OPT=-XX -CX -dFPC_ARMHF When using this cross compiler to build my code (also with -dFPC_ARMHF) I get this error at the end of the link: /usr/local/lib/fpc/2.7.1/**units/arm-linux/rtl/cprt0.o has EABI version 0, but target a.out has EABI version 5 which suggests the RTL was not built with EABI 5. cpr0.o is not generated by the compiler from Pascal code, but directly from assembler. The code in that file is not specific to any ABI. The Makefile does not appear to pass the proper parameters to the assembler when processing that file during a compilation for the ARMHF target, so it doesn't get the proper markers. I'm not even certain whether the Makefile can easily determine that we are compiling for ARMHF. Jonas __**_ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-develhttp://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross compiling x86_64 - ARM (RPi) | EABI mis-match.
On 23 May 2013, at 14:49, Bruce Tulloch wrote: Okay, thanks, so I should be able to simply patch the makefile in my copy of the fpc source to apply the correct assembler parameters when (re)building the RTL to fix this problem, right? If so, I'll look into doing this when I've resolved the cthreads issue. -b Yes. In theory, you could specify it on the command line via ASTARGET=somepara, but the problem is that this flag is used both when building natively and when cross-compiling. There is no separate cross version of that flag available. When cross-building from i386 to ARM it would work because for that target the assembler-based loader files are not used, but for x86-64 they are. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cross compiling x86_64 - ARM (RPi) | EABI mis-match.
Thanks for the tip; I will see if I can apply a patch dynamically when building the ARM cross-compiler and remove it when building all the others (they're all done in a multi-target build script I've written so presumably I just need to amend the clause that builds for ARM). -b On Thu, May 23, 2013 at 10:55 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:49, Bruce Tulloch wrote: Okay, thanks, so I should be able to simply patch the makefile in my copy of the fpc source to apply the correct assembler parameters when (re)building the RTL to fix this problem, right? If so, I'll look into doing this when I've resolved the cthreads issue. -b Yes. In theory, you could specify it on the command line via ASTARGET=somepara, but the problem is that this flag is used both when building natively and when cross-compiling. There is no separate cross version of that flag available. When cross-building from i386 to ARM it would work because for that target the assembler-based loader files are not used, but for x86-64 they are. Jonas __**_ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-develhttp://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
Le 2013-05-23 03:30, Michael Schnell a écrit : On 05/22/2013 10:31 PM, Michel Catudal wrote: Without the PE you need to program a word at a time. There is no way that you can compete in speed with Microchip's PICKit or ICD without this. ... unless you recreate what the PICKit (rather the ICD3) does with a homebrew device (e.g. using PICKit hardware) and driver that communicates with the PC in a way you define (receiving blocks of data to be programmed) and handles the chip's interface appropriately. Not a PIC32, debugging is bound to be different. Most likely they have some similarity though. Since Microchip will not release information on their proprietary debugging we need to use debugger that support MIPS debug mode. Does this not help ? http://ww1.microchip.com/downloads/en/DeviceDoc/51242a.pdf Another way (without creating hardware) would be to find out how MPLABX interfaces PICKit or ICD3. I am convinced that they do use gdb in some way, but I did not easily find out more on this. -Michael Some USB message trapping! -- For Linux Software visit http://home.comcast.net/~mcatudal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
Le 2013-05-23 03:30, Michael Schnell a écrit : On 05/22/2013 10:31 PM, Michel Catudal wrote: Without the PE you need to program a word at a time. There is no way that you can compete in speed with Microchip's PICKit or ICD without this. ... unless you recreate what the PICKit (rather the ICD3) does with a homebrew device (e.g. using PICKit hardware) and driver that communicates with the PC in a way you define (receiving blocks of data to be programmed) and handles the chip's interface appropriately. Since Microchip will not release information on their proprietary debugging we need to use debugger that support MIPS debug mode. Does this not help ? http://ww1.microchip.com/downloads/en/DeviceDoc/51242a.pdf Another way (without creating hardware) would be to find out how MPLABX interfaces PICKit or ICD3. I am convinced that they do use gdb in some way, but I did not easily find out more on this. -Michael From 61132B document To use ICD, an external system that supports ICD must load a debugger executive program into the microcontroller. This is automatically handled by many debugger tools, such as the MPLAB IDE. For PIC32MX devices, the program is loaded into the last page of the Boot Flash memory space. When not debugging, the application is free to use the last page of Boot Flash Memory. The document in question has some information on the debug registers. There is no very much but that could be a start. The part that is installed into the processor for programming is called Programming Executive (PE) You can find the document about programming on Microchip's web site. pic32prog does use the PE https://code.google.com/p/pic32prog/ Michel -- For Linux Software visit http://home.comcast.net/~mcatudal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
