![]() |
Forum Index : Microcontroller and PC projects : simplest 32MX150 ICSP
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Arrived at lunchtime - brilliant! I was going to program it using a umite but realised I don't have a 3K bootloader ready for a umite and got fed up of that issue (for now). Decided a new tack. Made a variant of the (4-wire) program for the RPi. Had to slow it down a little as GPIOs are fast on the RPi. It programs the MX170 with Geoff's umite for a 170 in 11 secs. So, here's a howto & the (ARM Linux) program.2014-09-08_164736_rpipic32.zip Test away - seem to recall Anthony has a Pi... John BTW, am using the 170 in bigmik's MuP v1 - thanks Mick! |
||||
WhiteWizzard Guru ![]() Joined: 05/04/2013 Location: United KingdomPosts: 2948 |
@JohnS I might finally have a use for one of my RPi's!! ![]() I am away from home at the moment but will try this out tomorrow evening when I'm back. Seems like a nice quick time to program the PIC. By the way - I did program your MX170 with 4.5D (the one time I didn't need to!). Hope this didn't cause you any issues. WW |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
haha - I never checked! Sorry. 3 wires + Gnd. Power PIC32 other than from the RPi as they suck plenty as it is. Biggest hassle may be getting the hex etc onto the RPi (easy for me, it's on my net). John |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Just completed a 100% successful burn of "MX170 28-pin.hex" ie 4.5D, into a 28 pin 170F in 00:25:10 using a uMite running mmBasic. In my configuration there is a Windows PC program which handles all of the high level stuff like loading the .hex file, PE etc, and the uMite does the actual bit-bashing into the target PIC32MX chip. I will shortly release a single Windows executable which will download the mmBasic code to the uMite and then provide the user i/f to the user. The slow programming speed is entirely due to mmBasic and the time it takes to do the bit-bashing, eg the fundamental 4 phase ICSP clock operation takes about 679 uS per oTDO bit, so an XferFastData op takes around 35 mS, ie a ROW_PROGRAM op takes of the order of 32 * 35mS + O'heads =~ 1.25 seconds. Still, 25 minutes isn't bad and you just need a standard uMite with mmBasic - 4.5C or 4.5D will do - with a serial connection to the PC and away you go, ie the standard setup. More in the next few days. Thanks to @Mobi, @JohnS for inspiring me to have a go at this really interesting project. 73 Peter The only Konstant is Change |
||||
WhiteWizzard Guru ![]() Joined: 05/04/2013 Location: United KingdomPosts: 2948 |
Hi Peter, I take it that your 25m10s is based on CPU 48? If not (i.e. you are using default CPU 40 then it would be interesting to see how much quicker it would be. Great result regardless of CPU setting. ![]() WW |
||||
bigmik![]() Guru ![]() Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
Peter, Will speed improve if you crank up the baudrate to the PC? Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Phil Thanks for your kind words of encouragement, very much appreciated. I am using CPU 48, and I have really optimised the MMBasic code, eg single letter variable names, numeric constants wherever possible and so on. The code which actually executes is quite unreadable/unmaintainable !! but I have used MCPP.EXE (with MMEdit 3.18) to do all the compression so I have really easily readable/maintainable source code - see Pre-Processor I will be porting the MMBasic code over to ByPIC after I have released the MMBasic Beta for testing, and because ByPIC has provision for calling 'C' plugins, see http://www.bypic.co.uk/index.php/Plugin_-_Running_C and ByPIC Plugin Maker I expect the ByPIC version of the programmer to be much, much quicker, but of course one has to purchase a ByPIC chip from ByVAC rather than simply flash program a PIC32MX with one of Geoff's (free) .hex files (only a few cents/pence premium for ByPIC). 73 Peter The only Konstant is Change |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Mick The Baudrate I'm using is 230,400 BPS. The issue is that in MMBasic just to do SETPIN PGD,DOUT:PIN(PGD)=(CommandHi AND M):PULSE CLK,.01 PIN(PGD)=LOW:PULSE CLK,PULSEWIDTH SETPIN PGD,DIN:PULSE CLK,PULSEWIDTH PIN(CLK)=HIGH:I=PIN(PGD):PIN(CLK)=LOW which after #defines and other tricks ends up as SetPin 5,DOUT:Pin(5)=(B And M):Pulse 6,.01 Pin(5)=0:Pulse 6,.01 SetPin 5,DIN:Pulse 6,.01 Pin(6)=1:I=Pin(5):Pin(6)=&H0 takes approx 700uS. The communication time at 230,400 BPS is negligible compared to the execution time of MMBasic. Here is XferFastData code for example. Sub S1(A, B, C, D) Local I,E,K,L,M SetPin 5,DOUT Pin(5)=0:Pulse 6,.01:Pin(5)=1:Pulse 6,.01 Pulse 6,.01 Pulse 6,.01 Pin(5)=0:Pulse 6,.01:Pin(5)=0:Pulse 6,.01 Pulse 6,.01 Pulse 6,.01 Pin(5)=0:Pulse 6,.01 Pin(5)=0:Pulse 6,.01 Pulse 6,.01 Pulse 6,.01 Pin(5)=0:Pulse 6,.01 Pin(5)=0:Pulse 6,.01 SetPin 5,DIN:Pulse 6,.01 Pin(6)=1 E=Pin(5) Pin(6)=0 M=&H1 For K=0 To 14 SetPin 5,DOUT:Pin(5)=(B And M):Pulse 6,.01 Pin(5)=0:Pulse 6,.01 SetPin 5,DIN:Pulse 6,.01 Pin(6)=1:I=Pin(5):Pin(6)=&H0 M=M*2 E=E Or (I*M) Next K D=E SetPin 5,DOUT:Pin(5)=(B And &H8000):Pulse 6,.01 Pin(5)=0:Pulse 6,.01:SetPin 5,DIN:Pulse 6,.01 Pin(6)=1:E=Pin(5):Pin(6)=0 M=&H1 For K=0 To 14 SetPin 5,DOUT:Pin(5)=(A And M):Pulse 6,.01 Pin(5)=0:Pulse 6,.01 SetPin 5,DIN:Pulse 6,.01 Pin(6)=1:I=Pin(5):Pin(6)=0 M=M*2 E=E Or (I*M) Next K C=E SetPin 5,DOUT:Pin(5)=(A And &H8000) Pulse 6,.01:Pin(5)=1:Pulse 6,.01 SetPin 5,DIN Pulse 6,.01 Pulse 6,.01 SetPin 5,DOUT:Pin(5)=0:Pulse 6,.01 Pin(5)=1:Pulse 6,.01 SetPin 5,DIN Pulse 6,.01 Pulse 6,.01 SetPin 5,DOUT:Pin(5)=0:Pulse 6,.01 Pin(5)=0:Pulse 6,.01 SetPin 5,DIN Pulse 6,.01 Pulse 6,.01 End Sub I seems to me that in MMBasic, just for MMBasic to read a line (never mind execute it) probably takes 100uS or so. The need to be able to call C code/machine code for these kinds of time-critical operations is really important if MMBasic is to be able to handle a broad spectrum of applications - I think the uMite with its emphasis on embedded systems really highlights the performance deficit. 73 Peter The only Konstant is Change |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
Peter: that is quite an accomplishment! i do see you are still reading TDO with: Pin(6)=1
E=Pin(5) Pin(6)=0 whereas i am quite confident from figure 5-4 on page 12 of the 61145N datasheet that this can/should be done as: E=Pin(5)
Pulse 6,.01 my own interpretation of the timing diagram is that TDO is not stable after the rising edge of the 4th clock pulse, whereas it is stable between the 3rd and 4th pulse. i'm hoping you'll be releasing the un-optimized MMbasic code too, to enable a bit of tinkering and experimentation ![]() rather than using a PC application, have you thought about making the MMbasic program completely self-contained? ie, the user just runs TeraTerm (or similar) to connect to the 'programmer' micromite - your basic code prompts for any required information, then asks the user to upload the .HEX file via just streaming the text. this assumes that the .HEX file can be parsed in a single pass. flow control could be handled using XON/XOFF. another interesting option would be running your code on a modified version of MMbasic for DOS. rob :-) |
||||
Keith W. Senior Member ![]() Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Congratulations Peter, I had not believed that such a short time would be possible with MMBasic despite assistance by the PC. And 25 minutes is useable. However, many entries back on this thread (page 10) I posed to Geoff G. that a short ICSP routine could be built into MMBasic that would enable a substantial speeding of programming. He answered with: - “It could be done Keith but I am trying to avoid stuffing MMBasic with specialised functions with limited appeal. There are many, many similar functions that individuals would like to see but they would fatally clutter the language if I implemented them all. I think that it would be best to wait until the project is finished and we find out what the real programming time will be. Then we can look at speeding it up if needed. Geoff” Peter you have surely reached that stage. Please propose the function(s) that you would wish to have incorporated into MMBasic, likely just the 4 pulse ICSP sequence is needed to obtain a most worthwhile improvement? Hopefully with your success Geoff might now investigate an addition. To optimize the pins used for programming and the pulse time must be fixed in the code and perhaps TDO should be handled every call to enable use of just a single code routine. Your 10 microsecond pulse is safely conservative and you have proved that it works. Keith. |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
It would probably be a nice feature to add to the VT100 companion to the uMite. It already has the USB-Serial working, adding software that enables programming PICs would be great. Maybe OldBitCollector can use a propellor cog to build a programmer. :) If it can be ported, the programming algorithm is already figured out. It already has SD card that can hold the .HEX file and VGA/keyboard support to allow a UI for a programmer. Microblocks. Build with logic. |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
All I see as needed is a generalised CALL feature to go with POKE. It would be enough to load a plugin as a string. My similar PC-hosted app (again using a umite to flash another 'mite) to Peter's takes 40 secs currently but the problem is you have to get the code into that first umite. --- Anyone tried the RPi version yet? (Just 11 secs, including erase & verify.) John |
||||
ajkw Senior Member ![]() Joined: 29/06/2011 Location: AustraliaPosts: 290 |
John, Many thanks, it works a treat on the RPi. Very fast, I didn't time it but it is certainly around the 11 seconds. I am still somewhat amazed by the different speeds of the USB - Serial version across different hardware and OS's configurations but those hours are behind me now. Cheers, Anthony. |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Well, a bit sent on USB takes (say) 2ms but the RPi can do it in about 40ns. (The RPi will do about 22MHz square wave if you toggle an I/O pin flat out.) John |
||||
MicroBlocks![]() Guru ![]() Joined: 12/05/2012 Location: ThailandPosts: 2209 |
How do you access those GPIO pins to be able to get that speed. I thought that there would be a driver layer that slowed it down, that 22Mhz is impressive. Microblocks. Build with logic. |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
There is indeed a driver layer which normally should be used but I wanted to DIY for speed. Like many computers (but not all) the RPi has the I/O ports in the memory address space so I used Linux mmap API then access the locations directly. Not portable, but hey this stuff is only semi-portable anyway. Tight loop on PIC32 I got about 4MHz. You might say that a 700MHz RPi ought to do better than 22MHz I/O but there's stuff going on inside the chip to do with internal buses. The 1GHz Allwinner chips are slower at (GPIO-type) I/O in my experience, though not exactly slow. John |
||||
Keith W. Senior Member ![]() Joined: 09/10/2011 Location: AustraliaPosts: 118 |
John, A Call function used with Poke to place code into memory MAY be a great general solution. Geoff’s answer to this proposal (this thread of 22 May page 11) was that writing in assembler is too difficult for PIC 32s. Can the small routine be written in C with an assembler output that could lead to a result in machine hex code? It can be for a predetermined fixed location. Would anyone with the necessary skills care to comment? Perhaps Geoff adding the ICSP function though not so general a solution is the quickest/easiest solution, then later investigate the Call to code function with examples that could replace the ICSP. Unless it can be shown that several “Miters” are able to easily create the necessary code routines to employ a Call function? Keith. |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
Yes, of course. C to ASM/HEX/binary, no trouble at all. (By way of example, that adequately describes plugins for ByPic Basic on the PIC32. Just google bypic basic plugin or the like and see.) John. |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
For those interested in how a C plugin might be implemented take a look at http://www.bypic.co.uk/index.php/Plugin_-_Running_C and also http://www.g8jcf.dyndns.org/bypic/ One writes the function(s) in C using regular MPLab/X, compile as normal, then use my ByPIC Plugin Maker to generate the ByPIC 'CONSTANT'(s) statements (these are what are called plugins) which are then uploaded to the PIC32 BYPic just as any other BYPIC basic code. Here's an example of a very simple plugin //plugin.c //This file contains 2 very simple C functions to demonstrate the use //of ByPICPluginMaker.EXE to create plugins for use in the ByPIC environment //These plugins will be called from the ByPIC program TestPlugin.bas //The add function will add 2 numbers passed in from ByPIC //and pass back the result both as a result of the function call //and in a result variable provided by the caller // // //The code is deliberately not optimised so that the //assembly output is easy to follow // //The arguments are passed in from the ByPIC program via a pointer //The pointer points at a 3 element array of pointers which themselves //point at the ByPIC variables - see the snippet of ByPIC below // /* array of pointers to the arguments to the call dim argv(3) //The arguments themselves dim a, b, c //put the addresses of the args into the argv array argv(0)=?a argv(1)=?b argv(2)=?c //Values to be added a=1234 b=5678 //Result c=0 */ int add(char *c){ unsigned long *ip, *a, *b, *d; // pointer to the array of pointers to Longs ip = (unsigned long*)c; //Get pointer to first argument a = (unsigned long*)*(ip); //Get pointer to second argument b = (unsigned long*)*(ip+1); //Get pointer to third argument - result d = (unsigned long*)*(ip+2); *d = *a + *b; return(*d); } //The sub function will subtract 2 numbers passed in from ByPIC //and pass back the result both as a result of the function call //and in a result variable provided by the caller // //see function add above for details of argument passing // int sub(char *c){ unsigned long *ip, *a, *b, *d; // pointer to the array of pointers to Longs ip = (unsigned long*)c; //Get pointer to first argument a = (unsigned long*)*(ip); //Get pointer to second argument b = (unsigned long*)*(ip+1); //Get pointer to third argument - result d = (unsigned long*)*(ip+2); *d = *a - *b; return(*d); } // //We have to have a main() function to keep the compiler happy //even though we have no need of for BYPIC plugin purposes. // int main(){ } Within the ByPIC basic code one calls the plugin functions with a syntax such as //TestPlugin.bas //Program to test simple ByPIC plugins created using the ByPICPluginMaker //by Peter Carnegie // // function start() //array of pointers to the arguments to the call dim argv(3) //The arguments themselves dim a, b, c //put the addresses of the args into the argv array argv(0)=?a argv(1)=?b argv(2)=?c //Values to be added a=132 b=12 //Result c=0 //Variable for the result of the function call dim d d=0 //Call the plugin and pass in the array of pointers d=call( ?add, ?argv(0) ) print "Plugin returned ";print d;print "\n" print a;print " + "; print b;print " = ";print c;print "\n\n" //Values to be Subtracted a=456 b=123 //Result c=0 //Variable for the result of the function call dim d d=0 //Call the plugin and pass in the array of pointers d=call(?sub, ?argv(0) ) print "Plugin returned ";print d;print "\n" print a;print " - "; print b;print " = ";print c;print "\n" endf It really is very simple, no need to know any MIPS assembler, no messing with the linker, no adjusting of addresses etc, just regular PIC32 MX C programming. The performance improvements possible by calling the C generated assembler are quite astounding, well one is running pure compiled code after all. Peter The only Konstant is Change |
||||
G8JCF![]() Guru ![]() Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@RR OK, I'll give your suggestion a tryout right now ie E=Pin(5) Pulse 6,.01 instead of Pin(6)=1 E=Pin(5) Pin(6)=0 I have to admit that my reading of the various timing diagrams is not the same as yours, but if your reading is correct then that saves probably 100uS per clock instruction or about 20% so worth trying out. Peter The only Konstant is Change |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |