Project Logs

Collapse

• PK2 device file (Pseudo-) decompilation, ardpicprog-java

  psmay • 07/15/2014 at 21:20 • 0 comments

  A couple of new levels of abstraction have been added to my PK2 device file analysis suite. Now included in the build is an intentionally C-like output file that fashions each script as a void function.

  For the version of the device file I'm currently using, instances of LOOP, LOOPBUFFER, and GOTO_INDEX are all successfully resolved into counting for loops. I haven't finished the translation of IF_EQ_GOTO/IF_GT_GOTO, but since all instances of those are in the DBG* scripts (what I gather to be for in-circuit debugging, which I'm not planning to implement anyway) they're not a major priority. Not counting the latter, there are no gotos to speak of in the output.

  Other semantic reworks are also included. For example, DELAY_SHORT and DELAY_LONG are normalized to delay_ns, whose argument is always an integer (with a human-friendly scaling of the value in a comment). I/O via the download/upload buffers and the data/clock lines is decomposed in a sort of functionalesque, orthogonal style; WRITE_BYTE_LITERAL(b) becomes putLineByte(b) while WRITE_BYTE_BUFFER() becomes putLineByte(getBufferByte()).
  
  The result is intended to be expressive rather than efficient; expressive code can be optimized straightforwardly, but optimized code tends to be difficult to make expressive.

  ---

  On a somewhat related note, to determine how easily it could be done, I ported the ardpicprog host program to Java. It turned out not to be all that difficult, and RXTX (the serial library) works nicely wherever it's supported at all. I have two branches: The master branch is written to be a Java program, while the pythonization branch includes a good deal of extra work to use Python-like idioms so that porting to Python would be less infeasible. Refactoring Python is a great deal more difficult than refactoring Java, so getting it right the first time seems pretty important.

  After working on this for a while, I now wonder whether I like Python enough to try to port anything to it or maintain something in it. As a matter of personal taste, I like static types and various other comprehensive static checking facilities that prevent uncaught run-time errors. I might proceed to make the piculear host code in Java (or Scala) and beg for help porting it down later.

• Level-shifter testing breakout

  psmay • 03/14/2014 at 21:20 • 0 comments

  The current design includes a 1-bit bidirectional level-shifter IC (the 74LVCH1T45 (PDF warning))  that I've never used and never even heard of before before browsing the schematic of the PICkit 3. And it's not even the same one in the PK3, but an improved version that doesn't involve pull-ups. It really seems like the right tool for the job. But how can one be sure?

  I've designed a breakout board for three of these little guys (and they are little—the tiny SOT-363 package will have some thinking twice about trying to solder it in by hand) with layout considerations for good breadboardability and homebrew manufacturability. (If there's one thing I want my home PCB fab lab to be really good for, it's breakouts for surface-mount devices. I'd like to save professional fabrication for more serious designs.)

• Allow shoot-through?

  psmay • 03/11/2014 at 21:44 • 0 comments

  TL;DR summary: Are the resistors I've placed between the drains of complementary MOSFETs really necessary?
  

  The Vpp and Vdd power switches in my current draft are conceptually based on a mix of the switches from the PICkit 2. (Follow along in the PICkit 2 User's Guide, appendix A, if you like.)
  

  In the original circuit, the Vpp switch consists of a low switch (on signal "MCLR TGT"), which is just an NPN transistor, and a high switch (on signal "Vpp ON") that is an NPN transistor whose output is pulled up to the high Vpp voltage and fed into a PNP transistor, which switches the high voltage into the output. The outputs of the low and high switches are tied together with a 100-ohm resistor, presumably to avoid a "shoot-through" condition blowing either of the transistors during the transition while neither high nor low transistor is fully turned off. The two input signals are controlled independently, making hi-Z output possible.

  The Vdd switch is decidedly different, but similar. MOSFETs are used, and the level shifting seems a bit less involved (because the programmer's own voltage and the target Vdd are similar enough that the extra input transistor is not necessary). There are still two distinct input signals ("Vdd TGT N" and "Vdd TGT P"), so the output can still go hi-Z. Though the schematic makes it harder to read, there is still a resistor between the two outputs, this time 1K, and there is also a Schottky diode from the high side, which appears to relate to the fact that the target may be self-powered and thus assert its own voltage (which could be higher than Vdd of the programmer). If the target voltage were too high, current would back up through the body diode of the PFET (and, in the PICkit 2, through that of the target Vdd adjustment PFET, into the programmer's Vdd rail) which could be nasty.
  
  My current draft of the schematic includes two nearly identical switches that combine elements of these two. Both have a level-changing input transistor, mostly in the interest of allowing the programmer to be 3.3V but be able to program at 5V (or higher). On the Vpp switch, the transistors are changed to MOSFETs because it seemed to be an opportunity to factor out unnecessary base resistors.

  My draft also retains the 100 and 1K shoot-through resistors. I'm trying to decide whether these are actually necessary for my version of the circuit.
  
  I've seen similar MOSFET-based topologies that don't place any resistor between the P and N drains, even when their gates are tied together rather than separately controlled as they are here. The excuse seems to be that, since MOSFETs have a positive temperature coefficient (PTC), they don't have to be protected from the condition in the same way as BJTs which have negative (NTC); in a sense, they behave as their own polyfuses. By this logic, either of the resistors might be unnecessary.

  So, does anyone have any input regarding whether this is the case?
  

View all 3 project logs