 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : simplest 32MX150 ICSP
Page 1 of 28   |
|||||
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
it occurs to me that programming the interpreter into a 32MX150 (aka micromite) is relatively straight forward from the electrical perspective. the three pins on the device that need to be manipulated are (1) reset, always an output from the programmer, (2) clock (PGC) that again is always an output from the programmer, and (3) data (PGD) that needs to be bidirectional. none of these lines need to have more than a swing between 0 and 3v3. pins that meet these requirements are available on the average USB to serial bridge, in the form of the various flow control pins. it therefore seems that, given that the rate of data flow is controlled entirely by the host, all that is needed beyond said bridge is a small windows (or mac or linux) application that can take a .HEX file and turn it into the required manipulation of the above lines. why hasn't anyone done this yet? better still, someone might care to take up the challenge. a solution quite specific to the 32MX150. yes, i am aware that general-purpose pic programmers are available at a price, but i am asking this question specifically in relation to not using one of these. rob :-) |
||||
| Alan68 Newbie  Joined: 28/01/2013 Location: AustraliaPosts: 17 |
Hi Robert, I was looking in to using a Maximite as a programmer and putting the HEX file on a SD Card, There is a lot of information on how the PICKIT3 works on the internet. |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 712 |
http://picpgm.picprojects.net/hardware.html Link Here you find several ways of Programming a PIC, Even with an FTDI Chip. Don't know why 32MX150 IS not supported. Is the programming algorythm different? Where is the difference? With some time and Google, you should be able to figure out. A simple an cheap Programmer with a pice of software should help uMite to spread over The world. Good idea! |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Some months ago I did a bit of research into programming pic32 chips with a home grown programmer. It seems (Geoff can probably put it better) that because the core processor is MIPS and not pic it needs a specific programming executive that is not the same as an 'ordinary" pic. What you might be able to do is dump in a uMite programme written in MMbasic by creating a simple 20x4 LCD based terminal programme. I have been contemplating designing such a system. David M. |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 712 |
Mobi, i do not understand what this will be good for ?? What do you mean with this? Dietmar |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 712 |
One must understand this an implement it: http://ww1.microchip.com/downloads/en/devicedoc/61145g.pdf ;-) Not me, i'am not retired ;-) |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Thanks Atmega8, I'll have a closer read. ================ I had a read through the programming specs and realised my memory lapse. When I first started playing with PICs, I wrote my own assembler/programmer for 8 bit pics using VB6 via serial cable and Silicon Chip portable programmer. When I was introduced to PIC32, my problem was not the programming but the writing of the assembly language programme as the PIC32 core was different to a "standard" PIC, hence lashing out and buying a PICKit 3 and using MPLABX. I could probably modify my own programmer to do PIC32 but..do I really need to now. David M. |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 712 |
The idea is really good, but the effort , i think, very high... |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
Even higher, the referred document does not even apply to the PIC32MX ones and twos. That document is vintage 2010. There may be a later one around but I did not look as it was easier to buy a Pickit3. |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I spent all evening (yet again) trying to decipher the microchip description of external too programming. At least I can get the chip into programming mode - that is the easy part. The rest of the description is the usual Microchip gobbled gook. I have been through the procedure a number of times with Microchip flow charts and timing diagrams and vague descriptions and in the end, I won. This one is a real challenge though. The timing diagrams are mostly incomplete have "holes" in the middle because they won't fit on a page and are left up to the reader to interpret. I don't think it matters that the document doesn't refer specifically to our PIC32MX versions as the programming algorithms and command values are likely to be the same. I think the main difference will be with the size and location of flash memory, boot segments and config words. No big deal as they are only parameters to the programmer and easily changed. Once it is nutted out, the mechanics of it all it is easy to apply to updated chips. I realise that nutting this out will be a lot of effort (and is it really worth it), but, it is a challenge and I think it is quite do-able. Does anyone want to go along for the ride? I'm willing to as I've been down this track before with the 8 bit units starting with the F84A, F628A, F88 and F819 as well as Atmel 328 chips. David M. |
||||
| BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
I am not sure if I am a capable party but I am certainly interested. |
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
I guess MX1/2 micros are a bit different than MX3-MX7 series regarding to programming protocol. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
These look newer ww1.microchip.com/downloads/en/DeviceDoc/61145L.pdf ww1.microchip.com/downloads/en/DeviceDoc/60001145M.pdf They show the PE is optional. The latter PDF includes the new PIC32MZ a bit. John |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
That is correct. I guess it is simpler and faster using the PE. I think I can implement the 4 wire method, but the 2 wire explanation leaves me befuddled. It would have been nice to see a timing chart using all clock pulses instead of implying them. Unless anyone else has their head around the 2 wire method, I think I will see if I can Implement the 4 wire mode first. At least that will get the MM software working. Any help gratefully accepted. ============== Think I'm beginning to cotton on to the data sequences. Needs a bit more analysing yet. I tried the serial to usb idea with 8 bit PICs and it was S L O W ! Ended up making a 'go between' to do the clocking. Are you actively working on this or is it just a challenge 'out there'? David M. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
i'm more just putting it out there - it is quite outside of my area of expertise, and i don't have the tools/resources necessary to to make much of a go of it. but i am willing to offer a hand wherever i can. it does seem to me, intuitively, that a simple (albeit specific to the 32MX150) solution should be possible. at the physical level the communications is very basic (just two wires, PGD and PGC) which are manipulated as digital I/O lines. similarly for MCLR i assume. a brute-force attack, on the assumption that all 32MX150B devices are identical, would be to capture (via hardware) the data flow along these three lines. a small windows/linux/etc application could then 'play back' the captured conversation to achieve the task of programming using just a USB to serial bridge via the flow control lines. another, similar approach, would be to build a software simulation of the PICKIT3 (or preferably PICKIT2 if it would suffice), and capture the data flow as it occurred at the (virtual) pins of the simulated PICKIT's processor. the advantage here would be that a general-purpose software solution could be arrived at to convert a .HEX file into something usable. would the above ideas be any simpler than decoding the protocol? rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3659 |
It's an interesting idea but a PICkit3 clone is so cheap that I don't know who'd really be bothered! In case the timings are fairly critical, USB driven by an app on an OS like Windows could be "awkward". John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2289 |
a pickit3 clone is still us$30 or so, which is quite a fair bit more than the $5 chip that is being programmed. you need to put yourself in the shoes of a hobbyist who (1) might have limited access to any sort of electronics store, (2) might not be in a position to buy supplies on ebay. because the data is clocked, there should be no major issue of timing. the only tricky bit wrt timing may be getting the 32MX into programming mode. has anyone out there managed to program a 32MX150 using mplab 8 and a pickit2? it seems that a pickit2 is mostly just a pic18f2550, making it a good candidate for software simulation. rob :-) |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
David, Serge, the author of PIC32prog may help you... or you can study his sources. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
I've got my head around the protocol now and besides being a little complex, is not difficult. The SiliconChip pic programmer of a few years back used the serial port control lines (RTS) etc. and worked fine with hardware comm ports but was dreadfully slow with the usb to ser version, so I wrote a pic interface to receive jtag like commands and do the switching. I imagined with this project that we would use say MPLAB to create a .HEX file onto a SD card and use a MMite to interpret the HEX data and do the signal switching as necessary. Yes, that is the reason why I bought a PICKit3. However, this was a challenge thrown out by Rob and I see it as a way to expand the knowledge base of PIC users who simply wonder how it all works but weren't game to dive in. Timings are not critical (well not much) as just like I2C, all timing is done by the PG clock. I think MMite speed will still be less than the minimum critical. If we use a MMite for the programming engine, then putting the PIC32 into programming mode is dead simple. Thanks, I'll have a read up. To all, it might be easy just to buy something already made every time we need something, but what do we learn from it? This is a way to test the capabilities of a MMite and where it might lead to. The outcome may lead to other adaptations, or if it is simply to be a PIC programmer, it is then an easy matter to alter a few lines if MMite code should a new PIC device come along. Some times, we do things for the 'fun' of it. Just as Geoff built the MMite, there are plenty of PCs around which do the job better, but it was a challenge, and how much has been learnt from it? Lots! David M. |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I reckon that this would make a great project and something that would be appreciated by a lot of people. Let me know if you need my help. Geoff Geoff Graham - http://geoffg.net |
||||
| Page 1 of 28 |
|||||
 Print this page |
