ZEPPP - Without the computer?

[mdeweerd]

Maybe you're not to far away from a stand-alone programmer.

The Pickit2 has a mode where the program can be loaded in Pickit2 which can then work without the computer and program pics with a push on the button.

If the hex file could be include in some way in the program itself, then the arduino would no longer require the CLI which is usefull for independent programming or in-circuit programming of a PIC from another controller.

[battlecoder]

That's an interesting idea and it's (to some extent) possible to add that, however, there are some things to consider:

1. Storage: The HEX/binary would need to be stored somewhere, and a standard Arduino Uno/Mini doesn't have enough data storage (EEPROM) to fit any reasonably large program in it. One way to overcome this would be to save the program to the PGM area of the microcontroller, assuming that we can determine a safe spot to place that data, and store the address/size and PIC parameters in the EEPROM. I am, however, also making the assumption that it's possible to store random data in there. Even if this was possible, this is asking for firmware corruption issues though. Another alternative would be to have this feature available only when compiling the firmware for Arduino-compatible platforms that have enough data storage space, which I'm even less of a fan of. The most platform-agnostic and robust solution to this, would be to use an SD card... or a flash memory IC (which is, as far as I know, what Pickit does).
2. Device Settings: This is a very minor thing, but I'm putting it here to shed some light onto the way ZEPPP works. It's currently the CLI that knows what "style" of programming commands to use for every PIC family. This "map" (PIC family --> settings), would need to be moved to the Arduino. Alternatively, (and as briefly mentioned in the previous point), if the "standalone" mode is configured from the CLI, then the settings to use for the target PIC could be stored alongside the HEX/BIN, removing the need for the Arduino to figure out the settings on its own (based on the target PIC).
3. Additional circuitry: Apart from the storage, there's other components needed to make this work; At least a button, and a couple of LEDs (or a screen) to inform of finished/successful operations, errors, etc. This conflicts a bit with one of the core ideas behind ZEPPP (i.e: "Zero external parts"). Most Arduino platforms provide an on-board LED, so I guess that we could use it as a very primitive indicator for everything, using different flashing patterns for working/success/error notifications, but everything else would need to be external. This may call for a custom PCB, or at least temporary breadboarding of the required external parts. (unless we restrict the feature to Arduino-compatible platforms that already provide buttons, LEDs and storage).
4. Value: I might be being really short-sighted here, but there's a lot of limitations to what the "Progammer to Go" feature of a Pickit does (programming one specific HEX file into one specific pre-set PIC family, in an scenario where a PC is for some reason too far or not available anymore after the initial configuration of the standalone mode). And I don't see how this is something that would be useful often. Considering how slow/cumbersome it is to boot the MPLAB tools, I can see this being more of a speed/efficiency feature for when a bunch of PICs need to be flashed in a production environment, but other than that I'm struggling to imagine where/when this is useful.

TL;DR: It can be implemented, but would require additional components. Because of this, it would need to be a sort of firmware variant, or something that is only enabled if the user is targeting an Arduino-compatible platform with enough memory/hardware for it, or maybe as a feature that can be enabled/disabled by the user when the firmware is compiled, provided that they know that it will require additional parts. I'm also curious about the use cases or situations where this mode of operation is desired.

To continue with the discussion: @mdeweerd: You mention "in-circuit programming of a PIC from another controller". Could you elaborate a bit further ? If you could also speak a bit about the scenario in which this feature would be useful to you or others, that would be fantastic too.

[mdeweerd]

"Arduino" today is a vast term for anything compatible with the Arduino platform. There's "a few" Arduino platforms out there that have enough memory to hold the software for a small PIC.

A scenario is the following: the display/keyboard is on board or on a separate board and controlled by a microcontroller. Some PICs are build for directly driving LCD screens (e.g., PIC16F913), or other more evolved screens (e.g. https://www.olimex.com/Products/Duino/Shields/SHIELD-LCD16x2/open-source-hardware ).

Programming from the main processor helps avoid a programming step or having multiple programmers. The main flash could be freed up after programming to use it for other purposes. For instance to allow "OTA" updates.

A "platform agnostic" way to do it would be to have a function that either reads from internal flash or external memory, but then there are a lot of external memories and the benefit from using a single chip would be lost. Using external memory would be useful for OTA programming for instance: the main processor receives the updated code, stores it in external flash, verifies it is ok and then sends it to the PIC.

Anyway, as far as I read, it's possible to adapt ZEPPP if the configuration is embedded with the build. I would create a script that transforms the "hex" file in a "C" file that can be added directly at build time.

I'll keep you posted if there is some concrete use, I am currently investigating the use of a PIC processor for "off board" driving of an LCD with push button handling.

[battlecoder]

Thanks for the detailed and quick response. There's definitely a lot of boards and platforms under the "Arduino" umbrella. That's why I mentioned that there's probably boards out there where space or extra buttons/LEDs are already provided. As it stands now, there's nothing in ZEPPP specific to one "Arduino" platform, so I'm quite reluctant to add a feature that would only work in a subset of the supported boards (although I can't claim full compatibility with EVERY Arduino-compatible board. For starters, I suspect that 3.3V boards will not work with PICs that require ~5V for LVP).

I don't know if I'm reading your use-case scenario correctly, but I think I get the general idea.

Creating a C file with the "HEX" embedded in the code along with the configuration so you can include it at compile-time is definitely possible. This is a bit more "involved" and "static" than the way that PicKit's "Programmer to Go" mode works, and a lot less convenient, but from what you say it seems like it would cover your needs and would bypass the need for external memory.

I recommend you to check the fw_commands.txt file, as well as the functions that each command calls inside the firmware to get an idea of how the differences between PICs are handled.

I will keep thinking on this, though. I'm not discarding the feature, but I am yet to think of a way in which this could be added in a more general, less-static fashion.

For the time being, I think I can help your experiments by isolating the PIC programming functions into its own file, separating them from the serial commands and wrapper methods. Would that be useful to you?

[mdeweerd]

I am not sure I will build on this project, I do not want you to spent too much effort on this.

Separating the functions is always a good idea as it is a step towards possibilities for other uses.

Thank you for the pointers to the documents to read, first I'll have to check datasheets a bit further ;-).

[battlecoder]

Alright, so I refactored the firmware during the week, and tested it this weekend. Nothing seems broken and it's working exactly as before, so I committed the changes to the master branch without updating the firmware version number (as no features were introduced, and no bugs were fixed). All of the PIC programming functions should be in their own module now, with its corresponding header file.

This should make it easier for you, or anyone, who wants to get rid of the PC-communication side and make a standalone PIC programmer.

Regards,

[mdeweerd]

@battlecoder Thank you for the update. The probability that I will build on this project decreased, but I'll keep this in mind ans maybe demonstrate that a computerless pic programmer is possible based on this.

[battlecoder]

Alright. I'll be closing the issue then!