Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 19:04 17 Sep 2025 Privacy Policy
Jump to

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 23 of 28    
Author Message
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4071
Posted: 06:48am 08 Sep 2014
Copy link to clipboard 
Print this post

  WhiteWizzard said   It's in the post John, along with a 28-pin socket in case you needed one!
Posted 1st class, so will be with you latest Tuesday (hopefully!)

WW

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!Edited by JohnS 2014-09-09
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2948
Posted: 11:51am 08 Sep 2014
Copy link to clipboard 
Print this post

@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 Kingdom
Posts: 4071
Posted: 11:59am 08 Sep 2014
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 676
Posted: 01:40pm 08 Sep 2014
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2948
Posted: 01:52pm 08 Sep 2014
Copy link to clipboard 
Print this post

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: Australia
Posts: 2956
Posted: 02:08pm 08 Sep 2014
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 676
Posted: 02:21pm 08 Sep 2014
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 676
Posted: 02:40pm 08 Sep 2014
Copy link to clipboard 
Print this post

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 Zealand
Posts: 2447
Posted: 04:40pm 08 Sep 2014
Copy link to clipboard 
Print this post

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 :-)Edited by robert.rozee 2014-09-10
 
Keith W.
Senior Member

Joined: 09/10/2011
Location: Australia
Posts: 118
Posted: 06:01pm 08 Sep 2014
Copy link to clipboard 
Print this post

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: Thailand
Posts: 2209
Posted: 06:22pm 08 Sep 2014
Copy link to clipboard 
Print this post

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.

Edited by TZAdvantage 2014-09-10
Microblocks. Build with logic.
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4071
Posted: 09:03pm 08 Sep 2014
Copy link to clipboard 
Print this post

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: Australia
Posts: 290
Posted: 11:34pm 08 Sep 2014
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 4071
Posted: 12:00am 09 Sep 2014
Copy link to clipboard 
Print this post

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: Thailand
Posts: 2209
Posted: 12:02am 09 Sep 2014
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 4071
Posted: 12:21am 09 Sep 2014
Copy link to clipboard 
Print this post

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.

JohnEdited by JohnS 2014-09-10
 
Keith W.
Senior Member

Joined: 09/10/2011
Location: Australia
Posts: 118
Posted: 02:03am 09 Sep 2014
Copy link to clipboard 
Print this post

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.
Edited by Keith W. 2014-09-10
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4071
Posted: 02:32am 09 Sep 2014
Copy link to clipboard 
Print this post

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.Edited by JohnS 2014-09-10
 
G8JCF

Guru

Joined: 15/05/2014
Location: United Kingdom
Posts: 676
Posted: 04:12am 09 Sep 2014
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 676
Posted: 04:19am 09 Sep 2014
Copy link to clipboard 
Print this post

@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
 
     Page 23 of 28    
Print this page
The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025