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
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
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
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
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
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
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
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
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 :=
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
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
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
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
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,
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
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,
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
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
18 matches
Mail list logo
