Author Topic: EEVblog #1144 - Padauk Programmer Reverse Engineering  (Read 100905 times)

0 Members and 2 Guests are viewing this topic.

Offline tim_

  • Regular Contributor
  • *
  • Posts: 98
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #900 on: May 25, 2020, 08:53:17 am »
Your programmer uses many different component, so it also does not have a very optimized BOM for production.

Yes, this programmer has a quite different approach. It is intended to feed VCC to a board, which may consume more current than the PIC itself would need. Also it is intended to set the voltage on VCC to values from approx. 2 volts to nearly 7 volts from the supply via USB and maintains the logic levels according to this span. That's probably a bigger gun than required for programming a Padauk controller.

But there are some details in the hardware, I would like to point on: the setup of the voltages is separated from the switches, it needs only a usual PWM and it is limited by the choosen values of the resistors, so no fault can occure if the software fails to limit it to the bounds given by the manufacturer.
Yeah, one could actually run the bost converter from an PWM output, i know that's also done in some PIC programmers. Or one could use a lowpass filter to get a DC reference voltage. Using a DAC saves some headache for calibration though and one can use an open-loop control. if it is available in the MCU it's a better approach in my books.

My comment was rather referring to the fact that you used many different component types. Not easier to get manufactured than the easypdkprog is now.

My problems with the easypdkprog are software problems, in particular the lacking definitions of the protocol between PC and programmer on the USB. I use to start any development by writing down the interface and protocol between different parts (like PC software and ┬ÁC firmware), so the whole development can be divided into smaller parts and can be written separately.

And I love to split down the necessary functions of the programmers firmware to atomic ones, so the algorithms can be left on the PC side without making the whole procedere clumsy. If there is an interest in this, I can post it here.

This sounds a bit like the GNU/Hurd vs. Linux debate (not that I witnessed that first hand...) :) What you are proposing is certainly cleaner from an architecture point of view, but in the end both solutions work equally well for the user. Changing the software now would be a major undertaking.

One thing that could be very interesting though, would be to adopt the Pickit programmer hardware. There are many clones available on eby/aliexpress and the hardware looks like it could support the Paduak.

Offline spth

  • Regular Contributor
  • *
  • Posts: 97
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #901 on: May 25, 2020, 09:19:41 pm »
Ok, I had the audacity to create a preliminary "lite"-Version of the easypdkprogrammer, based on "Basic" components from the JLCPCB catalogues.

Is this lite programmer mechanically compatible (i.e. will it fit into the same case as the normal programmer)?

The main problem I see for assembly is the USB connector. Replacing it with a through-hole part, while breaking mechanical compability, would make it easier to hand-solder (as JLCPCB does not solder connectors).

P.S.: Why not just put the design into free-pdk git, as an alternative programmer, to make it easier for people to have a closer look (and github issues might be better for discussion of individual features than this forum thread). We already have 10 repos there, so an 11th one won't hurt.
« Last Edit: May 25, 2020, 09:21:56 pm by spth »

Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo