 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 16 of 28   |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Be sure to check the datasheet as I've a feeling the BL may not have the bitbang mode. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Mick, Yes I added DTR and the resistor as you've worked out. 19 mins!! Grr, that's faster than Linux (though I don't have USB3.) Thanks for your offer, very kind! I'm very interested in security (not to save money, just would like stuff I "control"). Your boards are probably beyond my ability to solder unless they're old type components, though. I limp by with hardware!! John |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
John, I dont know why you say that? the old code went from 53 minutes down to under 19 minutes.. using an i7 4770 box and USB3. I tried the new code on one of my USB 2 ports and whilst it started ... within seconds it started spewing out errors.. that was the same with my `native' USB2 and the USB on my USB3 hub. Bottom line is on a decent PC and USB 3 it is pretty fast and painless. Regards, Mick PS. I must say though, getting my `Dontronics `Buggy' cable to work again took me about 3 hours of hair pulling and tantrum throwing to get working again.. Next time I test your program I will do a full backup,,, it will be quicker in the long run.. Of course the `Buggy' cable is most likely a fake FT chip and is finicky on drivers (must be old early drivers to work) and Dontronics got stung by the supplier, hence the reason they were cheap.. I would seriously recommend getting the correct cable from Dontronics instead. I just re-read what I wrote, of course I didnt use the cable mentioned, as I used the BG TTL adapter, but it uses the same driver.. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
you may like to look at having an option to use the CBUS pins to talk to the PIC. pages 13-14 of the FT232R datasheet describes a "CBitBangI/O" mode for CBUS0..3 as: this may simplify drivers under windows, and (a bit of a long shot) remove some driver overhead with a possible small speedup. it could also make no improvement; i only just spotted it while browsing the datasheet. the FT232RL bridge pointed to on ebay in earlier posts (that i have ordered) does have the CBUS pins brought out - i don't know if other ones available also do. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
There must be something USB3 "likes" about the change because otherwise it's not a factor of 3 speed up (i.e. it's not sending a third of the packets, more like 2/3). It ought to work fine on USB2 so long as you have the 3K3 resistor as well as the various wires needed. I don't have USB3 so am using USB2 both on my Linux laptop and my dual-boot Linux/Win7 desktop PC. I am very impressed that USB3 can achieve 19 mins under Windows and wish I had USB3 to try with Linux! Thanks for helping!! (That goes for everyone else, too.) John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
CBUSn are what I'm using :) John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
i thought you were using DBUS, which are also the modem lines: TxD, RxD, nRTS, nCTS, nDTR, nDSR, nDCD, nRI. these are the lines talked about in your readme. whereas CBUS are (by default) configured for status LEDs, nSLEEP, CLKxx, etc. rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Sorry, yes, you're right, I read my notes badly :( The various pins seem to act as GPIOs. I didn't notice anything better about the CBUS ones. I literally just soldered a few pins and set the bit masks in my code. I might have used CBUS pins by chance, just as it appears I didn't use them by chance. It doesn't look to help but have I missed something? The trouble is that each ICSP transaction uses 4 clocks (so 8 state transitions) on the line that becomes the PIC32 PGC. Those 8 each need an individual USB packet (so, 8 in all). It also needs some data out (which may happen to be the same as the old data out so then doesn't need a USB packet) and sometimes data in (another USB packet, well 2 as one goes out to ask for the value and one comes back with it). Everything is built on top of the above, by sending bit serial data out and when wanted reading bit serial data in. Every bit involves those 8 transitions plus extra packet(s) for data. John |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
oh no, it is just a hunch i have. the fact that the serial/RS232 driver can co-exist with the CBUS driver suggests that there may be a different data path involved (in software). it may be faster, it may be slower, or it may be exactly the same. i'm assuming you have no delays in your code, with all delays occuring in the usb drivers? rob :-) |
||||
| Keith W. Senior Member  Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Hi John, Thank you for your answers to me/us. My reading of the ICSP timing diagram suggests that TDI may be safely set/cleared with the 1st clock rising edge and that TDS may be set/cleared with the rising edge of the 2nd clock. This method will remove two more USB transfers as you have suggested. I think that you have eliminated 2 transmissions by virtue of the resistor coupling method which removed the requirement to disable the PGD drive to the chip from the FTD232R. If only a reception flag/pulse were given from the USB chip upon receiving data a simple monostable could provide the ICSP clocks, thereby saving 4 more transmissions currently required to lower the clock pulse. Another output pin toggled upon those transmissions when a clock is required could trigger the monostable via an exclusive or gate; you can build the monostable with the gate. The FTDI chip rx LED output is essentially driven by a monostable upon reception but likely the time is too long for our purpose. Does the LED still work in bit bang mode? I had best purchase a module. Edit: Just realised that with a monostable providing the clock there is a pin freed up to toggle!! Keith. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
I'll look at it some more - did you mean TMS instead of TDS though? Because I already drop USB packets where TDI/TMS haven't changed (i.e. the value for PGD hasn't changed), combining packets will save less than might first appear but is worth looking into. There are spare pins, but I haven't really had an obvious use for them... I expect the LED(s) still work but am not sure. I'd consider a very simple external circuit but would prefer to avoid it as things rapidly head to the point where a PICkit may as well be bought. I wasn't wonderfully keen on the 3K3 resistor as it's just another thing to forget / put in the wrong place plus not everyone has resistors (I have, but among software people almost no-one else I know has - scary or what...). The only software delays are a few where Mchp require them, such as during chip erase, but there aren't any at all in the often-used paths. (The USB is so slow that none are needed!) (Actually, there are some delay functions so that the code can move to be native but they're irrelevant with USB.) I can't actually meet at least one max time spec but it seems not to be a max. I've ignored it for so long that I'm now unsure which! I think it's P20 (aka TMCLRH). I suppose in theory it might do something bad internally like resetting a state machine but it seems to be fine. John |
||||
| JTR0701 Regular Member  Joined: 10/07/2013 Location: AustraliaPosts: 71 |
Fantastic effort to get this going John. I knew all a long that it was not going to be a cake walk and you have done well to see it through. It is possibly the most impressive thing I have seen done with a FTDI chip given the complexity of the programming protocol. Yeah, congratulations. - Jim |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Jim, thanks! John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Another version - this outputs data (TDI/TMS) at the same time as driving CLK (PGC) high. For me, Linux went from 30 mins to 28 mins and Win7 from 58 mins to 54 mins. 2014-08-17_211335_ftdipic32.zip I've had a thought: how do the various pins on the target PIC32 (PGC & PGD) and on the FT232R board come up on power on? Is there a risk any are driving each other in bad ways? There's only the one 3K3 resistor to prevent possible bad things. John |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
John, Thank you for latest effort. Regarding your concern with the initial state of the pins, I think it normal that pins are configured as inputs at reset until programmed otherwise. This is likely the case with the subject chip, and the FT232R DSR and DTR connected via the 3K3 resistor are thereby protected. Noting the time saved by eliminating two more USB transfers of about 7% when they would represent about 20% + of the transfers hints that eliminating a few more will not see a dramatic improvement. I had prepared to post yesterday a simple circuit that would enable elimination of 4 more transfers but had hesitated as it adds complexity (although just 2 low cost chips) for no substantial gain. I will buy a FT232R module as cannot try it yet. You had earlier reported some “failures” when programming, has that improved? Something under 1 hour running is time for a coffee break. Keith. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Keith, I think it's low (~7%) because so many of the data bits are the same as the previous data bit and I already optimised out (dropped) the USB packet in that case. Cutting 4 transfers should be a major saving. It's possible I have suitable chips as I bought a number to play with so go for the circuit :) I have 74HCT00, 74HC08, 74HC14, 74HC74, 74HC125, 74HC595 and 74HC4040 & CD4066 (also resistors and some small signal transistors; forgot to buy caps!). I've not had more of the failures (the -v verify was picking them up) so I think it was just a loose wire. I have du pont wires from FT232 board to PIC32 target, both then plugged into a USB hub (unpowered) and a USB extension cable that I plug into laptop or desktop PC. It's a lash up... John |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Well it was a cold wet day. Enclosed is a quick circuit for a complete Four Phase ICSP sequencer circuit. Not tested. Is the time saved in programming worth the effort? Just four easily obtained and inexpensive chips, though a circuit board would add cost. The circuit retains the 3K3 resistor to protect the chip output pin as not worth adding a tri state gate. The Latch added to the TDO read circuit makes reading asynchronous to the clocking; TDO can be read any time after the short clocking delay up until the next sequence. If the clocking oscillator ran at about 5 MHz perhaps about correct to try. I hope that the HCMOS will work at 3.3 volts. This would only require USB transmissions to: - a/ Send TDI and TMS and trigger the four clocks with one transmission, requires one extra bit from FD232R. b/ Read TDO if required, hopefully one but perhaps two transmissions. 2014-08-18_080008_Four_Phase_ICSP_Driver.pdf If you are interested in the circuit I will build and test it? Note that transitions on DCD to high or low triggers the sequence, to save transmissions. But this seems strange so have suggested 2 transitions with the latch clocking on the positiove edge, and no mono. Keith. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Ooh, horrors, that's a bit complicated! Sorry, not simple enough :( I sketched some ideas using Tx fed into a counter (plus enough modem control lines for MCLR/ and to reset the counter, things like that) but it still seemed overly complex and that's when I fell back on GPIOs via USB. I also considered USBASP (ATMEGAxx) boards, which are crazily cheap, but I didn't like the idea of having to use an AVR-type chip to program a PIC32. Mick says the USB3 now takes around 15 mins so I'm buying a USB3 board to try that. John |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Looking at the ports on my laptop & desktop, and also the slots in the desktop... Is there another way? Firewire? PCI/PCIe (I suppose add a parallel port board)? PCIMCIA? SD/MMC? I see PCI parallel port board is under $4. I suppose the voltages will be wrong, not a mega problem but more mess. Doesn't work for a laptop. Some of the others I suspect will not work for Windows without a custom driver :( Anyone with ideas for something very cheap & very simple (which excludes writing any Windows device drivers!)? John |
||||
| bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
John, Sorry I have tried to do a good accurate time for you with your new one.. I burned the sequence 5 times and every time I neglected to look at the screen as it finished. I can state though that it is less than 15minutes on my USB3 i7 4770 running windows 8.1 (dell XPS8700) I dont know if it uses any GPU speedup but it has an R9-270 video as well. Regards, Mick PS. Personally if that is typical of reasonable PCs then I dont feel you need to drill down further.. Anything less than an hour is good I feel but 15minutes is perfect. I have never had a failure with your latest versions (with resistor) on this PC. I also can confirm that a blank chip (straight from the tube from MicroChip programs your method and I can verify it with my PicKit3. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| Page 16 of 28 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
