Nabble - MicroControllers - GNUPIC

Re: gtk+extra package does not compile

2009-11-23T10:08:31Z

You can try with the patched version from
http://gpsim.sourceforge.net/gpsimWin32/packages/gtk+extra-2.1.1-src-20060611.zip
I prepared more then 3 years ago.

Borut

Nestor A. Marchesini wrote:

> Hello
>
> I'm a gentoo user ~x86 testing and a general update of my system (#
> emerge-uvaDN world)
> gtk+extra package gives me compilation errors.
>
> # emerge -av1 gtk+extra
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
> [ebuild R ] x11-libs/gtk+extra-2.1.1-r2 USE="-debug" 0 kB
> Total: 1 package (1 reinstall), Size of downloads: 0 kB
> Would you like to merge these packages? [Yes/No] y
>> >> Verifying ebuild manifests
>> >> Emerging (1 of 1) x11-libs/gtk+extra-2.1.1-r2
>
> and a little later ...
>
> i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I -I..
> -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> -I/usr/include/pixman-1 -I/usr/include/freetype2
> -I/usr/include/directfb -I/usr/include/libpng12 -O2 -march=prescott
> -pipe -Wall -MT gtkitementry.lo -MD -MP -MF .deps/gtkitementry.Tpo -c
> gtkitementry.c -fPIC -DPIC -o .libs/gtkitementry.lo
> gtkitementry.c: In function 'gtk_entry_real_insert_text':
> gtkitementry.c:696: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:696: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:698: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:698: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:700: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:701: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:704: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:705: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:705: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:706: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:709: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:710: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:710: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:712: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:712: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:721: error: 'GtkEntry' has no member named 'text_size'
> gtkitementry.c:726: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:729: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:733: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c: In function 'gtk_entry_real_delete_text':
> gtkitementry.c:766: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:768: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c: In function 'gtk_entry_move_cursor':
> gtkitementry.c:833: warning: enumeration value
> 'GTK_MOVEMENT_HORIZONTAL_PAGES' not handled in switch
> gtkitementry.c:867: warning: enumeration value
> 'GTK_MOVEMENT_HORIZONTAL_PAGES' not handled in switch
> gtkitementry.c: In function 'gtk_entry_retrieve_surrounding_cb':
> gtkitementry.c:1031: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c: In function 'gtk_entry_create_layout':
> gtkitementry.c:1232: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:1241: error: 'GtkEntry' has no member named 'n_bytes'
> gtkitementry.c:1275: error: 'GtkEntry' has no member named 'n_bytes'
> make[2]: *** [gtkitementry.lo] Error 1
> make[2]: *** Se espera a que terminen otras tareas....
> i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I -I..
> -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> -I/usr/include/pixman-1 -I/usr/include/freetype2
> -I/usr/include/directfb -I/usr/include/libpng12 -O2 -march=prescott
> -pipe -Wall -MT gtkiconlist.lo -MD -MP -MF .deps/gtkiconlist.Tpo -c
> gtkiconlist.c -o gtkiconlist.o >/dev/null 2>&1
> mv -f .libs/gtkiconlist.lo gtkiconlist.lo
> make[2]: se sale del directorio
> `/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/work/gtk+extra-2.1.1/gtkextra'
>
> make[1]: *** [all-recursive] Error 1
> make[1]: se sale del directorio
> `/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/work/gtk+extra-2.1.1'
> make: *** [all] Error 2
> * ERROR: x11-libs/gtk+extra-2.1.1-r2 failed:
> * compile failure
> *
> * Call stack:
> * ebuild.sh, line 55: Called src_compile
> * environment, line 2828: Called gnome2_src_compile
> * environment, line 2192: Called die
> * The specific snippet of code:
> * emake || die "compile failure"
> *
> * If you need support, post the output of 'emerge --info
> =x11-libs/gtk+extra-2.1.1-r2',
> * the complete build log and the output of 'emerge -pqv
> =x11-libs/gtk+extra-2.1.1-r2'.
> * The complete build log is located at
> '/var/log/portage/x11-libs:gtk+extra-2.1.1-r2:20091122-182957.log'.
> * The ebuild environment file is located at
> '/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/temp/environment'.
> * S: '/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/work/gtk+extra-2.1.1'
>
>> >> Failed to emerge x11-libs/gtk+extra-2.1.1-r2, Log file:
>
>> >> '/var/log/portage/x11-libs:gtk+extra-2.1.1-r2:20091122-182957.log'
>
> This worried me a lot because it is the package that makes the GUI
> gpsim operation, searching with google
> I meet people from debian that you wish to remove the GUI gpsim if
> unclaimed.
>
> http://www.mail-archive.com/debian-bugs-dist@.../msg701223.html
>
>
> There is there a patch that fits this?
>
> Greetings
> Néstor A. Marchesini
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: gtk+extra package does not compile

2009-11-23T08:09:38Z

El 22/11/09 21:17, Peter Stuge escribió:

> Hello Néstor,
>
> Nestor A. Marchesini wrote:
>> I'm a gentoo user ~x86 testing and a general update of my system
>> (# emerge-uvaDN world) gtk+extra package gives me compilation
>> errors.
>
> First of all, my advice is to emerge world fairly seldom, especially
> on ~x86. I find it is rarely needed, and can often cause problems. I
> prefer to update single packages instead.

Hello Peter

Yes, I know, but I come from realigning the entire system:

# emerge -euvaDN system && emerge -euvaDN system
# emerge -euvaDN world

To take the new changes in glibc with latest kernel headers.
Now everything is much more rapid and fluid, except that the "only"
package that does not compile is gtk+extra
Yes, I will try to report the bug.
> Please remember that these are very separate issues. The first issue
> is that gtk+extra does not build on your system. This is actually a
> Gentoo bug, and if you like, you can file a bug report about it at
> bugs.gentoo.org.
Yes, I will try to report the bug.

> gtk+extra seems to have been deprecated, and will not be developed
> further. In that case, there is also a gpsim bug, and gpsim should
> then be updated to work without gtk+extra. This mailing list is
> probably the right place for discussing gpsim development, but as
> Neil observes on the debian mailing list, there is not a lot of
> development activity for gpsim.
>
> The other issue is that debian does not have a maintainer for the
> gpsim package in debian, and that may drop gpsim from their package
> repository, which would of course be sad but at least you still have
> your gpsim package installed.
>
> The two issues are not really related.
> I agree that gpsim could benefit from being updated to the latest and
> greatest gtk+ API, but until it does you will have to keep your
> current version of gtk+extra installed, and possibly also a certain
> version of gtk+ itself, in order to let gpsim run on your system.
>
> //Peter

I also believe that gpsin should remove gtk+extra and passed of gtk2 to
gtk3 (which will be released in June 2010).
I'll have to forget the gpsim GUI and trying to make it work gpsim from
piklab.

Thanks for your reply
Greetings

Néstor A. Marchesini

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: gtk+extra package does not compile

2009-11-22T16:17:00Z

Hello Néstor,

Nestor A. Marchesini wrote:
> I'm a gentoo user ~x86 testing and a general update of my system
> (# emerge-uvaDN world) gtk+extra package gives me compilation
> errors.

First of all, my advice is to emerge world fairly seldom, especially
on ~x86. I find it is rarely needed, and can often cause problems. I
prefer to update single packages instead.

> [ebuild R ] x11-libs/gtk+extra-2.1.1-r2 USE="-debug" 0 kB
..
> gtkitementry.c: In function 'gtk_entry_real_insert_text':
> gtkitementry.c:696: error: 'GtkEntry' has no member named 'n_bytes'
..
>> >> Failed to emerge x11-libs/gtk+extra-2.1.1-r2, Log file:
>
> This worried me a lot because it is the package that makes the GUI
> gpsim operation, searching with google I meet people from debian
> that you wish to remove the GUI gpsim if unclaimed.
>
> http://www.mail-archive.com/debian-bugs-dist@.../msg701223.html

Please remember that these are very separate issues. The first issue
is that gtk+extra does not build on your system. This is actually a
Gentoo bug, and if you like, you can file a bug report about it at
bugs.gentoo.org.

gtk+extra seems to have been deprecated, and will not be developed
further. In that case, there is also a gpsim bug, and gpsim should
then be updated to work without gtk+extra. This mailing list is
probably the right place for discussing gpsim development, but as
Neil observes on the debian mailing list, there is not a lot of
development activity for gpsim.

The other issue is that debian does not have a maintainer for the
gpsim package in debian, and that may drop gpsim from their package
repository, which would of course be sad but at least you still have
your gpsim package installed.

The two issues are not really related.

> There is there a patch that fits this?

No.

I agree that gpsim could benefit from being updated to the latest and
greatest gtk+ API, but until it does you will have to keep your
current version of gtk+extra installed, and possibly also a certain
version of gtk+ itself, in order to let gpsim run on your system.

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

gtk+extra package does not compile

2009-11-22T13:13:39Z

Hello

I'm a gentoo user ~x86 testing and a general update of my system (#
emerge-uvaDN world)
gtk+extra package gives me compilation errors.

# emerge -av1 gtk+extra
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] x11-libs/gtk+extra-2.1.1-r2 USE="-debug" 0 kB
Total: 1 package (1 reinstall), Size of downloads: 0 kB
Would you like to merge these packages? [Yes/No] y
> >> Verifying ebuild manifests
> >> Emerging (1 of 1) x11-libs/gtk+extra-2.1.1-r2

and a little later ...

i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I -I.. -D_REENTRANT
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12
-O2 -march=prescott -pipe -Wall -MT gtkitementry.lo -MD -MP -MF
.deps/gtkitementry.Tpo -c gtkitementry.c -fPIC -DPIC -o
.libs/gtkitementry.lo
gtkitementry.c: In function 'gtk_entry_real_insert_text':
gtkitementry.c:696: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:696: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:698: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:698: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:700: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:701: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:704: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:705: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:705: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:706: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:709: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:710: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:710: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:712: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:712: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:721: error: 'GtkEntry' has no member named 'text_size'
gtkitementry.c:726: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:729: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:733: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c: In function 'gtk_entry_real_delete_text':
gtkitementry.c:766: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:768: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c: In function 'gtk_entry_move_cursor':
gtkitementry.c:833: warning: enumeration value
'GTK_MOVEMENT_HORIZONTAL_PAGES' not handled in switch
gtkitementry.c:867: warning: enumeration value
'GTK_MOVEMENT_HORIZONTAL_PAGES' not handled in switch
gtkitementry.c: In function 'gtk_entry_retrieve_surrounding_cb':
gtkitementry.c:1031: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c: In function 'gtk_entry_create_layout':
gtkitementry.c:1232: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:1241: error: 'GtkEntry' has no member named 'n_bytes'
gtkitementry.c:1275: error: 'GtkEntry' has no member named 'n_bytes'
make[2]: *** [gtkitementry.lo] Error 1
make[2]: *** Se espera a que terminen otras tareas....
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I -I.. -D_REENTRANT
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12
-O2 -march=prescott -pipe -Wall -MT gtkiconlist.lo -MD -MP -MF
.deps/gtkiconlist.Tpo -c gtkiconlist.c -o gtkiconlist.o >/dev/null 2>&1
mv -f .libs/gtkiconlist.lo gtkiconlist.lo
make[2]: se sale del directorio
`/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/work/gtk+extra-2.1.1/gtkextra'
make[1]: *** [all-recursive] Error 1
make[1]: se sale del directorio
`/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/work/gtk+extra-2.1.1'
make: *** [all] Error 2
* ERROR: x11-libs/gtk+extra-2.1.1-r2 failed:
* compile failure
*
* Call stack:
* ebuild.sh, line 55: Called src_compile
* environment, line 2828: Called gnome2_src_compile
* environment, line 2192: Called die
* The specific snippet of code:
* emake || die "compile failure"
*
* If you need support, post the output of 'emerge --info
=x11-libs/gtk+extra-2.1.1-r2',
* the complete build log and the output of 'emerge -pqv
=x11-libs/gtk+extra-2.1.1-r2'.
* The complete build log is located at
'/var/log/portage/x11-libs:gtk+extra-2.1.1-r2:20091122-182957.log'.
* The ebuild environment file is located at
'/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/temp/environment'.
* S: '/var/tmp/portage/x11-libs/gtk+extra-2.1.1-r2/work/gtk+extra-2.1.1'

> >> Failed to emerge x11-libs/gtk+extra-2.1.1-r2, Log file:

> >> '/var/log/portage/x11-libs:gtk+extra-2.1.1-r2:20091122-182957.log'

This worried me a lot because it is the package that makes the GUI gpsim
operation, searching with google
I meet people from debian that you wish to remove the GUI gpsim if
unclaimed.

http://www.mail-archive.com/debian-bugs-dist@.../msg701223.html

There is there a patch that fits this?

Greetings
Néstor A. Marchesini

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: gpdasm 0.13.6 alpha question

2009-11-20T12:55:29Z

I've been looking into byte vs. word addressing in gputils when ever I
have had some spare time. That is not very often, so the progress has
been very slow.

Since it now seems I'll eventually end up with some sort of a patch,
I'll let you know I'm working on it and report my current idea for it.

I've changed MemBlock to byte storage. I'll use the byte address for
everything internally. For instruction handling I always treat an
instruction as two bytes and for instruction writing and reading there
will be functions that write and read the two bytes. Instruction
memory usage is therefore also managed byte by byte. When ever an
instruction address is needed (in COFF or COD headers or messages for
ROM sections, or in assembly) it'll see if its not PIC16E and divide
byte address by two.

I've also turned processor class into a structure that holds what is
needed to remove a number of processor class switch statements around
the code.

Not everything compiles yet, and I expect it'll take some time to
clean it up and get it to pass the tests again. If someone likes to
take a look and comment or continue on it, I can send the patch in
whatever state it happens to be.

Marko

On Tue, Mar 17, 2009 at 3:32 PM, David Barnett <daviebdawg@...> wrote:

> Marko, that sounds right to me. Our handling of byte vs. word addressing is
> ugly throughout the system, and it definitely seems like we need to give
> byte order and address type an explicit representation.
>
> If you come up with something, I'd love to see it.
>
> David
>
> On Tue, Mar 17, 2009 at 5:02 AM, Marko Kohtala <marko.kohtala@...>wrote:
>
>> I too have been trying to wrap my head around these memory issues.
>>
>> Which is rather difficult as there seem to be things which are not
>> obvious and there are little comments to explain what is the design
>> choice. Does any developer have any feelings the code is better off
>> without such comments?
>>
>> This particular bug seems to be in the gpreadhex.c. It combines two
>> bytes into one word, hence dividing each address in .hex by two to get
>> the address for MemBlock access. However it does not do this for the
>> .hex record 04 value which sets the page. Therefore the data after
>> this records ends up into addresses twice too large in MemBlock. Of
>> course the values in page 0 are not affected.
>>
>> My current understanding is it would be clearer if MemBlock was
>> changed to be byte storage. It would then record separately for each
>> byte whether they have been used or not and these .hex file readers
>> and few other places need not be so complex to support partial words.
>>
>> Instead of scattering the processor class specifics in accessing
>> MemBlock around, I'd rather use some object oriented design and access
>> MemBlock through the processor class. The processor class would then
>> uniformly solve these addressing issues, as well as byte order issues.
>> This design change easily blows up because it could replace also a
>> number of other switch-case and if-else constructs around the code
>> with single call to processor class function.
>>
>> It'd take some thought.
>>
>> Maybe a simple fix to this gpdasm problem could be made before such
>> design changes. I attach a patch. Robert, does this solve the problem?
>>
>> Marko
>>
>> On Tue, Mar 17, 2009 at 9:04 AM, Peter Keller <psilord@...> wrote:
>> > On Wed, Mar 11, 2009 at 09:41:10PM +0000, Robert Pearce wrote:
>> >> Given what you've posted, it appears gpdasm may be misinterpreting the
>> >> "type 04" blocks - the lines of the HEX file that begin ":02000004"
>> >
>> > So, I inspected the readhex() function and followed what it was doing
>> during
>> > the gpdasm, and eventually found that it led to here:
>> >
>> > MemBlock * i_memory_new(MemBlock *m, MemBlock *mbp, unsigned int
>> base_address)
>> > {
>> > unsigned int base;
>> >
>> > /* added by psilord */
>> > printf("i_memory_new raw base_address = 0x%x\n", base_address);
>> >
>> > base = (base_address >> I_MEM_BITS) & 0xFFFF;
>> >
>> > /* added by psilord */
>> > printf("i_memory_new cooked base_address = 0x%x\n", base);
>> >
>> > mbp->memory = (unsigned int *)calloc(MAX_I_MEM, sizeof(unsigned int));
>> > mbp->base = base;
>> >
>> > do {
>> >
>> > if((m->next == NULL) || (m->next->base > base)) {
>> > /* Insert after this block */
>> > mbp->next = m->next;
>> > m->next = mbp;
>> > return mbp;
>> > }
>> >
>> > m = m->next;
>> > } while(m);
>> >
>> > assert(0);
>> >
>> > return NULL;
>> > }
>> >
>> >
>> > Here is some sample output:
>> >
>> > i_memory_new raw base_address = 0x30000000
>> > i_memory_new cooked base_address = 0x6000
>> >
>> > i_memory_new raw base_address = 0xf0000000
>> > i_memory_new cooked base_address = 0xe000
>> >
>> > So, from what I can gather, when readhex is supplying to i_memory_put the
>> > address to which it wants to write, the base address gets miscomputed in
>> the
>> > above function when it is a "new" address in a different memblock.
>> >
>> > Given the portion of code in gpdasm.c:dasm() which shifts left the
>> > base address of the mem block by one bit of the processor is of class
>> > PROC_CLASS_16E, maybe when i_memory_new is called and the state.class
>> > is PROC_CLASS_16E, it should shift right the base address by one more
>> > bit so it doesn't get truncated by the 0xFFFF? I hacked a test of that by
>> > hand hand it seemed to do the right thing. However, the state variable
>> > doesn't seem to be used in gpmemory.c, and I fear if I add that
>> dependancy
>> > in there I'm doing something wrong since it wasn't already in there. ;)
>> >
>> > Any ideas?
>> >
>> > Thanks.
>> >
>> > -pete
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: gnupic-unsubscribe@...
>> > For additional commands, e-mail: gnupic-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: gnupic-unsubscribe@...
>> For additional commands, e-mail: gnupic-help@...
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: PiKdev 1.2.1 available

2009-10-17T14:01:23Z

Le Saturday 17 October 2009 01:47:45 George M. Gallant, Jr., vous avez écrit :

Hello George

The src package containts a cpik050.pro, which is an input file for qmake
(the Makefile generator from trolltech/nokia which comes with Qt)

qmake -o Makefile cpik050.pro

generates the Makefile, according to the target system

This point is expained in the cpik WEB page, but an INSTALL
or README file should be provided in the package.

I plan to switch to cmake in the future - but I need to become comfortable
with it.

I am not sure it is really a good idea to install to /usr/local because
the executable itself is related to OS version (it depends on
glibc and stdc++ shared libraries)
After a major OS release, cpik will not work anymore if it is not rebuilded.
However, I must admit that such a situation is very rare.

Other files (cpik libraries, run-time library, devices headers) could be
stored in /usr/local/share. I just put them in /usr/share because 98%
of apps do that, but if people are unhappy with that, I can change it.

Alain

> Alain,
>
> I downloaded the src & bin for cpik. Two comments:
>
> 1. The src does not have a Makefile.
>
> 2. The bin install script is hard coded to install in /usr.
> I prefer to install non-distribution related code in /usr/local
> so that it does not get erased with the next OS upgrade.
>
> Thanks,
> George
>
> On 10/08/2009 04:21 PM, Alain Gibaud wrote:
> > Hi,
> >
> > PiKdev is a lightweigth integrated development environment for PIC
> > devices which exists since 2002. Due to various reasons, the development
> > of this IDE has been stopped during a couple of years, but I found enough
> > time to develop it again.
> >
> > PiKdev supports pic10, pic12, pic16 and pic18 devices.
> > Supported programmers are serial (JDM-like), parrallel (Tait-like)
> > or USB (Microchip's pickit2 and clones).
> >
> > Programming languages are ASM (with gputils tools) and C
> > (with the cpik compiler for PIC18 devices).
> >
> > PiKdev is simple but handy. It supports the "project concept",
> > but can also be used for stand-alone asm files.
> >
> > Recent improvements are:
> >
> > - Improved project browser, with direct access to each
> > function/variable/typedef declaration or definition.
> > This feature works also with cpik's source libraries (.slb files)
> > and is very useful when a project become important. A C parser has been
> > developped for C source code analysis.
> >
> > - Interactive CONFIG bits editor. This feature has been developed for
> > PIC18 devices because they contain no less then 14 config registers.
> > Populating these registers is a pain when you begin a project. The editor
> > allows you to choose a configuration and generates (commented) source
> > code for you. Can be used in both ASM or C contexts, and works for all
> > supported devices. Config fuses are now part of the project parameters.
> >
> > Link for pikdev: http://pikdev.free.fr
> >
> > The cpik (PIC18 only) compiler is now perfectly usable and has been used
> > for several projects (V0.5). Feel free to test and report opinions.
> >
> > Link for cpik: http://pikdev.free.fr/download-cpik.php3
> >
> > Alain
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: PiKdev 1.2.1 available

2009-10-16T16:47:45Z

Alain,

I downloaded the src & bin for cpik. Two comments:

1. The src does not have a Makefile.

2. The bin install script is hard coded to install in /usr.
I prefer to install non-distribution related code in /usr/local
so that it does not get erased with the next OS upgrade.

Thanks,
George

On 10/08/2009 04:21 PM, Alain Gibaud wrote:

> Hi,
>
> PiKdev is a lightweigth integrated development environment for PIC devices
> which exists since 2002. Due to various reasons, the development
> of this IDE has been stopped during a couple of years, but I found enough time
> to develop it again.
>
> PiKdev supports pic10, pic12, pic16 and pic18 devices.
> Supported programmers are serial (JDM-like), parrallel (Tait-like)
> or USB (Microchip's pickit2 and clones).
>
> Programming languages are ASM (with gputils tools) and C
> (with the cpik compiler for PIC18 devices).
>
> PiKdev is simple but handy. It supports the "project concept",
> but can also be used for stand-alone asm files.
>
> Recent improvements are:
>
> - Improved project browser, with direct access to each
> function/variable/typedef declaration or definition.
> This feature works also with cpik's source libraries (.slb files)
> and is very useful when a project become important. A C parser has been
> developped for C source code analysis.
>
> - Interactive CONFIG bits editor. This feature has been developed for PIC18
> devices because they contain no less then 14 config registers. Populating
> these registers is a pain when you begin a project. The editor allows you to
> choose a configuration and generates (commented) source code for you.
> Can be used in both ASM or C contexts, and works for all supported devices.
> Config fuses are now part of the project parameters.
>
> Link for pikdev: http://pikdev.free.fr
>
> The cpik (PIC18 only) compiler is now perfectly usable and has been used for
> several projects (V0.5). Feel free to test and report opinions.
>
> Link for cpik: http://pikdev.free.fr/download-cpik.php3
>
> Alain
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: PiKdev 1.2.1 available

2009-10-08T13:55:42Z

Alain Gibaud wrote:
> The cpik (PIC18 only) compiler is now perfectly usable and has been
> used for several projects (V0.5). Feel free to test and report
> opinions.

I haven't gotten around to using SDCC and I have to say I really the
looks of cpik! I'll give it a go in a project likely later this year.
I need timers, AD, some math and serial output so I'm all set! :)

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

PiKdev 1.2.1 available

2009-10-08T13:21:38Z

Hi,

PiKdev is a lightweigth integrated development environment for PIC devices
which exists since 2002. Due to various reasons, the development
of this IDE has been stopped during a couple of years, but I found enough time
to develop it again.

PiKdev supports pic10, pic12, pic16 and pic18 devices.
Supported programmers are serial (JDM-like), parrallel (Tait-like)
or USB (Microchip's pickit2 and clones).

Programming languages are ASM (with gputils tools) and C
(with the cpik compiler for PIC18 devices).

PiKdev is simple but handy. It supports the "project concept",
but can also be used for stand-alone asm files.

Recent improvements are:

- Improved project browser, with direct access to each
function/variable/typedef declaration or definition.
This feature works also with cpik's source libraries (.slb files)
and is very useful when a project become important. A C parser has been
developped for C source code analysis.

- Interactive CONFIG bits editor. This feature has been developed for PIC18
devices because they contain no less then 14 config registers. Populating
these registers is a pain when you begin a project. The editor allows you to
choose a configuration and generates (commented) source code for you.
Can be used in both ASM or C contexts, and works for all supported devices.
Config fuses are now part of the project parameters.

Link for pikdev: http://pikdev.free.fr

The cpik (PIC18 only) compiler is now perfectly usable and has been used for
several projects (V0.5). Feel free to test and report opinions.

Link for cpik: http://pikdev.free.fr/download-cpik.php3

Alain

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-08T10:23:13Z

Hi Noel,

> The reason I ask is that I'd have no problem designing a universal PIC
> programmer for us all to use.

Are you familiar with USBprog? There was an article on it in Elektor a
while back.

http://www.embedded-projects.net/index.php?page_id=165

Open source hardware and software. Different firmwares for programming
different families of devices along with other non-programming tasks.

http://www.embedded-projects.net/index.php?page_id=168

Having that support PIC properly would be good.

Cheers,

Ralph.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-08T10:11:05Z

Noel Henson wrote:
> Ah, the reason for the PIC with the USB IC are the issues with
> cross-platform USB drivers.

Strongly disagree. It's not that tricky. libusb and WinUSB cover a
lot of ground.

Good descriptors (no, I don't mean HID. Axelson's advice is great if
Windows is the only thing in one's world) and only very little host
code is needed.

> It's much easier for small volume products to put all of the USB
> issues to rest by using a USB-to-serial IC. No firmware issues. No
> extra engineering issues. No wasted host driver development time.

Your choice. I think USB devices deserve more careful thought. It is
almost always possible to make use of USB features in a way that
benefits the application, which is just impossible with a dumb
USB-to-serial chip. And, a discrete chip adds to BOM, size and cost,
only if just very little.

Finally, when USB-to-serial is an absolute must, I suggest Silicon
Labs CP2102 or CP2103, or possibly Prolific PL2303, rather than FTDI
chips. (No, I don't work for them. I've just had too much annoying
trouble with FTDI parts.)

https://www.silabs.com/products/interface/usbtouart/
https://www.silabs.com/Marcom%20Documents/Resources/CP210x_Comparison.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2103.pdf

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:45:17Z

On Thu, Oct 08, 2009 at 09:05:27AM -0700, Noel Henson wrote:

>
> The reason I ask is that I'd have no problem designing a universal PIC
> programmer for us all to use. In the past I needed to create one that
> worked for a particular line of remote controls for groups. It could
> program the Atmel (which is SPI-like) and Microchip (different for each
> family + HV Vpp). If the complexity of the programming 'OS' as Microchip
> calls it is removed from the programmer, or rather if the programmer only
> knew about the physical layer protocol, then the programming algorithm for
> each family could reside on the host where it is very easy to change.
>
> If I were to design one, I'd probably take the cheapest PIC part with and
> SCI port, add a charge pump for Vpp and throw on a USB-to-serial IC and
> call it done. But I'll only put in the effort if there's interest.
>
> Noel

Hi,

have you seen the Open Programmer?

http://openprog.altervista.org/

Anselmo

>
> --
>
> ------------------------------------------------------------------
> Noel Henson
> www.noels-lab.com Chips, firmware and embedded systems
> www.vimoutliner.org Work fast. Think well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>

signature.asc (853 bytes) Download Attachment

Re: Pic-Kit 3 and Linux?

2009-10-08T09:44:46Z

On Thursday 08 October 2009, Joe Pfeiffer wrote:

> Noel Henson writes:
> >The reason I ask is that I'd have no problem designing a universal PIC
> >programmer for us all to use. In the past I needed to create one that
> >worked for a particular line of remote controls for groups. It could
> >program the Atmel (which is SPI-like) and Microchip (different for each
> >family + HV Vpp). If the complexity of the programming 'OS' as
> > Microchip calls it is removed from the programmer, or rather if the
> > programmer only knew about the physical layer protocol, then the
> > programming algorithm for each family could reside on the host where
> > it is very easy to change.
> >
> >If I were to design one, I'd probably take the cheapest PIC part with
> > and SCI port, add a charge pump for Vpp and throw on a USB-to-serial
> > IC and call it done. But I'll only put in the effort if there's
> > interest.
>
> I'd be interested in such a thing. Having the intelligence on the
> host would definitely be a Good Thing.
>
> Why a PIC with SCI and a USB-to-serial rather than a PIC with USB?
> Also, for ease in assembly, I'd suggest cheapest DIP rather than
> cheapest (I've hand soldered surface-mount and regarded it as No Fun).
>

Ah, the reason for the PIC with the USB IC are the issues with
cross-platform USB drivers. I've been down this road many times. It's much
easier for small volume products to put all of the USB issues to rest by
using a USB-to-serial IC. No firmware issues. No extra engineering issues.
No wasted host driver development time. That kind of thing. And the
manufacturer of the USB-to-serial IC takes care of and keeps up-to-date the
host-side drivers.

I do prefer the SMT devices, though. If one can solder a DIP, then one can
solder a 50mil pitch SMT device. But, if we get that far with this, I'll
keep that in mind. Besides, if I were to do such a thing, I'd try to have
them assembled professionally in panels.

Noel

--

------------------------------------------------------------------
Noel Henson
www.noels-lab.com Chips, firmware and embedded systems
www.vimoutliner.org Work fast. Think well.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:37:37Z

Joe Pfeiffer wrote:
> >If I were to design one, I'd probably take the cheapest PIC part
> >with and SCI port, add a charge pump for Vpp and throw on a
> >USB-to-serial IC and call it done. But I'll only put in the effort
> >if there's interest.
>
> I'd be interested in such a thing. Having the intelligence on the
> host would definitely be a Good Thing.

It will also be kinda slow. But it's better than nothing.

> Why a PIC with SCI and a USB-to-serial rather than a PIC with USB?

Please PLEASE do not ever use USB-to-serial as the first choice!
It's a totally dumbed down way of using USB. It would be MUCH better
to use one of the USB PICs.

> Also, for ease in assembly, I'd suggest cheapest DIP rather than
> cheapest (I've hand soldered surface-mount and regarded it as No
> Fun).

I think SMT is fun, but it can be small. Fortunately there are USB
PICs which come in both SO and PDIP packaging so the same design can
easily be reused to create both a very compact design, and one which
is very easy to build.

Note that this design, (USB PCI + sync serial port + charge pump) is
pretty much what is inside the PICkit2.

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:29:19Z

Noel Henson writes:

>
>The reason I ask is that I'd have no problem designing a universal PIC
>programmer for us all to use. In the past I needed to create one that
>worked for a particular line of remote controls for groups. It could
>program the Atmel (which is SPI-like) and Microchip (different for each
>family + HV Vpp). If the complexity of the programming 'OS' as Microchip
>calls it is removed from the programmer, or rather if the programmer only
>knew about the physical layer protocol, then the programming algorithm for
>each family could reside on the host where it is very easy to change.
>
>If I were to design one, I'd probably take the cheapest PIC part with and
>SCI port, add a charge pump for Vpp and throw on a USB-to-serial IC and
>call it done. But I'll only put in the effort if there's interest.

I'd be interested in such a thing. Having the intelligence on the
host would definitely be a Good Thing.

Why a PIC with SCI and a USB-to-serial rather than a PIC with USB?
Also, for ease in assembly, I'd suggest cheapest DIP rather than
cheapest (I've hand soldered surface-mount and regarded it as No Fun).

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:05:27Z

On Wednesday 07 October 2009, Joe Pfeiffer wrote:

> Noel Henson writes:
> >On Wednesday 07 October 2009, Noel Henson wrote:
> >> On Wednesday 07 October 2009, Xiaofan Chen wrote:
> >> > On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer
> >> > <joseph@...>
> >>
> >> wrote:
> >> > > I see code to use Microchip's PICkit 2 under Linux is available
> >> > > from Microchip. Meanwhile, they are pushing hard to use their
> >> > > PICKit 3 for new designs. Does the PICKit 3 use the same command
> >> > > set as PICKit 2, or is there otherwise a way to use it with
> >> > > Linux?
> >> >
> >> > PICkit 3 does not use the same command set as PICkit 2. Its
> >> > firmware structure is also different from PICkit 2 (more like ICD
> >> > 2). So as of now it is not working under native Linux.
> >> >
> >> > You can of course use Virtual Machines and Windows to get
> >> > it working under Linux.
> >> >
> >> > I am not so sure when this situation will change. As of now,
> >> > PICkit 3 is not as good as PICkit 2, even under Windows.
> >> > Ref: http://www.microchip.com/forums/tm.aspx?m=450226
> >>
> >> Just a question... Do really we need an inexpensive, Linux-capable
> >> PIC programmer?
> >>
> >> Noel
> >
> >Whoa, it must be getting late. That should read, "do we really need an
> >inexpensive, Linux-capable PIC programmer?"
>
> "Need" is an awfully strong word. If you were to dilute your question
> to "would we really, really prefer to have an inexpensive PIC
> programmer we can use without either rebooting to Windows or starting
> a VM", my answer would be "yes".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...

The reason I ask is that I'd have no problem designing a universal PIC
programmer for us all to use. In the past I needed to create one that
worked for a particular line of remote controls for groups. It could
program the Atmel (which is SPI-like) and Microchip (different for each
family + HV Vpp). If the complexity of the programming 'OS' as Microchip
calls it is removed from the programmer, or rather if the programmer only
knew about the physical layer protocol, then the programming algorithm for
each family could reside on the host where it is very easy to change.

If I were to design one, I'd probably take the cheapest PIC part with and
SCI port, add a charge pump for Vpp and throw on a USB-to-serial IC and
call it done. But I'll only put in the effort if there's interest.

Noel

--

------------------------------------------------------------------
Noel Henson
www.noels-lab.com Chips, firmware and embedded systems
www.vimoutliner.org Work fast. Think well.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-07T23:32:16Z

>
> Just a question... Do really we need an inexpensive, Linux-capable PIC
> programmer?
>
> Noel
>

Sometimes, I would really need a Linux-capable debugger as well - i use PIC18F family and SDCC. Even debugging in GDB would be sufficient.

Vaclav

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-07T21:25:17Z

Noel Henson writes:

>On Wednesday 07 October 2009, Noel Henson wrote:
>> On Wednesday 07 October 2009, Xiaofan Chen wrote:
>> > On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer
>> > <joseph@...>
>>
>> wrote:
>> > > I see code to use Microchip's PICkit 2 under Linux is available from
>> > > Microchip. Meanwhile, they are pushing hard to use their PICKit 3
>> > > for new designs. Does the PICKit 3 use the same command set as
>> > > PICKit 2, or is there otherwise a way to use it with Linux?
>> >
>> > PICkit 3 does not use the same command set as PICkit 2. Its
>> > firmware structure is also different from PICkit 2 (more like ICD 2).
>> > So as of now it is not working under native Linux.
>> >
>> > You can of course use Virtual Machines and Windows to get
>> > it working under Linux.
>> >
>> > I am not so sure when this situation will change. As of now,
>> > PICkit 3 is not as good as PICkit 2, even under Windows.
>> > Ref: http://www.microchip.com/forums/tm.aspx?m=450226
>>
>> Just a question... Do really we need an inexpensive, Linux-capable PIC
>> programmer?
>>
>> Noel
>
>Whoa, it must be getting late. That should read, "do we really need an
>inexpensive, Linux-capable PIC programmer?"

"Need" is an awfully strong word. If you were to dilute your question
to "would we really, really prefer to have an inexpensive PIC
programmer we can use without either rebooting to Windows or starting
a VM", my answer would be "yes".

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-07T21:22:43Z

Xiaofan Chen writes:

>On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer <joseph@...> wrote:
>> I see code to use Microchip's PICkit 2 under Linux is available from
>> Microchip. Meanwhile, they are pushing hard to use their PICKit 3 for
>> new designs. Does the PICKit 3 use the same command set as PICKit 2,
>> or is there otherwise a way to use it with Linux?
>>
>
>PICkit 3 does not use the same command set as PICkit 2. Its
>firmware structure is also different from PICkit 2 (more like ICD 2).
>So as of now it is not working under native Linux.
>
>You can of course use Virtual Machines and Windows to get
>it working under Linux.

That's what I was afraid of. I'm currently only using the open source
version of VirtualBox, so this would involve switching.... not a big
effort, but something I'd rather not do.

>I am not so sure when this situation will change. As of now,
>PICkit 3 is not as good as PICkit 2, even under Windows.
>Ref: http://www.microchip.com/forums/tm.aspx?m=450226

That's very interesting to know -- it's actually a bit odd that they
still sell PK2, since they're so emphatic on wanting people to use
PK3.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-07T19:42:18Z

On Wednesday 07 October 2009, Noel Henson wrote:

> On Wednesday 07 October 2009, Xiaofan Chen wrote:
> > On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer
> > <joseph@...>
>
> wrote:
> > > I see code to use Microchip's PICkit 2 under Linux is available from
> > > Microchip. Meanwhile, they are pushing hard to use their PICKit 3
> > > for new designs. Does the PICKit 3 use the same command set as
> > > PICKit 2, or is there otherwise a way to use it with Linux?
> >
> > PICkit 3 does not use the same command set as PICkit 2. Its
> > firmware structure is also different from PICkit 2 (more like ICD 2).
> > So as of now it is not working under native Linux.
> >
> > You can of course use Virtual Machines and Windows to get
> > it working under Linux.
> >
> > I am not so sure when this situation will change. As of now,
> > PICkit 3 is not as good as PICkit 2, even under Windows.
> > Ref: http://www.microchip.com/forums/tm.aspx?m=450226
>
> Just a question... Do really we need an inexpensive, Linux-capable PIC
> programmer?
>
> Noel

Whoa, it must be getting late. That should read, "do we really need an
inexpensive, Linux-capable PIC programmer?"

Noel

--

------------------------------------------------------------------
Noel Henson
www.noels-lab.com Chips, firmware and embedded systems
www.vimoutliner.org Work fast. Think well.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-07T19:24:48Z

On Wednesday 07 October 2009, Xiaofan Chen wrote:
> On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer <joseph@...>
wrote:

> > I see code to use Microchip's PICkit 2 under Linux is available from
> > Microchip. Meanwhile, they are pushing hard to use their PICKit 3 for
> > new designs. Does the PICKit 3 use the same command set as PICKit 2,
> > or is there otherwise a way to use it with Linux?
>
> PICkit 3 does not use the same command set as PICkit 2. Its
> firmware structure is also different from PICkit 2 (more like ICD 2).
> So as of now it is not working under native Linux.
>
> You can of course use Virtual Machines and Windows to get
> it working under Linux.
>
> I am not so sure when this situation will change. As of now,
> PICkit 3 is not as good as PICkit 2, even under Windows.
> Ref: http://www.microchip.com/forums/tm.aspx?m=450226

Just a question... Do really we need an inexpensive, Linux-capable PIC
programmer?

Noel

--

------------------------------------------------------------------
Noel Henson
www.noels-lab.com Chips, firmware and embedded systems
www.vimoutliner.org Work fast. Think well.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Pic-Kit 3 and Linux?

2009-10-07T18:51:55Z

On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer <joseph@...> wrote:
> I see code to use Microchip's PICkit 2 under Linux is available from
> Microchip. Meanwhile, they are pushing hard to use their PICKit 3 for
> new designs. Does the PICKit 3 use the same command set as PICKit 2,
> or is there otherwise a way to use it with Linux?
>

PICkit 3 does not use the same command set as PICkit 2. Its
firmware structure is also different from PICkit 2 (more like ICD 2).
So as of now it is not working under native Linux.

You can of course use Virtual Machines and Windows to get
it working under Linux.

I am not so sure when this situation will change. As of now,
PICkit 3 is not as good as PICkit 2, even under Windows.
Ref: http://www.microchip.com/forums/tm.aspx?m=450226

--
Xiaofan http://mcuee.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Pic-Kit 3 and Linux?

2009-10-07T08:51:34Z

I see code to use Microchip's PICkit 2 under Linux is available from
Microchip. Meanwhile, they are pushing hard to use their PICKit 3 for
new designs. Does the PICKit 3 use the same command set as PICKit 2,
or is there otherwise a way to use it with Linux?

Thanks,

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Lightweight distros with GPUTILS in repository

2009-09-16T02:44:54Z

Hi,

Peter Olson wrote:
> Learn about using the 'top' program to find out how much real memory
> is used by various processes (this will take some studying of the
> help, I really can't give a 25 word explanation of what to do).

Alternatively,

ps xauww | sort -k4n

will list all the processes on the machine in order of their %MEM
column, largest last.

Cheers,

Ralph.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Lightweight distros with GPUTILS in repository

2009-09-15T08:33:53Z

At 7:38 AM +0800 9/15/09, Jason Hsu wrote:
>I'm trying to program microcontrollers in C on a 10-year-old laptop
>with only 256 MB of RAM and a 500 MHz processor.

...

>Are there any lightweight distros that offer GPUTILS in the
>repository? Is there anything I can do in a distro to substantially
>reduce its RAM requirement?

Most distros start server process that you don't need. If you don't need to
send and receive email directly at the box, then disable sendmail. Don't
run Firefox; it uses tons of memory. Unfortunately, X tends to use a lot
of memory, but you may need it to run design tools. If you don't need graphic
tools, learn to use the command line, and log in at run level 3, where
the X server doesn't get started. Learn about using the 'top' program to find
out how much real memory is used by various processes (this will take some
studying of the help, I really can't give a 25 word explanation of what to do).

peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: Lightweight distros with GPUTILS in repository

2009-09-15T06:56:33Z

On Tue, Sep 15, 2009 at 12:38 AM, Jason Hsu <jhsu802701@...> wrote:

> Are there any lightweight distros that offer GPUTILS in the repository? Is
> there anything I can do in a distro to substantially reduce its RAM
> requirement?
>

Usually graphical environment takes the most RAM so you may try not to
install X (and definitely not a big window manager like Gnome or KDE). With
'top' you can see which process takes most of the RAM so you may try to
remove those packages as well. You may also can try to use older kernels
with customized compilation so no unnecessary kernel modules are there.

Also you may can get a ram extention for your notebook from eBay or other
online market/store...

Tamas

>
> --
> Jason Hsu <jhsu802701@...>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

--
http://www.mcuhobby.com

Lightweight distros with GPUTILS in repository

2009-09-14T16:38:08Z

I'm trying to program microcontrollers in C on a 10-year-old laptop with only 256 MB of RAM and a 500 MHz processor.

I tried the version of Debian stable with XFCE as the default but gave up on it because I couldn't figure out how to get it to connect to the wireless Internet.

I tried Xubuntu, but it was slow. Even with no applications running, it used swap space.

As I mentioned before, I never was able to get GPUTILS to work in Puppy Linux or Damn Small Linux. The dependency hell was too overwhelming.

Are there any lightweight distros that offer GPUTILS in the repository? Is there anything I can do in a distro to substantially reduce its RAM requirement?

--
Jason Hsu <jhsu802701@...>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: How do I specify certain addresses to not be banked?

2009-09-14T05:13:48Z

It is better to use linker scripts and proper variable occupation with 'RES'
directive.

Anyway, it is also a common technique that you use a dedicated bank as a
"register area" or "temp bank" where the bank selection always points to
this area, and then use MOVFF to load the variables to this temporary area
before making any operation on it. For example if you need to do a long
calculation with several variables located in many different banks it is
better to move them to this "register area" and do all the calculations then
store the results back to it's original location. It is pretty much the same
as you were using a register architecture, and you can save CPU time and
program memory by this technique.

One another technique of course is to use the shared area for globals and
function parameters and each one of the program block use one particular
bank for it's locals (which the can be overlapped/overlayed with other
modules). Then at the module prolog you need to do a context saving and a
bank selection, then at the epilogue a context restore.

Which one is to use really depends on the application, and you can save on
banking quite a lot by choosing the right one.

Tamas

On Sun, Sep 13, 2009 at 5:39 PM, Jesse Gordon <jesseg@...> wrote:

> Hi Raphael,
>
> Thank you very much. You were most helpful!
>
> Actually, I was, for some reason, under the impression that the banked bit
> was set by default in the assembler - but I see now that for addresses 0-7f
> it is not set - which is exactly and perfectly what I want!
>
> Then for my non-"globals" I can just define them with EQU 0x1xx and they
> will all use the current bank select.
>
> Thank you very much!
>
> -Jesse
>
> Raphael Neider wrote:
>
>> Hi Jesse,
>>
>> And I wish to use the first half of bank 0 as "global" vars in the same
>>> way that the second half (the SFRs) are "global."
>>>
>>> [>>snip<<]
>>
>>> So, here is the question: How can I make some of my own ram locations
>>> also always be accessed in bank 0 without me having to specify the ",0" on
>>> every file instruction?
>>>
>>> For example, if I do:
>>>
>>> MyGlobalByte EQU 0xF01
>>>
>>> As it is, the assembler just drops the F00 part and a CLRF on
>>> MyGlobalByte will clear byte 1 in the currently selected bank. Why can't the
>>> assembler see that I've specified 0xF01 and automatically clear the
>>> use-bank-selected bit - Just like it does for addresses above 0xF80?
>>>
>>
>> The PICs have an access bank, which is split into general purpose
>> registers (often 0x00 - 0x7F, sometimes 0x00 - 0x5F) and special
>> function registers (0x80 - 0xFF, which are mapped to 0xF80 - 0xFFF,
>> sometimes 0x60 - 0xFF, remapped to 0xF60 - 0xFFF). The split point
>> is defined by Microchip and cannot be changed.
>> You can use
>>
>> MyGlobalByte EQU 0x001
>> ...
>> MyGlobalByte EQU 0x07F
>> SFR0xF80 EQU 0xF80
>> ...
>> SFR0xFFF EQU 0xFFF
>>
>> and gpasm (knowing the memory layout of the target device) will
>> access these via the access bank. All other memory locations
>> (0x80 - 0xF7F) will use banked access - so use proper BANKSEL
>> directives where needed.
>>
>> Hope that helps,
>> Raphael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: gnupic-unsubscribe@...
>> For additional commands, e-mail: gnupic-help@...
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

--
http://www.mcuhobby.com

Re: How do I specify certain addresses to not be banked?

2009-09-13T09:39:31Z

Hi Raphael,

Thank you very much. You were most helpful!

Actually, I was, for some reason, under the impression that the banked
bit was set by default in the assembler - but I see now that for
addresses 0-7f it is not set - which is exactly and perfectly what I want!

Then for my non-"globals" I can just define them with EQU 0x1xx and they
will all use the current bank select.

Thank you very much!

-Jesse

Raphael Neider wrote:

> Hi Jesse,
>
>> And I wish to use the first half of bank 0 as "global" vars in the
>> same way that the second half (the SFRs) are "global."
>>
> [>>snip<<]
>> So, here is the question: How can I make some of my own ram locations
>> also always be accessed in bank 0 without me having to specify the
>> ",0" on every file instruction?
>>
>> For example, if I do:
>>
>> MyGlobalByte EQU 0xF01
>>
>> As it is, the assembler just drops the F00 part and a CLRF on
>> MyGlobalByte will clear byte 1 in the currently selected bank. Why
>> can't the assembler see that I've specified 0xF01 and automatically
>> clear the use-bank-selected bit - Just like it does for addresses
>> above 0xF80?
>
> The PICs have an access bank, which is split into general purpose
> registers (often 0x00 - 0x7F, sometimes 0x00 - 0x5F) and special
> function registers (0x80 - 0xFF, which are mapped to 0xF80 - 0xFFF,
> sometimes 0x60 - 0xFF, remapped to 0xF60 - 0xFFF). The split point
> is defined by Microchip and cannot be changed.
> You can use
>
> MyGlobalByte EQU 0x001
> ...
> MyGlobalByte EQU 0x07F
> SFR0xF80 EQU 0xF80
> ...
> SFR0xFFF EQU 0xFFF
>
> and gpasm (knowing the memory layout of the target device) will
> access these via the access bank. All other memory locations
> (0x80 - 0xF7F) will use banked access - so use proper BANKSEL
> directives where needed.
>
> Hope that helps,
> Raphael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: How do I specify certain addresses to not be banked?

2009-09-13T03:44:54Z

Hi Jesse,

> And I wish to use the first half of bank 0 as "global" vars in the same
> way that the second half (the SFRs) are "global."
>
[>>snip<<]

> So, here is the question: How can I make some of my own ram locations
> also always be accessed in bank 0 without me having to specify the ",0"
> on every file instruction?
>
> For example, if I do:
>
> MyGlobalByte EQU 0xF01
>
> As it is, the assembler just drops the F00 part and a CLRF on
> MyGlobalByte will clear byte 1 in the currently selected bank. Why can't
> the assembler see that I've specified 0xF01 and automatically clear the
> use-bank-selected bit - Just like it does for addresses above 0xF80?

The PICs have an access bank, which is split into general purpose
registers (often 0x00 - 0x7F, sometimes 0x00 - 0x5F) and special
function registers (0x80 - 0xFF, which are mapped to 0xF80 - 0xFFF,
sometimes 0x60 - 0xFF, remapped to 0xF60 - 0xFFF). The split point
is defined by Microchip and cannot be changed.
You can use

MyGlobalByte EQU 0x001
...
MyGlobalByte EQU 0x07F
SFR0xF80 EQU 0xF80
...
SFR0xFFF EQU 0xFFF

and gpasm (knowing the memory layout of the target device) will
access these via the access bank. All other memory locations
(0x80 - 0xF7F) will use banked access - so use proper BANKSEL
directives where needed.

Hope that helps,
Raphael

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

How do I specify certain addresses to not be banked?

2009-09-12T21:43:51Z

Greetings. This is my first post - so please be patient as I learn the
ropes. Thanks!

I'm working with an 18f1220.

I wish to use bank 1 for my main code, and bank 2 for my low priority
ISR so they can have each plenty of non-shared ram.

And I wish to use the first half of bank 0 as "global" vars in the same
way that the second half (the SFRs) are "global."

Let me explain:

PORTA, for example, is defined as:
PORTA EQU H'0F80'

Let's say I then do a:
CLRF PORTB
the assembler (gpasm-0.13.4 beta) does (and should) clear the access bit
so the CLRF will always operate on 0x80 in bank zero.

Thus, no matter what bank is currently set in BSR, a CLRF on PORTA will
always hit bank 0...

So, here is the question: How can I make some of my own ram locations
also always be accessed in bank 0 without me having to specify the ",0"
on every file instruction?

For example, if I do:

MyGlobalByte EQU 0xF01

As it is, the assembler just drops the F00 part and a CLRF on
MyGlobalByte will clear byte 1 in the currently selected bank. Why can't
the assembler see that I've specified 0xF01 and automatically clear the
use-bank-selected bit - Just like it does for addresses above 0xF80?

That way, whenever I do an operation on MyGlobalByte, it would always
(without me having to specify ",0") access 0x01 in bank 0.

Surely I can go change some line in some file to make it do that task
for the range of 0xF00-0xFFF since it already does it for 0xF80-0xFFF.

Thank you very much,

-Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

Re: What distros offer GNUPIC in the package management system?

2009-09-03T07:07:17Z

Jay Dagenais wrote:
> imo,, you are better off sticking with debian or possibly ubuntu.

I think that's a risky statement, because how the distribution works
is very important to me. The original question did not say what the
motivation for the question is, so it's impossible for everyone here
to share their (vast!) experience with gputils.

Me, I really like Gentoo. But Fedora Electronic Lab (FEL) looks very
interesting for EDA tasks:

http://chitlesh.fedorapeople.org/FEL/
http://fedoraproject.org/wiki/Interviews/FEL

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

RE: What distros offer GNUPIC in the package management system?

2009-09-02T08:29:33Z

oh,, and I've had it running on suse,, but I think maybe I didn't get it thru yast but rpm'd from a site- this was some years ago so they may well have added it to the official package listing??

imo,, you are better off sticking with debian or possibly ubuntu.

> From: jaydag71@...
> To: gnupic@...
> Date: Wed, 2 Sep 2009 08:11:01 -0700
> Subject: RE: [gnupic] What distros offer GNUPIC in the package management system?
>
>
> I think you can find it for slackware also,,, but I could be wrong,, too many distros!!
>
> > Date: Wed, 2 Sep 2009 09:18:53 +0100
> > From: nospam@...
> > To: gnupic@...
> > Subject: Re: [gnupic] What distros offer GNUPIC in the package management system?
> >
> > Jason Hsu wrote:
> > > I know that Debian and Ubuntu both offer GNUPIC in the official package management system.
> > >
> > > What other distros offer GNUPIC through the official package management system?
> >
> > Is there a package called "GNUPIC"? Debian has:
> > gputils - GNU PIC utilities
> > gputils-common - headers and linker scripts for gputils
> > gputils-doc - documentation for gputils
> > picasm - Assembler for the Microchip PIC-family Microcontrollers
> >
> >
> > gpsim - Simulator for Microchip's PIC microcontrollers
> > gpsim-dev - Libraries needed only for building gpsim components
> > gpsim-doc - Documentation for gpsim
> > gpsim-lcd - LCD module for gpsim
> > gpsim-lcd-graphic - LCD module for gpsim
> > gpsim-led - LED module for gpsim
> > gpsim-logic - logic module for gpsim
> > nitpic - simulator for the Microchip PIC16C84 microcontroller
> > simulpic - simulator for Microchip PIC16F84 microcontroller
> >
> > picp - command line utility to drive a PICSTART programmer
> > picprog - Microchip PIC serial programmer software
> > odyssey - PIC microcontroller programming application
> >
> > sdcc - Small Device C Compiler
> > sdcc-doc - Small Device C Compiler (documentation)
> > sdcc-libraries - Small Device C Compiler (libraries)
> >
> > piklab - IDE for PIC-microcontroller development
> > No pikdev but there is a Debian package available
> > from the pikdev website: http://pikdev.free.fr/
> >
> > There are probably other PIC related packages in
> > Debian.
> >
> >
> >
> >
> >
> > --
> > Linux 2.6.30
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
> >
>
> _________________________________________________________________
> New! Open Messenger faster on the MSN homepage
> http://go.microsoft.com/?linkid=9677405

_________________________________________________________________
New! Open Messenger faster on the MSN homepage
http://go.microsoft.com/?linkid=9677405

RE: What distros offer GNUPIC in the package management system?

2009-09-02T08:11:01Z

I think you can find it for slackware also,,, but I could be wrong,, too many distros!!

> Date: Wed, 2 Sep 2009 09:18:53 +0100
> From: nospam@...
> To: gnupic@...
> Subject: Re: [gnupic] What distros offer GNUPIC in the package management system?
>
> Jason Hsu wrote:
> > I know that Debian and Ubuntu both offer GNUPIC in the official package management system.
> >
> > What other distros offer GNUPIC through the official package management system?
>
> Is there a package called "GNUPIC"? Debian has:
> gputils - GNU PIC utilities
> gputils-common - headers and linker scripts for gputils
> gputils-doc - documentation for gputils
> picasm - Assembler for the Microchip PIC-family Microcontrollers
>
>
> gpsim - Simulator for Microchip's PIC microcontrollers
> gpsim-dev - Libraries needed only for building gpsim components
> gpsim-doc - Documentation for gpsim
> gpsim-lcd - LCD module for gpsim
> gpsim-lcd-graphic - LCD module for gpsim
> gpsim-led - LED module for gpsim
> gpsim-logic - logic module for gpsim
> nitpic - simulator for the Microchip PIC16C84 microcontroller
> simulpic - simulator for Microchip PIC16F84 microcontroller
>
> picp - command line utility to drive a PICSTART programmer
> picprog - Microchip PIC serial programmer software
> odyssey - PIC microcontroller programming application
>
> sdcc - Small Device C Compiler
> sdcc-doc - Small Device C Compiler (documentation)
> sdcc-libraries - Small Device C Compiler (libraries)
>
> piklab - IDE for PIC-microcontroller development
> No pikdev but there is a Debian package available
> from the pikdev website: http://pikdev.free.fr/
>
> There are probably other PIC related packages in
> Debian.
>
>
>
>
>
> --
> Linux 2.6.30
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>

_________________________________________________________________
New! Open Messenger faster on the MSN homepage
http://go.microsoft.com/?linkid=9677405

Re: What distros offer GNUPIC in the package management system?

2009-09-02T01:18:53Z

Jason Hsu wrote:
> I know that Debian and Ubuntu both offer GNUPIC in the official package management system.
>
> What other distros offer GNUPIC through the official package management system?

Is there a package called "GNUPIC"? Debian has:
gputils - GNU PIC utilities
gputils-common - headers and linker scripts for gputils
gputils-doc - documentation for gputils
picasm - Assembler for the Microchip PIC-family Microcontrollers

gpsim - Simulator for Microchip's PIC microcontrollers
gpsim-dev - Libraries needed only for building gpsim components
gpsim-doc - Documentation for gpsim
gpsim-lcd - LCD module for gpsim
gpsim-lcd-graphic - LCD module for gpsim
gpsim-led - LED module for gpsim
gpsim-logic - logic module for gpsim
nitpic - simulator for the Microchip PIC16C84 microcontroller
simulpic - simulator for Microchip PIC16F84 microcontroller

picp - command line utility to drive a PICSTART programmer
picprog - Microchip PIC serial programmer software
odyssey - PIC microcontroller programming application

sdcc - Small Device C Compiler
sdcc-doc - Small Device C Compiler (documentation)
sdcc-libraries - Small Device C Compiler (libraries)

piklab - IDE for PIC-microcontroller development
No pikdev but there is a Debian package available
from the pikdev website: http://pikdev.free.fr/

There are probably other PIC related packages in
Debian.

--
Linux 2.6.30

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...