TheBackShed.com

Forum Index : Microcontroller and PC projects : Free pic16f1455 USB/Serial PIC32 prgmer

Page 3 of 3

Author

Message

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 06:46am 28 Jan 2016

Copy link to clipboard

Print this post

Can you confirm that you are using the same MM with the CP2102?

I also can not get higher then 115200 and i tested with a FTDI and MCP2200 both commercial products. This gave me the impression that 115200 was the maximum a MicroMite could do.

Now i know better. :) I'll try to figure out why, but unfortunately can not work on it at the moment as i am on a job.

Thanks for taking the time to test!

Microblocks. Build with logic.

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133

Posted: 07:05am 28 Jan 2016

Copy link to clipboard

Print this post

Hi Jean,

the programmer is also working (pic32prog.exe v.2.0.186).

Previously I've tried a older pic32prog.exe v.2.0.157, which did not work.

------------------------------

I think maybe your programmer will also work with Jims MMfFlash ?

Tested: works! Takes 147sec (Arduino mode).

Thanks again for your great job!

Michael

EDIT:

MicroBlocks said Can you confirm that you are using the same MM with the CP2102?

Yes! BP170/MM v5.1 (and earlier)

Edited by twofingers 2016-01-29

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 07:16am 28 Jan 2016

Copy link to clipboard

Print this post

Great to hear. I am a bit puzzled by the programming time though.
on my machine (surface pro 3 with Intel i5/4GB, windows 10) i got this
[code]
C:\Users\mail\Dropbox\Micro Blocks\Projects\BreadBoard\U2SP5\Software\pic32prog>
pic32prog -d ascii:com10 MMV4.7B32.hex
Programmer for Microchip PIC32 microcontrollers, Version 2.0.174
Copyright: (C) 2011-2015 Serge Vakulenko
(ascii ICSP coded by Robert Rozee)

Adapter: .. OK1 OK2 - ascii ICSP v1E
Processor: MX170F256B
Flash memory: 256 kbytes
Boot memory: 3 kbytes
Data: 258692 bytes
Erase: (110mS) done
Loading PE: 1 2 3 4 (LDR) 5 6 7a (PE) 7b 8 v0301
Program flash: ################################################## done
Program boot: ####### done
Verify flash: ################################################# done
Verify boot: ####### done
Program rate: 7595 bytes per second

total TDI/TMS pairs sent = 3723775 pairs
total TDO bits received = 957768 bits
total ascii codes sent = 1190023
total ascii codes recv = 329262
maximum continuous write = 452 chars
O/S serial writes = 111528
O/S serial reads (data) = 29940
O/S serial reads (sync) = 10
XferFastData count = 58902
10mS delays (E/X/R) = 11/0/0
elapsed programming time = 0m 35s
[/code]

Microblocks. Build with logic.

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8590

Posted: 07:40am 28 Jan 2016

Copy link to clipboard

Print this post

Loading 5.1 to MM+, W10, I5-3470 Desktop, with Microblocks PIC16F1455 code

There is something very odd going on but there is no doubt Microblock's PIC16F1455 holds all the speed records when used as a programmer

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133

Posted: 07:41am 28 Jan 2016

Copy link to clipboard

Print this post

MicroBlocks said Great to hear. I am a bit puzzled by the programming time though. on my machine (surface pro 3 with Intel i5/4GB, windows 10) i got this

Hmm, this machine should be much slower (Windows Experience Index 6.5 Win7), but I would not expect such a influence.

Can you use please the pic32prog.exe v.2.0.186 (the latest, I guess)? Or send me a link for Version 2.0.174?.

EDIT:
As Peter has shown it's probably the higher PC speed.

No need to test the 2.0.174!
Edited by twofingers 2016-01-29

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 07:53am 28 Jan 2016

Copy link to clipboard

Print this post

I think the biggest difference is the PC's USB port. The newer ones (3.0) are much faster.
The programming function is not influenced by a baud rate. The USB has handshaking and sends packets as quickly as it can.

The best thing however, even with a 2 minute programming time is that you not need to connect/disconnect wires when developing. The latest laptops have only one USB port so that makes it also more convenient.

@Peter, Yep that is pretty quick! How does it compare to a pickit3?
Edited by MicroBlocks 2016-01-29

Microblocks. Build with logic.

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8590

Posted: 08:02am 28 Jan 2016

Copy link to clipboard

Print this post

Quote How does it compare to a pickit3?

Faster

Pickit3: 40 seconds for MM+ 5.1

PS my times are with a standard USB 2.0 portEdited by matherp 2016-01-29

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133

Posted: 08:27am 28 Jan 2016

Copy link to clipboard

Print this post

MicroBlocks said I think the biggest difference is the PC's USB port. The newer ones (3.0) are much faster.

Hmm, I can not confirm that. I got the same results on USB 3.0.

If I use Jims MMFlash (MicroMite Mode) I get slightly slower results (147/120) compared with command line mode.

MicroBlocks

Guru

Joined: 12/05/2012
Location: Thailand
Posts: 2209

Posted: 07:44pm 28 Jan 2016

Copy link to clipboard

Print this post

Maybe it is windows 10. :)
In win10 the driver is 64bit and automatically loaded and is not from microchip. Maybe that is the difference.

Microblocks. Build with logic.

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5907

Posted: 08:34pm 28 Jan 2016

Copy link to clipboard

Print this post

twofingers said
If I use Jims MMFlash (MicroMite Mode) I get slightly slower results (147/120) compared with command line mode.

The only difference between the two modes is in Micromite mode, I send RUN first.
Then in both modes, I had over to pic32prog.

pic32prog does all the work.

Jim

VK7JH
MMedit MMBasic Help

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133

Posted: 02:39am 29 Jan 2016

Copy link to clipboard

Print this post

TassyJim said

twofingers said
If I use Jims MMFlash (MicroMite Mode) I get slightly slower results (147/120) compared with command line mode.

The only difference between the two modes is in Micromite mode, I send RUN first.
Then in both modes, I had over to pic32prog.

pic32prog does all the work.

Jim

Hi Jim,

I'm not criticizing your program. I made a observation (see screenshots). But I have no idea why this delay is happen.
I like your wrapper program!

Regards
Michael

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2290

Posted: 03:23am 29 Jan 2016

Copy link to clipboard

Print this post

twofingers said

TassyJim said

twofingers said
If I use Jims MMFlash (MicroMite Mode) I get slightly slower results (147/120) compared with command line mode.

The only difference between the two modes is in Micromite mode, I send RUN first.
Then in both modes, I had over to pic32prog.

in my delphi gui wrapper i use the following line to launch pic32prog:

if CreateProcess(nil, PChar(ACommand + ' ' + AParameters),
@saSecurity, @saSecurity, True, NORMAL_PRIORITY_CLASS,
nil, nil, suiStartup, piProcess) then
begin
[...]

where the 6th parameter (NORMAL_PRIORITY_CLASS in this case) specifies the priority at which pic32prog runs. if you have inadvertently selected a lower priority when creating the pic32prog process, it will run slower.

the available priority options include:
HIGH_PRIORITY_CLASS - time-critical tasks that must be executed immediately
IDLE_PRIORITY_CLASS - process whose threads run only when the system is idle
NORMAL_PRIORITY_CLASS - indicates a normal process with no special scheduling needs
REALTIME_PRIORITY_CLASS - real-time processes that need to preempt all other threads

i don't know how you are creating the child process in PureBasic, but there should be a priority parameter specified somewhere. the default, i believe, is 'idle', which may explain the slower results. note: the above is all windows-specific.

cheers,
rob :-)Edited by robert.rozee 2016-01-30

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133

Posted: 04:38am 29 Jan 2016

Copy link to clipboard

Print this post

Hmm,

seems the MMFlash generates higher CPU load.

This is the pic32prog (command line/batch file):

and this Jims MMFlash:

Maybe under certain circumstances (background programs) the CPU uses 100% on my system. This may explain the differences.

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2290

Posted: 03:10pm 29 Jan 2016

Copy link to clipboard

Print this post

you could have a look under the 'processes' tab, click on 'CPU' to sort the list based on %CPU usage, and check to see what process (pic32prog or mmflash) is sucking up all the computrons. it is possible mmflash is looping tightly (rather than waiting blocked) for pic32prog.

you might like to give this a try and see if the performance is any better:
2016-01-30_010349_P32P_GUI_r3_lite.zip

usage is pretty self-evident - click on the 'select file' button to select your .hex file, then click on 'flash PIC32' to flash your pic. it should work with either nano or 1455 based programmers, or with a pickit2 (USB HID) programmer.

cheers,
rob :-)

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5907

Posted: 05:48pm 29 Jan 2016

Copy link to clipboard

Print this post

The high CPU load is probably due to MMFlash polling pic32prog to see if there is any output.

I forgot to check for that. I can slow it down a bit if needed.

As soon as life here returns to something resembling normality, I will check.

Jim

VK7JH
MMedit MMBasic Help

matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8590

Posted: 11:16pm 29 Jan 2016

Copy link to clipboard

Print this post

Quote The high CPU load is probably due to MMFlash polling pic32prog to see if there is any output.

No issue on multi-CPU machines but probably a problem on single CPUEdited by matherp 2016-01-31

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133

Posted: 12:19am 30 Jan 2016

Copy link to clipboard

Print this post

@Peter

matherp said [...]
No issue on multi-CPU machines but probably a problem on single CPU

No! Sorry, I'm using a dual core system (for this). A single core system with XP did it in the same time = 120sec (CPU load ~10% for PIC32prog.exe).

@Robert

robert.rozee said you could have a look under the 'processes' tab, click on 'CPU' to sort the list based on %CPU usage, and check to see what process (pic32prog or mmflash) is sucking up all the computrons.

CPU LOAD
PIC32prog.exe = 0%
MMFash.exe = 50% (avg. 47.5%) 50% means 100% for one core!
P32P_GUI = 0%

robert.rozee said you might like to give this a try and see if the performance is any better:
2016-01-30_010349_P32P_GUI_r3_lite.zip

Your P32P_GUI works very well with no measurable load!

@Jim

Again: this is not a issue for me! It doesn't matter if I have to wait 120s or 150s. Just something remarkable.

Michael

robert.rozee
Guru

Joined: 31/12/2012
Location: New Zealand
Posts: 2290

Posted: 12:44am 30 Jan 2016

Copy link to clipboard

Print this post

a sustained 50% load indicates something is going very wrong - unless carrying out number crunching of some sort, this should not be anywhere near that high for a simple gui application.

jim, your code should contain something like this:

if CreateProcess(nil, PChar(ACommand + ' ' + AParameters),
@saSecurity, @saSecurity, True, NORMAL_PRIORITY_CLASS,
nil, nil, suiStartup, piProcess) then
begin

try CloseHandle(hWrite) except showmessage('unable to close hWrite') end;

repeat
Running:=WaitForSingleObject(piProcess.hProcess, 100);
Application.ProcessMessages();

repeat
try
if PeekNamedPipe(hRead, nil, 0, nil, @BytesAvail, nil) and (BytesAvail<>0)
then LB:=ReadFile(hRead, ReadBuffer[0], sizeof(ReadBuffer), BytesRead, nil)
else LB:=false
except
LB:=false
end;

if not LB then BytesRead:=0 else
for I:=1 to BytesRead do
begin
// process output from pic32prog
end;

until BytesRead<sizeof(ReadBuffer)

until (Running<>WAIT_TIMEOUT) or KILL;

GetExitCodeProcess(piProcess.hProcess, DWORD(ExitCode));
if KILL then TerminateProcess(piProcess.hProcess, 0);

try CloseHandle(piProcess.hProcess) except end;
try CloseHandle(piProcess.hThread) except end
end;
[...]

essentially you are using a call to WaitForSingleObject to cause your process (mmflash) to sleep for 100mS timeslices while it waits on pic32prog. between each slice you process characters from the pipe, and terminate the whole thing when WaitForSingleObject returns prematurely (due to pic32prog having exited).

the variable KILL is there so that a button in your gui labelled 'halt' can be used by the user to terminate things if something goes awry. the periodic calls to Application.ProcessMessages allows the gui to keep functioning throughout. no doubt PureBasic will have some equivalent.

cheers,
rob :-)
Edited by robert.rozee 2016-01-31

TassyJim

Guru

Joined: 07/08/2011
Location: Australia
Posts: 5907

Posted: 10:11am 30 Jan 2016

Copy link to clipboard

Print this post

In PureBasic we do

While ProgramRunning(Compiler)
If AvailableProgramOutput(Compiler)
Output$ + ReadProgramString(Compiler) + Chr(13)
EndIf
Wend

That is taken directly from the PB help file.

I should have added a Delay(20) into the loop and the help file should have the delay as well but that's no excuse - I know the delay should have been there.
Even a 1 ms delay makes a huge difference.

pic32prog's output is not that simple to use but the process is the same. I forgot the delay.

The attached should be much better but I am still not able to test it.
2016-01-30_200828_MMflash_exe.zip

Jim

VK7JH
MMedit MMBasic Help

twofingers
Guru

Joined: 02/06/2014
Location: Germany
Posts: 1133

Posted: 10:38am 30 Jan 2016

Copy link to clipboard

Print this post

Hi Jim,

thanks for your efforts.

But it seems not to make any difference (CPU load 50% = 100% for one core).

Success!
Programming completed in 147.634 seconds

Michael

Page 3 of 3

Print this page

To reply to this topic, you need to log in.