如何用PIC将十六进制生成的代码上传到另一个PIC？

如果目标PIC与源PIC完全相同，那么传递生成的代码就行了。如果你没有源代码，那么你最好是创建一个新的源，它在功能上等同于目标PIC。苏珊



      以下为原文

    If the target PIC is exactly the same as the source PIC then transferring the generated code will work.
I would say to forget trying anything else. If you don't have the source code then you are probably better off creating new source that is functionally equivalent for the target PIC.
Susan

谢谢你的快速回复。我不确定我是否已经做了我的观点。我想做的是把一个PIC MCU转换成一个程序员。我希望这个程序员可以在现场使用（不使用PC）通过数据、CLK和MCLR引脚来编程另一个PIC（只是一个特定的PIC），我们称之为目标PIC。我在C和HEX中都有TalpPIC的源代码。我已经为程序员F打开了一个开源的解决方案。iRMWEED称为开放程序员。然而，这是使用USB连接到PC，所以我不知何故必须适应这一代码，我猜这不是一个容易的任务。另一个解决方案是，正如我在OP中提到的那样，根据编程规范SH来削减十六进制代码并生成信号。靶向PIC的EET。



      以下为原文

    Thanks for the quick reply.
I'm not sure if I've made my point quite clear.
What I want to do is transform a PIC MCU into some sort of a programmer. I want this programmer to be used on the field (without the use of PC) to program another PIC(just one specific PIC) through DATA, CLK and MCLR pins, lets call it target PIC.
I do have the source code for the target PIC, in both C and hex.
I have looked into an open source solution for the programmer firmware called open programmer.
However this is using an USB connection to the PC so I would somehow have to adapt this code which I guess its not an easy task.
Another solution is, as I have mentioned in OP, to strip down the hex code and generate signals according to the programming specification sheet of the targeted PIC.
 

你知道PACTIT3已经可以这么做了。



      以下为原文

    You know the PICKit3 can do that already.

是的，我需要，但是我需要在没有使用PC/LAPPoT的情况下在现场进行，并且目标PIC的源代码将存储在程序员PIC中。



      以下为原文

   
Yes, I do, but I need to do it on the field without the use of a PC/laptop.
And the source code for the targeted PIC will be stored in the programmer PIC.

嗯，在这个链接中，源控制器没有一个内存作为伙伴。你还需要一个源内存，你可以把你的代码传输到目标。所以程序员会更复杂一些；例如，找一个EPROM程序员。这样你就可以做一个独立的程序员。杰拉尔德。----



      以下为原文

   
Well, in this link - the source controller doesn't have a memory as companion.
You need also a source memory from that you can transfer your code to the target.
So the programer will be a bit more complex; look for an EPROM programmer for example.
With that you can make an standalone programmer.
 
Gerald
----
 

谢谢你的输入。我想上传到目标PIC的程序并不是那么大。用程序内存代替它不是不可能的吗？



      以下为原文

   


Thanks for the input.
The program that I want to upload into the target PIC is not that big.
Isn't it possibble to just use the program memory instead?

是的，我需要，但是我需要在没有使用PC/LAPOTPT的情况下在这个领域做它，并且目标PIC的源代码将被存储在程序员PIC中。



      以下为原文

   
Yes, I do, but I need to do it on the field without the use of a PC/laptop.
And the source code for the targeted PIC will be stored in the programmer PIC.

A PK3 set to use "On the Go" mode can do precisely that.
 

是的，我需要，但是我需要在没有使用PC/LAPToP的情况下在这个领域做它，并且目标PIC的源代码将被存储在程序员PIC中。一个使用“Ongo”模式的PK3集可以精确地做到这一点。我知道。但是我的客户希望使用5个或更多个（每个都是48美元），这样他们就可以使用。也就是说，程序板没有一个ICSP连接，我相信，只是背面的一些引脚。程序员也将被用作这些板的测试仪。



      以下为原文

   
Yes, I do, but I need to do it on the field without the use of a PC/laptop.
And the source code for the targeted PIC will be stored in the programmer PIC.

A PK3 set to use "On the Go" mode can do precisely that. 

 
I know.But my client wants to use like 5 or more of them(each being 48$) so they can accelerate the production time.
Also the programmed board doesn't have an ICSP connection I belive, just some pins on the back I think.
The programmer is also gonna be used as a tester for these boards.

如果使用LVP，则有一个例子（LVP.C，LVPY2000 .C）来编程PIC16F18855 AtTPSP://GithuB/COM/MICCHIPTea/XPress加载程序/Tee/Mask/MPLA.Xu，也可以尝试引导加载程序，这样您就不会对某些图片有LVP约束。您可以编写一个PC程序来合并HEX文件。你的程序员代码，并用合并的十六进制文件闪存你的程序员。然后你的程序员可以用数据编程另一个PIC，或者你可以有一个PC程序来读取HEX文件并与你的程序员通过UB-UART桥…所以你可以把十六进制数据存储在程序存储器中。



      以下为原文

    If you use LVP, there is an example (lvp.c, lvp_2000.c) to program PIC16F18855 at 
https://github.com/MicrochipTech/XPRESS-Loader/tree/master/MPLAB.X
 
You may also try the bootloader, so you don't have the LVP constraint for some PICs.
 
What you can do is you write a PC program to merge the HEX file with your programmer code, and flash your programmer with the merged HEX file.  Then your programmer can program the other PIC with the data.
 
Or you can have a PC program to read the HEX file and talk with your programmer throught USB-UART bridge... so you can store the HEX data in the program memory.
 

没有ICSP连接，你不能做任何事情。您需要至少访问MCLR、PGC和PGD。如果你没有一个ICSP连接，你将如何连接它？



      以下为原文

   


You cannot do anything without ICSP connection. You need access to at least MCLR, PGC, and PGD. If you don't have an ICSP connection, how are you going to connect to it?

同意NothGee和Timijk，没有可用的ICSP连接，你的唯一选项将已经在目标设备上安装了一个引导加载程序。除非它远远超过5个必要的设备，并且你将不会接收它们，我仍然建议使用程序员去模式PIDIT3。如果有ICSP连接器的设备。对我来说，250块钱是不值得的，只是说：-。



      以下为原文

    Agree to NorthGuy and timijk, without the ICSP connection available your only option will be already having a bootloader installed on the target devices.
 
Unless it is far more than 5 devices necessary and you will not receive them back I would still recommend the use of Programmer-to-Go mode PicKit3 devices if there is a ICSP connector. To me 250 bucks wouldn't be worth the effort, just saying :-).
 

对不起，我的坏…测试的设备确实有连接到MCLR数据和CLK。测试/目标设备将被编程和测试在同一时间在一个“装配线”时尚。有人知道多少“程序员”会花费我吗？



      以下为原文

    Sorry my bad...The tested device does have connection to mclr data and clk.
The tested/target device its gonna be programmed and tested at the same time in an "assembly line" fashion.
Does anyone know how much the "programmer" would cost me?

我知道这不是你的最后一个问题的答案，但你能指定你打算如何测试目标没有任何PC附加？如果你打算遵循程序员的PACKIT3方法去模式，建议它只允许你用预加载的十六进制图像闪耀设备。它将验证编程是否成功。另一个注意：Microchip指出，PACTIT3程序员不打算用于生产线编程（仅仅为了完整性）。



      以下为原文

    I know this is not an answer to your last question but can you specify how you're intending to test the target without any PC attached?
If you're aiming to follow the PicKit3 approach in Programmer-to-go mode, be advised that it will only allow you to flash the device with an preloaded hex image. It will verify the if the programming was successful though.

Another Note: Microchip states that the PicKit3 programmer is not intended for production line programming (just for the sake of completeness).

Regards
Fabian

非常感谢你的信息。我还没有具体的细节如何测试将要完成。从我所知道的，它将测试MCU的行为……它将根据给定的电压输入测量一些电压输出。我知道这很普遍，但这是我迄今为止得到的。



      以下为原文

    Thanks a lot for the info.
I do not have the specific details yet on how the testing is going to be done.
From what I know it is going to test MCU behaviour...like... it will measure some voltage outputs based on given voltage inputs. I know this is very general but this is what I got so far.

因为听起来好像你只能访问MCLR PGD和PGC，一个好的选择是使用PGD和PGC作为你的应用程序的串行通信管脚，这样你就可以在你的目标应用程序闪现/编程后发送和接收数据。您不仅打算对设备进行编程，还希望以后对应用程序进行校准，我建议使用Bootloader工作。通过应用程序串行接口、闪存更新固件、引导加载程序跳转到应用程序，您可以跳转到Bootloader，Bootloader跳转到应用程序，您将能够执行您的测量/校准。其他人可能在“真实”程序中更有经验。MIN而不是通过Bootloader闪烁。我认为这不仅仅需要向目标发送命令。你可能需要提供VDD和VPP交换功能。正如我说的，我不太熟悉这一点，也许有经验的人会纠正我，如果我错了。



      以下为原文

    Since it sounds like you will only have access to MCLR PGD and PGC, a good choice will be to to use PGD and PGC as your serial communication pins from your application as well, that way you will be able to send and receive data to and from your target application once it is flashed/programmed.
 
Since you do not only intend to program the devices but also want to 'calibrate' the application afterwards, I would suggest to work with a bootloader. You could jump to the bootloader upon reception of a dedicated command via the applications serial interface, flash updated firmware, the bootloader jumps back to the application and you will be able to perform your measurements/calibration whatsoever.
 
Others may be more experienced in 'real' programming rather than flashing via bootloader. I think this would require more than simply sending commands to the target. You might need to provide vdd and vpp switching functionality.
As I said I'm not very familiar with this, maybe somebody more experienced will correct me if I'm wrong.
 
Regards
Fabian

所以，你需要一个独立的动力装置，比如电池，可以连接到现有板上的ICSP线（你不能改变），并且它上有两个按钮——读写。读取按钮将读取PIC16F179（如果它没有保护），写按钮将编程目标芯片的内容与以前读过的内容。这个设备不应该与PC.有连接，那是你想要的吗？



      以下为原文

    So, you want a device which is independently powered, such as by battery, can connect to the ICSP lines on the existing board (which you cannot change), and has two buttons on it - read and write. The read button will read the PIC16F1769 (provided that it has no protection) and the write button will program the target chip with the content of what has been read before. This device should not have a connection to PC. Is that what you want?

我想知道如果用SD卡制作一个程序员/测试器来保存程序可能比将目标代码合并到程序员PIC本身更容易。如果它从卡上的一个特定文件中读取代码来编程，那么很容易改变程序而不必对程序员ITSE进行重新编程。LF，SD卡也可以用来存储测试过程中产生的数据（像从每个设备中读取和测试的特定值），而不是仅仅有一个带通/不亮灯的盒子或类似的盒子。



      以下为原文

    I wonder if making a programmer/tester using an SD card to hold the program might be easier than merging the target code into the programmer PIC itself.
 
If it read the code to program from a specific file on the card, it'd be easy to change the program without having to reprogram the programmer itself, and the SD card could also be used to store data resulting from the testing process (like specific values read from each device programmed and tested), rather than just having a box with pass/fail lights on or suchlike.

有很多可能性。您可以使用Android移动设备与UB-UART对话PIC中的引导加载程序，或者使用UB-ICSP来闪存PIC。您还可以使用Android移动设备与支持USPART模块的蓝牙UART模块进行对话，以与PIC中的引导加载程序对话。我以前试过这个，但是用笔记本电脑。它非常方便，它是无线的…你也可以使用Android移动设备连接到MPLAB XPress评估板，并删除一个十六进制文件来编程PIC。



      以下为原文

    There are many possibilities.
 
You might use Android mobile device with USB-UART to talk to the bootloader in the PIC, or use USB-ICSP to flash the PIC.
 
You can also use Android mobile device to talk to the bluetooth UART module which supports SPP profile  to talk to the bootloader in the PIC.  I have tried this before but with the laptop.  It's very convenient and it's wireless...
 
You can also use Android mobile device to connect to the MPLAB Xpress evaluation board, and drop a HEX file to program the PIC.

HiStIt整个事情对我来说是很熟悉的。我在想象一条生产线，包括一些PCBA的PIC编程，在运行了一个诊断，不仅在编程的PIC上，而且在整个PCBA上。已经有了类似的事情。所以：-在任何生产设备上的应用程序代码。E不易发生变化，所以在I/D部门控制下的程序员PIC的闪光灯中填充它就足够了。-为了能够编程只访问MCLR、PGC和PGD的PIC，它必须使用高电压编程。你必须按照规范来执行这个协议，包括MCLR管脚的受控高压电源。为了运行某种诊断/校准，你需要程序员PIC和目标PIC之间的通信通道。正如已经提出的那样，您需要使用PGC和PGD管脚来实现这种通信，因为您不能访问其他人。在编程和测试阶段，能够控制PCBA的功率也很有趣。NETE，必须在解耦和噪声滤波方面非常谨慎。程序员必须有2个操作阶段：1 -从自己的有效负载编程目标PIC（用目标应用的二进制图像的闪存表）。2——编程切换到测试模式。释放MCLR线路并将PGC和PGD线路切换到通信模式。3 -最有可能还必须输出一个输出（与工业硬件兼容）发出一个好的/坏的板，因此生产线可以将坏的信号从出口路径中除掉。目标PIC应用程序必须包括D。IAGNONTIS/校准支持，使用PGC和PGD线的通信信道的形式，因此它可以与程序员/ TEST交换诊断命令和数据。作为最终产品的安全特征，应用程序应该只接受诊断/校准的开始。在一个POR或MCLR之后的一个给定的时间间隔中，我将排除任何基于Bootloader的目标PIC（生产设备）的解决方案，这通常意味着稍微大一点的PIC，每一块板的成本稍高一些，这通常超出了大规模生产的范围。对…最好



      以下为原文

    Hi
 
This whole thing feels quite familiar to me.
I'm imagining a production line that includes the programming of a PIC in some PCBA, and after runs a diagnostic not only on the programmed PIC but on the whole PCBA.
Already been fighting something alike.
 
So:
- The application code on any production device is not prone to frequent changes, so stuffing it in the FLASH of the programmer PIC under the I&D department control would be good enough.
- To be able to program a PIC with only access to MCLR, PGC and PGD, it must use high voltage programming. You have to implement this protocol as per the specification, including a controlled high voltage supply for the MCLR pin.
- For running some kind of diagnostics/calibration you will need a communications channel between the programmer PIC and the target PIC. As already suggested you need to implement this communication using the PGC and PGD pins as you don't have access to others.
- It might also be interesting to be able to control the power to the PCBA during the programming and testing phases.
- All this must be able to operate on an industrial environment, so great care must be used on decoupling and noise filtering.
 
The programmer must have 2 operation stages:
1 - Program the target PIC from its own payload (a flash table with the binary image of the target application).
2 - After programming switch to test mode. Release the MCLR line and switch the PGC and PGD lines to communication mode.
3 - Most probably it must also have an output (compatible with industrial hardware) signaling a good/bad board, so the production line can ditch the bad ones from the exit path.
 
The target PIC application must include the diagnostic/calibration support, on the form of a communication channel using the PGC and PGD lines, so it can exchange diagnostic commands and data with the programmer/tester.
As a safety feature for the final product, the application program should only accept the start of the diagnostic/calibration process during a given time interval after a POR or MCLR.
 
 
I would exclude any bootloader based solution for the target PIC (production device) has this usually means a slightly bigger PIC with a slightly higher cost per board, something that is usually out of scope on mass production.
 
 
Just my 2 cents....
 
 
 
Best regards
Jorge