 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 15 of 28   |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
bigmik - I'm wondering why yours fails. Does it say anything or what? With -R and -v together does it not skip lots - more quickly but still slowly - and then slow even more but continue? If not, what does it do? It may be crosstalk, probably from PGD on to PGC as that would upset things greatly. There's some info here I've seen a trick circuit which connects an extra wire to PGD (and there's a resistor). Then the idea is that the existing one is In (or Out) and the extra is Out (or In). So, a lot of USB packets would be avoided. It would leave DSR driving PGD but through a resistor, and add one extra pin to the FT232 that would be an input from PGD. The idea is to use a resistor that the PIC32 won't mind when both it and the FT232 are driving PGD. But... is it OK and what value resistor (I've seen 10K or 4K7 suggested)? I'm no hardware guy so choosing is beyond me. Currently every time PGD is to be read I need to send 3 USB packets: 1. set DSR as an I/P 2. read DSR 3. set DSR as an O/P So 2 USB packets would be avoided, often - very often indeed. John |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Hi John, I stopped the last test (at work) when it was about 85% done BUGGER... it took about 2hrs or so to get there but I think it may have been succsessful, I just didn't want to sit in the dark at a racetrack by myself and then go into the carpark to find my van up on blocks and the wheels missing.. 
I am just doing an erase on my home PC (the i7 4770) ... What I will do is change the wires around so that PGC and PGD are separated by GND that should minimise any crosstalk, Also I was using my laptop at work and they can get a bit iffy sometimes... Dont know why... Stay tuned.... This will be my first test on this PC, after fixing the wiring prob I had. mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Fingers crossed! The heart of the question on the series resistor: if one had: FT232's DSR <----> R <----> PGD of PIC32 is there an R where it's definitely safe for both DSR and PGD to be driving at the same time and what R is it if so? The R must still allow PGD to read the correct value from DSR and also allow DSR to see the correct data from PGD (when the software actually wants the value, which is not often). I could skip a lot of USB packets if such an R exists. I could skip even more if an extra FT232 pin is used: FT232's DSR ----> R ----> PGD of PIC32 FT232's xxx pin <-------- PGD I suppose it might be a different R since now it doesn't mess with the data from PGD. Ideas from anyone, please! John |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
John, I swapped the wires around.. Actually was easier to swap to put 5V between the PGD and PGC wires.. It has just hit 40% after only 17minutes.. it is rocketing along.. The other difference is I am using a USB3 port this time rather than USB2, but I would have thought that as you are `bit banging' it that the type of port wouldnt matter. Stay tuned.. Mick EDIT *** OK, it is now 00:18 and I am back at the DOS prompt.. it took a total of 53 minutes to burn... I will now test verify with my pickit 3 Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Wow. Well maybe USB3 means some delays vanish. (This is a kind of abuse of USB.) Must be rather late or do I mean early there! John |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Possibly, we will see how this one finishes and tomorrow I can try on usb2.. It is flashing a new `period/dot' every 3seconds where-as my laptop USB 2 was every 8seconds or so. I started it at 23:25 and it is now 23:57 and I am roughly at 64% Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
this is definitely the way to go. when PGD is acting as an input R will have no real impact and PGD will follow DSR. when PGD is acting as an output, it will only need to be able to at most sink/source 3v3 across R, while pin xxx on the FT232 reads PGD. the pins of the PIC32 can happily drive into a load of a few milliamps, so i would try a value of 3k3 for R. this represents a maximum source/sink current of 1mA, which is well within the specs. while being able to leave DSR permanently set as output, you also do not need to worry about DSR being left high or low - in either case the drive from PGD into R is so small that the level at the PGD pin will be unaffected either way. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Rob, thanks. Will have a play as I do have resistors LOL :) John |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Hi John, All, OK I successfully programmed using my cheap Chinese FTDI (clone) Banggood Clone Using my i7 4770, windows 8.1, it took 53 minutes and worked first go (after I rigged my wiring correctly.) I then tried it as a uMite and it worked as expected, then I did a verify with the PicKit3 and it verified successfully.. So all in all a great effort John, I will try in the morning to run it on my USB2 port to see if it is any different in speed. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Thanks! And good news indeed. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
The 3K3 resistor works a treat - thanks, Rob. I made some software changes, too. Linux micromite flash went from 43 mins to 30 mins. Windows 7 for me is 58 mins. Oh well. Here's a new version with a new How To (add the resistor) 2014-08-15_220827_ftdipic32.zip The command I used was: ftdipic32 -e -v micromite.hex (erases, then programs & verifies) John |
||||
| ajkw Senior Member  Joined: 29/06/2011 Location: AustraliaPosts: 290 |
I was about to try this when I found my FTDI cable does not have all the required pins, i.e. only has TX,RX, RTS & CTS, so I am one control line short. I have no hope of buying a board locally this weekend so the mind wandered. Is it possible to use a Maximite instead of the FTDI. i.e. USB to Maximite that has a, simple(?), program to take instruction from the PC or Linux Program and convert those instructions to a set of I/O pins? I am really quite keen to update my 2 Micromites on Mick's v1 board and also a unit I have from Zonker. I have been holding off buying a PicKit pending the excellent progress made in this thread. Now I write this I think my idea above may well be impractical but I thought I would post it anyway, you never know it may trigger another idea. I would be quite happy to test the Linux version once I sort out the hardware. Anthony. |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Hi Anthony, Are you in Melbourne? If so I have one you can pick up if you are keen. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Enthused by the progress and a small speed improvement may be possible. You may be using a “clock” routine similar to code that I posted earlier. In this subroutine the value of TDO is returned from the subject chip upon every sequence. However the value of TDO is not used after every “clock” and determining this value requires a USB transmission. Perhaps two transmissions are required where the PC requests FTDI chip status and then the chip returns it. Utilizing two “clock” routines, one that returns TDO and one that does not will likely give a slight speed improvement. I think that when transmitting data to the chip most “clocks” do not require TDO returned. Dreaming? I investigated the adding of a small hardware sequencer after the USB chip that will perform the CLK sequence, thereby eliminating many USB transmissions. If PCs still had hardware parallel ports the USB overhead would be eliminated. USB parallel port chips are available; though not as common (cheap) as the serial ports. Transmitting parallel MCLR, TDI and TMS bits with just one USB transmission to a USB parallel port, and then a hardware sequencer to create the required ICSP signals would surely speed it up. This will likely be as expensive as a PicKit3. Keith W. |
||||
| ajkw Senior Member Joined: 29/06/2011 Location: AustraliaPosts: 290 |
Many thanks Mick, on occasion I am in Melbourne but I live ~50km north of Newcastle in Port Stephens. Probably a bit far to Melb for a this weekend thing. Cheers, Anthony. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6302 |
This is excellent work. I have an FTDI FT232BL chip to try it on. I also have the same FT232RL as Mick. I will try and do a test in the next day or two. Jim VK7JH MMedit |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
JohnS Too late to edit my last post. Now find that FT232R chip may be used in Bit Bang mode where more bits are available for i/o. Are you using this mode which will enable elimination of some transmissions? I.e data and clock edge may arrive simultaneously. Seems that FT232R may be used more as a parallel port. Keith W. |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
John, Your new instructions in step 2 mentions DTR (this wasn't used in the old instructions), Is that a typo or is another pin being implemented? Mick OK I just did the burn with your new software and I think you have it right now. Burned in just under 19 minutes... Now that is very workable.. A big reward to you.. I don't know what I can offer you for your efforts but I am happy to offer you, if you want, one of my MuP PCBs or my, to be formally announced, (possibly tomorrow) MuP-VT (addon to MuP to give a VT100 interface), IO Panel (fully stand alone) or Security alarm (MuP add-on). Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Your board probably has the signals but soldering to the pins may be impracticable. (If you can, add DCD, DSR & DTR.) The snag is that "2-wire" ICSP needs 3 + GND. The 3rd is MCLR/. (I looked at ways round this e.g. using Tx but it's rather awkward.) MCLR/ needs 1s and 0s at appropriate times so can't just be tied to one level. Yes it can be done with a Maximite and in multiple ways. MOBI is part way through one. My code will work but would need adapting and first needs to settle down! I can readily provide a Linux version as it's what I use. (It's a pain having to use Windows.) Let me know if/when you want one. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Keith - the original with "simple" code didn't optimise the TDO but the newer one does. It helped but not a huge amount. (The code got uglier.) I'm using the bitbang mode. To send data & clock together is something I contemplated but with the timing lack of clarity in Mchp docs I wanted to get it all working before messing yet more! The core routine that slows it all down is the very one you've identified (now 2 variants: with or without TDO being read). I'm unclear exactly where it would be safe to send a data bit at the same time as a clock bit (which turns into an edge as it always changes state). In rough terms, it used to have something like 13 USB packets, reduced by 2 or 3 with the recent tweaks. (I also drop any TDI packet if TDI hasn't changed state.) Fairly often it is actually lots of CLK hi & lo packets with few data (TDI, TMS) ones. The best improvement would be to do multiple CLK states in a single packet i.e. trigger an external chip as you also say. John |
||||
| Page 15 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
