Menu
▾
▴
usbpicprog-technical
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(13) |
Nov
(27) |
Dec
(23) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(13) |
Mar
(24) |
Apr
(4) |
May
(11) |
Jun
(1) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(5) |
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
(22) |
Mar
(52) |
Apr
(7) |
May
(19) |
Jun
(12) |
Jul
(9) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(8) |
Dec
(7) |
| 2011 |
Jan
(12) |
Feb
(7) |
Mar
(10) |
Apr
(14) |
May
|
Jun
(1) |
Jul
|
Aug
(11) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(12) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(17) |
Nov
|
Dec
|
| 2013 |
Jan
(7) |
Feb
(6) |
Mar
(6) |
Apr
(21) |
May
(7) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Francesco M. <f18...@ya...> - 2009-04-01 16:17:29
|
Hi Frans, Frans Schreuder ha scritto: > Hi Francesco, > > Are you through with your exam? I hope everything went smoothly... Not yet :) Unfortunately I'll be busy until 8 April :/ I just managed to write some code for drawing the MQFP, TQFP, PLCC packages but I didn't even finish it. > I have gone through your great work on the piklab xml files and all the > code around it. great! > I also implemented the relation between the hexfile and the config > generator and everything seems to work now. Very good. I've compiled and tested the code which on a first glance looks fine! I'm still having some trouble during program phase with my P16f84A (using firmware revision 547)... I'll look into it as soon as I have some more time. > What would you think if I would merge the thing back into trunk? I think it's fine because if program/erase/read operations work fine again, others (like package drawing) are non-critical features and even if they're not perfect yet, it's good for trunk :) Francesco -- |
|
From: Frans S. <fra...@gm...> - 2009-03-30 09:59:07
|
Hi Francesco, Are you through with your exam? I hope everything went smoothly... I have gone through your great work on the piklab xml files and all the code around it. I also implemented the relation between the hexfile and the config generator and everything seems to work now. What would you think if I would merge the thing back into trunk? Cheers, Frans Francesco Montorsi wrote: > Frans Schreuder ha scritto: > >> Hi Francesco, >> >>> These things are going to require me more knowledge about the exact meaning of >>> the values stored in the Piklab files (some of them are not clear to me) and >>> some bit-by-bit operations. If you have time to help, it would be very welcome :) >>> >>> >>> >> Of course I will help implementing these things :) >> > Great; since today I must focus on studying for an incoming exam :/ > so I want have much free time to put in UPP. > > The GUI code anyway is practically complete; I'm aware of three small problems > with it currently: > - the drawing code for various package types yet needs to be written; > - the loading of floating values from Piklab files doesn't work correctly when > locale != en_US. This is because wxString::ToDouble() expects the floating point > separator to be in the right form for the current locale (in my case it should > be ',') but in Piklab files a dot is always used. I'm fixing this in wx now > (enhancing wxString::ToDouble); > - wxGTK package drawing at startup isn't correct and you need to manually force > a redraw changing the package variant to get it right > > I'll focus on these tasks so that if you want to work on the "backend" part we > won't make conflicting changes... > > Francesco > > > |
|
From: Francesco M. <f18...@ya...> - 2009-03-19 16:32:43
|
Frans Schreuder ha scritto: > Hi Francesco, >> These things are going to require me more knowledge about the exact meaning of >> the values stored in the Piklab files (some of them are not clear to me) and >> some bit-by-bit operations. If you have time to help, it would be very welcome :) >> >> > Of course I will help implementing these things :) Great; since today I must focus on studying for an incoming exam :/ so I want have much free time to put in UPP. The GUI code anyway is practically complete; I'm aware of three small problems with it currently: - the drawing code for various package types yet needs to be written; - the loading of floating values from Piklab files doesn't work correctly when locale != en_US. This is because wxString::ToDouble() expects the floating point separator to be in the right form for the current locale (in my case it should be ',') but in Piklab files a dot is always used. I'm fixing this in wx now (enhancing wxString::ToDouble); - wxGTK package drawing at startup isn't correct and you need to manually force a redraw changing the package variant to get it right I'll focus on these tasks so that if you want to work on the "backend" part we won't make conflicting changes... Francesco -- |
|
From: Francesco M. <f18...@ya...> - 2009-03-19 16:04:40
|
Frans Schreuder ha scritto: > Nicolas' raction :) > > Hi Frans, > > since your software is GPL, you're more than welcome to use the XML files. good! Thanks to Nicolas, then :) Francesco PS: I already have committed some changes to the Piklab XML files living in our repository. Once we manage to get the branch in a stable [working] status, I'll post him the diffs. -- |
|
From: Frans S. <fra...@gm...> - 2009-03-19 07:55:28
|
Hi Jasper, > > My usbpic prog is now programmed with svn version 552 firmware, and i've > using usbpicprog rev 559 on ubuntu 8.10. > > usbpicprog corectly identifies 16F88's and a 16F84A. Using the commandline > I can successfully read the 16F84A and reprogram it. If i swap the 16F84A > for a 16F88 the pic programmer appears to be able to read the pic, but the > results are all 1's (i.e. 0xff for data memory, 0xff3f for code memory). > > This seems to be a bug then. Unfortunately I don't have the chance anymore to test all the devices I implement, since microchip doesn't send free samples anymore :'( I will put a note on the website that 16F88 is not working properly and I'll have a good look through the code. > If i try to write to the 16F88 it appears to write correctly (the pic > programmer returns '2' for each chunk written, and 1 when it's done (i added > some debugging)), but when the pic is put into a jdm programmer and read > it's blank. > ok, so it seems reading is ok (as it reads ff3f) but writing doesn't work. > Also if i use the usbpicprog gui it hangs on reading and writing with both > the 16F88 and 16F84A > well, can you tell me when it hangs (maybe a screenshot)? Does it give a segfault? How about 0.2.0 of the software? does it also hang on the 16F84A? Did you use the .deb package or did you build it yourself? > I need the Hightech C18 compiler to compile the upp firmware? does anyone > have a good link to what needs to be done to get it running under wine? > No, it's the Microchip C18 compiler that I use Cheers, Frans |
|
From: Frans S. <fra...@gm...> - 2009-03-19 07:20:26
|
Nicolas' raction :)
Hi Frans,
since your software is GPL, you're more than welcome to use the XML files.
I see that you made lots of progress on your project. Congratulations! I
didn't find much time to work on Piklab lately...
Cheers,
Nicolas
On Wed, Mar 18, 2009 at 08:33, Frans Schreuder <fra...@gm...
<mailto:fra...@gm...>> wrote:
Dear Nicolas,
It's been a long time since I contacted you about usbpicprog.
Usbpicprog has now become a mature project with its own hardware and
software.
As the number of supported device models is growing, we must think
of another way to implement the properties of the devices.
Another developer of usbpicprog, Francesco Montorsi, has now made a
branch in which it is possible to load the xml files provided by Piklab.
What do you think if we use the piklab xml files? Whenever we make
changes to them in terms of fixes or additions, we can of course
send you de diffs.
Regards,
Frans Schreuder
|
|
From: Jasper W. <ja...@po...> - 2009-03-18 20:04:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 10 Mar 2009, Frans Schreuder wrote: > Hi Jasper, > > Did the software autodetect the 16F88 as a device? > I am pretty sure that if it didn't autodetect it, something should be wrong > with the cable or your breadboard... Hi, I've had a chance to look at this again. My usbpic prog is now programmed with svn version 552 firmware, and i've using usbpicprog rev 559 on ubuntu 8.10. usbpicprog corectly identifies 16F88's and a 16F84A. Using the commandline I can successfully read the 16F84A and reprogram it. If i swap the 16F84A for a 16F88 the pic programmer appears to be able to read the pic, but the results are all 1's (i.e. 0xff for data memory, 0xff3f for code memory). If i try to write to the 16F88 it appears to write correctly (the pic programmer returns '2' for each chunk written, and 1 when it's done (i added some debugging)), but when the pic is put into a jdm programmer and read it's blank. So it looks as if 16F88's can be neither written or read. Also if i use the usbpicprog gui it hangs on reading and writing with both the 16F88 and 16F84A I need the Hightech C18 compiler to compile the upp firmware? does anyone have a good link to what needs to be done to get it running under wine? - -- [http://pointless.net/] [0x2ECA0975] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iQEVAwUBScFT1ACB+Qwuygl1AQKvzQf/Suk0E36uugl/gDGZETTElDeQeDLcZXZO +jphk2Dqjnr823EDapH3fqOC68so7gfLZyCZfdokWwhFZa4BKC09+yVQ32z2F9ki dQvEN+gyte9NYZaVKb5yCmH+QE+mbrfL3T21L/oHvujvRHHSHM6SwnCMnC5zyLPu pBLt+ElOAIFICKft/sGP2cO5V1mRv4e6E6OsL24ti4pQ7D9sDiXGuQQtDCyRah7J DeN+FmwRCTpQTUESXmDcCDlVpa67G1VkmYxv2F6KHq2oN6z52WT1JBNTwDEpiGnZ +PPNuhhzE4foPWENryrg1Op0PX+JIoSCdCAdf65VWWSZASxEEBq11g== =NHO7 -----END PGP SIGNATURE----- |
|
From: Frans S. <fra...@gm...> - 2009-03-18 15:37:52
|
Hi Francesco, > These things are going to require me more knowledge about the exact meaning of > the values stored in the Piklab files (some of them are not clear to me) and > some bit-by-bit operations. If you have time to help, it would be very welcome :) > > Of course I will help implementing these things :) Cheers, Frans |
|
From: Francesco M. <f18...@ya...> - 2009-03-18 15:02:29
|
Hi, Frans Schreuder ha scritto: >> Also, distributing the XML files would encourage the user to complete them with >> the missing info for their favourite PIC models (e.g. many names of pins in the >> <package> tags are missing...). >> >> Btw before releasing an upp_wx version which uses Piklab XML files it would be >> nice to inform Piklab developers of this (and we may periodically post them the >> diffs between our XML files and theirs, so that both projects can converge to a >> correct database of PICs info). >> > Of course, I'll contact Nicolas Hadacek about it. thanks - I saw your mail. >>> I know that loading the xml files at runtime has some advantages, eg >>> that you can edit them without having to recompile the program, but I am >>> sure that it will bring some problems especially when we are talking >>> about cross platform development... >>> >> sorry, which problems could it bring? >> I'm using XML files in various other (cross-platform, wx-based) projects and I >> never had troubles... >> > Well, I was just thinking about the location, we really have to think > where the files are being placed. >Linux puts them in > /usr/share/usbpicprog/... or usr/local/share/usbpicprog/... > Windows would put them somewhere in program files and mac will put them > in the .app bundle. It's not impossible but it takes some different > scripts and a lot of testing. This shouldn't be a big problem: wxStandardPaths::GetDataDir() returns the platform-specific correct path for such type of stuff. I've just committed a fix and now usbpicprog installs and works fine under linux. Unfortunately I cannot test on Mac. I'll test on Windows soon (but I'm not used to InstallJammer and thus I won't touch the installer :)). Btw I have (mostly) completed the new GUI (basically it's just using an array of wxChoice controls for all flags -- I emulated Piklab in this) but I need some help with the "backend" part :) First I'd like to discuss the Config[Value|Mask|Block] classes I've added to pictype.h; their names are probably not ideal (suggestions welcome) and also their member names are not ideal :) In particular I'd like not to use "Value" name as in reality those classes should only contain the description of the configuration flags of a PIC, not the actual configuration values (just like the Pic class stores description of a PIC model, but the real code/config/data bytes are stored in the HexFile class). After that, we need to - remove the Pic::ConfigMask[] field and update Hardware class to use newer config flags classes - correctly initialize values of the choice controls loading them from the hex file in UppConfigViewBook::SetHexFile - correctly modify the UppConfigViewBook::m_hexFile instance in UppConfigViewBook::OnChange These things are going to require me more knowledge about the exact meaning of the values stored in the Piklab files (some of them are not clear to me) and some bit-by-bit operations. If you have time to help, it would be very welcome :) Thanks, Francesco -- |
|
From: Frans S. <fra...@gm...> - 2009-03-18 07:33:38
|
Dear Nicolas, It's been a long time since I contacted you about usbpicprog. Usbpicprog has now become a mature project with its own hardware and software. As the number of supported device models is growing, we must think of another way to implement the properties of the devices. Another developer of usbpicprog, Francesco Montorsi, has now made a branch in which it is possible to load the xml files provided by Piklab. What do you think if we use the piklab xml files? Whenever we make changes to them in terms of fixes or additions, we can of course send you de diffs. Regards, Frans Schreuder |
|
From: Frans S. <fra...@gm...> - 2009-03-18 07:23:14
|
Hi Francesco, > > > I think it would be better; unfortunately sometimes there are infos in the > Piklab XML files which are wrong (at least they look wrong to me but I'm not > 100% sure) and if the user may just edit an XML file to fix upp_wx for his PIC > model, it would be indeed more happy than being forced to wait for a new > release/snapshot. > you are right about that, most people don't edit it in the source, but maybe they do in their copy of the xml files. > Also, distributing the XML files would encourage the user to complete them with > the missing info for their favourite PIC models (e.g. many names of pins in the > <package> tags are missing...). > > Btw before releasing an upp_wx version which uses Piklab XML files it would be > nice to inform Piklab developers of this (and we may periodically post them the > diffs between our XML files and theirs, so that both projects can converge to a > correct database of PICs info). > Of course, I'll contact Nicolas Hadacek about it. >> I know that loading the xml files at runtime has some advantages, eg >> that you can edit them without having to recompile the program, but I am >> sure that it will bring some problems especially when we are talking >> about cross platform development... >> > sorry, which problems could it bring? > I'm using XML files in various other (cross-platform, wx-based) projects and I > never had troubles... > Well, I was just thinking about the location, we really have to think where the files are being placed. Linux puts them in /usr/share/usbpicprog/... or usr/local/share/usbpicprog/... Windows would put them somewhere in program files and mac will put them in the .app bundle. It's not impossible but it takes some different scripts and a lot of testing. Cheers, Frans |
|
From: Francesco M. <f18...@ya...> - 2009-03-17 20:38:47
|
Hi Frans, Frans Schreuder ha scritto: > I am looking through the xml branch you made and it sure looks good! Thanks! > (I'm sorry that I couldn't find more time earlier to have a look at it, > but I have a lot of other things to do at the moment...) no problem, really. I was busy on other things too and so the progress was/is slow :) > There's just one thing I am wondering: what have you done to autogen.sh > and configure.ac? I have recently changed my workstation (now I'm on x86_64 linux) and doing so I discovered that the usbpicprog configure didn't warn if libusb was missing. I fixed it and in the meanwhile I also cleaned it up a bit (mostly organizing it in sections and using wx's 'official' M4 macros)... > It doesn't seem to install the locales anymore, nor does it install the > xml files. ops, fixed copying the install-sh of the trunk. It should be ok now... let me know if I broke something else :) > Do you think it is necessary to distribute the xml files with the > program? I think it would be better; unfortunately sometimes there are infos in the Piklab XML files which are wrong (at least they look wrong to me but I'm not 100% sure) and if the user may just edit an XML file to fix upp_wx for his PIC model, it would be indeed more happy than being forced to wait for a new release/snapshot. Also, distributing the XML files would encourage the user to complete them with the missing info for their favourite PIC models (e.g. many names of pins in the <package> tags are missing...). Btw before releasing an upp_wx version which uses Piklab XML files it would be nice to inform Piklab developers of this (and we may periodically post them the diffs between our XML files and theirs, so that both projects can converge to a correct database of PICs info). > I think Piklab really compiles the xml files into the program > which makes it easier to distribute. yes, I realized it after writing the XML loading code. However I also made upp_wx "smart", in the sense that it loads XML files on request (does not load all of them at startup!) and thus is quite fast. >Do you know if wxWidgets provides > something for that? there is http://wiki.wxwidgets.org/Embedding_PNG_Images-Bin2c_In_C ; it's for binary files but I think should work ok also for XML files. But as I said thanks to the load-on-request and given the added advantages of having the XML files on the end-user system, I think it's not required. > I know that loading the xml files at runtime has some advantages, eg > that you can edit them without having to recompile the program, but I am > sure that it will bring some problems especially when we are talking > about cross platform development... sorry, which problems could it bring? I'm using XML files in various other (cross-platform, wx-based) projects and I never had troubles... Francesco -- |
|
From: Frans S. <fra...@gm...> - 2009-03-16 18:50:41
|
Hi Francesco, I am looking through the xml branch you made and it sure looks good! (I'm sorry that I couldn't find more time earlier to have a look at it, but I have a lot of other things to do at the moment...) There's just one thing I am wondering: what have you done to autogen.sh and configure.ac? It doesn't seem to install the locales anymore, nor does it install the xml files. Do you think it is necessary to distribute the xml files with the program? I think Piklab really compiles the xml files into the program which makes it easier to distribute. Do you know if wxWidgets provides something for that? I know that loading the xml files at runtime has some advantages, eg that you can edit them without having to recompile the program, but I am sure that it will bring some problems especially when we are talking about cross platform development... Cheers, Frans |
|
From: Frans S. <fra...@gm...> - 2009-03-10 07:21:25
|
Hi Jasper, Did the software autodetect the 16F88 as a device? I am pretty sure that if it didn't autodetect it, something should be wrong with the cable or your breadboard... Cheers, Frans > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 9 Mar 2009, Frans Schreuder wrote: > > >> Hi Jasper, >> >> Please have a look at this page: >> http://usbpicprog.org/?page_id=6 >> Does that answer your question? >> > > Hi, > > yes, Sorry i found that shortly after posting to the list. > > I've updated the usbpicprog with the firmware from svn, however i don't seem > to be able to program the 16f88. I'm not sure if it's my icsp cable (an old > ide cable with a bunch of jumper leads on the end, the pic i'm trying to > program is on some breadboard with no other components), or something else. > > I'm trying to get ahead with my project atm, so i've gone back to my old jdm > programmer for the moment (which i've never got working with icsp either). > > - -- > [http://pointless.net/] [0x2ECA0975] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (NetBSD) > > iQEVAwUBSbV/CgCB+Qwuygl1AQLSQwf/V0BR9QIWQFceNmqMR89q7D8KwqGBN8ln > gCJ2zlKcVzrDiurb4VySJ3lnC7rwFgGF+FtEk3BlpKByWVBN1ZUvn4jSuSjRF8iK > TZsv14G9AB54bfKbDZTbwVESIBO7enLiAeWjaIo3+Qh7321uwo4K2Phtk7PqE8tH > zrT5mhYYWFuna4SonpAqvm0qU3Te7sZFK7lIqLQSdkJP9il2A65RAjsONz4lHqWl > RcEibrNx52GOMYoK1qRNBN451/TwGkRQH5l+/guoGSYvahTfUl3e1WMSzDT/moGz > iuvdcpShVDRliDjPwc/N2pFXfFmTuvjtekoBtF7nSyowKJVmqV2IpA== > =cDKR > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
|
From: Jasper W. <ja...@po...> - 2009-03-09 20:41:35
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 9 Mar 2009, Frans Schreuder wrote: > Hi Jasper, > > Please have a look at this page: > http://usbpicprog.org/?page_id=6 > Does that answer your question? Hi, yes, Sorry i found that shortly after posting to the list. I've updated the usbpicprog with the firmware from svn, however i don't seem to be able to program the 16f88. I'm not sure if it's my icsp cable (an old ide cable with a bunch of jumper leads on the end, the pic i'm trying to program is on some breadboard with no other components), or something else. I'm trying to get ahead with my project atm, so i've gone back to my old jdm programmer for the moment (which i've never got working with icsp either). - -- [http://pointless.net/] [0x2ECA0975] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iQEVAwUBSbV/CgCB+Qwuygl1AQLSQwf/V0BR9QIWQFceNmqMR89q7D8KwqGBN8ln gCJ2zlKcVzrDiurb4VySJ3lnC7rwFgGF+FtEk3BlpKByWVBN1ZUvn4jSuSjRF8iK TZsv14G9AB54bfKbDZTbwVESIBO7enLiAeWjaIo3+Qh7321uwo4K2Phtk7PqE8tH zrT5mhYYWFuna4SonpAqvm0qU3Te7sZFK7lIqLQSdkJP9il2A65RAjsONz4lHqWl RcEibrNx52GOMYoK1qRNBN451/TwGkRQH5l+/guoGSYvahTfUl3e1WMSzDT/moGz iuvdcpShVDRliDjPwc/N2pFXfFmTuvjtekoBtF7nSyowKJVmqV2IpA== =cDKR -----END PGP SIGNATURE----- |
|
From: Frans S. <fra...@gm...> - 2009-03-09 13:44:34
|
Hi Jasper, Please have a look at this page: http://usbpicprog.org/?page_id=6 Does that answer your question? Regards, Frans Schreuder Jasper Wallace wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 7 Mar 2009, Frans Schreuder wrote: > > >> Hi Jasper, >> >> The 16F88 should be implemented, also in the bulk erase from revision 552. >> The fact that you don't see it in the case statement is because the >> 16F88 has the same protocol as the 16F87. It should not return 3 though. >> Have you loaded the latest firmware (available from the snapshot >> download page on usbpicprog.org) >> > > how to i upgrade the firmware? do i need to change the jumpers on the self > prog header? > > >> It's true that I haven't tested the 16F88 and in the stable release it >> is not yet implemented, so expect some bugs for this device... >> > > - -- > [http://pointless.net/] [0x2ECA0975] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (NetBSD) > > iQEVAwUBSbOqswCB+Qwuygl1AQLFKQf+I4nnAJPPpDIeNkSSCaZZcsBKJ48hFmmN > NHORSIeDVZVl8Sv+4LFc63wF9Y7vD1j+8GYH1ndJu8uvNyY8pOzxVFKLLVf/cix9 > Biw9Mt/j64vSZ0ISgCiCS31SYxezYKV1f0gPXLVEes9/GQvX3UX71DIsbJFPxemA > Jlhc68Jzt+oqaui2gwgGdihnoTLl5boesrXVE/MfbgUnsK1XMDRT8YR+jsXaV6xS > CAbJbAe3zlRDdXQyzyatTWFFQlvafJNdv1f0d4c3fPtX6UWzYlHd6DL+apzDeHbO > 2Ll2KK1xZD1ZHRSVY+xf4KRjLUEUR3r/f0a788StjgEnzRHDg6bkGQ== > =EULA > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
|
From: Frans S. <fra...@gm...> - 2009-03-09 07:21:36
|
Hi Francesco,
> Hi Frans,
>
> Frans Schreuder ha scritto:
>
>>> PS: do you think it would be better to create a separate branch for
>>> experimenting with the XML approach or should I commit the changes directly in
>>> trunk?
>>>
>>>
>>>
>> Well, I think this is something we can do in the trunk version, with the
>> threaded version I was afraid that it could maybe do something to the
>> hardware stability, so I thought that would be safer.
>>
> I've implemented most of the basic stuff... however the changes are quite big
> and unfortunately I can't seem to get my PIC16F84A correctly programmed anymore now.
>
> Hardware::writeCode() returns -4 now and the programming operations fails with a
> log message:
> LogFromThread(wxLOG_Error, _("Verify error while writing code memory"));
>
>
> Unfortunately I'm not very confident with the Hardware class code and I don't
> understand why it fails now. It must have something to do with the changes I did
> to PicType class obviously; could it be something related to the fact that (at
> least for now) the Pic::ConfigFlags[] array is simply set to zero in my local
> copy (because those info are not in piklab XML files)?
>
> In any case I fear that committing my modifications in the trunk may result in
> "programming failures" for many other PIC types; this also because some data in
> the Piklab XML files seems not correct to me... e.g. PIC16F84A's config memory
> is reported to start at 0x2007 and to end at 0x2007: I corrected it to report
> the end at 0x2009, but other small details for other PICs may have to be fixed, too.
>
> So I think it would be better to create a new branch and commit there. Unless
> you think we can fix the (new) bugs in trunk directly.
>
I think that's a good idea, let's make a branch, also if small things
are still missing and people want to use the latest snapshot, they can
still co the trunk.
Though I think it could also be something which I did in the firmware.
I can't find a way how configflags could damage writing code memory.
Do you know whether the process quits immediately or that it programs
well for some time?
>
>> Do you know if there is something like an editor for those xml files? or
>> will it just be a general text editor?
>>
> I use the same text editor (Kate) I use for normal CPP/H files :)
> Nothing special is required ;)
>
Ok, I'll just have to get used to the xml syntax then!
Frans
|
|
From: Francesco M. <f18...@ya...> - 2009-03-08 14:10:59
|
Hi Frans,
Frans Schreuder ha scritto:
>> PS: do you think it would be better to create a separate branch for
>> experimenting with the XML approach or should I commit the changes directly in
>> trunk?
>>
>>
> Well, I think this is something we can do in the trunk version, with the
> threaded version I was afraid that it could maybe do something to the
> hardware stability, so I thought that would be safer.
I've implemented most of the basic stuff... however the changes are quite big
and unfortunately I can't seem to get my PIC16F84A correctly programmed anymore now.
Hardware::writeCode() returns -4 now and the programming operations fails with a
log message:
LogFromThread(wxLOG_Error, _("Verify error while writing code memory"));
Unfortunately I'm not very confident with the Hardware class code and I don't
understand why it fails now. It must have something to do with the changes I did
to PicType class obviously; could it be something related to the fact that (at
least for now) the Pic::ConfigFlags[] array is simply set to zero in my local
copy (because those info are not in piklab XML files)?
In any case I fear that committing my modifications in the trunk may result in
"programming failures" for many other PIC types; this also because some data in
the Piklab XML files seems not correct to me... e.g. PIC16F84A's config memory
is reported to start at 0x2007 and to end at 0x2007: I corrected it to report
the end at 0x2009, but other small details for other PICs may have to be fixed, too.
So I think it would be better to create a new branch and commit there. Unless
you think we can fix the (new) bugs in trunk directly.
> Do you know if there is something like an editor for those xml files? or
> will it just be a general text editor?
I use the same text editor (Kate) I use for normal CPP/H files :)
Nothing special is required ;)
Francesco
--
|
|
From: Jasper W. <ja...@po...> - 2009-03-08 11:23:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 7 Mar 2009, Frans Schreuder wrote: > Hi Jasper, > > The 16F88 should be implemented, also in the bulk erase from revision 552. > The fact that you don't see it in the case statement is because the > 16F88 has the same protocol as the 16F87. It should not return 3 though. > Have you loaded the latest firmware (available from the snapshot > download page on usbpicprog.org) how to i upgrade the firmware? do i need to change the jumpers on the self prog header? > It's true that I haven't tested the 16F88 and in the stable release it > is not yet implemented, so expect some bugs for this device... - -- [http://pointless.net/] [0x2ECA0975] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iQEVAwUBSbOqswCB+Qwuygl1AQLFKQf+I4nnAJPPpDIeNkSSCaZZcsBKJ48hFmmN NHORSIeDVZVl8Sv+4LFc63wF9Y7vD1j+8GYH1ndJu8uvNyY8pOzxVFKLLVf/cix9 Biw9Mt/j64vSZ0ISgCiCS31SYxezYKV1f0gPXLVEes9/GQvX3UX71DIsbJFPxemA Jlhc68Jzt+oqaui2gwgGdihnoTLl5boesrXVE/MfbgUnsK1XMDRT8YR+jsXaV6xS CAbJbAe3zlRDdXQyzyatTWFFQlvafJNdv1f0d4c3fPtX6UWzYlHd6DL+apzDeHbO 2Ll2KK1xZD1ZHRSVY+xf4KRjLUEUR3r/f0a788StjgEnzRHDg6bkGQ== =EULA -----END PGP SIGNATURE----- |
|
From: Frans S. <fra...@gm...> - 2009-03-07 19:31:10
|
Hi Jasper, The 16F88 should be implemented, also in the bulk erase from revision 552. The fact that you don't see it in the case statement is because the 16F88 has the same protocol as the 16F87. It should not return 3 though. Have you loaded the latest firmware (available from the snapshot download page on usbpicprog.org) It's true that I haven't tested the 16F88 and in the stable release it is not yet implemented, so expect some bugs for this device... Cheers, Frans Jasper Wallace wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hi, > > I've just got a upp and i'm trying to program pic 16f88's - i can read > them fine, but eraseing them gives error '3', looking at the firmware > source the case statment in the bulk_erase function in uc_code/upp/prog.c > dosn't have a case for P16F88 - and so it drops through to the default. > > Is that intentional, or is it just that the case statement is missing? > > - -- > [http://pointless.net/] [0x2ECA0975] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (NetBSD) > > iQEVAwUBSbGOYwCB+Qwuygl1AQLUNwf/SfQlF22/ucWAfHHj2IPkLJ1mfFr4kBHw > Eli7/1dKgVlE6DbstHIGU2rlIZAsylgNlHKuCmY5/G11nuX4o42TG4Iw5aA4s7mw > J68TxEklj/pp7fothY7P+GD45WGsCNsjpC70/tJQTzSFyBZzZ75Qfa7zejV04fmI > EHyFbuiRGDOwpAFVste5413pRma+RPOKOe+NUPUJeNdY7gNlmnVUj8NMFsSwIh71 > Y+dSc5oWQsA1D+I4DvFa+7TDktlZMtHxDMLSOQPjXOxOdgW76/ZpoFjMJNQAAojl > Pg0CExgsnAnvuh9BA62ACCrMUi1CPRJozY0nxM1yXARsJN362nocgA== > =q8JO > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Usbpicprog-technical mailing list > Usb...@li... > https://lists.sourceforge.net/lists/listinfo/usbpicprog-technical > |
|
From: Jasper W. <ja...@po...> - 2009-03-06 21:39:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've just got a upp and i'm trying to program pic 16f88's - i can read them fine, but eraseing them gives error '3', looking at the firmware source the case statment in the bulk_erase function in uc_code/upp/prog.c dosn't have a case for P16F88 - and so it drops through to the default. Is that intentional, or is it just that the case statement is missing? - -- [http://pointless.net/] [0x2ECA0975] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (NetBSD) iQEVAwUBSbGOYwCB+Qwuygl1AQLUNwf/SfQlF22/ucWAfHHj2IPkLJ1mfFr4kBHw Eli7/1dKgVlE6DbstHIGU2rlIZAsylgNlHKuCmY5/G11nuX4o42TG4Iw5aA4s7mw J68TxEklj/pp7fothY7P+GD45WGsCNsjpC70/tJQTzSFyBZzZ75Qfa7zejV04fmI EHyFbuiRGDOwpAFVste5413pRma+RPOKOe+NUPUJeNdY7gNlmnVUj8NMFsSwIh71 Y+dSc5oWQsA1D+I4DvFa+7TDktlZMtHxDMLSOQPjXOxOdgW76/ZpoFjMJNQAAojl Pg0CExgsnAnvuh9BA62ACCrMUi1CPRJozY0nxM1yXARsJN362nocgA== =q8JO -----END PGP SIGNATURE----- |
|
From: Frans S. <fra...@gm...> - 2009-03-03 07:56:41
|
Hi Francesco, > well, there's not much to know about XML. See the link below. > > > Do you know if there are some standard tools to parse them using simple > > scripts or something? > I've already written all the code to load Piklab files (well, it's few lines > thanks to wxXmlDocument class); you can see how easy is to parse an XML document > with wx at: > > http://docs.wxwidgets.org/trunk/classwx_xml_document.html > > Seems simple indeed! > > PS: do you think it would be better to create a separate branch for > experimenting with the XML approach or should I commit the changes directly in > trunk? > > Well, I think this is something we can do in the trunk version, with the threaded version I was afraid that it could maybe do something to the hardware stability, so I thought that would be safer. Do you know if there is something like an editor for those xml files? or will it just be a general text editor? Cheers, Frans |
|
From: Francesco M. <f18...@ya...> - 2009-03-02 21:21:42
|
Hi, Frans Schreuder ha scritto: > Hi Francesco, > > I think this is a great approach, especially if we can load all the data > from piklab directly. > I really haven't done anything with XML files yet, so I will have to > read some tutorials I guess. well, there's not much to know about XML. See the link below. > Do you know if there are some standard tools to parse them using simple > scripts or something? I've already written all the code to load Piklab files (well, it's few lines thanks to wxXmlDocument class); you can see how easy is to parse an XML document with wx at: http://docs.wxwidgets.org/trunk/classwx_xml_document.html > I agree that the hex flags are ugly, it was just something I still had > in mind for the future :) > > I don't know yet what to do with the PicFamily, This one is quite > necessary for the firmware... I agree; I think the best way to add such PicFamily value to the various PICs is to leave untouched the various Piklab XML files (so we can replace them with newer Piklab files in future) and rather add a new index.xml file which would go like this: <xml ..> <upp> ... <device name="16F84A" upp_family="P16F84A"/> ... <device name="P16F683" upp_family="P12F6XX"/> ... </upp> it would allow us: 1) to load from all Piklab XML files only the data for those which UPP actually supports 2) to specify custom UPP data for each PIC (e.g. upp_family, but if we can't go without the devIdMask we may add a upp_devidmask attribute, too) > The config mask won't be necessary anymore since the flag names replace it. ah, ok > The devid mask is something very important, since the devid is divided > into two portions, devid and revision. Some devid's have 4 bits for the > revision and some have 5, so we can't just hard-code it to 4 or 5 bits. > Let me check out how piklab does it... ok; anyway as I said if it's really necessary to have it we may add an "upp_devidmask" attribute in the index.xml file. Francesco PS: do you think it would be better to create a separate branch for experimenting with the XML approach or should I commit the changes directly in trunk? -- |
|
From: Frans S. <fra...@gm...> - 2009-03-02 08:16:50
|
Hi Francesco,
I think this is a great approach, especially if we can load all the data
from piklab directly.
I really haven't done anything with XML files yet, so I will have to
read some tutorials I guess.
Do you know if there are some standard tools to parse them using simple
scripts or something?
I agree that the hex flags are ugly, it was just something I still had
in mind for the future :)
I don't know yet what to do with the PicFamily, This one is quite
necessary for the firmware...
The config mask won't be necessary anymore since the flag names replace it.
The devid mask is something very important, since the devid is divided
into two portions, devid and revision. Some devid's have 4 bits for the
revision and some have 5, so we can't just hard-code it to 4 or 5 bits.
Let me check out how piklab does it...
Cheers,
Frans
Francesco Montorsi wrote:
> Hi Frans,
> I'm looking at implementing loading PIC data from Piklab XML as we talked
> about some time ago.
> This would allow to have an "Info" page next to the "Code", "Cfg flags" and
> "Data" current pages with lots of info about the selected PIC and to have the
> "Configuration flags" page reorganized to contain e.g. an array of checkboxes
> which indicate "Oscillator type", etc etc. This last feature in particular would
> help very much IMO (looking at the flags in hexadecimal form is quite ugly).
>
> Looking at the UPP source file, for example for PIC16F84A, I see:
>
> {
> "P16F84A", //Name
> 0x1FF*2, //CodeSize
> 0x2007, //ConfigAddress
> 0x2100, //DataAddress in hex file
> 0x40, //Datasize
> 0x2, //ConfigSize
> P16F84A, //PicFamily
> 0x0560, //DevId
> 0x3FE0, //DevIdMask
> {0xFF,0x3F}
> },
>
> the relative XML data is:
>
> <device name="16F84A" ... id="0x0560" ...>
> ....
>
> <!--* Memory ***************************************************************-->
> <memory name="code" start="0x0000" end="0x03FF" />
> <memory name="user_ids" start="0x2000" end="0x2003" rmask="0x007F" />
> <memory name="device_id" start="0x2006" end="0x2006" />
> <memory name="config" start="0x2007" end="0x2007" />
> <memory name="eeprom" start="0x0000" end="0x003F" hexfile_offset="0x2100" />
>
> <!--* Configuration bits ***************************************************-->
> <config offset="0x0" name="" wmask="0x3FFF" bvalue="0x3FFF" >
> <mask name="FOSC" value="0x0003" >
> <value value="0x0000" name="LP" cname="_LP_OSC" />
> <value value="0x0001" name="XT" cname="_XT_OSC" />
> <value value="0x0002" name="HS" cname="_HS_OSC" />
> <value value="0x0003" name="EXTRC_CLKOUT" cname="_RC_OSC" />
> </mask>
> <mask name="WDT" value="0x0004" >
> <value value="0x0000" name="Off" cname="_WDT_OFF" />
> <value value="0x0004" name="On" cname="_WDT_ON" />
> </mask>
> <mask name="PWRTE" value="0x0008" >
> <value value="0x0000" name="On" cname="_PWRTE_ON" />
> <value value="0x0008" name="Off" cname="_PWRTE_OFF" />
> </mask>
> <mask name="CP" value="0x3FF0" >
> <value value="0x0000" name="All" cname="_CP_ON" />
> <value value="0x3FF0" name="Off" cname="_CP_OFF" />
> <value value="default" name="invalid" />
> </mask>
> </config>
> ....
> </device>
>
> So that the info we currently keep in pictype.cpp could be loaded from (using a
> pseudo syntax to refer to the XML tags and XML attributes):
>
> typedef struct {
> string Name; <== "P"+ <device@name>
> int CodeSize; <== <memory@name="code"@end> - <memory@name="code"@start>
> int ConfigAddress; <== <memory@name="config"@start>
> int DataAddress; //in hex file <== <memory@name="eeprom"@hexfile_offset>
> int DataSize; <== <memory@name="eeprom"@end> - <memory@name="eeprom"@start>
> int ConfigSize; <== <memory@name="config"@end> - <memory@name="config"@start>
> PicFamily picFamily;
> int DevId; <== <device@id>
> int DevIdMask;
> int ConfigMask[16];
> } Pic;
>
> stuff that seems cannot be loaded from XML is thus:
>
> 1) PicFamily picFamily;
> This is a number corresponding to the UPP internal classification of
> the PIC families and thus is obviously not present in Piklab XML files.
> I think we can't do nothing about this.
>
> 2)
> int DevIdMask;
> int ConfigMask[16];
> maybe I'm just missing something but this data cannot be derived from the data
> contained in Piklab XML files in some way?
>
>
> It would be nice to be able to load all data from the Piklab XML files without
> being forced to modify them so that we could simply overwrite our XML files with
> Piklab's updated ones from time to time.
>
> Thanks,
> Francesco
>
>
|
|
From: Francesco M. <f18...@ya...> - 2009-03-01 12:46:17
|
Hi Frans, Frans Schreuder ha scritto: > I think Doxygen is a good idea, the thing is that I have never done it, > how do I start? I've just committed the necessary setup to generate the manual. To generate it (it's a good thing to NOT commit to SVN repo the HTML files generated by doxygen), just cd to upp_wx/docs and run "doxygen", then "firefox html/index.html". To use doxygen you just need to write the comments in the headers with a special syntax. E.g. instead of /* */ if you want that comment to document the function that follows it, just must use /** */. Instead of // use /// or //! More info at: http://www.stack.nl/~dimitri/doxygen/docblocks.html Bye, Francesco PS: I've not committed doxyfied comments for PicType since I'm modifying it for the XML-data load stuff (see the other mail). -- |
6 messages has been excluded from this view by a project administrator.
