The SMALpic Assembler
When I embarked on a substantial PIC-based project for paid work, I encountered a common issue: most of the PIC tools were designed exclusively for Windows. Additionally, the Linux tools available seemed to require a significant time investment to upgrade my outdated Linux system. However, I already had a capable assembler at my disposal in the form of the machine-independent SMAL assembler.
I decided to devote a few days to adapting this assembler into a PIC assembler. This newly adapted tool is written in C, employs a command-line interface, and is virtually free from system dependencies, apart from the necessity of having a C compiler. There is no need for the latest versions of lex, yacc, make, or any other similar tools.
This assembler is designed to process code for all 14-bit PIC microcontrollers, and it includes files specifically tailored for the PIC16C72, PIC16C73, PIC16C74, PIC16C76, and PIC16C77. (I happened to be working on code for the 16C76.)
The distribution of the code comes in the form of a shell archive, encompassing source code, header files, and a concise manual.
The SNOPPP Pic Programmer
All the commercial PIC programmers I came across were primarily designed for Windows, but I needed a solution that could work seamlessly with Linux. So, I began my search for a suitable programmer. The NOPPP from Covington Innovations seemed promising, prompting me to construct my version, the NOPPP-2, which utilized an IC instead of a handful of diodes in the original design. However, I encountered some issues when using it with UV EPROM-based PICs for several reasons:
First, it lacked the critical feature of a marginal voltage check necessary for producing high-quality PIC programmers. This entails programming with a 5-volt supply and then reading back the program using a 5.6-volt supply and a 3.8-volt supply to verify the programming’s quality. To address this, I incorporated an array of 1N4003 diodes to generate these essential voltages.
Second, the programming voltage Vpp required for the UV EPROM-based PICs needed to fall within a narrower range than that of the flash EEPROM PICs. They demanded precisely 14.0 volts, but I empirically determined that 13.8 volts worked as well. Furthermore, programming the UV EPROM versions appeared to draw significant power from the 14-volt programming supply, making it unsuitable to have a series resistor between the regulator and the chip. Consequently, I introduced an additional transistor into the programming voltage supply. This had the effect of inverting the programming signal to the NOPPP, necessitating modifications to the driver code.
I’ve named my adapted NOPPP the “Son of NOPPP,” or SNOPPP for short. Below, you’ll find the schematic and a photograph of the final product:
Following the ethos of the initial NOPPP, I constructed my SNOPPP by repurposing spare components. Among the components at my disposal was a resistor network, and you can spot all the 3K resistors illustrated in the diagram within the white dual-inline package situated at the upper left of the image. With some extras available, I decided to employ one for an indicator light, as depicted in the photo with the LED.
In-Circuit programming with the SNOPPP
It’s worth mentioning that I utilize this programmer for in-circuit programming. I use a 3M DipClip attached to the end of an 8-inch ribbon cable for the programming process. To ensure reliable operation, I found it necessary to include a clock line terminator for the PIC. I integrated the terminator within the SNOPPP device rather than the cable assembly, making it a simple plug-and-play solution when connecting it to the SNOPPP socket for in-circuit programming.
The schematic for the programming clip intended for 28-pin PICs is displayed here, while the photo illustrates the clip I actually used, securely fastened to a PIC16C76 on the motor control board I was tasked with developing. My programmer cable comes with a dedicated 14-pin socket, and ideally, I should have designed it to connect directly to the programmer using a header that matches the same pinout as the PIC, as indicated in the schematic.
Please be aware that when using this in-circuit programming method, the programmer supplies power not only to the PIC but to all components connected to the same +5 supply circuit as the PIC. It is crucial to exercise caution in the circuit design to ensure this does not create any issues. Additionally, when applying power to the PIC, it will resonate if a crystal oscillator or ceramic resonator is attached. To prevent this, the programming clip grounds the O1 pin. This grounding is also present on the programmer’s socket, but it is advisable to ground it locally with a short jumper (indicated by an asterisk in the schematic) rather than using a lengthy wire.
Another point to note is that the cable configuration is designed in a way that each signal wire is flanked on both sides by ground wires, providing some level of shielding.
A Linux Driver for the SNOPPP
The Linux driver software for the SNOPPP is provided in the form of a UNIX shell archive. Installing this driver requires root privilege, as it circumvents the standard driver for the parallel port and directly interfaces with the hardware.
This driver has undergone testing specifically with the 16C76, but it should theoretically function with other 14-bit Flash EEPROM PICs if you specify them as 16C76 chips. Additionally, it still includes Covington’s code for supporting the 16C84, 16F84, and 16F83 chips, although this functionality remains untested.
Apart from modifying the original NOPPP driver to reverse the Vpp line, I had to make adjustments to implement Microchip’s recommended adaptive burner logic for UV EPROM-based PICs. This involves a sequence of programming steps, data verification after each step, and iterative repetitions until the read data matches the data being programmed.
Suggested Enhancements to the SNOPPP
Contemplating the aforementioned issue, it dawned on me that implementing certain hardware adjustments could significantly enhance its performance. For instance, substituting D0 and D1 for Autofd and D0 as output, or employing PE instead of BSY for input, would have allowed me to adapt the system to function seamlessly with the standard LINUX parallel port driver. This, in turn, would eliminate the need for manual configuration, resulting in improved efficiency. However, I refrained from making these alterations because I preferred dedicating my time to revenue-generating activities rather than tinkering with support tools.
It would also be intriguing to employ D2 and D3 for voltage control, enabling the software to execute marginal testing without necessitating manual switching for each verification pass by the user.
Source: Pic Cross Development Support Tools
About The Author
Ibrar Ayyub
I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.
Follow Us:LinkedinTwitter