SoftUART - A free PIC debugging tool for the masses. - Page 1
Forum section: electronics / general

author: caroper
author_rank: Regular Contributor
timestamp: February 25, 2013, 05:55:02 pm
content: The oldest, most portable and easiest to use Debugging tool for Microcontrollers and Microprocessors has always been the RS232 Serial port and a Dumb Terminal or a Terminal Emulator. At an absolute minimum it can occasionally spit out a value on the Serial port to indicate where it is in the Software, indicate that a particular subroutine has been called or to show the contents of a critical Variable. All that is required is one wire. Add a second wire and the terminal can issue commands to the DUT (Device Under Test) to control the flow or respond to menu options. Even when equipped with an ICD (In Circuit Debugger) it is often still useful, and easier, to have the DUT interact with a debug console. The Baseline and Mid Range parts don’t have any built in support for debugging anyway, so the ICD3, PICKit3 and PICkit2 devices are relegated to the programming role only.However, not all Microcontrollers offer a hardware UART, certainly not the Baseline and some of the Mid Range PIC’s, and even when they do have one it may well be needed as part of the application and so not available for debugging, leaving the developer with no option but to use one of the scarce pins to drive an LED and possibly another to read a button, just to get a rudimentary debugging facility and confidence that the device is even running. The second problem is that additional external Hardware is required to convert the UART output levels into a form compatible with RS232. The usual solution is to add a MAX232 or equivalent chip to the design, increasing the cost and the board complexity. FTDI Chips and a USB Virtual Serial Port are another common solution but they are only available in SMT packaging which rules them out of a lot of hobbyist designs.SoftUART is intended to address all of the above problems and allow everyone access to free debugging tools, or at least to make the most of the tools you already have. It is written in XC8, the free C compiler from Microchip, it uses only Timer0 (without interrupts) which is available on even the smallest of the Baseline PIC’s and it allows you to use any available Pin’s for the Tx and, optionally, Rx lines. It has the advantage that it’s minimal requirements should support all of the 8 Bit families of PIC Microcontrollers and still be a useful tool all the way up to and including the PIC32 family as well.The cherry on the top is that it can talk to a serial port equipped PC without any external hardware. (OK 2 resistors and a DB9 Female, but no active devices, MAX232 or FTDI chips), and it even uses the pins you would have dedicated to an LED and button. It comes at a cost in the form of Program memory, using the Free version of XC8 it requires about 136 words of program flash, which on a Baseline or Midrange PIC can seem quite a lot. It represents 14% of the PIC12F675, but in terms of functionality it punches well above its weight, and if you are running low on Flash you can always disable it and free up the memory.The CodeI can’t claim all the credit as my code is based on the work of Roman Black (http://www.romanblack.com/) one of my favorate and most esoteric of PIC code optomisers. Take a look at his page, it is both entertaining and inspirational. Romans code was part of a PIC18 project and introduced the concept of the Hardware Free RS232 connection (http://www.romanblack.com/bitbangserial.htm).Inspired by its potential, I converted Roman’s code from MikorC to XC8 for portability, changed it to use Timer0 to reduce its hardware dependency and adapted it to provide both Normal and Inverted RS232 protocols so that it is equally at home driving the PICkit Uart Tool, an FTDI cable or Directly connected to a PC RS232 Port. Full details of how I did it and the Tools involved will be in a separate tutorial, but as that is taking so long to write I decided to release the code here first so that everyone can benefit.This version is configured for the PIC12F675 and is ready to run with Roman's RS232 Hardware Hack at 19200 BAUD. The comments should be sufficient for most PIC coders to adapt it to other hardware, for the beginners, you will just have to wait for my Tutorial post.Here is a post on building the hardware:https://www.eevblog.com/forum/microcontrollers/tutorial-advanced-debugging-and-code-porting-with-mid-range-pics/msg196232/#msg196232CheersChrisp.s. To try it out on the Low Pin Count Board with a PICkit2Modify the line:#define SER_BIT0 to read #define SER_BIT 1Change the target device to suit your chip and compile the code in either MPLAB 8.x or LABX with XC8 installed.Use the PICkit2 External software to program the chip and then select TOOLS->UART Tool.Set the Baudrate to 19200 and press connect.Whatever you type will echo back in the UART Tool.

author: fcb
author_rank: Super Contributor
timestamp: February 25, 2013, 09:32:26 pm
content: I'm going to disagree abit.John Morrison (UK) in the early 90's built a little LPT driven board that could do a good emulation (not at full speed) of various 16C/16F pics (my favourite was the 16C71/16F84 emulator). These had a two or three IC's only on them (something like a '373 and an 8 bit ADC - $3 of parts).They did an amazing job until I could afford the full-blown microchip ICE (including Mike Harrison's WWL PCMCIA adaptor).

author: brainwash
author_rank: Frequent Contributor
timestamp: February 25, 2013, 09:51:49 pm
content: Good posting. I have been using Roman's code for years now exactly for this reason, across the whole range of 8-bit PICs. Unfortunately I had to rewrite (refactor) it for almost each different device and compiler combination, so it pays attention to spend an extra 30 minutes (at most) to understand exactly how it works so that everyone can port it correctly.The reason why it's so nice compared to the soft-uart implementations is that it has an small timing errors are averaged.With internal RC oscillator (4 or 8MHz) I have used this successfully at up to 19200 baud. I've never needed to go higher, but I don't remember ever getting a stray bit.Roman has some nice code examples and general design decisions but unfortunately he is kind of slow with the updates

author: Jon Chandler
author_rank: Frequent Contributor
timestamp: February 25, 2013, 10:40:19 pm
content: As an extension to this, if you select the RxD and TxD pins to correspond to the PICkit 2 UART tool, you can program via ICSP, then switch over to the UART tool to monitor output without the Ned to swap connections.

author: caroper
author_rank: Regular Contributor
timestamp: February 26, 2013, 08:33:58 am
content: Yes, that is why I chose GP0 for Tx and GP1 for RX, they are the ICSP pins and are often left available in most designs to use with debugging.You will also notice (if using the Low Pin Demo Board that is supplied with the PICKit2) that Pin 6 of the ICSP is connected to GP4. I use that in the Tutorial (Still to be posted) to provide Timing Pulses for the Logic Analyser Tool in the PICkit2. That way you can use the PICkit2 as a programmer, developers Terminal and Logic Analyser, all without having to unplug it between test samples.CheersChris

author: caroper
author_rank: Regular Contributor
timestamp: February 26, 2013, 06:39:31 pm
content: The Tutorial is up and running here:https://www.eevblog.com/forum/microcontrollers/tutorial-advanced-debugging-and-code-porting-with-mid-range-pics/Remember it is a work in progress, so far it covers up to sending a byte to the Logic Analyser and RealTerm.CheersChris

author: Unknown
author_rank: Unknown
timestamp: February 26, 2013, 07:39:43 pm
content: Nice work! I use something similar on 2 pins except I send the data via bluetooth for remote debugging and I just do the timing in code rather than use the internal timer.

author: Ata
author_rank: Contributor
timestamp: February 27, 2013, 11:41:24 am
content: This is a very good idea... But, on small pics 8pin-Dip (like a 12F675, 12F1840, etc) 2-pin interface for debugging is too much and Timer0 is a very valuable pic resource to leave it for the debugger.That's why I designed a poor's man ICD.. As an interface to the PC it only needs 1x PIC16F628 and a dual optocoupler on a 1"x2" single layer pcb and a terminal prog like Hyperterminal or Putty.It has a 1-pin interface on any (user selectable) pic-I/O. It doesn't use any pic's resource.Only takes no more than 150 prog-words and 5 data-reg. You can place as many BreakPoints as you need. Only 10 commands to use that allows you to view/edit the Data or EEdata area, write /read any pic' SFRs and more.You can GO or CALL any prog-line and handles the user-code interrupts.It can be used on any 8-bit pic (12Fxxxx, 16Fxxxx, 18Fxxxx).It can be connected to a USB using any cheap USB-Serial cable and it floats... Allowing you to debug pic-apps connected directly to the mains AC-line on power electronics like driving TRIACS, MosFets on a High Voltage H-Bridge,... etc..All the software, sources, pcb and docs are attached... any opinion (destructive or constructive) are welcome.

author: caroper
author_rank: Regular Contributor
timestamp: February 27, 2013, 01:48:19 pm
content: Thanks Ata,That looks like a very useful and well designed tool indeed.I have not had a chance to read your documentation in full but, based on a quick skim and your description, I think I will go ahead and build one to try out.Whilst your solution is way more elegant than this one for debugging, I still find this to be very useful on the basis that it can be implemented across the entire PIC family, all the way up to the PIC32's, is dirt cheep, just 2 resistors, the Timer is only used whilst sending or receiving and software timing could be used instead, it is not generating interrupts so is still available to the application in may cases and you don't have to dedicate 2 pins to it, one is sufficient and could even be shared with an input.It is also more than just a debugging tool, it can be used to connect to sensors if your PIC has no UART's or if the UART is being used for SPI etc.Thanks again for the info,CheersChris

author: Ata
author_rank: Contributor
timestamp: February 27, 2013, 09:37:03 pm
content: Hi ChrisYou are right, the softuart is more friendly and easier to use....The poor's man ICD I posted was only and alternative... nothing more..I have a very fast, short and efficient softuart code that works in background, in other words,, It works by interrupts,So the main code that uses this softuart can do anything between bits and bytes sent..It also allows multiple instances.. Up to four softuarts at different baudrate working at the same time..If you think it is useful to you, I can send you the assembler source code of it and a demo code to test it.

author: caroper
author_rank: Regular Contributor
timestamp: February 28, 2013, 06:46:26 am
content: That would definitely be useful,I don't think you can ever have too many proven code snippets and every library needs good comm's modules.I avoided interrupts for this one, for the sake of the baseline PIC's but on Midrange and above the option to use interrupts is a great bonus, especially for things like communications.CheersChris

author: caroper
author_rank: Regular Contributor
timestamp: February 28, 2013, 09:58:46 am
content: For anyone keen to try the SoftUART implementation but have not been following the related Tutorial, here is a link to my post on building the Hardware portion:https://www.eevblog.com/forum/microcontrollers/tutorial-advanced-debugging-and-code-porting-with-mid-range-pics/msg196232/#msg196232CheersChris

author: metalphreak
author_rank: Frequent Contributor
timestamp: March 06, 2013, 09:07:21 am
content: There's a software UART in the XC8 library. It's not included in the PDF manual. It also doesn't workThere's no stop bit implementation. Someone on the microchip forums emailed support, who replied with working code. This was before the latest release of the compiler. It's still not fixedThis looks like a better solution anyway. ThanksIt's also handy when you have one of the PIC chips with hardware UART but it uses the same pins as I2C or SPI...