 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 6 of 8   |
|||||
| Author | Message | ||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Jeff The wiring is as follows NEW 28 pin 170 uMite 28 pin '170 1 (MCLR) 7 4 (PGD) 5 5 (PGC) 6 Console on 28 pin uMite goes to your PC. "uMite" refers to the chip running existing MMBasic 4.6 B16, "NEW" refers to your PIC32MX170F256B which is to be programmed. OK ? Peter The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith Thanks for the report  Excellent news.
You must be using a "real" RS232 serial port on your PC rather than a USB<-->TTL Serial converter ? Peter The only Konstant is Change |
||||
| Keith W. Senior Member  Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Hi Peter, Yes I am using a true RS232 port, if I loop the PC port I can Rx / Tx 230400 baud using TerraTerm, therefore not the PC. Motherboard purchased purposely with RS232 port. Likely next update RS232 no longer available? As you are thinking of a goal of 60 seconds I will post this, more on my old theme. The communication rate has now become more important. If you are still transferring the code as numbers please read my argument below. Unfortunately to gain any advantage will require some changes. But perhaps overall simpler? The baud rate is not the only factor with communication speed. Reducing the number of characters transferred improves speed, and also requires less processing time for characters. The application code to be programmed is in a PC file as printable hex ASCII coded characters, each representing a 4 bit nibble. More efficient data packing than number strings. By using hex characters, or my variation described below, messages may be fixed length with little message formatting required, again improving the transfer and processing efficiency. OK, we can transmit these hex ASCII characters directly from the file, but they come with a receive processing overhead. Explained by looking at the partial ASCII character coding chart below:- 
The characters assigned to Hex values are “0” to “9” and then “A” to “F” (or “a” to “f”). Transferred data bits may almost be obtained by removing / masking-off the 4 most significant bits of the ASCII code. Unfortunately past character “9”, jumping to “A” the least nibble bit pattern does not progress correctly. A correction is performed to the data nibble by testing that: - If the character has either of bits 01100000 set, then add 9 to the code and mask to retain the least 4 bits. An MMBasic function also can perform this but that is adding processing. By substituting the displayable ASCII sequential characters from “0” to “?” correction is not required upon reception. Only (perhaps?) masking to obtain the relevant least 4 bits. Conversion in the PC to the new characters for transmission may be simply performed by “And” character with $40, if the result is now not zero add 9 ($09) to the character, then “And” the result with $0F and “Or” with $30 to obtain our new character. Slightly complicated as the original Hex character may be upper or lower case. This processing is required only in the PC, which runs faster than the Micromite. The Micromite no longer uses “Input” or “Val” to convert numeral character strings into MMBasic binary format. In the application received binary data is shifted though ICSP to the chip being programmed. The received characters could be placed sequentially into a 64 bit integer. Thereby storing up to 8 required 4 bit nibbles placed alternately with 4 redundant bits. By using single bit shifts the least 4 bits may progress through ICSP and then jumping to the next least sig nibble by shifting by 4 bits. Alternatively the data may be converted into 32 bits of a 64 bit integer, or other methods. Keith W. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4034 |
Do you really want to go faster? How many chips are you programming? My RPi code runs much faster and anything with plenty of bandwidth should, too. That largely rules out using a serial port. John |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Johns, Why stop when improvements are still coming? The brief seemed to be to use a Micromite if any hardware. And think of the exciting journey that we have been on and what has been learnt and gained. Learning how to program PIC32 from the beginning using MMBasic. What a great demonstration of the Micromite’s ability. Perhaps CFunctions would not have been so urgently argued for or quickly demonstrated without the interest in this application? Keith W. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4034 |
It's not going to go much faster if serial port is used. BTW, anyone know that max baud rate Windows can generally set a COM port to? (I'm not much of a Windows user.) Also, can a umite CPU cope with it (even if MMBasic can't)? I expect I'd have tried my own code as a CFunction if the release had been publicly available. John |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Would it not be useful when you copy the flash contents of a micromite to another chip directly. No need for serial communication at all except when you need to use a newer version. Microblocks. Build with logic. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi JohnS According to the uMite manual, the console port and COM1 are limited to 230400 bps at CPU 40MHz. I run at 230400 bps without any flow control of any sort. As I said previously, at 230400 bps, 192KBytes is programmed and verified in 1 min 13 secs, ie 73 secs, I performed the programming run at least 8 times, and it was always reliably 73 secs +- 1 sec. Hi Keith There may be some mileage to be gained from tighter encoding of the 32 bit words being sent to the uMIte. Right now each 32 bit word is sent as 8 ascii characters with &H prepended, and a "," appended, so 11 ascii characters/32 bit word, which at 230400 is 10 * (1/230400) * 11 = 0.000477431 sec/word or approx 500uS. I will try removing the "&H" and prepend it instead at the uMite end - although a line of MMBasic seems to take around 60~100uS so I'm not sure that would gain me much if any time. Now as for encoding the words more efficiently; assume I have to send 0x3c0901fd, ie 00111100 00001001 00000001 11111101, then right now the PC sends 10 chars (in Hex) 26 48 33 43 30 39 30 31 46 44, so let's drop the &H, then the PC sends 33 43 30 39 30 31 46 44. I've read your post a good few times, and I still can't figure out what you mean - sorry - so could you please take the hex word above and show me how to encode it using your scheme ? But it still seems to me that 8 bytes will be sent from the PC to uMite for each 32 bit word, I must be missing something. Hi TZ MMProg32RPC will program ANY.hex file into a PIC32MX device. If all I wanted to do was clone a PIC32 into another PIC32, it would have been much simpler indeed. Also, another approach could have been to specify that the .HEX file to be flashed should be on an SD card, and then read in the .HEX file directly into the uMite and flashed it into the target PIC32. But, the goal was to keep it as simple as possible. Thanks Peter The only Konstant is Change |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Ah Peter, As you are now transferring hex characters and not decimal number strings you have passed 98% of my story. I understand about beginning the hex string with &H to prepare for VAL to do its job. My transcoding suggestion may gain little if you are currently able to convert a complete 32 bits from hex to binary easily / quickly, I did not think that it would handle so large a value. Well done large integers. But Val may cause MMBasic to think a bit? My suggestion of using different characters was an attempt to remove the need for any conversion as the character least nibble could be used immediately. Your hex data - 33 43 30 39 30 31 46 44 Is the character string ----- 3 C 0 9 0 1 F D My proposal is to make it -- 3 < 0 9 0 1 ? = Instead of ----- 0 1 2 3 4 5 6 7 8 9 A B C D E F for transmitting hex I suggest use - 0 1 2 3 4 5 6 7 8 9 : ; < = > ? Look at my ASCII table from earlier post. Now to obtain the correct binary data from the least nibble of the character VAL is not required. To explain further the hex character 44 or C is used to represent the binary 1100, but its least nubble is actually 0011, whereas the least nibble for character < is the correct 1100. I was hoping that thereby the least nibble of each character could be used in turn without conversion. Keith W. |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith Now I understand, I was looking at what you were suggesting through the prism of a way of somehow transferring fewer bytes rather than as a way of speeding up the conversion to binary, which probably explains why I couldn't make sense of what you were saying. Indeed, to optimise the Hex2Bin conversion, it may be that your encoding scheme might result in a faster conversion time compared to VAL. I'll write a CFunction and do a comparison of execution times. I've been looking into this business of transferring binary instead of AsciiHex which has the potential to more than halve the data transmission time, ie 11 chars/32bit word down to 4 bytes/word, (plus an overall checksum for data integrity) and it's looking quite feasible. At the receiving end this approach would result in a contiguous 128 byte run of bytes which I could then chop up with a CFunction. So, currently a row of data 32 x 32 words takes (10/230400)*11*32=15.278 mS to send from PC to uMite with binary encoding, a row of data could take (10/230400)*4*32 + (10/230400)=5.598958 mS to send from PC to uMite which, if I can make it work reliably, represents a very significant improvement. Anyway, it's Remembrance Sunday here, so time to remember those who gave so much for us. Peter The only Konstant is Change |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi John I've got it down to 47 secs for 192KBytes (using binary data transfer) but that's with 30cm of cable from uMite to target, and when I shorten the pulse times, things stop working. I think I may have to put the uMite really close up to the target device and then try shortening pulses. At 230400 bps, I should be able to transfer 23040 bytes/sec meaning that I should be able program 192 KBytes in about 8.6 seconds theoretically, ie I think the bottleneck is now the programming s/w and the cable lengths rather than the data transfer limitations. It's quite interesting seeing just how far this can be pushed now that we have CFunctions in MMBasic Peter The only Konstant is Change |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
hi, for all who like to test cfunction without mmedit i wrote this insert Clipboard to Teraterm open Tera Term place the Cursor on the insert Position (in Edit Mode) select the cfunction you will insert to Tera Term in Cfungen press Make Cfunctions call my programm and dont move the mouse or type anything until the sound one beep - ok two beep - clipboard is empty i test this with xp and vista , its virusfree (Avira) have fun its not needed to change the settings . |
||||
| Frank N. Furter Guru Joined: 28/05/2012 Location: GermanyPosts: 946 |
Hi Plasma, your link seems to content a virus: 
Frank |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I can confirm that. Passwords stealer detected with windows 8.1 defender. (PWS:Win32/Lineage.gen!C.dam) Microblocks. Build with logic. |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
oh no 
2 from 55 Antiviren Scanner say its Malware . ok this is because upx using i testet on online scan results i will upload a normal exe |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
online scan results now without upx 29 downloads and nobody say it work or its buggy ? |
||||
| G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676 |
Hi Keith, Bo, Jeff and others Here is the latest version of MMProg32RPCII for testing. This version requires MMBasic 4.6 Beta 20 installed on the uMite. This version will flash 192 KBytes in about 1 min 13 secs at 230,400 bps console speed - Option Baudrate 230400<crlf> Peter 2014-11-12_205123_MMProg32RPC_4.6B20.zip The only Konstant is Change |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Peter, You have likely wrung out what is possible. I tried initially at 38,400 baud then at 57,600 using RS232 port. I then plugged into a USB adapter and tried at 115,200 and 230,400. Results below: - 38,400 Baud ---- 2:12 57,600 Baud ---- 1:32 115,200 Baud --- 1:13 230,400 Baud --- 1:13 Note; - The same time at 115,200 and 230,400. Tried both twice to be sure, still 1:13. From 115,200 to 230,400 does the data transmission rate from the PC actually rise? Regardless of the Baud rate. That the time is exactly the same is interesting. I think that you have not achieved faster despite much trying? It makes it seem that the comms becomes 100% efficient and processing time utterly dominates. The PC is multitasking and may not service the port at a faster rate? Comms appears to top out abruptly at about 80 kBaud. Peter, what pulse time have you settled on? Interestingly (for my system) I used a USB/RS232 adapter plugged into the MAX232 chip on my Maximite card and it worked OK up to 230,400 Baud. It seems that my PC’s RS232 port does not drive hard enough above 57,600? The USB/232 adapter contains an FT232RL and an Intersil HIN213 chip to give a RS232 output. I found this USB/232 adapter before I could find just a FT232R, which is hiding somewhere. Keith W. |
||||
boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
@Peter awesome result. I have the similar results like Keith W on my Dell I7 PWS with RS232, on my I7 laptop with USB only time doubled. Thanks Peter. Bo |
||||
| Keith W. Senior Member Joined: 09/10/2011 Location: AustraliaPosts: 118 |
Hi, Thought of something to try but too late for an Edit. Tried the two lower Baud rates via USB from PC v.s. direct RS232 connection. Times are different. 38,400 Baud --- 2:12 RS232,-- 2:25 USB 57,600 Baud --- 1:32 RS232,-- 2:01 USB Does this also hint that we are not achieving the true expected rate from the PC? With more overhead for USB? Probably USB2? Also slightly faster when "Verbose" not selected. Graphing the results is interesting, although need more Baud rates. 
Keith W. |
||||
| Page 6 of 8 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
