Complier tweak for rp2040, and other ARM variants ... ???

[RandoSY]

First off, thanks for this great little utility, I am leaning a ton.

When I attempt to compile for other than AVR, I get a sprinkle of these errors.

"invalid conversion from 'char' to 'ZEPPP_RET' [-fpermissive]"

I changed the def of several enums to further type, "constant enum" but now change. Is there something clever I can do, that would apply globally?

Thanks again!

[battlecoder]

Hi @RandoSY, Thanks for your interest in ZEPPP! To be fair I never attempted to compile this for a different processor, so I'm intrigued.

The enum casting problem is easy to solve as long as we are willing to lose some of the return value strictness (which is fine. Enum casting is not that strict of an operation to begin with). Making all functions that return a ZEPPP_RET value just return a char (this can easily be done with a #define) is enough. The comparison against enum values should still work, although it won't be "enforced".

I tried this tweak and found out that a function was also missing a return value that was probably implicit when compiling for AVR processors. I took the liberty of making the changes, and I have pushed them to the experimental/code-compatibility branch.

The firmware is compiling now for AVRs and RP2040 without any other changes, but I've not had time to check if the firmware actually works once uploaded to a board. I'll probably be able to test later today, but it would be great if you can test that branch and report back ~

[RandoSY]

Thanks so much for the consideration of your prompt response. I apologize my lab is in a mess with a move, so I'm not setup to test like I'm usually able to do.

I just wanted to start the process of adding PIC programming to the logic analyzer, and basic o-scope functionality I already have working. Your java skill are amazing, do you work in Eclipse? I was going to try to step debug the zeppp-cli app just for fun, and understanding.

The rp2040 is a very versatile platform, and dirt cheap and most importantly, readily available.

Just an FYI, these changes all allow for compilation for the ESP8266, ESP32 ... web Zeppp? 👍

Executable segment sizes: ICACHE : 32768 - flash instruction cache IROM : 240840 - code in flash (default or ICACHE_FLASH_ATTR) IRAM : 27337 / 32768 - code in IRAM (IRAM_ATTR, ISRs...) DATA : 1496 ) - initialized variables (global, static) in RAM/HEAP RODATA : 948 ) / 81920 - constants (global, static) in RAM/HEAP BSS : 25984 ) - zeroed variables (global, static) in RAM/HEAP "C:\\Users\\randa\\AppData\\Local\\Arduino15\\packages\\esp8266\\tools\\xtensa-lx106-elf-gcc\\3.0.4-gcc10.3-1757bed/bin/xtensa-lx106-elf-size" -A "C:\\Users\\randa\\AppData\\Local\\Temp\\arduino_build_940702/ZEPPP.ino.elf" Sketch uses 270621 bytes (28%) of program storage space. Maximum is 958448 bytes.

[RandoSY]

This works out like a champ, with Zeppp-cli. Eclipse was able to understand everything and automatically import the Maven build info....

[battlecoder]

I mostly develop with IntelliJ IDE when I'm working in Java, but I'm glad to hear that the project works in Eclipse as well. Maven is a pretty standard build system, so I wouldn't have expected many issues to be completely fair.

I did, indeed, verify that now the project compiles for a lot of other platforms. What remains to be checked, though, is whether all the firmware functions still work. They should, sure, but I would love to verify first.

In particular I would love to know whether an RP2040 with this firmware can actually be used to program PICs. As far as I understand it's a 3.3V device, and I'm not entirely sure that all LVP pics can be programmed at that voltage.

[RandoSY]

Thinking about just getting a PICO, loading the program and testing if it can eat a HEX file from Zeppp-cli, and see the pins wiggle? I think I can dig one out of the chaos.

I've seen other projects that all run on 3V, that seem to program the more modern PICs OK. I like the entire 16F15XXX, they are still available in volume, and have great peripherals.

[battlecoder]

I'm sure a lot of older PICs also support <3V operation, but I've personally never used any old PIC below 5V. I'll try to load the firmware onto a RP Pico later today after work, and if I'm able to program a couple of PICs we'll be good to go.

[RandoSY]

I bet good news on my end ...

I sent a test.hex file to the Arduino programmed PICO, and got this response. (Sorry about the clumsy formatting)

PS C:\Users\randa\Desktop\zeppp-experimental-code-compatibility> java -jar zeppp-cli.jar -c COM26 -i test.hex -p Opening port COM26...

Connecting to ZEPPP interface...

-- Interface detected: ZEPPP 1.0.1 20200715

Detecting connected device... ERROR: Failed to Detect connected device. Unrecognized device with ID 0x0000

So the program has it wits!

[RandoSY]

Here's the Arduino core for rp2040 I'm using ...

[battlecoder]

It doesn't seem to be reading anything from the PIC (device id 0x0000 hints this). It definitely could be that we are missing something (timing issues, pin configuration, etc), but I would advice you to check your connections to your target device and make sure you are also connecting the PIC to VCC and GND.

[RandoSY]

Just to clarify I don't and did not have it connected live to a real PIC chip, just checking to see if the Arduino port on your experimental branch seemed to program OK, and have its basic wits. I need to build a test jig. put on my logic analyzer, and test away.

But sorry to say, will be battle to get my equipment setup soon ... thanks for your help!

[RandoSY]

Here's the source to my test program in GCB (Great Cow Basic), toggling PIN#1, on PORTC, PIC16F887.

`'''A demonstration program for GCGB and GCB. '''-------------------------------------------------------------------------------------------------------------------------------- '''This program blink one LED on PORTC.0 (bit 1) using the Toggle command. '''The LED must be attached via appropiate resistors. ''' '''@author EvanV plus works of HughC '''@licence GPL '''@version 1.0a '''@date 31.01.2015 '''****

; ----- Configuration

chip 16F887, 16

option explicit

; ; no config. assumes defaults

; #include ; no solution specifc includes, default includes are always included

; ----- Define Hardware settings dir PORTC out

; ----- Variables Dim DESTBIT as Byte

; ----- Main body of program commences here. Do Forever

 ' toggle the first bit - this equates to PORTC.0
 Toggle @PORTC, 1
 'Then wait after the pin goes off
 Wait 500 ms

Loop

; ----- Support methods. Subroutines and Functions

' You can toggle any number of pins by addressing the bits using this method ' Toggle PORT, BIT Sub Toggle ( In DestPort As word, In DestBit ) Poke DestPort, Peek(DestPort) xor DestBit End sub `

[RandoSY]

And of course, PIN mapping on PICO for GPIO

Arduino | ICSP Signal | PIC 16F6xxA | PIC 16F87/88 | PIC 16F87x(A) -- | -- | -- | -- | -- D9 | PGM (6) | RB4 (Pin 10) | RB3 (Pin 9) | RB3 (Pin 36) D8 | PGC (5) | RB6 (Pin 12) | RB6 (Pin 12) | RB6 (Pin 39) D7 | PGD (4) | RB7 (Pin 13) | RB7 (Pin 13) | RB7 (Pin 40) D6 | MCLR (1) | RA5 (Pin 4) | RA5 (Pin 4) | MCLR (Pin 1) GND | Ground (3) | Vss (Pin 5) | Vss (Pin 5) | Vss (12, 31)

NOTE: I think there is a 5V VDD available from the USB port

[battlecoder]

Just to clarify I don't and did not have it connected live to a real PIC chip, just checking to see if the Arduino port on your experimental branch seemed to program OK, and have its basic wits. I need to build a test jig. put on my logic analyzer, and test away.

But sorry to say, will be battle to get my equipment setup soon ... thanks for your help!

Oh ok, that makes sense. Even if you have +5V available on the RP2040 board I would advice you to use the +3.3V out, because the programming levels from the RP Pico pins are not going to be +5V.

If you are working with a 16F887 PIC you will need the changes from another branch experimental/PIC16F88X. I have not merged those changes yet because I've not had time yet to sit and implement the calibration word, nor test PGM block writes for that device.

I'll try to do that today together with the RP2040 testing.

[RandoSY]

Relevant?

http://picpgm.picprojects.net/install_raspberry_pi.html

Some commands, like "Begin Programming Only Cycle" or "Bulk Erase Setup[12]", only work in the 4.5V-5.5V voltage range for "old" devices like pic16f876 (see http://ww1.microchip.com/downloads/en/D ... 39025f.pdf , page 6). For newer devices, like pic16f628a, you can program the device at lower voltages, but all Bulk Erase operations must take place with VDD between 4.5-5.5V.

So, short answer, I had to choose 5V to be able to bulk erase the chips.

But encouragingly ...

PIC16(L)F1919X

DS40001846C-page 2 2016-2018 Microchip Technology Inc.

1.3 Hardware Requirements 1.3.2 LOW-VOLTAGE ICSP PROGRAMMING In Low-Voltage ICSP mode, the device can be programmed using a single V DD source in the operating range. The MCLR/VPP pin does not have to be brought to a different voltage, but can instead be left at the normal operating voltage.

and you can see that the newer generation of PICS can be programmed via the 3.3V GPIO I/0 pin on a generic Raspberry Pi, but of course your hard won programming algorithm may not apply ...

https://www.pedalpc.com/blog/program-pic-raspberry-pi/

Finally a very clear discussion of the "3.3V only line of PICS", in the context of a dedicated ICSP programmer,. that was new to me...

http://www.embedinc.com/products/lprog/index.htm

[battlecoder]

So the requirement is for VDD to be ~5V for a number of scenarios.

You can still proceed with your plan of using the 5V USB line from the RP2040 to power your target PIC, BUT you will need something like a level shifter between the board and the PIC. All the pins that are "output" (from the programmer point of view) like PGM and PGC can be a straight connection between them, but the data pin (PGD) needs to have a sort of voltage conversion in place. A simple solution could be something like this, but I've not tried it myself. There are other diode-resistor configurations (for example a current-limiting resistor and a 3.3V zener to ground) that can act as a voltage clamp and could be more suitable for this.

We would need to test, but voltage levels could definitely be an issue when using ESP or RP2040 boards.

Out of curiosity, why are you trying to use an RP2040 for this and not an Arduino?

[RandoSY]

I'm constrained in an educational environment, and I get like double, and triple duty on the other RasPi PICO community add-ons, like a good logic analyzer, and a USB connection to a smartphone for a remarkably effective oscilloscope.

Strategically, I got interested in a tiny PIC's as an intro to physical computing in the classroom from this author, 10 years ago.

https://sites.google.com/site/softwarephysical/_/rsrc/1375784809281/home/

But of course the economics of micro-controllers is completely upside down. The availability of the trusty PIC16F887a today is zero, at a price of 7:00$. I really don't relish trying to get to the nuts and bolts of processor instructions on a admittedly beautiful, but overly complex ARM processor day one, esp. with younger kids. A lot of the big vendor computer curricula have way too much black box and hand wave, with no opportunity to see what's going on behind the curtain.

I'm working on a learning progression starting with TTL logic and the 555, through very basic PIC, with the Arduino in the middle, and Circuit Python and related at the end. Every body needs to start somewhere... the simpler the better.

Based on supply constraints, here's where I have to be if I need quantity X 1000.

https://www.digikey.com/en/products/detail/microchip-technology/PIC16F15324-I-P/6691275

It would be a big job to adapt Zeppp to this product, but it would deal with the 3V issue, it should program LVP fine, all except total block erase, but row by row erasure should work at the spec'd VDD.

There are some funny passages in this, but they seemed to add quite a bit of complexity to the PIC programming task.

https://ww1.microchip.com/downloads/en/DeviceDoc/PIC16F152XX-Family-Programming-Specification-40002149.pdf

[battlecoder]

I see. I really wish you the best in your educational journey. I love PICS and learning them is quite a joy.

I was just thinking that if you had access to a RP2040 board maybe you probably also had access to Arduino boards. Especially because "third party" Arduino boards are cheaper than a Raspberry Pico.

Boards like the Pico, STM, or ESP-based designs are very popular, but using them for this is kind of a waste. All of those boards are very capable platforms better suited for more complex tasks. ZEPPP barely requires some serial communication and toggling some digital pins so I'm sure that even the most basic Arduino with the lowest-spec processor can do it.

Unfortunately I don't see many solutions around the voltage limitation other than either only programming low voltage parts, OR having a small voltage conversion solution for the PGD line and powering the target device with 5V. I'm sure that if I go through the list of currently supported PICs and check which ones can actually be programmed at ~3V I'll come out empty handed, so I'll try to propose a circuit for 3.3V boards.

Not sure how much experimentation I can do today, but I'll try.

[RandoSY]

Thanks again! I totally agree with your assessment.

Just an FYI, the new 16F1 (mid-range "extended") do program @ 3.3V, LVP only. They might even bulk erase, but I would need to research that some more.