usbpicprog-technical

Re: [Usbpicprog-technical] Pic16F88 and eeprom/data programming

[Jasper W. <ja...@po...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 28 May 2010, Frans Schreuder wrote:

> Dear Jasper Wallace,
> 
> Have you tested the latest build?

Hi,

Yes, and both config words don't work now!

Well they do sometimes but not always, I'm not sure whats going on.

Luckily this ties into another project of mine which is interfacing with a 
HP1650A logic analyser and converting the data into a format the open 
source sump logic analyser client can read.

Unfortunatly thats still a work in progress, i can't get the analyser to 
record exactly what i want (i need to read the manual more).

the client is here:

http://www.sump.org/projects/analyzer/client/

attached is a .slp file that labels the traces, and some .sla files which 
are the actual traces.

btw - one of the problems with my converter is that i think i've got the 
time units wrong.

One thing that might be a problem is that the 1st and last clock pulse for 
the 14/16 data bits are shorter than the others, it dosn't look like the 
diagrams in the datasheet.


- -- 
[http://pointless.net/]                                   [0x2ECA0975]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBTABqywCB+Qwuygl1AQJWYwf+P91d7z15XEvV9vtoUvmNOu7tN0cI1WIA
+52FRJyghHUfEB6BgENxo3Tj4WaWWTmMNE/95j67/Kd3hNFUV8bhsZvcWnJANYoL
uczXsAukTiQjhObOXixevgGJCMcSdAhVMahiWKvHncXdcXzVTZuHUV15Fx3rDN9u
bkVAPNuK1NUz7Z5DUf0Su11Muv7igX2o7iFSMuGBvGWtXCCFSlG3+iiuulSM9eUo
nDIqs31N1bMLD8s9h+A8ZE/CcaHSwcwl/cvTL6PqYfk7cXuJZ6z2Wgr5fx0PaG+m
k6o1gEoDx0Mzyb+e/RjFdp8WMqQ69L/8VG4y5MatQFXVUXmzxLy0LQ==
=SXrC
-----END PGP SIGNATURE-----

[Usbpicprog-technical] Help supporting a new device (16f506)

[Matt H. <mh...@me...>]

I built pcb-0.3.1, (through hole version) and have tested it as working 
with a couple of different devices (16f84a, 18f2550). I'd like to be 
able to program the 16f506, which from looking at the programming specs, 
is very similar to the 12f508/9.

12f508/509:
http://ww1.microchip.com/downloads/en/DeviceDoc/41227E.pdf

16f506
http://ww1.microchip.com/downloads/en/DeviceDoc/41258C.pdf

I modified index.xml to include the 16F506 under the P12F508 family, and 
src/hardware.cpp to backup the oscillator calibration bits. I noticed 
there was already a 16F506.xml under xml_data, which seems to agree with 
the data sheets.

After recompiling, when I try to read from the 16F506 I get all 0's. 
Writing to the device gives a "verify error". When I hook a scope up to 
the PGC and PGD lines I see activity there. The supported devices list 
says that the 12f508 is not tested, so perhaps the code to program this 
part isn't working for these chips either?

Can someone recommend a direction to start debugging?

I'm going to try to get a hold of a 12f508/9 to see if that part works, 
but it could take awhile.

Thanks,
Matt

Re: [Usbpicprog-technical] Pic16F88 and eeprom/data programming

[Frans S. <fra...@gm...>]

Dear Jasper Wallace,

Have you tested the latest build?

Frans

On 05/25/2010 10:30 AM, Jasper Wallace wrote:
> more time to look into this and i've got the Microchip C18 
> compiler installed now.
>
> Firstly it looks as if the pic16F88 data programming is missing the 
> end programming command, see attached patch.
>
> Unfortunatly i cant test it beacause the C18 compiler failes to link 
> usbdsc.o with this error:
>
> Error - section '.romdata_usbdsc.o' can not fit the section. Section 
> '.romdata_usbdsc.o' length=0x000000ae 
> Errors : 1 
>
>   

Re: [Usbpicprog-technical] Pic16F88 and eeprom/data programming

[Frans S. <fra...@gm...>]

On 05/26/2010 05:35 AM, Jasper Wallace wrote:
> On Tue, 25 May 2010, Frans Schreuder wrote:
>
>   
>> Dear Jasper Wallace,
>>
>> You are right, thank you for the patch! I have applied the changes in
>> the subversion repos and in the 0.4.0 firmware release.
>>     
> Thanks, if i use uc_code.hex from svn I can write the data ok!
>
> However now the 2nd config word has stoped working!
>
> I think the attached patch will work (I'm looking at the 39607c 
> datasheet). I wonder how it ever worked in the 1st place!
>   
Hmm, this is weird... but your patch seems to be right. I have built it
and put in the svn. Could you try again?
>   
>> About the warnings, this is part of the Microchip usb stack, and I have
>> seen them but let's just ignore those warnings.
>>     
> yup, but the linker error means i can't generate firmware to test with :(
>   
Also this is weird. Maybe the difference is in the student version. I
did get a full version of the c18 compiler from a formal job (they
didn't use it anymore). And now I am still able to upgrade with the
latest upgrades.
> I've using:
>
> mcc18:
>
> MPLAB C18 v3.35 academic Copyright 2000-2010 Microchip Technology Inc.
>
> mplink:
>
> MPLINK 4.35, Linker
>
> the linker command line is:
>
> wine mplink /k/ rm18f4550.lkr /l/home/jasper/.wine/drive_c/MCC18/lib/ 
> /ouc_code.cof /muc_code.map main.o usbdsc.o interrupt.o usbmmap.o usbgen.o 
> usb9.o usbctrltrf.o usbdrv.o upp.o prog.o prog_lolvl.o 
>
>   
>>> Unfortunatly i cant test it beacause the C18 compiler failes to link 
>>> usbdsc.o with this error:
>>>
>>> Error - section '.romdata_usbdsc.o' can not fit the section. Section 
>>> '.romdata_usbdsc.o' length=0x000000ae 
>>> Errors : 1 
>>>       
>   
>
>
> ------------------------------------------------------------------------------
>
>   
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

Re: [Usbpicprog-technical] Pic16F88 and eeprom/data programming

[Jasper W. <ja...@po...>]

On Tue, 25 May 2010, Frans Schreuder wrote:

> Dear Jasper Wallace,
> 
> You are right, thank you for the patch! I have applied the changes in
> the subversion repos and in the 0.4.0 firmware release.

Thanks, if i use uc_code.hex from svn I can write the data ok!

However now the 2nd config word has stoped working!

I think the attached patch will work (I'm looking at the 39607c 
datasheet). I wonder how it ever worked in the 1st place!

> About the warnings, this is part of the Microchip usb stack, and I have
> seen them but let's just ignore those warnings.

yup, but the linker error means i can't generate firmware to test with :(

I've using:

mcc18:

MPLAB C18 v3.35 academic Copyright 2000-2010 Microchip Technology Inc.

mplink:

MPLINK 4.35, Linker

the linker command line is:

wine mplink /k/ rm18f4550.lkr /l/home/jasper/.wine/drive_c/MCC18/lib/ 
/ouc_code.cof /muc_code.map main.o usbdsc.o interrupt.o usbmmap.o usbgen.o 
usb9.o usbctrltrf.o usbdrv.o upp.o prog.o prog_lolvl.o 

> > Unfortunatly i cant test it beacause the C18 compiler failes to link 
> > usbdsc.o with this error:
> >
> > Error - section '.romdata_usbdsc.o' can not fit the section. Section 
> > '.romdata_usbdsc.o' length=0x000000ae 
> > Errors : 1 

-- 
[http://pointless.net/]                                   [0x2ECA0975]

Re: [Usbpicprog-technical] Pic16F88 and eeprom/data programming

[Frans S. <fra...@gm...>]

Dear Jasper Wallace,

You are right, thank you for the patch! I have applied the changes in
the subversion repos and in the 0.4.0 firmware release.

About the warnings, this is part of the Microchip usb stack, and I have
seen them but let's just ignore those warnings.

Frans

On 05/25/2010 10:30 AM, Jasper Wallace wrote:
> Hi,
>
> I've had some more time to look into this and i've got the Microchip C18 
> compiler installed now.
>
> Firstly it looks as if the pic16F88 data programming is missing the 
> end programming command, see attached patch.
>
> Unfortunatly i cant test it beacause the C18 compiler failes to link 
> usbdsc.o with this error:
>
> Error - section '.romdata_usbdsc.o' can not fit the section. Section 
> '.romdata_usbdsc.o' length=0x000000ae 
> Errors : 1 
>
> I get these warnings when i compile it:
>
> usbdsc.c:269: warning: [2054] suspicious pointer conversion 
> usbdsc.c:269: warning: [2054] suspicious pointer conversion 
> usbdsc.c:273: warning: [2054] suspicious pointer conversion 
> usbdsc.c:273: warning: [2054] suspicious pointer conversion 
> usbdsc.c:273: warning: [2054] suspicious pointer conversion 
>
> but i don't know if thats significant.
>
> Also - there are lots of references to sdcc in the firmware source, does 
> compiling with sdcc work now? I tried breifly but got loads of errors...
>
>   
>
>
> ------------------------------------------------------------------------------
>
>   
>
>
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

[Usbpicprog-technical] Pic16F88 and eeprom/data programming

[Jasper W. <ja...@po...>]

Hi,

I've had some more time to look into this and i've got the Microchip C18 
compiler installed now.

Firstly it looks as if the pic16F88 data programming is missing the 
end programming command, see attached patch.

Unfortunatly i cant test it beacause the C18 compiler failes to link 
usbdsc.o with this error:

Error - section '.romdata_usbdsc.o' can not fit the section. Section 
'.romdata_usbdsc.o' length=0x000000ae 
Errors : 1 

I get these warnings when i compile it:

usbdsc.c:269: warning: [2054] suspicious pointer conversion 
usbdsc.c:269: warning: [2054] suspicious pointer conversion 
usbdsc.c:273: warning: [2054] suspicious pointer conversion 
usbdsc.c:273: warning: [2054] suspicious pointer conversion 
usbdsc.c:273: warning: [2054] suspicious pointer conversion 

but i don't know if thats significant.

Also - there are lots of references to sdcc in the firmware source, does 
compiling with sdcc work now? I tried breifly but got loads of errors...

-- 
[http://pointless.net/]                                   [0x2ECA0975]

Re: [Usbpicprog-technical] [usbpicprog-technical] Ready for release 0.4.0?

[Frans S. <fra...@gm...>]

Yes, Vista was tested by a friend of mine, (32 bit as well as 64 bit)
and it works fine.

I have already released the Ubuntu build and source build.
I will build Windows and Os X tomorrow.

Frans

On 05/24/2010 12:38 AM, Francesco wrote:
> do you know perhaps if 

Re: [Usbpicprog-technical] [usbpicprog-technical] Ready for release 0.4.0?

[Francesco <f18...@ya...>]

Hi Frans!
 sorry for the delay but in this period I've got plenty of things to do... :/

2010/5/20 Frans Schreuder <fra...@gm...>:
> I think usbpicprog is ready for a 0.4.0 release.
> I have released two beta versions, and apart from a timeout bug in
> Windows while reconnecting the bootloader (on which I have made a dirty
> workaround) I didn't get many complaints.
> What do you think?
I didn't manage yet to setup a virtual machine with WinVista to test
upp there... do you know perhaps if 0.4.0 has been tested on that OS
already?

Except for that, I think it should be fine to release 0.4.0...

Francesco

[Usbpicprog-technical] [usbpicprog-technical] Ready for release 0.4.0?

[Frans S. <fra...@gm...>]

Hi Everyone,

I think usbpicprog is ready for a 0.4.0 release.
I have released two beta versions, and apart from a timeout bug in
Windows while reconnecting the bootloader (on which I have made a dirty
workaround) I didn't get many complaints.
What do you think?

Frans

Re: [Usbpicprog-technical] adding PIC projects as examples ?

[Frans S. <fra...@gm...>]

I have implemented the menu item in the application, as well as adding
the Makefiles to automatically install the examples on linux and osx.

Frans

On 4/15/2010 12:22 AM, Francesco wrote:
> Hi,
>
> 2010/4/14 Frans Schreuder <fra...@gm...>:
>   
>> I think it's nice to put the files in the installer, but I think it
>> would be better to have a menu item that just opens a nautilus /
>> explorer / finder to wherever the examples are.
>> Since there are not only .hex files in that folder it would be good to
>> show the people that there is more than just the .hex file.
>>     
> well, it would strange for me (as a user) to click File -> Open
> Example and be redirected to the standard file
> explorer/nautilus/finder; as user I should first understand that the
> explorer which has been launched is a wanted effect and second that I
> should rather use "File -> Open" command, browse to the example folder
> and finally select the .hex file to "really" open the example in the
> upp_wx application...
>
> what about adding both
> - a File->Open example which always open the standard "file open"
> dialog in the examples folder installed together with upp_wx (and lets
> you select a .hex)
> and
> - an Help->Examples menu which always open the examples folder in the
> standard file explorer/nautilus/finder;
> ?
>
>   
>> Yes, let's add the dice project as well, I was planning to do so anyway,
>> but I just found this nice example somewhere on a computer where I
>> didn't have an svn client installed...
>>     
> ok, nice!
>
> Francesco
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

Re: [Usbpicprog-technical] adding PIC projects as examples ?

[Francesco <f18...@ya...>]

Hi,

2010/4/14 Frans Schreuder <fra...@gm...>:
> I think it's nice to put the files in the installer, but I think it
> would be better to have a menu item that just opens a nautilus /
> explorer / finder to wherever the examples are.
> Since there are not only .hex files in that folder it would be good to
> show the people that there is more than just the .hex file.
well, it would strange for me (as a user) to click File -> Open
Example and be redirected to the standard file
explorer/nautilus/finder; as user I should first understand that the
explorer which has been launched is a wanted effect and second that I
should rather use "File -> Open" command, browse to the example folder
and finally select the .hex file to "really" open the example in the
upp_wx application...

what about adding both
- a File->Open example which always open the standard "file open"
dialog in the examples folder installed together with upp_wx (and lets
you select a .hex)
and
- an Help->Examples menu which always open the examples folder in the
standard file explorer/nautilus/finder;
?

> Yes, let's add the dice project as well, I was planning to do so anyway,
> but I just found this nice example somewhere on a computer where I
> didn't have an svn client installed...
ok, nice!

Francesco

Re: [Usbpicprog-technical] [usbpicprog-technical] Usbpicprog 0.4.0-beta released, let's stop changing translatable strings until 0.4.0

[Frans S. <fra...@gm...>]

Hi,

The German translation file has just been updated for 0.4.0, but I think
my German is good enough to create just those two strings.

I will also send an e-mail to the other translators when the "open
examples" has been added.

Fran

On 4/14/2010 0:00, Francesco wrote:
> Hi Frans,
>
> 2010/4/10 Frans Schreuder <fra...@gm...>:
>   
>> Hi All,
>> I have recently released 0.4.0-beta as you might have seen. It would be
>> nice to give the chance for all the translators to update their language
>> files before 0.4.0 is released. Let's not change any translatable
>> strings in the source code until it has been released!
>>     
> I'll try to update the Italian translation.
>
> Francesco
>
> PS: The only additional string to translate in case we agree on the
> specific "open example" menu would be that "open example" and maybe a
> "example folder could not be found" so I think we would still be in
> time... ;)
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>   

Re: [Usbpicprog-technical] adding PIC projects as examples ?

[Frans S. <fra...@gm...>]

Hi Francesco,

I think it's nice to put the files in the installer, but I think it
would be better to have a menu item that just opens a nautilus /
explorer / finder to wherever the examples are.
Since there are not only .hex files in that folder it would be good to
show the people that there is more than just the .hex file.

Yes, let's add the dice project as well, I was planning to do so anyway,
but I just found this nice example somewhere on a computer where I
didn't have an svn client installed...

Frans

On 4/13/2010 23:56, Francesco wrote:
> s you may have noticed I've added a small test PIC project to the
> usbpicprog folder as previously discussed... I noticed only after that
> there is now a specific page for the projects on the usbpicprog.org
> website :)
>
> However I think it would be nice to have the projects installed
> together with the upp software and have a dedicated "File -> Open
> example" command just below "File -> Open"... what do you think?
>
> Should we add the dice project to the SVN too and update the installers?
>
> Francesco
>   

Re: [Usbpicprog-technical] [usbpicprog-technical] Usbpicprog 0.4.0-beta released, let's stop changing translatable strings until 0.4.0

[Francesco <f18...@ya...>]

Hi Frans,

2010/4/10 Frans Schreuder <fra...@gm...>:
> Hi All,
> I have recently released 0.4.0-beta as you might have seen. It would be
> nice to give the chance for all the translators to update their language
> files before 0.4.0 is released. Let's not change any translatable
> strings in the source code until it has been released!
I'll try to update the Italian translation.

Francesco

PS: The only additional string to translate in case we agree on the
specific "open example" menu would be that "open example" and maybe a
"example folder could not be found" so I think we would still be in
time... ;)

Re: [Usbpicprog-technical] adding PIC projects as examples ?

[Francesco <f18...@ya...>]

Hi Frans,
    as you may have noticed I've added a small test PIC project to the
usbpicprog folder as previously discussed... I noticed only after that
there is now a specific page for the projects on the usbpicprog.org
website :)

However I think it would be nice to have the projects installed
together with the upp software and have a dedicated "File -> Open
example" command just below "File -> Open"... what do you think?

Should we add the dice project to the SVN too and update the installers?

Francesco



2010/3/25 Francesco <f18...@ya...>:
> Hi Frans,
>
> 2010/3/25 Frans Schreuder <fra...@gm...>:
>> I this is a very good idea, but maybe also a community thing to do. I
>> think I can make a few examples with different compilers, but shall I
>> make a page on the website with a submit form or something like that in
>> order to be able to have contributions from the community?
> well, I was proposing to add just a couple examples very very simple
> (and thus portable among many PICs and easy to realize on e.g.
> breadboards for quick tests)... community inputs may be useful to
> build something different like a collection of hobbyst PIC projects. I
> think that it could be a good start to add a few small examples and
> add a notice on the website that user projects (of limited complexity)
> are welcome and can be posted on this mailing list (I don't think
> forms are well-suited for posting multiple files / code).
> Then we'll see how many users propose their projects and eventually
> develop more appropriate features for sharing user pic projects ;)
>
> One thing to consider however is that the more code we add to the repo
> the more code we have to maintain, comment, fix, etc. So simply adding
> everything we can add may not be the best choice.
>
>> I think it would be good to also deliver some example schematics.
> yes, good idea, although what I had in mind was to require as less hw
> as possible (e.g. an R+C for the PIC oscillator and a R+LED for
> blinking) and thus a schematic maybe not be so much necessary. But
> adding it would of course be a plus.
>
>> For
>> that we will need a standard tool - shall we suggest KiCad for that?
> Personally I always use Cadsoft EAGLE for schematics and layouts and
> MicroCap for simulations (yes I know: neither of them is open-source
> :/ but free student/limited versions are available for both) . I used
> Kicad only for opening usbpicprog schematics but I've found it a bit
> messy (icons not clear, menus partially translated and partially not,
> and often translated wrong, commands uncomfortable to use, redrawing
> not always working, etc).
> Nonetheless given that the schematics should be very simple I think it
> would be ok to go with KiCad...
>
>> I will give it a shot!
> great!
>
> Francesco
>
> PS: I can provide the MPLAB versions of the projects if you need.
>

[Usbpicprog-technical] [usbpicprog-technical] Usbpicprog 0.4.0-beta released, let's stop changing translatable strings until 0.4.0

[Frans S. <fra...@gm...>]

Hi All,

I have recently released 0.4.0-beta as you might have seen. It would be
nice to give the chance for all the translators to update their language
files before 0.4.0 is released. Let's not change any translatable
strings in the source code until it has been released!

Frans

Re: [Usbpicprog-technical] Time for a beta release 0.3.1?

[Francesco <f18...@ya...>]

Hi,

2010/3/23 Frans Schreuder <fra...@gm...>:
> I think the latest version of usbpicprog 876 seems to be running quite
> stable on all systems (win 32 / 64, osx universal and ubuntu)
> What do you think, is it time for a beta release of version 0.3.1?
Unfortunately I had no much time to fiddle with real PICs on
breadboards recently... I'll try to test my latest PICs (18f2550,
18f4553) in the weekend.
Anyway I think it's fine to make at least a beta of 0.3.1.

However I wonder if it wouldn't be better to call the new release
0.4.0 since the major upgrade from libusb-0.1 to libusb-1.0...

Francesco

Re: [Usbpicprog-technical] adding PIC projects as examples ?

[Francesco <f18...@ya...>]

Hi Frans,

2010/3/25 Frans Schreuder <fra...@gm...>:
> I this is a very good idea, but maybe also a community thing to do. I
> think I can make a few examples with different compilers, but shall I
> make a page on the website with a submit form or something like that in
> order to be able to have contributions from the community?
well, I was proposing to add just a couple examples very very simple
(and thus portable among many PICs and easy to realize on e.g.
breadboards for quick tests)... community inputs may be useful to
build something different like a collection of hobbyst PIC projects. I
think that it could be a good start to add a few small examples and
add a notice on the website that user projects (of limited complexity)
are welcome and can be posted on this mailing list (I don't think
forms are well-suited for posting multiple files / code).
Then we'll see how many users propose their projects and eventually
develop more appropriate features for sharing user pic projects ;)

One thing to consider however is that the more code we add to the repo
the more code we have to maintain, comment, fix, etc. So simply adding
everything we can add may not be the best choice.

> I think it would be good to also deliver some example schematics.
yes, good idea, although what I had in mind was to require as less hw
as possible (e.g. an R+C for the PIC oscillator and a R+LED for
blinking) and thus a schematic maybe not be so much necessary. But
adding it would of course be a plus.

> For
> that we will need a standard tool - shall we suggest KiCad for that?
Personally I always use Cadsoft EAGLE for schematics and layouts and
MicroCap for simulations (yes I know: neither of them is open-source
:/ but free student/limited versions are available for both) . I used
Kicad only for opening usbpicprog schematics but I've found it a bit
messy (icons not clear, menus partially translated and partially not,
and often translated wrong, commands uncomfortable to use, redrawing
not always working, etc).
Nonetheless given that the schematics should be very simple I think it
would be ok to go with KiCad...

> I will give it a shot!
great!

Francesco

PS: I can provide the MPLAB versions of the projects if you need.

Re: [Usbpicprog-technical] win7 testing

[Mark J. <hel...@gm...>]

> Hi Mark,
> 2010/3/12 Mark Jones <heliosstudios@...:
> > Hello friends, I've been having some difficulty using the UPP in
> > Windows 7 32-bit...
>
> can you retest against latest revision of the trunk? I think r864
> should have fixed the programming problems...
>
> Francesco


Hi Francesco and Frans, yes indeed that helped quite a bit! UPP is now
able to read/write/verify/erase the 16F84A, 16F628, and 18LF2553. The
erase feature silently does nothing on the 16F628 (expected) and the
18LF2553 (PDIP) can be programmed and read successfully, however its
configuration bits behave oddly. This could be my fault as I used a 1m
ICSP cable (and it works... amazing.) I will check into this further
when I have more time.

I am still planning on setting up a build environment, which looks
like it will be MSVC. Hopefully once everything is in place, I can
help test and verify UPP on several Windows platforms.

Regards,
Mark

Re: [Usbpicprog-technical] adding PIC projects as examples ?

[Frans S. <fra...@gm...>]

Hi Francesco,

I this is a very good idea, but maybe also a community thing to do. I 
think I can make a few examples with different compilers, but shall I 
make a page on the website with a submit form or something like that in 
order to be able to have contributions from the community?
I think it would be good to also deliver some example schematics. For 
that we will need a standard tool - shall we suggest KiCad for that?

I will give it a shot!

Frans

On 3/24/2010 21:55, Francesco wrote:
> Hi Frans/all,
>    I wonder if it wouldn't be a good idea to ship with upp_wx a couple
> examples of PIC projects which:
> 1) could be used by new users to get started with the PIC world and
> usbpicprog itself
> 2) could be used as quick test for us to check if usbpicprog works
> well with a certain PIC
>
> I think it should not be too difficult to create a couple projects
> suitable (with very small modifications) to cover a wide range of PIC
> devices (e.g. a small program which blinks a LED). I'd also include
> both Piklab and MPLAB project files and the .hex files (so that users
> without piklab or MPLAB can immediately test their usbpicprog ;)).
>
> Just my 2 cents,
> Francesco
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Usbpicprog-technical mailing list
> Usb...@li...
> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>    

[Usbpicprog-technical] adding PIC projects as examples ?

[Francesco <fra...@gm...>]

Hi Frans/all,
  I wonder if it wouldn't be a good idea to ship with upp_wx a couple
examples of PIC projects which:
1) could be used by new users to get started with the PIC world and
usbpicprog itself
2) could be used as quick test for us to check if usbpicprog works
well with a certain PIC

I think it should not be too difficult to create a couple projects
suitable (with very small modifications) to cover a wide range of PIC
devices (e.g. a small program which blinks a LED). I'd also include
both Piklab and MPLAB project files and the .hex files (so that users
without piklab or MPLAB can immediately test their usbpicprog ;)).

Just my 2 cents,
Francesco

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Frans,

2010/3/24 Frans Schreuder <fra...@gm...>:
> Oops... Francesco has changed something in the .vcproj file, you have to
> build wxWidgets using MONOLITHIC = 0 now.
right. Monolithic builds were only introduced for some wxMac-related
hacks (I think related to framework building) which are no longer
necessary and are "deprecated" in wx2.9... is wxDevCpp distributing a
monolithic build of wx?

Multilib is the default because it's a lot better (the linker can
easily throw away tons of unused features of wx and make a smaller and
thus faster executable)...

Francesco

Re: [Usbpicprog-technical] win7 testing

[Francesco <f18...@ya...>]

Hi Mark,

2010/3/24 Mark Jones <hel...@gm...>:
>>2010/3/12 Mark Jones <hel...@gm...>:
> Hi Francesco, today is as good as any to learn some C++ eh? : )
ehm, sorry, I didn't even think that you may not have the full C++
development environment ready for use :)
I've updated the installers at: http://usbpicprog.org/downloads/
(look for *r877-release* packages).

> I decided to try setting up a build environment for UsbPicProg. I
> installed wxDev-C++ v7.3.1.3 on Win7 32-bit (thinking it would be
> better-suited to developing wxWidgets-based applications), installed
> TortoiseSVN v1.6.7, retrieved the trunk from SVN, updated the paths to
> libusb.h, but then got stuck on the wxWidgets dependency. I know it
> needs the wxWidgets-2.9.0 "libraries" but what exactly needs to go
> where? The folder tree is rather complex, and wxWidgets can be
> compiled in an alarming number of ways. Even tried doing "configure"
> under MSYS. I'll keep plugging away at it, but any additional hints
> would be very helpful.
well, if you have wxDevCpp you should have mingw installed. Then you
may compile wx just going to wxWidgets\build\msw and typing

 mingw32-make -f makefile.gcc BUILD=release

then you could run exactly the same command from upp_wx\build\win.

Anyway I'd suggest you to use MSVC++ 2008 Express instead (specially
if you want to compile C++ code often :)).


Francesco

Re: [Usbpicprog-technical] Build-instructions (and app) for Mac OS X 10.4+ universal (32-bit Intel + PPC)

[Frans S. <fra...@gm...>]

Hi Gustav,

It still doesn't work, still with the same error messages (see attachment).
If I copy the .dylib files from 
http://usbpicprog.org/downloads/UsbPicProg-OSX-r876M.dmg (built by me)
to UsbPicProg-OSX-r876.dmg, the application runs fine, so it has been 
built using the right compiler settings!
However your libusb and libiconv dylibs are either 64 bit or built using 
gcc 4.2.

Copying the files to the cocoa app doesn't help. I guess, I do need 64 
bit libraries for that (?)

btw, I have one more question: Do we really need the cocoa version? How 
does it work, or is it still quite buggy?
The normal version appears very fine to me!


Cheers,

Frans


On 3/23/2010 19:27, Gustav Johansson wrote:
> Hi Frans,
>
> I apologize for not telling you that those two were broken. I noticed
> when I checked the files after I uploaded them and the libiconv.dylib
> is actually missing in them, and I believe the error is due to that
> rather than being the wrong version. The problem was the line in the
> script which loops through the libraries to install, it did not end
> with a space and thus did only install the first library. It has been
> fixed and both libraries are installed properly now.
>
> Since I did this, I have set up a "nightly" script that builds if the
> svn has been updated, but it has taken me a couple of days since I
> managed a careless rm * instead of rm *~... so I had to start over.
> Both builds *should* be uploaded tonight at about 3:45 AM CET.
> Hopefully, they will both work.
>
> In addition, I noticed that the cocoa-version for x86_64 did not build
> properly when set for 10.4 compatibility. I assume it is because 10.4
> did not actually have support for 64-bit Intel. This has also been
> fixed now by using different compatibility  settings for ppc/i386 vs.
> x86_64.
>
> I'll check the nightly build tomorrow morning, and if they seem to be
> working, I'll send you a mail and it would be great if you could check
> those again then to see if I managed to get everything right in the
> nightly scripts.
>
> Regards,
> Gustav
>
>
> On Tue, Mar 23, 2010 at 4:31 PM, Frans Schreuder
> <fra...@gm...>  wrote:
>    
>> Hi Gustav,
>>
>> I have tried your build on a clean osx 10.5 system. Both the cocoa and the
>> normal build give the same error about libiconv. I am affraid that the
>> libiconv.dylib that you have installed was either not built universal, or it
>> was built using gcc 4.2.
>> I have also built the latest revision r876 wich does seem to run on a clean
>> system. This version seems to work fine (I also fixed the configuration
>> flags appearance)
>>
>>
>> UsbPicProg-OSX-rexported.dmg  (UsbPicProg-OSX-Cocoa-r872.dmg - buld gives
>> the same error report)
>>
>> Process:         usbpicprog [770]
>> Path:
>> /Volumes/UsbPicProg/usbpicprog.app/Contents/MacOS/usbpicprog
>> Identifier:      org.usbpicprog
>> Version:         ??? (???)
>> Code Type:       X86 (Native)
>> Parent Process:  launchd [92]
>>
>> Date/Time:       2010-03-23 08:11:43.203 -0700
>> OS Version:      Mac OS X 10.5.2 (9C31)
>> Report Version:  6
>>
>> Exception Type:  EXC_BREAKPOINT (SIGTRAP)
>> Exception Codes: 0x0000000000000002, 0x0000000000000000
>> Crashed Thread:  0
>>
>> Dyld Error Message:
>>    Library not loaded: @executable_path/../SharedSupport/libiconv.dylib
>>    Referenced from:
>> /Volumes/UsbPicProg/usbpicprog.app/Contents/MacOS/usbpicprog
>>    Reason: Incompatible library version: usbpicprog requires version 8.0.0 or
>> later, but libiconv.2.dylib provides version 7.0.0
>>
>>
>> Regards,
>>
>> Frans
>>
>> On Fri, 2010-03-19 at 23:56 +0100, Gustav Johansson wrote:
>>
>> Hi Frans,
>>
>> tried your build now, and it seems to work fine! Although I think that
>> what you've added was added already. In the end of each ./configure
>> line I had put in the CC=gcc+4.0 and the DEPLOYMENT_TARGET is set via
>> the $sdk_flags. But better safe than sorry, right? ;)
>>
>> I've just uploaded two snapshot version of the r872, one carbon (named
>> rexported due to a typo, already fixed and commited, but I want to
>> test my nightly scripts, so hopfully there will be two r873 builds in
>> the morning) and one cocoa. Please test them and see if they work.
>> They do work on my Intel 10.6 and on my PPC 10.5. But they both have
>> MacPorts installed, so I can't (or haven't, at least) tested them for
>> library content...
>>
>> Cheers,
>> Gustav
>>
>> On Fri, Mar 19, 2010 at 5:33 PM, Gustav Johansson<gu...@ne...>  wrote:
>>      
>>> Hi Frans,
>>>
>>> I'll try it tonight, I'm not at home at the moment...
>>>
>>> Cheers,
>>> Dr. Gustav Johansson
>>>
>>>
>>> On 19 mar 2010, at 17.23, Frans Schreuder<fra...@gm...>
>>> wrote:
>>>
>>>        
>>>> Hi Gustav,
>>>>
>>>> As you can see in the buildmac.sh script (and also in the
>>>> install_wxWidgets.sh script) I have added
>>>>
>>>> export MACOSX_DEPLOYMENT_TARGET=10.4
>>>> export CC="gcc-4.0"
>>>>
>>>> I also added libiconv.dylib because it wouldn't run if you didn't have
>>>> it installed from macports.
>>>> I think you will also need to build wxWidgets again with gcc-4.0 (as
>>>> well as some other libraries)
>>>>
>>>> Could you try 869M, the one that I have uploaded to
>>>> usbpicprog.org/downloads?
>>>>
>>>> Cheers,
>>>>
>>>> Frans
>>>>
>>>>
>>>> Gustav Johansson schreef:
>>>>          
>>>>> Hi Frans!
>>>>>
>>>>> I have not uploaded any of the "fixed" builds, I was going to
>>>>> yesterday but the FTP didn't work... I'll upload one of my snapshots
>>>>> tonight and we'll see if they work then. I've also managed to build
>>>>> for cocoa, so if you can test that build as well it would be great!
>>>>>
>>>>> Cheers,
>>>>> Dr. Gustav Johansson
>>>>>
>>>>>
>>>>> On 19 mar 2010, at 16.39, Frans Schreuder<fra...@gm...
>>>>> <mailto:fra...@gm...>>  wrote:
>>>>>
>>>>>            
>>>>>> Hi Gustav,
>>>>>>
>>>>>> I have tried the .dmg on an intel 10.5 system, and it didn't seem to
>>>>>> work because it was compiled using gcc 4.2.
>>>>>> I compiled it using gcc 4.0 and modified buildmac.sh.
>>>>>> I think the latest one does now run on 10.4, 10.5 and 10.6.
>>>>>> Also libiconv has been included in the .app now.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Frans
>>>>>>
>>>>>> On Thu, 2010-03-11 at 20:34 +0100, Gustav Johansson wrote:
>>>>>>              
>>>>>>> Hi!
>>>>>>>
>>>>>>> Since I'm new to this mailing-list, I apologize in advance if I break
>>>>>>> some rules... If I do, just tell me and I won't do it again! :)
>>>>>>>
>>>>>>> I've been working on creating a universal build for OS X of the
>>>>>>> usbpicprog.app, and I think I've got it now. Attached are two files,
>>>>>>> one disk image containing a freshly built usbpicprog.app that *should*
>>>>>>> work on both Intel and PPC Macs, from 10.4 and up. I've tested it on
>>>>>>> an Intel 10.6 and an PPC 10.5, and they both work just fine. I do not
>>>>>>> however have a usb-programmer yet, so I have not tested the
>>>>>>> programming functionality. If you can help out by testing, please do
>>>>>>> so and tell me about any problems.
>>>>>>>
>>>>>>> If there is an interest in it, I can setup a cron-job and built
>>>>>>> "nigthly" builds of usbpicprog for OS X and upload the disk images to
>>>>>>> wherever is suitable.
>>>>>>>
>>>>>>> The second file is a couple of scripts and a README file with
>>>>>>> information on how you can build this yourself. I used a lot of the
>>>>>>> info by Lukas Zeller, and only had to do a bit of tweaking to get it
>>>>>>> to work.
>>>>>>>
>>>>>>> The main problem that Lukas Zeller saw was the libiconv linking, which
>>>>>>> was almost correct. The problem is not with the MacPorts libiconv, but
>>>>>>> rather that Apple ships with a number of libiconv versions, some of
>>>>>>> which takes precedence over the MacPorts version. The solution is to
>>>>>>> force wxWidgets to use the MacPorts version by using a configure flag.
>>>>>>> For more information, see the install_wxWidgets.sh script.
>>>>>>>
>>>>>>> There is however another issue that can mess stuff up. libtool! Again,
>>>>>>> Apple ships there own "special" version of libtool/libtoolize, which
>>>>>>> is NOT compatible with the GNU version. Unfortunately, stuff breaks in
>>>>>>> OS X if you overwrite Apple's version, and thus MacPorts have solved
>>>>>>> this by renaming libtool to glibtool and glibtoolize. To get
>>>>>>> everything to compile correctly, I had to make a symlink from
>>>>>>> /opt/local/bin/glibtool to /opt/local/bin/libtool (and glibtoolize of
>>>>>>> course). This makes everything build fine, but is a bit of a hack
>>>>>>> since I have to remove this symlinks after the build is complete or OS
>>>>>>> X will mess stuff up when installing other programs. The best way
>>>>>>> would be to make the configure/autogen.sh scripts to realize that
>>>>>>> they're building on a Mac and change from libtool to glibtool...
>>>>>>>
>>>>>>> I think that was all. Hope it works for everyone else as well!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel&#174; Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________ Usbpicprog-technical
>>>>>>> mailing list Usb...@li...
>>>>>>> <mailto:Usb...@li...>
>>>>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>>>>>
>>>>>>>                
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel&#174; Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Usbpicprog-technical mailing list
>>>>>> Usb...@li...
>>>>>> <mailto:Usb...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>>>>              
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel&#174; Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Usbpicprog-technical mailing list
>>>>> Usb...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>>>
>>>>>            
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel&#174; Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Usbpicprog-technical mailing list
>>>> Usb...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>>>          
>>>        
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Usbpicprog-technical mailing list
>> Usb...@li...
>> https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical
>>
>>
>>      
>
>
>