Be the first to post a text review of GunProg - universal chip programmer. Rate and review a project by clicking thumbs up or thumbs down in the right column.

• Code committed

  grab_rat committed patchset 3 of module Website to the GunProg - universal chip programmer CVS repository, changing 7 files

  posted by grab_rat 2430 days ago

• Code committed

  grab_rat committed patchset 3 of module Software to the GunProg - universal chip programmer CVS repository, changing 15 files

  posted by grab_rat 2430 days ago

• Code committed

  grab_rat committed patchset 5 of module GunProg to the GunProg - universal chip programmer CVS repository, changing 33 files

  posted by grab_rat 2430 days ago

• Forum thread added

  kodrat created the Need some help with GunProg? forum thread

  posted by kodrat 2437 days ago

• Project split: see new GunFire project!

  Since working on the software, it's become obvious that the hardware and software have two different goals. The hardware side is aiming to produce a specific piece of hardware to do a specific thing. By contrast the software side is being designed to work with any hardware. To manage this conflict, I've decided to split the project. GunProg (this project) will be for the programmer hardware. GunFire (the new project) will produce the software to give support for any programmer hardware. Having two projects will make it easier to handle the two different deliverables.

  posted by grab_rat 2493 days ago

• DLL handling complete

  The code to add in devices and programmers via DLL is now complete. You just throw a DLL filename at the code, and it handles everything else. So data-file loading and saving is done, and DLL handling is done. That's all the infrastructure in place to get the actual programming stuff done - reading and writing values to chips. So my job now is to work out a good generic interface to control pins and read back pin states, and then get this coded up. Once that's done, I'll write a simple DLL to program a PIC16F877 on a ProPIC2 board (both of which I happen to have :-) so that I can prove this works. I'll then have an alpha version of the code that people can see working! This alpha will NOT have any provision for moving chips around in a socket - that will come later. The user interface will also be a POS text interface to keep things simple - again, the pretty interface will come later. This alpha will be the proof-of-concept, to get something that does things.

  posted by grab_rat 2500 days ago

• Programming code under way

  Instead of coding, I've been sat down for the last 2-3 weeks with Word. First a lot of brainstorming to get details of exactly what I wanted everything to do, then a whole load of time on how to do it. I always find that works better - instead of doing the job several times over as you come up with new requirements and better ways of doing things, work out all the requirements first, and then work out how to make those requirements fly. I've changed my mind about DLLs - it's going to be easier to get this right once. All support for devices and programmers will be through DLLs. Doing a bit of research, it seems that Windows and Linux use the same basic approach (just with different function names), so I'll only have to rewrite one class for using Linux DLLs. The design for setting up everything for programming is 100% there - I've got all the classes planned for what they'll do, I just need to write the code as per the design (which is under way now). I'm a bit more sketchy about how the actual programming will go - I still need to think about the design of that a bit. But that should be easy enough to graft on afterwards - it's just added extra functions to the device and programmer classes. File operations are still going to be hardcoded for the moment bcos I've got that implemented already, so it's good enough for now. I'll likely change that over to DLLs as well when I've got the programming side finished. The file operations are independent of the programming, so I can make changes to that without having to rip out anything else. The other change to be done sometime is to improve the class which stores the data to be programmed. I started writing C code and changed my mind later, but I kept the algorithm. Anyway, the method used is dynamic array allocation, which seemed fun at the time and a neat programming challenge, but now I realise I'm just allocating, deallocating and moving large blocks of memory for no good reason, every time anyone adds another byte to the data. The proper way to do this would be to allocate memory in chunks, say 64 bytes at a time, so that adding more bytes of data only affects a single chunk of memory and not the whole damn lot! With a bit of luck, I may have DLL access to device and programmer drivers ready by Xmas. If not, sometime in January. What with my wife's birthday, our wedding anniversary, Xmas parties, Xmas itself and New Year, I might not get much time to code! ;-)

  posted by grab_rat 2531 days ago

• Code committed

  grab_rat committed patchset 2 of module Website to the GunProg - universal chip programmer CVS repository, changing 1 files

  posted by grab_rat 2566 days ago

• Code committed

  grab_rat committed patchset 1 of module Website to the GunProg - universal chip programmer CVS repository, changing 1 files

  posted by grab_rat 2566 days ago

• Code committed

  grab_rat committed patchset 2 of module Software to the GunProg - universal chip programmer CVS repository, changing 15 files

  posted by grab_rat 2566 days ago