• Pic® Basic


  • Serial Debug Bench

    After developing many designs incorporating serial communications, I realised that if I had a simple program that ran on a known stable system, namely a PC, where I could send and receive individual bytes of data quickly, my life would be much easier. On some occasions it is necessary to provide a piece of hardware that responds to serial commands from another source. You can simply use HyperTerminal or a similar terminal program to send and receive data, and this does work very well. But to send and receive multiple commands quickly is not really HyperTerminal’s strong point. I therefore decided that I would learn Visual Basic and force myself to write this code. Almost two years parted and my intentions went from bad to non-existent. Like many of those projects that you yourself probably have lined up in your mind, this was never going to happen unless I had a certain application where I had to develop a custom serial control bench. Well, it happened. I had to develop basic windows front-end application that could control some hardware serially. I used that excuse to develop the application as generically as I could. I would imagine that there are a number of errors within the code, but to be honest, it works very well and I have not yet seen anything that causes any major problems. After using it on three projects, I am now convinced that it was the right thing to do. It saves masses of time in the debug and is good enough to demonstrate and issue to the customer. I did think about selling it, but to be honest, there are far better programs out there that folk have developed that are free and I really have not got any time to mess about for a program that may only sell a handful of copies for a minimal fee. In any case it is not error free and is really only a demonstration platform. If you feel compelled to send me something, then give it to a good charity and send me an email saying what you like about it (Email is at the end of this document).

    Okay, Serial Debug….



    The help file on the program is not really what I would call a help file. This is because I don’t have a program to create help files and I just have not got the time, so I will try to explain how it works here.

    Assigning data to command buttons The program has 20 user configurable buttons where data can be assigned. To alter the data that is sent you must click the ‘APPEND’ option button and then one of the 1 – 20 command buttons. A new window will appear that allows you to set the name of the command button and alter the data to be sent. Data will only be allowed if the syntax is correct. This was probably the most time consuming portion of the program. Hex or ASCII data can be entered but it must follow these simple rules. Hex is entered as 00,01,02,AA,1F etc. All that is needed is a comma to separate the hex values. ASCII is entered between a single inverted comma. For example ‘ASCII’ These made my life easier so don’t ask me to change it. If you need to send a single inverted comma then use the direct text on the main screen. ] You can use a mix of hex and ASCII. For example 00,01,02,AA,1F,’ASCii’,FF I have tried to put as much error trapping in as I could think of. If you find one let me know and I may fix it. The next step is to load the data into the array. If you don’t do this then data will not be saved. Click the ‘Push to load data’ command button. At this point you can look at the array in pure hex form or mixed by pressing the HEX command button. Pressing it again will return back to the mixed data. To check that the data is what you think it is. You can view the stored data in the array by pressing the ‘Read Array’ command button. Once the data has been loaded you can exit and return back to the main program.

    Opening the ports

    Setting the serial transmission configuration is self-explanatory. Choose your desired conditions from the drop down menus. To open the port for communications, push the ‘Open Port’ command button. At this point you will get either an error and the red status bar, or a green status bar and a display of your serial connection

    choice. If you get an error at this point, it means that windows have failed to open the communications port for the particular selection that you made. The usual fault is due to the fact

    that your serial option is not supported by your communications hardware. On my PC 256K baud is not supported.

    You can now open and close the communications port. If you are using the bootload program or any other program that uses the same comport as your selection, then obviously you must close one of the comports to use the program. Click the ‘Close Port at any time. All data is kept static during this closure.

    Loop-Back testing

    I have seen no issues with operation on a dozen or so different PC’s but to perform a simple check you can perform a loop back test. Get a female d-type and connect RX to TX, pin 2 to 3 (I use a 1K resistor). This will make a loopback plug. Connect this to your PC serial port and test the Serial Debug by opening the port and sending data. You should receive exactly what you send. The above screen shot was taken using a loop-back plug at 115200 baud.

    Transmit/Receive windows

    You will notice that the program has 2 text windows. Receive and transmit. If you enter data here, nothing will happen and you will corrupt the data in the windows. I have left them like this so you can copy data from here and save it. You can clear the screen by clicking the clear window command buttons.

    Delay and direct ASCII

    What’s left… I added a direct ASCII window so you can type and send without storing it to a button. This helps you do text on the fly. I was going to add direct keyboard transmit, but I have not got any time left. If I get enough requests I may do it. I did add a button (from a request) that places a delay between every transmitted byte. This is approximate as the receive interrupt will fire when a byte is received. This will push the time delay out. I don’t think there is a need for it to be too accurate but I may work on this area for my own benefit. Delays from 0 to 5 seconds in 10mS steps.

    Clear Before Send/Individual Bytes

    I had a requirement to clear the receive buffers after every transmitted byte. It is sometimes very useful to do this for debug purposes. If this option is selected then it will clear all buffers after each command button is pressed. If you have a multiple byte command then by selecting the ‘Individual Bytes’ option, you will see the program clearing the buffers after every byte sent.

    Saving and loading command buttons

    I added a Save and Load function so you can store your favourite settings. It will store all of the command button data and the serial communications settings. It stores the direct ASCII (commas corrupt the data) and the transmit delay. SERDEFAULT is loaded at run. If you corrupt this file then the program will load up blanks!

    SERIN on Proton

    I have added the SERIN constant that is required by the SERIN statement on Proton. If the serial settings are valid, and the speed results in a positive constant, then you will see a number displayed in the green status bar when you open the port. I have only checked the values with the ones listed in the compiler. I have yet to try it out.

    Running from PROTON+

    You can run this program from within PROTON+ V2.13, it is easy to configure it.

    1. Install this program into your chosen location. 2. Find the ‘Serial_Debug.exe’ executable and move it, along with the serdefault.txt and the proton_demo.txt files, into the external programs file (located in the crownhill/inc/external programs. 3. Load PROTON+ and under the OPTION menu you will see RUN at the bottom. Place your mouse pointer over the RUN and you will now see Serial_Debug. Click it and Serial_Debug will now load. Simple addition to Proton, but very useful.

    Demo Proton Development Board Demo

    I have included a very basic program to show the potential of the Serial Debug Tool. It should be included along with this data. The file is Serial_Degug_Demo.bas. If you have a Proton Development board then you can try this out in a few minutes. I will guide you through the program and its features. First compile and load the code into the development board. Next, connect a serial cable from the Proton+ Development Board to your PC. At this point I hope that you have transferred the Serial Debug Bench executable and the two text files into the Proton+ external programs location. Now run Serial Debug from within Proton+. The Serial Debug Bench should have loaded with the default SERDEFAULT settings (you should see the filename serdefault.txt on the header bar for the Serial Debug Bench. If this file has not loaded then you may not have transferred the two text files across.

    Load the Proton_Demo file into the Serial Debug Bench (it should look like the above screen shot). Now click the clear before send option in the top right hand corner of the Serial Debug Bench. We are now ready to test. Remove the LCD from the Development board as we are only using the LED’s on PORTD. If everything is loaded, programmed and connected you can now open the Serial Debug Bench communications port by clicking the ‘OPEN PORT’ command button. I have already assigned the 20 buttons and they are linked to the program Serial_Degug_Demo.bas. The first 6 command buttons send a request to retrieve data from a specified location within the PIC®. This uses the FSR (File Select Register) within the PIC® to access registers INDIRECTLY. It is a useful tip if you need to peek at the registers in real-time for debugging. I have only included values within page0 or page1. To request any register from page0 you send ASCII 0 and then the hex file address, in hex. For example, to request the PortA register contents you would append the command button to ‘0’,05 This would request register 05 (PortA) from page 0. Similarly, to request TRISB register (Page 1) contents, you would enter ‘1’,86. It is that simple. Try it and see for yourself. Click one of the VIEW buttons and you should receive the binary value of the register contents in the receive window. Buttons further down clear and set the LED’s on PORTD. The random is self explanatory but the command with the * next to it uses the DELAY function of the Serial Debug Tool. I coded a very simple serial receive routine that has no buffering, so this delay is useful to stop data being corrupted. This corruption is due to the processing speed of the PIC® and the speed at which the data is incoming. We can easily create simple repeat like feature by delaying the serial data from the serial port. Try increasing this delay and observe that the Led’s change more slowly. Click the random Led* and you will see the PORTD Led’s change in sympathy with the delay setting. Cool feature. The final six command buttons are to show you how to write a value using the indirect addressing technique. Reset the PIC® and clear the transmit/receive windows on the Serial Debug Bench. Ensure the communications port is open and press the WRITE (‘W’) button. You should now be presented with ENTER PAGE0 LOCATION IN HEX in the receive window. This wants you to give a location for the data to be written, we can do this by clicking the PORTD ($08) command button. The text ENTER WRITE VALUE IN HEX now appears. This is now requesting data to be written to the location specified in the previous command. Click one of the binary values listed (10101010). You should see the LED’s change on the Proton Development Board. What you have done is indirectly altered the contents of the PIC®. This is a very powerful feature that the PIC® devices have inbuilt and should be remembered.

    Limitations

    The Serial Debug Tool was not intended as a terminal program and thus vast amounts of receive serial information will corrupt the program. This is due to the serial receive routines. I intended it to receive a few hundred bytes at the most. If you require a large amount of data to be received then use a terminal program. The one supplied with proton is very good. The transmission from the commands is limited to 256 bytes. The reception is 2048 bytes, however corruption can occur at high data rates.

    Summary

    Well I think that is about it. I am pretty sure that I have covered everything. If you do find a problem or think of a good addition then let me know and I will try to fix or update the code. I do not want to release the source, but may sell it if you find a requirement. If you want to contact me, you can send me a private message from the PROTON+ forum. I am JonW. Have Fun and I hope that you find it as useful as I do.

    ' TITLE: SERIAL_DEBUG_DEMO
    ' AUTHOR: JONATHAN WALKER
    ' DATE: JAN 06 2004
    ' COMPANY I WISH...
    '************************************************* ***********************************************
    ' NOTES

    ' VERY SIMPLE PROGRAM TO DEMONSTATE THE USE OF THE SERIAL DEBUG TOOL
    ' DISCONNECT THE LCD FROM THE PROTON+ DEVELOPMENT BOARD
    ' LOAD SERIAL DEBUG TOOL WITH PROTON_DEMO.TXT


    Include "PROTON_4.INC"

    TRISB = 001111 ' ONLY RB0 IS INPUT
    TRISD = 000000

    Dim BYTEIN As Byte
    Dim LOCATION As Byte
    Dim WRITEVAL As Byte

    DelayMS 600 ' WAIT FOR PIC® MICRO TO STABILISE
    Clear ' CLEAR ALL RAM


    RECEIVE:
    While 1 = 1 ' CREATE AN INFINITE LOOP
    HRSin {5000, TIMEOUT}, BYTEIN ' RECEIVE A BYTE

    Select BYTEIN ' DECODE RECEIVED BYTE

    Case "1"
    HRSin BYTEIN ' GET SERIAL BYTE
    movf BYTEIN,W ' LOAD INTO WORKING REGISTER
    bsf STATUS,RP0 ' PAGE 2
    movwf FSR ' LOAD RECEIVED BYTE INTO FSR
    movf INDF,W ' GET DATA POINTED TO BY FSR INTO WORKING REG
    bcf STATUS,RP0 ' BACK TO PAGE 0
    movwf BYTEIN ' TRANSFER W TO HOLDING REGISTER
    HRSOut BIN8 BYTEIN ' SEND OUT DATA IN BINARY FORMAT

    Case "0"
    HRSin BYTEIN ' GET SERIAL BYTE (WILL BE IN PAGE0 IN THIS PROGRAM)
    movf BYTEIN,W ' LOAD INTO WORKING REGISTER
    movwf FSR ' LOAD RECEIVED BYTE INTO FSR
    movf INDF,W ' GET DATA POINTED TO BY FSR INTO WORKING REG'
    movwf BYTEIN ' TRANSFER W TO HOLDING REGISTER
    HRSOut BIN8 BYTEIN ' SEND OUT DATA IN BINARY FORMAT

    Case "W"
    HRSOut CStr TEXT1 ' SEND OUT REQUEST FOR LOACTION
    HRSin LOCATION ' RECEIVE LOCATION
    HRSOut CStr TEXT2 ' SEND OUT REQUEST FOR WRITEVAL
    HRSin WRITEVAL ' RECEIVE WRITEVAL

    movf LOCATION,W ' GET LOACTION INTO WORKING
    movwf FSR ' WRITE LOCATION VALUE TO FSR
    movf WRITEVAL,W ' GET WRITEVAL INTO WORKING
    movwf INDF ' LOAD WRITEVAL DATA INTO LOACTION POINTED BY FSR

    Case "C"
    comf PORTD ' COMPLIMENT PORTD
    Case "J"
    HRSOut CStr TEXT3 ' SEND OUT TEXT

    Case "X"
    PORTD = Random ' PORTD RANDOM

    Case Else
    HRSOut CStr TEXT4 ' SEND OUT TEXT

    End Select

    Wend ' CLOSE THE LOOP

    TIMEOUT:
    GoTo RECEIVE ' ENTER CODE HERE FOR TIMEOUT

    TEXT1: CData "ENTER PAGE0 LOCATION IN HEX",0
    TEXT2: CData "ENTER WRITE VALUE IN HEX",0
    TEXT3: CData "(C) JON WALKER 2004",0
    TEXT4: CData "CMD NOT RECOGNISED",0


    Stop ' AND STOP HERE UNTIL RESET PRESSED
    Serial Debug.zip

    contributed by Jonathan Walker.
  • Recent Activity

    SimonJA-751

    Replace Label with String

    Thread Starter: SimonJA

    I would like read font data in a procedure using Cread something like this: dataOut = CRead8 myFontFile Where myFontFile is a string in...

    SimonJA Yesterday, 21:37 Go to last post