Padauk is not making any money selling the programmer, so why don't ask them for the programming protocol?Companies are reluctant to publish information that might want to change at any time. If they want to alter the silicon, maybe to change fabs or for a die shrink, and change the protocol, its a nightmare trying to deal with an open ended set of tools.
Would adding some photographs of the assembled boards help (even though it would show how bad I am at hand-soldering)?Yes, photos of the boards would help a lot! If possible, a screenshot of the schematics would also help. Having both of these would allow people to review/troubleshoot without downloading files and opening them in an external program.
For now, because of availability and cost, I find the PFS154 and PFS173 to be more interesting than the PFS172 which isn't currently stocked at lcsc.
Also, do you know the current status of the PMS152 when used with the easy-pdk-programmer? Is it still read-only, or has the write mode been written/tested? The PCS152-S16 is currently the cheapest 16-pin variant on lcsc and I was thinking of picking some up in addition to the flash variants if they are likely to work.
Well, it is good to have device support early, getting ahead of LCSC a bit.
One device I am looking forward to (said to be released in Q3) is the PGC434.
I'v added both now (though I left out the photo of the f-eval-pdk-s08b with PFC161, since my hand-soldering looks worst there):
Oh yes, I agree completely. Actually, I forget my original point now... I think it was more around wondering if the low voltage programming would also work on the earlier (already widely available) flash parts PFS154 and PFS173, or if those are only high voltage programmable. If the low voltage mode would work on those, it would be interesting to work on a much cheaper / more available programmer to potentially accelerate adoption.
One device I am looking forward to (said to be released in Q3) is the PGC434.That does indeed look interesting (depending on cost). Where did you find that it would be released in Q3? I do see it referenced in this doc (https://www.netvisiontek.com/pdfs/selection_guide_2019H1__20190227_EN.pdf), but am not finding much information otherwise. I suppose since it is a multi FPPA IC, using SDCC would be out of the question for now, right? Maybe I understand incorrectly, but I thought the easy pdk programmer only works with SDCC .hex files, and not output from the official compiler?
I see two capacitors, one on the USB input of 0.1uF and one on the MCU side of the diode that is 0.01uF. I assume the one on the MCU side of the diode is a bypass capacitor? If so, why not the more normal 0.1uF/100nF for that one?
And, what is the point of the capacitor on the USB side of the diode?
Speaking of the diode, I assume it is just there to make sure voltage isn't back-fed into the USB connector if you happen to power this through the programmer or breadboard pins, right?
I finally got around documenting my last project with the Padauk MCU. It's a chainable 7 segment disaply, where each segment is controlled by PFS154.
It's not too exciting, but I thought it was a suitable application for a 3 cent MCU and is a nice testbed to play around with networking protocols.
You can find a writeup here: https://cpldcpu.wordpress.com/2020/04/05/addressable-7-segment-display/
Btw, one nice trick I found during the design was to use a SOIC8-clamp for programming (see attachment). All Padauk MCU have their supply and programming pins arranged in a way that easily allows doing this. No need to add any ISP connectors. You can get these very cheap on aliexpress and ebay.
I see two capacitors, one on the USB input of 0.1uF and one on the MCU side of the diode that is 0.01uF. I assume the one on the MCU side of the diode is a bypass capacitor? If so, why not the more normal 0.1uF/100nF for that one?Yes, it is a bypass capacitor. According to the datasheets, 0.01 µF is both the recommended value and the maximum allowed for in-circuit programming. Apparently during programming, VDD needs to change quickly, and higher capacitance would interfere with that.
And, what is the point of the capacitor on the USB side of the diode?But 0.01 µF also seems a bit low, especially when the board is powered via a potentially long USB cable, so I added another capacitor on the USB side.
Speaking of the diode, I assume it is just there to make sure voltage isn't back-fed into the USB connector if you happen to power this through the programmer or breadboard pins, right?The main purpose is indeed to protect a USB hub, port, or whatever the other end of the USB connector is plugged in, from back-fed voltage. And it allows me to place that extra capacitor.
I see two capacitors, one on the USB input of 0.1uF and one on the MCU side of the diode that is 0.01uF. I assume the one on the MCU side of the diode is a bypass capacitor? If so, why not the more normal 0.1uF/100nF for that one?Yes, it is a bypass capacitor. According to the datasheets, 0.01 µF is both the recommended value and the maximum allowed for in-circuit programming. Apparently during programming, VDD needs to change quickly, and higher capacitance would interfere with that.Thanks for the clarification. I am looking at the datasheet for the PFS154, and on page 85 it mentions a capacitor on VDD/GND of less than or equal to 0.1uF. I don't see any mention of 0.01uF. Did that come from a different datasheet? Also, the easy-pdk programmer itself already has a 0.1uF capacitor on the VDD line. Are these in conflict with each other then?
And, what is the point of the capacitor on the USB side of the diode?But 0.01 µF also seems a bit low, especially when the board is powered via a potentially long USB cable, so I added another capacitor on the USB side.Ok, that makes sense. Surely something 1uF or higher would be better here, right? I guess it is a 0805, so higher uF caps can be installed as needed.
I see two capacitors, one on the USB input of 0.1uF and one on the MCU side of the diode that is 0.01uF. I assume the one on the MCU side of the diode is a bypass capacitor? If so, why not the more normal 0.1uF/100nF for that one?Yes, it is a bypass capacitor. According to the datasheets, 0.01 µF is both the recommended value and the maximum allowed for in-circuit programming. Apparently during programming, VDD needs to change quickly, and higher capacitance would interfere with that.Thanks for the clarification. I am looking at the datasheet for the PFS154, and on page 85 it mentions a capacitor on VDD/GND of less than or equal to 0.1uF. I don't see any mention of 0.01uF. Did that come from a different datasheet? Also, the easy-pdk programmer itself already has a 0.1uF capacitor on the VDD line. Are these in conflict with each other then?
Which PFS154 datasheet? In version 1.03 of the datasheet, page 87 I see the less than or equal to 0.1 µF. In version 1.05, page 89 it is less than or equal to 0.01 µF.
easy-pdk programmer has in it it needs to be able to deal with. I guess Padauk datasheets assume their programmer (another programmer might be able to sink or source current more quickly to charge or discharge the capacitor).
I noticed that you opened an issue on github about moving from gEDA schem to leptop. Is there a reason you aren't considering KiCad, which as far as I know, has a much broader user base and is more cross platform compatible? I would be more than happy to convert the files over for you, if interested.
The LEDs are configured backwards compared to what I am used to seeing. Usually the MCU sinks them down to ground instead of sourcing voltage to them. I think this is because most MCUs are able to sink current better than sourcing it. I'm not as familiar with the Padauk MCUs yet, but wondering if you took that into consideration?
Since this is a dev board (i.e. in-circuit programming) maybe it should be targeting the On-Board/In-Circuit/Limited-Voltage mode that JS is working on?
Since this is a dev board (i.e. in-circuit programming) maybe it should be targeting the On-Board/In-Circuit/Limited-Voltage mode that JS is working on?
Thess boards are quite minimal, so for now I'm just trying to keep them compatible with both modes.
That might be less of a priority for a future board with a bit more features that I intend design once the PGC434 datasheet becomes available.
Thank you for taking the time to explain your design choices. I will probably create my own version anyway, as my priorities are a bit different. For one, I would rather have a narrower board that is a bit more optimized for use in a breadboard.
I finally got around documenting my last project with the Padauk MCU. It's a chainable 7 segment disaply, where each segment is controlled by PFS154.
It's not too exciting, but I thought it was a suitable application for a 3 cent MCU and is a nice testbed to play around with networking protocols.
You can find a writeup here: https://cpldcpu.wordpress.com/2020/04/05/addressable-7-segment-display/
tim_, Awesome project! It really helps show the usefulness of such inexpensive devices.
I was reading through your article and source code last night and had a couple of thoughts that I wonder if you had considered:
- Because you are only using 5 of 8 bits, I think it would be fairly easy to add autobaud capabilities to support a much wider (and variable) range of baud rates. Basically make sure that bit 0 is always a '1' and then the length of the start bit can be measured to use for the delay loops
- The EOF could be removed by instead using a counter variable on the idle state (slightly more efficient protocol). So, inside the interrupt (re-)set a counter variable to 255 (or some number) and then in the main loop decrement the counter variable and enable/change the output when it reaches 0. So, as long as new bytes are being shifted in, the counter variable keeps getting reset, but once idle the output gets latched after some short delay. Obviously the delay would have to be longer than the expected time between each byte for this to work right.
- It looks like there are two extra pins available, so it seems like a single IC could easily support two 7-segment displays by using multiplexing. Obviously it would mean adding two transistors or mosfets and changing the main loop to time divide between the two, and the interrupt code to stay in receive mode for longer. But might be slightly cheaper end result, and how often is just one 7-segment useful anyways. EDIT: Actually I just noticed that there are two other pins that are only being used for ICP that could also be used to make a 4x 7-segment multiplexed display with one IC. If on-board programming is needed, isolation resistors might be required.
Another thought is that it is unlikely to often need a chain of more than about 8 of these to begin with, so potentially the 3 un-used bits in each byte could be used as an address, meaning each one could be directly connected to the input (instead of being chained), and they would only update when their address matched.Now that I think about some more, each one would have to know what their address is, which would mean giving up on 2 displays per MCU (need the pins for address setting), and would also have to give up on autobaud (need all 3 un-used bits), and would be limited to only 8 displays, so probably not worth looking into.
- I'm curious if the current limiting resistor is needed at all? It looks like the IO pins can only source/sink so much current anyway, although it is unclear if damage would occur without the resistor, or if the IO pins would just naturally limit the current?
- Final thought (for now)... I wonder if it is possible/useful to implement sleep mode after setting/changing the outputs? The pin change interrupt will wake the device when communication occurs, although it might take longer for the interrupt to be invoked (has this latency been tested yet?) Again, this may not be worth it because these MCUs take less than 1mA anyways (a fraction of what the 7-segment LEDs take), and if using two display with multiplexing then sleep mode gets more complicated (might be able to use a wake-up timer to sleep between alternating digits). Another option might be to lower the system clock when doing the multiplexing in the main loop, and raise it again in the interrupt (again not sure how that impacts the interrupt latency)
One topic I can really relate to is that there are many breakout boards that have too much PCB overhang next to the headers. This basically wastes one row of pins for nothing. Philipp, your boards are also guilty of this, see pic .
Also, how about introducing some silkscreen description of the pins and the device?
I would also add a copper fill as a ground plane as best practice, but it probably has little impact in this case.
One topic I can really relate to is that there are many breakout boards that have too much PCB overhang next to the headers. This basically wastes one row of pins for nothing. Philipp, your boards are also guilty of this, see pic .On the other hand, that overhang makes it easier to route stuff (e.g. to the LEDs and the programming header). But feel free to open an issue on GitHub, so I'll check if I could reroute to save that one row on each side.
You could reduce the copper trace width for easier routing. Since the Padauk cannot drive high currents anyways, 10mil lines should be more than sufficient.
If you need something narrow for breadboards, directly using DIP devices might also be an option for you.]
I usually use stock breakout-boards when I want to test a device on a breadboard. See pic. You can get them on ebay or aliexpress for next to nothing.
One topic I can really relate to is that there are many breakout boards that have too much PCB overhang next to the headers. This basically wastes one row of pins for nothing. Philipp, your boards are also guilty of this, see pic .
On other occasions, I have directly mounted the device in the target circuit and used a SOIC clamp for programming.
I will probably create my own version anyway, as my priorities are a bit different. For one, I would rather have a narrower board that is a bit more optimized for use in a breadboard.