 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 : Micromite MkII beta testers needed
  Page 5 of 8   |
|||||
| Author | Message | ||||
| Frank N. Furter Guru  Joined: 28/05/2012 Location: GermanyPosts: 946 |
Hi Plasma, your project is very cool! 
I'm very curious about your finished code!!! Frank |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
Ha ! Got it . Supports now maxled = mem - programmmemory ;) I need a bigger power station . Working on Hsv routine to get some cool colorcycles. |
||||
| aargee Senior Member  Joined: 21/08/2008 Location: AustraliaPosts: 255 |
Yes, Plasma, you're beating me to it. I was looking at writing a CFunction to support my Neopixels. When you're ready I'd be very interested to see your code. - Rob. For crying out loud, all I wanted to do was flash this blasted LED. |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Could below be a CFunction? Peter Carnegie (G8JCF) with the aid of Micromite MKII MMBASIC and CFunctions has wrestled his MMProg32RPC to program a PIC32MXF170 in about 10 minutes. Now a very useable time. He has previously commented that the baud rate, the Micromite – PC communications, did not influence the programming time greatly. But that was before he recently achieved an order of magnitude speed improvement utilizing Maximite MkII. I hope that Peter will respond to this tale to correct my stumbles, and will this proposal actually help? Being curious, I looked at the program that was loaded into the Micromite. No comments of course, or helpful white space. I think that Peter’s Micromite program is basically a loop that executes various ICSP functions upon commands from the PC. A single Input “”, RP,A(1),A(2),A(3) receives PC commands. An RP number between 1 and 10 determines which ICSP routine. A(1) and A(2) are digits representing up to 16 bits of data each, size limited to remain an integer. In the case of, for instance, “Transfer Fast Data” A(1) and A(2) are used together to give the 32 bits required. A message is transmitted to the PC upon the completion of each Micromite routine, in some cases returning 32 data bits as 2 numbers. The return likely initiates the next transmission from the controlling PC. I cannot find that the received variable A(3) is used now in the program. Although initially surprised at the data transfer method I understand more after investigating MMBasic Console async port ability. Although MMBasic numbers are binary, naturally formatted to shift through the ICSP connection, here it requires (on average) 5 ASCII characters to transfer 16 bits from the PC. For example 32769 gives H8000. Only 2 bytes are required for 16 bits if able to use 8 bits per async character. Now 5 message bytes are required instead of the current likely 13 characters. Though not including A(3). One byte for RP and 4 bytes for 32 bits of data, no commas required in the message to separate the fields. Received characters to be placed progressively into a 64 bit integer variable by “Poke” upon reception. Our received data does not require conversion from a string into a digit as performed by the “Input” command. A new Function is required for 8 bit asynchronous binary data transmission that can read and write the async port data registers directly and monitor the port status. Such a function will be simpler and quicker than the current “Input” or “Print” functions as no data conversion or formatting is required. An interrupt for each byte received, or packet of “variable” length, will allow reception from the PC whilst the previous command is being executed, rather than the program presently being stuck waiting for a message. To return the port to its normal (Console?) operation perhaps by executing an “Option”, or of course a reset. But not on CTRL C. Great if this could all be performed by a CFunction but it may not be possible to purloin the port hardware from the MMBasic program. For the programming application it is preferable that the Console port is used. The above method should speed operation, particularly by incorporating interrupts to enable reception to occur in the background. There will be other applications, although binary data is now more commonly transferred by SPI. Keith W. |
||||
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith Pretty good summary of how it currently works  You must have a lot of patience !
The MMBasic program is stored inside MMProgRPC and transferred down to the uMite when the user clicks Connect. The MMBasic program is a very heavily crunched version of the original source for maximum performance reasons. The crunching was done using the 'C' preprocessor MCPP to :- 1) translate all long symbols into very short symbols using #define's 2) eliminate the need for MMBasic Const and Variables wherever possible by using #define's and then by MMEdit to :- 1) eliminate all comments 2) eliminate all leading and trailing white space In terms of speedup at the serial port level, In debugging I use COM1 (so that I can see errors/debugging info on the console) and run the serial port at 230,400 bps, ie 6 x faster, and it makes almost no difference to the overall programming speed. I understand what you say about transferring stuff in binary compared to transferring stuff in Ascii, but :- a) the console port was/is intended primarily for ascii, b) debugging serial binary transfers is a lot more difficult c) Ascii eliminates any code representation differences between the PC and MMBasic. The reason I don't switch in to 230,400 bps for production is that I'm not sure how to perform the equivalent of a full reset using s/w, ie how do I reliably put the uMite console back to 38400 afterwards - I don't think people would like it if I left their uMite at 230,400 bps if something went wrong ! The really important speed up will happen when I transfer the PE_ROW_PROGRAM function from the PC into the uMite - PE_ROW_PROGRAM is where the programmer spends virtually 100% of its time when programming. For a 170F a row is 32 x 32 bit words. Each 32 bit word requires a call to XferFastData. So if instead I transfer the 32 x 32 bit words directly to the uMite, and then in the uMite, I implement PE_ROW_PROGRAM as a CFunction, the speedup should be quite remarkable. So why haven't I done it yet ? The CFunction is the easy bit, the harder bit is passing 32 x 32 bit words over the console link to the uMite - not that hard really, I just have to have the will to code it up  Also as one moves up the PIC32 chip range, the ROW size increases to 128 x 32 bit words for MX3/4/5/6/7 devices and 512 x 32 bit words for MZ devices meaning that I can't just implement a single solution.
You correctly observed that 32 bit quantities are passed around as a pair of 16 bit numbers. This mechanism is a hangover from the days before MMBasic had 64 bit integers. I just have to convert/update the code to take advantage of 4.6. (again will power is the blockage !) Now that I have a reasonably quick working 4.6 based programmer, and 4.6 is out in the wild, I'll turn my attention to properly optimising the code for 4.6. Peter The only Konstant is Change |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
Hmmm... I'm glad you two seem to know what you're talking about and I can see why this is going to be useful. Pity I don't understand it all better but I am enjoying following the thread. Greg |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Thank you for your answer Peter. I now seem to think about this project as an exercise, it has passed the usable stage. Of cause my thinking is influenced by my experience. In a project while building a digital oscilloscope I was forced into binary from hex characters to give an acceptable refresh rate. I agree that being able to “read” the comms while debugging is a fine aid and, without pressure otherwise, is recommended formatting. I hope that you do continue to pursue the quest. If you can achieve the performance that you are suggesting it will be very fulfilling. Is it that you now have too many projects to think about? Keith W. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@paceman
Keith I'm just all "coded" out right now ! I've done a couple of months now of intensive coding and my brain needs a rest for a little while. I do intend to finish up but I have to admit that the incentive to do it now is somewhat lessened because MMProg32RPC works 'good enough' ! Hopefully in the next couple of weeks, I'll release a newer, much faster MMProg32RPC. Thank you for being such a co-operative partner in the endeavour to produce a PIC32 programmer which programs another PIC32, without your continued interest and valuable insights, I'm not sure if I would have kept/keep persevering. Many thanks Peter The only Konstant is Change |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
Hi Peter , After writing some cfunctions i have a idea for your Generator. Is it possible to export the selected function into The clipboard? But without the Tab in the front of the Data? So you can write a Function and import it to the Editor without extra open the .bas File. Please exclude the Tab ( ok it looks bad now) but for every tab the editor add a " " also so you get a line too long error if you have much Datas. Thx |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith, Bo, Jeff and others. A new version of MMProg32RPCII is available for download from http://www.g8jcf.dyndns.org/mmbasicmkii/MMProg32RPCII.html . This version has the PE_ROW_PROGRAM function moved across to the uMite and implemented as a CFunction. This version will program 192 KBytes in about 2 mins 21 secs with 230,400 bps console speed - use Option Baudrate 230400 to set the uMite's Console baud/bit rate. A further improvement in speed to sub 2 mins is expected when MMBasic 4.6 goes Gold. Please give this version a whirl and let me know how it goes. Peter 
The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@Plasma When CFuncGen generates the CFunction(s) in addition to writing the CFunction(s) to the .bas file, CFuncGen ALSO places the text of the CFunction onto the Windows Clipboard ready for the user to do Ctrl+V to paste the text onto the end of the user's MMBasic program. Re the indent/tab for the CFunction lines, which "Editor" are you referring to please ? I use Notepad++, PSPad, and MMEdit, and none of them complain about too long lines Each CFunction line when generated by CFuncGen is 1+(8*8)+8=73 chars long, ie TAB, 8 x 8 hex digits, 8 spaces, ie CFuncGen generates lines which are less than 80 chars so I'm puzzled why your editor should be complaining. OK ? Peter The only Konstant is Change |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
Haha i never test this before , but if clipboard Ready so it cool , thx I mean teraterm , if i copy the function from the .bas file and insert the file in teraterm i get an extra space after every tab. Looks like Cfunction blah Data. Data data Data Data Data Data data dat Datat data data --- line too long |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
its formated 
Ok so Cfunction Tab , space data Tab , space ,space data And so on |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
i have noticed the above-mentioned 'automatic indenting' that the micromite editor does if pasting in text from the windows clipboard, where it creates quite a mess. when pasting from windows it is also necessary to add an end of line delay in teraterm to give mmbasic time to digest each line. geoff: how practical would it be to have a function key in the editor toggle on/off automatic indenting? at the same time a teraterm keyboard macro could be created to enable a teraterm key sequence to turn on/off the end of line delay. if indenting on/of was effected by a control character then the whole process could be controlled by teraterm. cheers, rob :-) |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
Good idea but i think geoff is busy atm, so i ask peter for a workaround. And yes i need 1 ms for char and 1200 for a line in serial settings But i can live with it. I written format and copy to clipboard also to workaround this but i think without extra Programms its all easyer . |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@Plasma I've never used the built in Edit function in MMBasic. Anyway I used PUTTY and tried what you do, and I do see the mess that is created. I do think the problem may be that MMBasic can't accept the lines as fast as they are being pasted, and/or is dropping characters. I don't think that anything I could do will solve the Paste problem. I tried pasting in 10 short lines of text from notepad (no tabs) into Edit in PUTTY and again what a mess. Have you noticed that if at the MMBasic Prompt you do Autosave<crlf>Ctrl+V<Ctrl+Z> there is no problem ? I would really recommend that you give MMEdit a go
Peter The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith re MMProg32RPCII Programming time for 191 KBytes, ie Beta 20, is down to 1 min 13 secs at 230400 bps ! I wonder if I can get it under the 60 sec mark ? Peter The only Konstant is Change |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6268 |
The MMBasic editor does auto-indent. It gets it's indent position from the first non white space character on the previous line. When a line of text with leading white space is pasted in, those new leading white space are added to the indent. In MMEdit I had to strip any indents for some transfers to prevent to extra indenting. The speed of entering lines in TeraTerm is easing controlled and is not the problem here. Jim VK7JH MMedit |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Peter. Yes, your latest release version works. I had a problem at 230400 baud, at this rate my Micromite will not communicate at all and at 115200 still with a few errors. Most likely due to my use of a venerable MAX232 chip, seems only useable to 120 Kbit/s. I will look around for a faster version chip, I think will find one among my bits? The good news is that it programmed MX170 MKII V4.6 B20 in 2:14 at 57600 baud and still only 3:06 at 38400 baud. This using a Maximite programmed to B20. Peter this is fantastic progress. Keith W. |
||||
Oldbitcollector Senior Member Joined: 16/05/2014 Location: United StatesPosts: 172 |
Peter, I'm going to try your MMProg32RPCII this weekend, but I'm a little confused about the hook up. If I read this right, since I'm using an MX170 4.6 chip for programming a new MX170 4.6 (beta) then I need to hook the two chips together Pin 1 to pin 1, 4 to 4, 5 to 5? (MCLR is Pin 1, PGD is Pin 4, PGC is Pin 5) Then tie your program from the PC to the console pins of the originating chip. Have I got this right? Thanks Jeff My Propeller/Micromite mini-computer project. |
||||
| Page 5 of 8 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
