07/04/2014 at 11:16 •
This device was designed with low power consumption in mind. That’s why I choose operation speed of PIC32 to 4MHz, with peripheral bus clock 2MHz. Running 80MHz PIC32 at 4MHz may seem strange, but this power is quite enough for such as application. Old computers (I mean those with 6502 or Z80 CPU, not your old dual-core system) ran at about the same clock frequency, but it were simple 8-bit architectures, so my system has higher power after all. On the other hand, thanks to using low-power LCD the complete current consumption of MAX32 board with my add-on falls down to 12mA (after unsoldering indication LED from MAX32 board, taking 4mA of current), so this enabled me to run this device for at least ten hours from small 140mAh Li-Ion cell. This also allows using solar cells (practically tested with this one) or small wind generators (untested, but interesting option – for example here) or even water generators (like this one). All those option allows direct powering of this device, but irregularity in power supply can cause open file to be lost. This is reason for powering PP4 from Li-Ion cell and using power from those energy sources for charging this Li-Ion cell, even when PP4 is not turned on.
That is why I created extension for powering PP4 from small Li-Ion battery or solar cell. I measured parameters of this solar cell – the weak February sunlight can make it deliver circa 5,5V at open circuit and 80mA into short circuit, so 0,5W is quite reasonable estimation of its power capabilities. I built a simple circuit:
When there is no voltage on input, PFET (Si2333) transistor opens and supplies output from battery. 22K resistor between its G terminal and ground ensures that transistor is fully open.
Input (from solar cell, USB cable or standard 5V wall wart) is brought to output through diode BAT48 and G terminal of PFET, closing D-S channel and removing load from battery. MCP73831 works as Li-Ion charger, charging cell between pins 2 and 3. 20K resistor on pin 5 sets the charging current, on this case it is around 50mA. LED on pin 1 indicates the end of charging process.
There are more sophisticated ways of achieving functionality with both battery and solar power, but this one is simple and usable enough for me.
07/04/2014 at 10:22 •
Most of work was done on software side. It can be divided into two parts – system kernel and user programs. Kernel operates above FAT32 file system and currently supports only single logical (and) physical drive. All user programs are currently in FLASH memory, build together with kernel, however during writing of this document, I’m writing and testing new version, allowing running binaries from SD card.
This part of software allows running user program and provides standardized interface to it. There is a set of commands allowing operation with file system and selecting standard IO interface.
After reset, invitation message is displayed, starts initialization of SD card and if it is successful, message prompt appears:
Kernel now accepts commands, for example ls is such as “non-destructive” command, not altering anything, just listing files on current directory.
Example above shows listing in case there are four files. Maximal displayable format is 8 characters for filename and two characters for extension, however, kernel can – internally – work with standard 8:3 filenames. LFN support is not enabled (though simple to implement) now, as using long filenames wouldn’t be practical for such as simple device – there are no technical reasons for not implementing it. I will not go through all commands supported by kernel (comprehensive summary can be found in appendix A).
Messages are scrolled on display, one can see history of commands by using “up” and “down” keys to unscroll it back. Maximum history size is 128 lines.
Though kernel allows program to use standard IO interface, not all programs use it – there are two exceptions: ED and DE. Those operate directly above display and keyboard buffer, so its operation is limited to local display and keyboard. I’m working on new kernel supporting full-display operation, so those exceptions will disappear.
There is a few programs implemented into this release, including text editor, PIC18 assembler, PIC18 programmer, PIC18 debugger, then programs not related to PIC18 programming – BF interpreter, BASIC interpreter.
BF - BF interpreter
BF is one of esoteric programming languages, probably the most famous one, interesting by its minimalism, however surprisingly functional. It was developed for amusement while experimenting how small compiler can be written for this language. It was released in 1992 as compiler for Amiga computer (68000 based), however variants of it were written for many other platforms, PIC32 with PP4 including. For more information about BF, you can visit form example Wikipedia page.
BF can be invoked from PP4 command line:
bf <source file> <input file (optional) >
shows running BF interpreter with one parameter (only source file) and with two parameters (both source and input files). First example runs famous “Hello world” example, second runs “cat” program (copying input to output), while parameter is source file itself, so this effectively prints content of source file to display, being equivalent to ad kernel command.
Cell size is 8 bits, array size is 30000 cells, stack depth 5000 levels, input is redirected from file only as input from stdio would not be practical. When end of source is encountered, BF interpreter returns to system kernel, when end of input file is encountered, BF interpreter returns with “BF-input ended” message (see example above).
BA - BASIC interpreter
This interpreter is based on uBasic by Adam Dunkels. It provides all usual BASIC commands while maintaining simplicity and portability of code.
This interpreter can be invoked from command line:
ba <source file>
runs simple demo program
10 gosub 100
20 for i = 1 to 3
30 print i
40 next i
50 print "end"
100 print "subroutine"
Maximum size of interpretable file is 40000 bytes.
PIC 18 development set
This is trio of programs, allowing cross-development for PIC18 on PIC32 PP4. It consists of editor, simple two-pass assembler, programmer and debugger.
ED is simple WYSIWIG editor, designed for work with PIC18 assembler sources.
It can be invoked by calling
ed <input file>
If input file is not submitted, then ed creates empty space in memory, which can be edited and saved. If input file exists, its content is loaded and edited in memory. No changes to actual file is done while not saved from user command.
Its layout looks like this:
Where first seven lines of display show actual content (with cursor on first row) and last status line telling cursor is on line 13, what is 33% of overall number of lines in file and this file occupies 28% of allocated memory.
There are a few limitations for this editor: line length can be max. 16 characters, excluding <NEW LINE> character, currently there is only 2000 bytes allocated for editor in memory, so there is no way of editing longer files. Former issue is fixed in 1.1 version, space is expanded to 40kB.
Currently, ED cannot operate through standard IO mode – it operates only above local display, however it can be run from command line, debug results can be observed only on local display.
AS is simple assembler for PIC18 MCU, enabling creating cb file (see appendix B for description of cb format). This file contain binary images of program memory, configuration bytes, PIC configuration (used by debugger and programmer) and debug info (used by debugger only).
It is invoked in form
as <input file> <output file>
It messages any error that could happen during assembly, in ideal case it looks like this:
This output informs that assembler was invoked, assembly of input file with 45 lines was successful and output file was saved.
There is list of possible error codes:
1, Unknown opcode on line x – self explanatory
2, Bad px on line y – first (x=1), second (x=2) or third (x=3) parameter of instruction on line y is invalid
3, 8 bit over range on line x – parameter that is expected to be in range 0..255 is out of range on line y
4, 11bit over range on line x – the same as before, for parameter 0..2048
5, Deftable over on line x – too much definitions in this file, first definition over range is on line x
6, Unknown definition on line x – definition on line x is not found
PG is programmer for PIC18 devices, reading input from cb file accessing PIC18Fxxxx, PIC18FxxFxx and PIC18FxxJxx devices. Though PIC18F25K20 was most intensively tested, all other devices from mentioned families should work. Tested were also 18F4221, 18F45J10, 18F4620, 18F26K22.
Assembler is invoked in form
pg <input file>
And in ideal case its output looks like this:
(notice that number of “display” lines was increased in order to fit all data, which would be scrolled up on real device)
This output shows that cb file was successfully loaded, device with ID 0x2079 was found, everything was programmed correctly and FLASH was verified and OK. If verification would find any error, particular byte at which first error was found is outputted.
DE is in-circuit, source level debugger for PIC18 devices. Supported devices are the same as for PG application. It accepts cb files as binary files and ASCII text files as source files.
It is invoked as:
de <cb file> <source file>
After this, debugger tries to load file, erase and program FLASH, and start communication with debug executive and read signature from debug executive. In ideal case it looks like this:
notice that number of “display” lines was increased in order to fit all data, which would be scrolled up on real device). If there is a problem with communication to debug executive, it will stop after line “Waiting for DE”, with option esc to cancel process and enter to repeat it. If this process runs as expected, screen is cleared and debugger windows takes place:
It shows cursor on first position of first row. There are two lines of source code (on row 1 and 2), two lines of options (rows 2 and 3), three lines of selected content (row 4, 5 and 6) and finally status row, showing values of PC, WREG and STATUS.
User can select functions by moving cursor using cursor keys:
Here is cursor moved to SS option (Single Step). After pressing enter, this option is executed:
Notice change of PC and showing second line of code as actual instruction. After pressing enter again (SS option is still selected) another single step is executed:
PC is double incremented again and “clrf trisc” instruction is executed. LEDs on PORTC would light up, if there is valid value on LATC. Another pressing of enter would do another single step:
Notice that PC is increased again and WREG value is changed by last instruction (“movlw 0xcc”). After selecting RS option, reset of target is executed:
Selecting EX option would result in leaving DE application and return to system kernel. RN option will start running of code in target PIC
As application suggests, enter will stop target and allows debugging of target. Second option line allows selecting what will be displayed on content lines while debugging. One can select WA (watch), RA (RAM), FL (FLASH) and BP (breakpoint) options. Default view is WA, user can change it to RA in the same way as for options before:
There are viewable addresses from 0x000 to 0x1B, in twelve bytes. One can also selectFLASH view:
There is viewable range 0x0000 – 0x0009, in six words. After selecting BP view, user can view placement of breakpoints:
There is information about actual breakpoint (at address 0xFFFE, currently unavailable) and breakpoint to be set. Dollar sign shows current line in source code where breakpoint resides.
One can also change range of content lines that are currently showed. We will demonstrate it at watch view; user selects watch view and moves cursor to content line:
After pressing shift button, cursor is “locked” to current address and pressing buttons up or down changes address, while symbol “e” is visible on end of lines, indicating edit mode.
Another press of up key increments address again:
Moving left allows to change higher orders of address:
Pressing shift again “unlocks” edit mode and user can continue debugging.
This way user is able to view any RAM memory address. The same procedure applies to other options (RA, FL or BP).
Debugger is limited to one breakpoint, it is currently unable to export any output. It cannot operate through standard IO mode – it operates only above local display, however it can be run from command line, debug results can be observed only on local display (the same IO limitations as for ED).
Debugger DE is based on my research work, as debug specifications for PIC18 were never published, so I spent a lot of time putting puzzle together. A lot of information was guessed only, however debugging works as intended. For more details about debug mode of PIC18 devices, see my homepage.
07/04/2014 at 09:56 •
All hardware is built around MAX32 development platform, as extension to be stacked on original board, creating compact device.
Extension contains everything needed to turn MAX32 into PIC18 programmer - mainly Vpp generator (voltage to bring on MCLR line to enter programming mode of some PIC18 devices), voltage level converters for data lines, data storage, power supply, keyboard (made from discrete switches) and display (tiny and low-power 98x64 pixels), with strong accent on low power operation. In fact, there is nothing much to add, due to completeness of MAX32 board and usage of PIC32 peripherals.
PIC18 programming interface
This part of circuit is built around Q2 to Q5 and level converters 74LVC1T45.
Q2 is power switch for step-up converter, its base is feeded from PWM generator in PIC32. Depending on frequency and duty cycle, on capacitors C8 to C10 voltage rises above level on C7, C11 and C12. This voltage is brought into voltage divider R5 and R6, dividing high voltage to level suitable for AD converter in PIC32. This allows to implement PID regulator, keeping high voltage at needed level (13,5V for PIC18Fxxxx and 8,5V for PIC18FxxKxx).
Q3 is high-side switch, switching high voltage on its emitter to MCLR target pin (T_MCLR). Q4 is part of switch, enabling Q3 to be switched from 3,3V CMOS PIC32 level. When Q3 is off, Q5 allows T_MCLR to be pulled down.
PGC and PGD lines of target PIC (T_PGC and T_PGD) are controlled by two 74LVC1T45 drivers, what allows target to be powered by 1,8-5,5V source. R13 and R14 are pull-down resistors ensuring logic levels for correct operation.
Data storage is possible in two ways - SPI FLASH memory and Micro SD card.
SPI FLASH memory is currently unpopulated, but there are more options at this position. You can populate SPI FLASH (25VF161 or similar), SPI EEPROM (25LC256 or similar) or SPI RAM (23K256) due to universal footprint.
Micro SD card (uSD) is connected in simpler SPI mode (as opposed to full-blown 4-wire interface), using SPI peripheral of PIC32.
There is option on board to supply target and circuits of upper half of PP4 from separate voltage regulators. EN pins of regulators are brought to PIC32 pins, however this feature is not used now. All circuits are supplied by MAX32 board voltage regulator.
There is also space for MCP73831 charger, this one is unpopulated too.
This part of circuit consists of two main parts - display and keyboard.
Display is small 98x64 pixel LCD, with low power operation (circa 200uA), with IIC interface. This interface uses IIC peripheral in PIC32, allowing easy implementation of this part of user interface. Display is used in text mode (there is no font generator in this device, so it is emulated in PIC), with 8 lines by 16 characters.
Keyboard consists of 20 discrete buttons, because such as complete keyboard is almost unobtainable. Those buttons are not very pleasant to work with, but it is simple, cheap and available solution. Keyboard is arranged into three parts - cursors keys (up, down, left, right) arranged into group of four buttons, alphanumeric area (12 keys to write numbers or letters, the same principle as keyboard of mobile phone) and special keys (enter, escape, shift and backspace).
Except of local keyboard and display, there is option to communicate through serial communication channel, as an alternative terminal. There is kernel command to switch between terminals. Standard communication parameters are 9600 baud, no parity, no handshaking.