EEVblog #1144 - Padauk Programmer Reverse Engineering

[serisman]

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.

I realize you are responding to a several year old post, and I agree that Padauk is not likely to release the programming protocol, unfortunately.  But, I would imagine if they did change the silicon in a way that changed the programming protocol they would also have to release an update to their own programmer and they would probably release the IC with a different part number anyway.

And, there are many vendors that DO release programming information.  Take a look at Atmel's AVR datasheets, or TI's for their CC series.  There is enough information contained within to build a custom programmer.  Maybe that is part of why Atmel's AVRs were/are so successful (i.e. their openness on programming protocols and instruction set encoding and so forth helped pave the way for avr-gcc and avrdude and ultimetly Arduino).

[spth]

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.

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):

https://github.com/free-pdk/f-eval-boards/tree/master/photos
https://github.com/free-pdk/f-eval-boards/tree/master/drawings

[spth]

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. Though the biggest (28-pin) variant is likely to be DIP package only on release (I guess I'll make an evaluation board with through-hole parts only when datahseets become available).

[serisman]

Well, it is good to have device support early, getting ahead of LCSC a bit.

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?

[serisman]

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):

Thank you!  Those photos and drawings are very helpful.  And your soldering looks fine. 

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.

And, a couple of questions about the schematics:

• 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?
• 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?  If it is for bulk storage, wouldn't it make sense to be larger (1uF, 4.7uF, 10uF, etc) and on the MCU 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?

[spth]

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.

According to the datasheets, both support a limited-voltage programming mode.

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?

We don't know yet if the PGC434 will be pdk15 or pdk16. If the former, SDCC could still be used when using only one FPPA. But AFAIK, that would then be Padauk's first multi-FPPA pdk15 device. If the latter, it could indeed not be used with current SDCC.

An SDCC pdk16 port for only one FPPA would still be easy to do, but for now we don't even have a fully working assembler / linker - there is an SDCC branch for such basic pdk16 support, but it has not seem much activity recently: https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/pdk/

Finishing the pdk16 assembler / linker support wouldn't require much knowledge of the rest of SDCC, I guess one could just go by the example of the pdk13, pdk14, pdk15 assemblers and the documentation on GitHub.

[spth]

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.

[serisman]

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.

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)

[serisman]

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.

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.

Yep, makes sense.

[spth]

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).

[spth]

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.

AFAIK, bigger capacitors tend to be slower, and I wanted this one to be fast (despite begin seperated fromt he chip by a diode, it is till placed quite close), but I guess we could go a bit bigger, 0.22 µF maybe.
I also wouldn't want to go to full 1 µF or above for another reason: I'd like to leave plenty of headroom in case someone wants to add other components via the pins, e.g. on a breadboard. And the USB spec has an upper limit on the total capacitance of 10 µF.

[serisman]

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).

Ahh yes... I was looking at the one from lcsc, which is even older (1.02).  Interesting that they would change the recommendation between datasheets.  Although, in 1.05, there is a bit of a discrepancy.  Or more accurately, apparently it depends on whether one is using normal programming mode (for off board programming?), or limited-voltage programming mode (for in circuit programming?) .  On page 89 the 0.01uF is under the Normal Programming Mode section, which seems to be intended for bare IC programming with the programmer (although I'm not really sure what they mean by Multi-Chip-Package).  The eask-pdk's capacitor is probably sufficient here, although technically over the limit.  On page 90, which seems to be referring to On-Board (in-circuit) programming (using Limited-Voltage Programming Mode) it refers to less than < 500uF.  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?

[spth]

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.

I don't design electronics often (so I definitely don't want to put much time into learning new tools), but when I did in the past I used gEDA. Now the original gEDA looks more and more like a dead end. But with pcb-rnd fork of pcb and lepton fork of the rest of gEDA are well-maintained successors available, so I can continue that way.

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?

Typically, there is not much difference between source and sink current on the Padauk µC. For a lot of µC, most pins just have 5 mA sink and source current. There are exceptions, such as the open-drain PA5 on the PFS173, and the PFS154 has a few pins that have 10 mA sink current, but 5 mA source curent. But for the LEDs protected by their 15 k resistors, not much current is needed anyway.

So in the end it comes down to what is most likely to be a good choice for someone wanting to connect something extra to those pins, e.g. on a breadboard. At the time I thought this arrnagement might be better. The 15 k resistors should also help a lot with that. In particular anyone wanting to use those pins for input from some device with open-drain outputs can easily use additional pullups on them.

P.S.: The LED configuration could surely be changed if there is an advantage to doing so.

[spth]

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?

These 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.

[serisman]

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.

Fair enough, although you may want to think about adding the isolation (>10k resistors or <220p capacitors) to pins PA3, PA5, PA6 that they talk about in the On-Board wiring section on page 90.  Actually, if you moved the 15k resistors and LEDs to these pins, you could kill two birds with one stone potentially.  And it would make things more consistent between boards, as some of the smaller ICs don't even have PBx pins.  Might want to make them sink instead of source if you did that based on the comment on page 90: "In general, the writing signal pins PA3, PA5 and PA6 SHOULD NOT be considered as strong output pins."

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.

[spth]

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.

Thanks for taking the time to review the boards.
If you need something narrow for breadboards, directly using DIP devices might also be an option for you.

[tim_]

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 . 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.



On other occasions, I have directly mounted the device in the target circuit and used a SOIC clamp for programming.

[tim_]

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.

Thanks!

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

Yes, there are many protocol enhancements and variants that could be tested. Autobauding is a nice idea. One could also do direct clock recovery by introducing pseudo-manchester? The challenge is to combine this with a standard UART interface, although one could also move away from that.

• 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.

EOT by timeout: This is how it is done in the WS2812. I opted not do go this way, because it forces stringent timing requirements on your protocol. What if the datastream from the host-device is paused for some reason, for example an interrupt or a task switch?

• 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.

Sure, but the point of the design was to use one MCU per Display

• 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.

Well, why would you limit it to 8 devices? But anyhow, one could also imagine a protocol with packet routing that directly allows to address specific devices. There could be an autonumeration phase where the devices assign addresses to themselves based on the position in the chain.

• 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?

The output drivers of the PDK MCUs are unusually weak. They barely drive 10mA. You can connect any LED to it without series resistor. Whether that is a good and stable design is another question, though...

• 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)

Yes, sleep mode would make a lot of sense and is easy to implement, since the RX already uses an interrupt.

Right now I am not planning to continue working on the project though. If you have a pull request, feel free to submit something
[/list]

[spth]

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. [Edit: I just opened the issue myself: https://github.com/free-pdk/f-eval-boards/issues/3]

Also, how about introducing some silkscreen description of the pins and the device?

I don't want to add silkscreen forthe device (as each board can be used for multiple devices, as long as thtey have the same pinout. But I indeed want to add silkscreen for the pins in the next version.

I would also add a copper fill as a ground plane as best practice, but it probably has little impact in this case.

There already is (on the bottom side).

[tim_]

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.

[spth]

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.

40 mA seems to be the maximum drive / sink current, so if necessary, I could indeed go below the currently used 20 mil.

[serisman]

If you need something narrow for breadboards, directly using DIP devices might also be an option for you.]

Yeah, but that means stocking different size ICs (and I didn't see the DIP one available on LCSC) and dealing with all the hookup wires and supporting components.

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.

Yeah, I have used the same in the past.  But a dev board makes things a bit simpler to wire everything up.  There is a reason people reach for an Arduino more often than a bare IC and supporting components.  (Well technically there are many reasons, not all of them valid, but that is a different topic entirely.)

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 .

Yeah, definitely a pet peeve of mine.  The STM32 blue pill is especially bad in this regard.

On other occasions, I have directly mounted the device in the target circuit and used a SOIC clamp for programming.

Yeah, I have one of those.  They are handy for quick one-off hacking sessions, but I wouldn't want to rely on one for a general purpose dev board.  They are slightly annoying to position properly, and can slip off if bumped.

[serisman]

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.

Ok, after consulting the datasheets more and thinking about it for a while, here is what I came up with for a dev board for the PFC154/PFS154/PFS173 16-pin ICs.  The board is sized to fit in a standard breadboard and leave room for 3 rows (cols?) of pins on each side.

There are four LEDs on PA3, PA4, PA5, and PA6 in a current sink configuration (needed because PA5 can only be open drain).  Having LEDs on PA3, PA5, and PA6 should give some blinky status while the programmer does its thing.  The LEDs are properly isolated (according the datasheet) using 10k resistors, which also double as the current limiting resistors for the LEDs.  Other than the LEDs I decided not to isolate PA3, PA5, PA6 from the programmer in this version.  I went back and forth on it, and decided to leave the isolation off for now.

PA5 also has a switch on it that can be configured to be either a reset button or a general purpose user button as desired.

I used a 2x4 programming header that matches up with the standard pinout of the eask-pdk-programmer.  The thought is that a 2x4 IDC cable can be brought over to an adapter board that plugs into the standard programmer header.  I already happen to have a suitable adapter that came with my SOIC-8 SMD clamp.  In addition to the in circuit programming pins (ICVPP, ICPCK, ICPDA, VDD, and GND) this 2x4 progamming header also has PA0, PA4, and PA7, which can be used for debugging support (i.e. UART through the programmer)

I used the same USB +5V (with cap) -> diode -> VDD (with cap) arrangement, although I am still not convinced on the proper values to use.  I have re-read the datasheet and app notes (APN004 and APN011) several times and am still not fully convinced that the 0.01uF capacitor limit applies to On-board wiring.  But values can be changed easily enough if there is an issue.

Footprints used:

• All capacitors, resistors, and LEDs are 0805
• micro USB: LCSC C393940 (https://lcsc.com/product-detail/USB-Connectors_SHOU-HAN-MICRO5-9mmusb_C393940.html)
• Push button (3mm x 4mm): LCSC C398055 (https://lcsc.com/product-detail/Tactile-Switches_SHOU-HAN-TS342A2P_C398055.html)
• Schottky Diode: LCSC C438001 (https://lcsc.com/product-detail/Schottky-Barrier-Diodes-SBD_Shandong-Jingdao-Microelectronics-SD103AW_C438001.html)

I ordered 3x of them for $3.30 (free shipping) from OSHPARK, and shared it here: https://oshpark.com/shared_projects/eN9zYouf

I will release the source files after successful testing.  (I am still without ICs or programmer)

There may be additional revisions of this dev board after testing it out and using it for a while.

[tim_]

Just a short update on the "lite"-Version. I already received the partially populated boards about a week ago. Looks very nice so far. I chose not to populate the MCU, because I still had a few left.

Unfortunately the parts that have to be added manually are still stuck at customs in a separate shipment.. Nowadays ordering assembled PCBs is much faster than ordering only components.

[js_12345678_55AA]

Hi,

Today I started working on PFC154 (industrial part?) and to my surprise after analyzing the READ and WRITE I found:

PFC154 program word = 14 bits, but read / write using 19 bits.

5 extra bits are attached to the beginning of every program word. Some extra bits usually are for error corrections, lets' see..

Some samples from logic analyzer reading: 14 bit data => 5 extra bits:
3FFF => 1F
0070 => 08
2F00 => 0E
0182 => 04

First try: classic Hamming ECC
Confirmation by using this web site http://www.ecs.umass.edu/ece/koren/FaultTolerantSystems/simulator/Hamming/HammingCodes.html
After entering the binary 14 bit values from above, website will show result attached to the end of the bistring.
=> All matching! It is a classic Hamming ECC using the standard syndrom

It is a bit unexpected, but it looks like the "industrial grade parts" are really having some extra features.


JS