 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 : pic32prog
  Page 3 of 4   |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
The limit i hit was in the way characters were processed from the USB receive buffer. I studied the logfile from Rob and did a rough statistic on which commands are used most.Obviously it were the 'i'-'x' characters as those contain the data to be programmed. But also the 'a', 'z', 'e' and 'g' are in most command sequences. By testing the value of the character in the order of most used many false tests can be avoided resulting in quit a bit of difference. Together with avoiding too many function calls and leaving out a read from the PGD line when the result is ignored got another significant speed boost. The results are way better then i ever expected. 2-3 minutes and i am happy. BUT making things fast and small is my part of the fun while programming so i kept trying. The results are very good as this little chip has lots more power then previously thought. Memory usage is now 548 bytes RAM and 4560 bytes Flash. A little bit more because i gained lots of speed by removing multiple calls to the same function. As these function were small they are now inlined with a define. OK (drumroll!), here is the latest result programming a PIC32MX170 with the latest b30 firmware! [code] C:\Users\mail\Dropbox\Micro Blocks\Projects\BreadBoard\U2SP5\Software\pic32prog> pic32prog -d ascii:com4 mm.hex Programmer for Microchip PIC32 microcontrollers, Version 2.0.BETA (30-08-2015) 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: 258712 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: 7306 bytes per second total TDI/TMS pairs sent = 3706009 pairs total TDO bits received = 953736 bits total ascii codes sent = 1184377 total ascii codes recv = 327876 maximum continuous write = 911 chars O/S serial writes = 110994 O/S serial reads (data) = 29814 O/S serial reads (sync) = 5 XferFastData count = 58606 10mS delays (E/X/R) = 11/0/0 elapsed programming time = 0m 36s [/code]  
AND, without removing the cables, resets or anything i can just go into MMEdit and start programming in basic. Microblocks. Build with logic. |
||||
| Chris Roper Senior Member  Joined: 19/05/2015 Location: South AfricaPosts: 280 |
[quote]elapsed programming time = 0m 36s [/quote] I flashed one with the PICKit 3 earlier today and I think it took LONGER than 36s, TZA you have nailed it 
Now how do we get it to do the 8 and 16Bit families too
Those 18F2550's and 18F25k50's that I got to build a modified PICkit 2 look like they are going to be available for other projects instead :) Cheers Chris May I have a copy, pretty please  the 1455 on my dev board is feeling jealous.http://caroper.blogspot.com/ |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Just to be clear. Most of the brains are in the pic32prog. The program in the PIC16F1455 just toggles some pins and read some pins and sends it back. It does not know anything about the chip it is connected to. The ascii based ICSP protocol is pretty brilliant because you are now able to program on a more convenient platform (PC) the actually process that is needed for programming chips. In theory any chip could be programmed with it. Even eeprom/flash other brands like atmel etc. Also you could use it just to switch on/off some pins through USB just by giving the right 'command'. And i still have 500 bytes RAM and 3636 bytes of flash to be able to adapt the code for other chips if needed. My first goal now is to get this manufactured and on a PCB! Unfinished things before being able todo that are more research into using normal output pins instead of OC. It should work fine but i want to make sure. Potentially chips can be fried if done wrong. Don't want that to happen! If it means adding a resistor/transistor/diode to the pcb then that is what needs to be done. The PGD pin switches between input and output and when the programmer and target chip have those pins in opposite state (a short circuit) then there is potential for damage. If i read the programming datasheet well then i switch this pin to an input right before the target switches its pin to an output. I have a scope but as these pins are tied together i am not sure how to get a good reading. Send me a PM with your email address and i will send you the HEX file. Microblocks. Build with logic. |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Thanks PM sent. A couple of 100R resistors would probably be plenty of insurance on the PGC/PGD pins without interfering with the signal. http://caroper.blogspot.com/ |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I was thinking of series resistor but they have to be around 470R to get a maximum of around 10ma when 5v is used. I am now testing with making the PGC pin OC again and see what effects it has on the speed. Microblocks. Build with logic. |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
The PICKit2 uses a 100R in series and a 4K7 pulldown on PGC/PGD not sure if they are OC too. Another thought on how to use some of the remaining capacity of the device. If you could add a PS/2 - Serial Keyboard interface you would have the ultimate MicroMite / Pic32 Peripheral. ICSP, +5V & +3V3 PSU, Console Interface and Keyboard. Cheers Chris http://caroper.blogspot.com/ |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
regarding the times the PGD line is being driven by the PIC32, this diagram is what i have been working from: 
i believe that the rising edge of the 3rd clock pulse turns around PGD (making it an output), and that the TDO data becomes valid on the falling edge of that 3rd clock pulse. the TDO data should be read out during the interval between the falling edge of the 3rd clock pulse and the rising edge of the 4th clock pulse. my feeling is that it would be unwise to leave reading the TDO data any leter. by the falling edge of the 4th clock pulse PGD is guaranteed to have been reconfigured as an input. i recall there being some quite heated discussion over this timing on the original ICSP thread. attached below is a zip file containing a new beta of the windows compile of pic32prog.exe: 2015-09-21_111425_pic32prog_2.0.BETA_2015-09-21.zip this has all current patches applied, along with the buffer requirement for the programmer reduced from 1024 bytes down to 512 bytes to accommodate the 512 byte RxD buffer in your PIC16F1455 version. this can be seen in the output line: maximum continuous write = 452 chars have you considered incorporating into your board a USB plug at one end and a 2-row pin header socket at the other end? something like this: 
or this: 
it could then be covered in heatshrink, and several (keyed) leads made up using different pins for the different functions (ICSP, serial bridge, program 1455). you could even go so far as fitting it into a plastic shell, though i do rather prefer clear heatshrink myself. cheers, rob :-) |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
I incorporated the USP plug in my first prototype with the 16f1455, but decided in practice that I preferred having the ICSP socket, same as the PICKit, and a USB cable, rather than eliminating the USB Cable and having a 6 strand ribbon cable to the ISCP Plug. Integrated USB Plug is great for Flash-drives or Wireless devices but not so good for interfacing when several connections are required. Cheers Chris http://caroper.blogspot.com/ |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I have some other ideas of using the remainder that i would like to try first. One of those is to measure the current that is used by the connected circuit. So when you use this 'block' to provide USB to Serial and 3.3v power then i would measure what current goes out on the 3.3v pin. This would then allow you to monitor how much your circuit consumes. Also a HID device is high on my list. This would then allow you to design your own keyboard/mouse/joystick that can be used by any PC that has HID support (that would be almost all). One of the projects i have in mind for that is a small keyboard with just 5 function keys on it. Programmable so it can be used for often used commands. Nowadays lots of smaller computers (laptops/netbooks,tablet/notebook hybrids etc) combine the Function keys with others and you need to hold down an extra key to access the functie keys itself. PS/2 keyboard needs to be interrupt driven, i am hesitant to do that because it can interfere with the critical timing that is needed for USB. But i will certainly look into that when i have done the other functionality first. I am not done with testing yet, so please have a bit more patience with the HEX file. I not want you to blow up your pic32 on first try. :) Microblocks. Build with logic. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
@Matherp I currently use the following connections to the MUP. [code] PIN MUP C3 #MCLR A4. PGC A5. PGD C4/TX. RX C5/RX. TX 3.3V. 3.3v GND. GND [/code] At this moment i simplified the code a bit and not used a switchable power supply for the target. With the current software it is essential that both the pic1455 and the pic32 have the same 3.3v and gnd lines as i use the ports as outputs when in programming mode. In standard USB-Serial mode C3,A4 and A5 are inputs and in high impedance mode. I currently have both get power from usb through a 3.3v regulator and all signals are also on 3.3v level. The still available pins are C0,C1,C2. For my plans i need at least one analog input pin. Which one is best i am figuring out now. C0 and C1 could be used for I2C, which would add another functionality to the 'block' and that is USB-I2C which might be interesting. Microblocks. Build with logic. |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
I wasn't thinking of a Keyboard to PC interface but rather a Keyboard that could inject key strokes into the existing serial console stream to the PIC32. I was actually thinking of your other Keyboard project at the time, thought there may be some synergy there and a useful crossover. Monitoring the current is also good but I am not immediately sure how useful it will be with only a 10 bit ADC, especially when you consider that current monitoring is most important when you are aiming at nA consumption in Sleep mode. No hurry on my side, just eager to try it out :) Take your time though, I know what you are going through, I hate to release anything till I am satisfied with it. With a PICKIT2, PICKIT3 and ICD3 laying on my desk programmers are not in short supply. And don't worry about me blowing PIC32's I have about 10 times as many of those than I have 16f1455's :) Cheers Chris http://caroper.blogspot.com/ |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
We are thinking the same. My Keyboard project uses a 1459 which has more pins that can be used toscan a matrix. The internals are the same just more pins. The 1455 code can then be enhanced with a keyboard matrix scanner. What i meant with implementing PS/2 is that you need to use interrupts to catch when data is arriving. Polling a pin will be too slow. This has a big change of messing up the timing of the USB as this is probably used at the same time to act as a terminal display. A PS/2 to serial can probably be done with a 8 pin chip. Might be a good project by itself.
[quote=Chris Roper] Monitoring the current is also good but I am not immediately sure how useful it will be with only a 10 bit ADC, especially when you consider that current monitoring is most important when you are aiming at nA consumption in Sleep mode. [/quote] YES! 10 bit should be plenty when the range is small. i was thinking between 0.01 - 10ma. You would then have a 0.01ma resolution. The usage would be to set the 'block' in 'current monitoring' mode and that will then output the measurements every configurable interval to the USB. A PC can then log that and make a nice graph. Microblocks. Build with logic. |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
I didn't realise that you needed interrupts for PS/2 having never actually tried to code it myself. I just assumed it would be relatively slow and you could clock the data out in any idle time left after the USB polling. Take a look at Geoff;s ASCII Terminal controller for the functionality I intended. I am currently using it for the USB to serial with a PS/s keyboard attached. In fact the MicroMite and controller are embedded in the keyboard and the PS/2 cable replaced by a USB cable connected to the PC as CDC connection. It works well. Cheers Chris http://caroper.blogspot.com/ |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
After trying for many hours to get it running with PGD being an simulated OC output with pullup resistors and getting nowhere i just realized that it would be better to just add an NPN transistor and keep the speed that can only be reached when using the pins as outputs. This is the latest result. [code] C:\Users\mail\Dropbox\Micro Blocks\Projects\BreadBoard\U2SP5\Software\pic32prog> pic32prog -d ascii:com4 mm.hex Programmer for Microchip PIC32 microcontrollers, Version 2.0.BETA (2015-09-21) 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: 258712 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: 7712 bytes per second total TDI/TMS pairs sent = 3771166 pairs total TDO bits received = 1010088 bits total ascii codes sent = 1207270 total ascii codes recv = 347247 maximum continuous write = 452 chars O/S serial writes = 112755 O/S serial reads (data) = 31575 O/S serial reads (sync) = 10 XferFastData count = 58606 10mS delays (E/X/R) = 11/0/0 elapsed programming time = 0m 34s [/code] @Rob, i checked what is being exchanged between the PC and the MCU over USB and most packages that come from the PC are 64 bytes or less. The MCU often send 1 or 2 characters when response is needed. I tried to buffer them and transmit them in one time but there was no increase in speed whatsoever. It did make the code more difficult as extra bookkeeping needed to be done. I tried by increasing buffers and working in smaller and bigger batches but no result. I think i just hit the limit and it is now the toggling of the pins that consumes the time. I now use the standard buffers of 64 bytes and when the PC wants to send more it get nack's. This is a built in mechanism and after i think about a hundred or so test burns, not one character was missed. So i think we are good on the buffering and processing. The source is just some buffering and a bunch of if statements. What happens on the pins is put into 'define's. This gave me the opportunity to find patterns and i think i got them reasonably well divided. Sometimes a pin is set low twice, which could be seen in the define easily. removing that extra setting of the pin gained a little speed. I did not use the 'power target', in my opinion it is better that the target is powered constantly and that will also force the user to think about what they are doing. If through the program another source of power is activated it might have nasty results. I think that this will be used often by beginners as it is a very cheap alternatief compared to a pickit3. [code] /******************************************************************* * A port of the ascii ICSP protocol for a PIC16F145(4/5/9) * by Microblocks. 2015-09-22 * * This is part of the U2SP5 Microblock that contains * a USB-Serial adapter, PIC32 programmer, Analog current logging * and maybe a few more.... :) * * Details can be found on https://github.com/MicroBlocks/BBM-Series/tree/master/U2SP5 * * Original code by Robert Rozee. Source on github * (https://github.com/robert-rozee/pic32prog/blob/master/bitbang/ICSP_v1E.ino) * * Software license..... what software license? It is on the internet! * I would appreciate if you left this header with the source code. *******************************************************************/ /** INCLUDES *******************************************************/ #include "usb.h" #include "usb_function_cdc.h" #include "HardwareProfile.h" #include "Mode.h" #include "ASCII_ICSP.h" #include "usb_function_cdc.h" const UINT16 AI_TimeOut = 10000; //Ten seconds of inactivity will drop the //module out of Programmer mode and into USBSerial mode unsigned char SequenceCounter; AI_STATE AI_State = AI_IDLE; UINT16 TimerTicks; BYTE LastDelay = 0; BYTE BufferIndex= 0; BOOL BufferEmpty = TRUE; BYTE BufferLength = 0; int PrAcc = 1; // accumulated PrAcc flag //Test characters for a sequence to enable PROGRAMMER mode. //The sequence is at least 2 times a '>' character after a DTR signal //or startup. char AI_isStartSequence(char c) { if (c == '>') { SequenceCounter++; if (SequenceCounter >= 2 ) { return 2; } else { return 0; } } else { SequenceCounter = 0; } return 0; } //Activate/Deactivate PROGRAMMER Mode. //This is under control of 'Main ProcessIO' BOOL AI_RaiseEvent(AI_EVENT e) { switch(e) { case AI_ACTIVATE: AI_Activate(); //Setup all the Programmer Pins AI_State = AI_ACTIVE; break; case AI_DEACTIVATE: AI_DeActivate(); //Set all pins into high impedance input mode AI_State = AI_IDLE; break; } return AI_State == AI_ACTIVE; } void AI_Activate() { //Setup variables and PINS TimerTicks = 0; LastDelay = 0; PGC_LOW;PGC_OUTPUT; PGD_LOW;PGD_OUTPUT; MCLR_LOW;MCLR_OUTPUT; } void AI_DeActivate() { //put all pins in high impedance mode PGC_INACTIVE; PGD_INACTIVE; MCLR_INACTIVE; } //Copy data from the USB to the shared buffer char AI_ProcessUSBToProgrammer(void) { char v = 0;BYTE J; BYTE B; if(AI_State != AI_ACTIVE) return 0; if (BufferEmpty == TRUE) { BufferLength = getsUSBUSART(RS232_Out_Data, CDC_DATA_IN_EP_SIZE); if(BufferLength > 0) { BufferEmpty = FALSE; BufferIndex = 0; } } while(v == 0 && BufferEmpty == FALSE && LastDelay == 0) { //Read character from buffer and process it. //Unless a delay is requested then skip processing //and leave character in buffer for next time. char c = RS232_Out_Data[BufferIndex]; TimerTicks = 0; //Keep PROGRAMMER Mode active. BufferIndex += 1; if (BufferIndex == BufferLength) { BufferEmpty = TRUE; } //Check the character, most often used ones first for increased speed. if(c >= 'i') { if(c <='x') { J = (c - 'i') & 15; if (J & 1) {C4_10;} else {C4_00;} if (J & 2) {C4_10;} else {C4_00;} if (J & 4) {C4_10;} else {C4_00;} if (J & 8) {C4_10;} else {C4_00;} continue; } else if (c == 'z') { C4_01;C4_00; continue; } } else if (c == 'a') { C4_01;C4_00;C4_00; continue; } else if (c == 'e') { C4_01; continue; } else if (c == 'g') { C4_11; continue; } else if (c >= 'I') { if (c <= 'Z') { J = (c - 'i' & 15); //v = 'I' + clockIn16(J); if(J & 1) {C4R_10;} else {C4R_00;} v = B; if(J & 2) {C4R_10;} else {C4R_00;} v |= B << 1; if(J & 4) {C4R_10;} else {C4R_00;} v |= B << 2; if(J & 8) {C4R_10;} else {C4R_00;} v |= B << 3; v += 'I'; break; } } if (c == 'd'){ C4_00; continue; } else if (c == 'f') { C4_10; continue; } switch (c) { case 'D': C4R_00;v = '0' + B; // TDI = 0, TMS = 0, read_flag = 1 break; case 'E': C4R_01;v = '0' + B; // TDI = 0, TMS = 1, read_flag = 1 break; case 'F': C4R_10;v = '0' + B; // TDI = 1, TMS = 0, read_flag = 1 break; case 'G': C4R_11;v = '0' + B; // TDI = 1, TMS = 1, read_flag = 1 break; case 'A': C4_01;C4_00;C4R_00; // TDI = 0, TMS = 1-0-0, read_flag = 1 v = '0' + B; break; case '+': C4_00;if (!B) {PrAcc = 0;} // TDI = 0, TMS = 0, accumulate PrAcc // remember if any error ('0') continue; // '>', '.', '=': handshake and formatting commands, placed here for possible speed case '>': v = '<'; // request a sync response of '<' break; case '=': v = PrAcc ? '1' : '0'; // retrieve value of PrAcc PrAcc = 1; break; // '0','1': used to clock out "MCHP" signature for ICSP entry case '0': PGD_LOW; PGC_PULSE; continue; // clock out a 0 bit on PGD pin case '1': PGD_HIGH; PGC_PULSE; continue; // clock out a 1 bit on PGD pin case '-': v = '0' + clockIn1(1); break; // clock in single PGD bit // '2','3': pulse MCLR high, clock out signature, set MCLR high case '2': MCLR_LOW; continue; // set MCLR low case '3': MCLR_HIGH; continue; // set MCLR high // '4','5': control power supply to target case '4': // turn power to target OFF PGC_LOW; // PGC = 0 PGD_LOW; // PGD = 0 MCLR_LOW; // hold target in reset //POWER_ON; continue; case '5': // turn power to target ON PGC_LOW; // PGC = 0 PGD_LOW; // PGD = 0 MCLR_LOW; // hold target in reset //POWER_OFF; continue; // miscellaneous other commands case '8': LastDelay = 10; continue; // insert 10mS delay case '?': v = '?';break; // return ID string, "ascii ICSP v1X" default: continue; // invalid input - skip it } if(v != 0) { // If a return value is available break out of the while break; // The value will then be placed in the output buffer. } } return v; } // USBCB_SOF Hook. HS USB will call this every 1 millisecond. // It is used for delays and timeouts. BOOL AI_Timer1ms() { if(AI_State == AI_ACTIVE) { TimerTicks += 1; if (TimerTicks > AI_TimeOut) { //No activity. Drop out of Programmer mode AI_RaiseEvent(AI_DEACTIVATE); return FALSE; } if(LastDelay > 0) { LastDelay -= 1; } return TRUE; } return FALSE; } BYTE clockIn1(BYTE D) { //Not USED Untested!! BYTE B; PGD_INPUT; PGC_PULSE; B = PGD_READ; PGD_OUTPUT; return B; } [/code] And the defines [code] typedef enum _AI_STATES {AI_IDLE, AI_ACTIVE} AI_STATE; typedef enum _AI_EVENTS {AI_ACTIVATE, AI_DEACTIVATE} AI_EVENT; //Define pins that are used for programming #define PGC_INACTIVE TRISAbits.TRISA4 = 1 #define PGC_OUTPUT TRISAbits.TRISA4 = 0 #define PGC_LOW LATAbits.LATA4 = 0 #define PGC_HIGH LATAbits.LATA4 = 1 #define PGC_PULSE PGC_HIGH;PGC_LOW #define PGD_INACTIVE TRISAbits.TRISA5 = 1 #define PGD_OUTPUT TRISAbits.TRISA5 = 0 #define PGD_INPUT TRISAbits.TRISA5 = 1 #define PGD_LOW LATAbits.LATA5 = 0 #define PGD_HIGH LATAbits.LATA5 = 1 #define PGD_READ PORTAbits.RA5 //Simulate OC output #define MCLR_INACTIVE TRISCbits.TRISC3 = 1 #define MCLR_INPUT LATCbits.LATC3 = 0;TRISCbits.TRISC3 = 1 #define MCLR_LOW TRISCbits.TRISC3 = 0 #define MCLR_HIGH TRISCbits.TRISC3 = 1 #define MCLR_OUTPUT MCLR_LOW #define C4_NOREAD PGD_INPUT;PGC_PULSE;PGC_PULSE;PGD_OUTPUT #define C4_00 PGD_LOW; PGC_PULSE; PGC_PULSE;C4_NOREAD #define C4_01 PGD_LOW; PGC_PULSE;PGD_HIGH;PGC_PULSE;C4_NOREAD #define C4_10 PGD_HIGH;PGC_PULSE;PGD_LOW; PGC_PULSE;C4_NOREAD #define C4_11 PGD_HIGH;PGC_PULSE; PGC_PULSE;C4_NOREAD #define C4R_READ PGD_INPUT;PGC_PULSE;B=PGD_READ;PGC_PULSE;PGD_OUTPUT #define C4R_00 PGD_LOW; PGC_PULSE; PGC_PULSE;C4R_READ #define C4R_01 PGD_LOW; PGC_PULSE;PGD_HIGH;PGC_PULSE;C4R_READ #define C4R_10 PGD_HIGH;PGC_PULSE;PGD_LOW; PGC_PULSE;C4R_READ #define C4R_11 PGD_HIGH;PGC_PULSE; PGC_PULSE;C4R_READ BOOL AI_RaiseEvent(AI_EVENT e); BOOL AI_Timer1ms(); char AI_isStartSequence(char c); void AI_Activate(); void AI_DeActivate(); char AI_ProcessUSBToProgrammer(void); BYTE clockIn1(BYTE D); [/code] Microblocks. Build with logic. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Some more news. i was able to program a PIC16F1455 also. Added some extra commands and a simple windows program and it work pretty ok. Thi should pave the way to be able to program a whole other range of chips. Now the task of cleaning the code up so that it is actually understandable and maintainable. After a whole night hacking away at it, it is not really structured anymore. Microblocks. Build with logic. |
||||
| MMAndy Regular Member  Joined: 16/07/2015 Location: United StatesPosts: 91 |
@robert.rozee Great job on your programmer! Our question, hopefully, should not be offensive. How much effort is involved in using your Nano to program a PIC32MX chip with an MM+ Explore 64 with SD memory, TFT LCD display and keyboard? By using a serial port from the MM+ and attaching it to the Nano serial port? (with level conversion?). The SD memory would have the "hex" file installed and a MMbasic "pic32prog.exe" like program would generate the programming sequence. Programming speed or thru-put would not be a concern. This way you can eliminate the PC altogether except for hex source file downloading. Any thoughts? Addition ... Imagine a PIC32 ecosystem that a portable MM+ embedded basic laptop can develop and program firmware code for other PIC32s without a personal computer. No special drivers, no Microsoft and no reset problems!
|
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Maybe the mm+ would be able to update itself. Reading from sd and writing to flash does not seem to difficult. Maybe it can be done with a cfunction? Thinking about it more it would be fantastic if you could make a tiny boot program that checks for a firmware file on sd, then writes that to its flash. Instant updates.😃 Microblocks. Build with logic. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
TZA: it does indeed look like you don't need to be worrying about the Rx buffer size, the USB mechanics taking care of this for you. i suspect that the same trick would apply with hardware (RTS/CTS) flow control and the CH340G used on the Arduino NANO, but the necessary connections between the flow control pins are not there on any Arduino board. i have done some more testing, and found that in fact very little of the 512 byte Rx buffer on the Arduino is used, although in the case of the Arduino implementation there is little point in reducing the buffer size. for a detection mechanism you could consider: a sequence of perhaps 10 '>' characters, after which the 1455 responds back to the PC with a '<'. if a '?' is then received from the PC switch to programming mode and send back the protocol ID string. you could combine this with the rule: after startup, if a character other than '>' or '?' is seen from the PC, lock out entry to programming mode. this would mean that programming or serial mode would be seamlessly selected at startup with almost no risk of accidentally triggering programming mode. just plug the 1455 into the USB port and start up pic32prog. a useful debug tool would be that all characters received from the PC are still sent out the serial port, even if programming mode is engaged. futhermore, every character that programming mode wants to send back to the PC is also echoed out the serial port with bit 7 set. this would give you an ability to display a trace of any programming session (very similar to the one pic32prog produces when configured appropriately) on an attached terminal, and could be quite useful for debugging the programming of other PIC (non 32-bit) devices. what extra commands did you need to add for programming the 1455? MMAndy: if you are talking about an MM+ being able to program a pic32 device, this would be possible by (1) porting pic32prog to MMbasic, then (2) porting the Arduino code to MMbasic. you would then not need the Arduino at all. this would be a quite worthwhile project, if you felt so inclined. but it would be beyond me, as i only wrote the Arduino code and portions of adapter-bitbang.c (from pic32prog). the majority of pic32prog was written by serge. cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2290 |
btw, TZA: i really do recommend at least providing a single pin (if one is spare) to turn power to the PIC32 on/off, even if this feature requires an external switching transistor and is not connected/used. others may wish to use the feature, and having pic32prog able to control the power helps ensure that the PIC32 is prevented from running any code. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8592 |
See wikipedia for details of the Oozlum bird 
|
||||
| Page 3 of 4 |
|||||
 Print this page |
