(Standalone) Debugger

[David VB]

Hi there,

Apparently simple question (please don't laugh at me).

Until now I usually "debug" my programs by making a LED blink at different stages of the program.

I would like to go further and display more useful information.

I see two methos:

- A PC with a terminal to display values sent on the serial (TX) output of the PIC (with the help of an RS232/USB converter)
- A LCD display directly connected to the PIC

I do have a 2x20 LCD that can be connected by either I2C, SPI, or RS232 (RX only)
( https://newhavendisplay.com/content/specs/NHD-0220D3Z-NSW-BBW-V3.pdf )

In the RS232 mode, it whould take only one pin on my application PIC.

How to I define the strings to be send to that display ?
var byte text_string[] = "ABC" and then send text_string[i] one at a time with the help of the serial module ?

Is there an exemple somewhere in the lib where I could see how constant strings are defined and send on RS232 ?

(Note that I can also use I2C, but that takes 2 pins, of course...)

Thanks

David

[Rob CJ]

Hi David,

Using the RS232 connection is the easiest. I always use the serial interface for debugging.

Some thing to consider. If you use the display you need to send control commands first so it is not straight forward. If you use a PC with a USB to Serial connection you need some electronics to change the RS232 signals levels to TTL levels since it works with different voltage levels. You can make it with a MAX323 or you buy a module:

https://nl.aliexpress.com/item/1005002384613879.html

CP2102 Usb 2.0 Naar Uart Ttl 5PIN Connector Module Serial Converter Stc Vervangen FT232 CH340 PL2303 - NL.AliExpress Smarter Shopping, Better Living! Aliexpress.com nl.aliexpress.com

The advantage of using it with your PC is that you can use the JAL print library to make your live easier since it supports printing strings, bytes, word, etc.

About printing constant strings, there are serveral ways to do that. For example.

const byte MY_STRING[] = "This is my string"

You can then use the serial hardware library and print llibrary, like: print_string(serial_hw_data, MY_STRING)

If you do not want to use the print library then this is an option which you can also use for your display (once initialized with the correct commands):

   var byte index

    for count(MY_STRING) using index loop

        serial_hw_data = MY_STRING[index]

    end loop

Hope this helps.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens David VB <pinhe...@gmail.com>
Verzonden: dinsdag 21 januari 2025 13:06
Aan: jallist <jal...@googlegroups.com>
Onderwerp: [jallist] (Standalone) Debugger

 

--
You received this message because you are subscribed to the Google Groups "jallist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallist+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jallist/5414d413-0aee-4eae-b94d-841c7b325830n%40googlegroups.com.

[David VB]

Hi Rob,

Thanks for your answer.

I have a CH340A-based (never used) "stick" laying around, but sometimes my PC is not in the vicinity of the circuit I have to debug, this is why I also need a "portable" solution.

Thank you for your code example: these will be of great help !

Have a nice day

[David VB]

Hi again,

I tried to output some commands through the serial interface, but apparently, nothing is output (I tested with a logic analyzer)
I changed the defaut TX pin to RB6 by means of the PPS (see attached source code).   Would it be the source of the error ?

I simplified the code to the maximum: therefore I did not use serial_hardware_init, because I was not sure it worked (no output either)

(The used libraries are from Jallib 1.9, and the PIC used is 16F1713)

Any help welcome!

Thanks,

David.

[Rob CJ]

Hi David,

I always struggle with PPS but I did an attempt to fix it in your code, see attachment. It is not tested.

I also added a hint on how to sent data to the serial port, see two comments that start with @David.

If you have any questions, let me know.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens David VB <pinhe...@gmail.com>

Verzonden: zaterdag 1 februari 2025 18:07
Aan: jallist <jal...@googlegroups.com>
Onderwerp: Re: [jallist] (Standalone) Debugger

 

To view this discussion visit https://groups.google.com/d/msgid/jallist/fcea69bb-cf64-4562-8c2f-3adc6ad0d041n%40googlegroups.com.

[FraserSmith51]

I have used the following code successfully for a while now.

const serial_hw_baudrate = 9600

; Aliases for the USART pins            -- (not declared in the device files)

alias pin_TX            is  pin_c5

alias pin_TX_direction  is  pin_c5_direction

-- ok, now setup serial

include delay

include pps

include new_pic_data_eeprom

include serial_hardware

include print

; setup pps pins for serial OUTPUT----------------------------------------

pps_control_lock(FALSE)                 -- unlock PPS module

;RXPPS  = PPS_RC5                        -- pin_RX is on pin_c5 (INPUT)

RC5PPS = PPS_TX                         -- pin_c7 is pin_TX (OUTPUT)

pps_control_lock(TRUE)                  -- lock PPS module

serial_hw_init()

print_string(serial_hw_data,"serial started\r\n")

Here is some code to write values to TX with a tab between and a bit of text and then a new line

print_dword_dec(serial_hw_data,current_position)

print_string(serial_hw_data,"\t")

print_word_dec(serial_hw_data,current_speed)

print_string(serial_hw_data," dec\r\n")

HTH

Fraser

[FraserSmith51]

Forgot to remove a couple of lines. The new_pic_data_eeprom was a modification I made to allow reading and writing of byte*3. You won't need delay unless you need it for your program.

Good luck with it

Fraser

[Pinhead]

Hi Rob,

Thanks for your help.   I will not be able to test today (sunday = family time), but my problems are that RB7 cannot be assigned to RX since it is used for something else.   In fact, every pin except one (RB6) are used in my app.

As for the reason I did not use serial_hardware is that I think it is not compatible with 16F1713, because in serial_hw_init, it is treated has a "classic UART type" and configures the TX pin as input.   Maybe you could have a look there ?

In the meantime, I detected that I forgot to enable the transmitter: 

TX1STA_TXEN    = 1  ; Enable transmitter

(Not tested yet either)

I'll answer the mail of FraserSmith

Thanks to all, and enjoy your Sunday (plenty of sun here in Belgium :-) )

David

Le 02-02-25 à 09:11, Rob CJ a écrit :

You received this message because you are subscribed to a topic in the Google Groups "jallist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jallist/tt-i0mbIHlY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jallist+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/jallist/AM7PR02MB609803EAA7941582FFB16B97E6EA2%40AM7PR02MB6098.eurprd02.prod.outlook.com.

[Pinhead]

Thanks Fraser,

See my answer to Rob earlier: I think that serial_hw_init() may not be compatible with 16F1713, reason why I initialize the USART directly (and I forgot to enable the transmitter, doh !)

I'll test all your suggestions this evening or tomorrow, and keep you posted.

Thanks to all !

David

Le 02-02-25 à 11:22, FraserSmith51 a écrit :

To view this discussion visit https://groups.google.com/d/msgid/jallist/9cbd78bf-78b2-4491-916c-920c25d36da1n%40googlegroups.com.

[Rob CJ]

Hi David,

If the serial_hw_init() does not work for this PIC I will have a look at it. Libraries should work for all PICs.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Pinhead <pinhe...@gmail.com>
Verzonden: zondag 2 februari 2025 12:56
Aan: jal...@googlegroups.com <jal...@googlegroups.com>

To view this discussion visit https://groups.google.com/d/msgid/jallist/aff5a1e5-0440-4bc3-86d3-50fcf2109f3a%40gmail.com.

[David VB]

Hi Rob,

i tested your version using serial_hardware:

- At first run, nothing appears on the display

- Then, every time a press a /MCLR button, one character appears right to the previous one, and this character, given the datasheet of the display is 0xFC

About the compatibility of the library (without a debugger to validate my hypothesis), as I understand the initialization:

- 16F1713 does not have a register U1CON0 defined

- however, it has a PIE1_RCIE bit defined
then the following aliases are defined:

alias SERIAL_TXIE is PIE1_TXIE

alias SERIAL_TXIF is PIR1_TXIF

alias SERIAL_RCIE is PIE1_RCIE

alias SERIAL_RCIF is PIR1_RCIF

and that is correct.

Now, let's examine serial_hw_init:

- Again, 16F1713 does not have U1CON0 defined

- then, in the "else" branch ("classic UART type"), among other things, it defines

pin_TX_direction = INPUT -- make transmit pin input!

-- (required by some older ..

-- .. PICs like 16f628)

and this does not seem ok for a 16F1713 (i checked the errata)

So, I added pin_TX_direction = OUTPUT

in the main program just after the call of serial_hw_init

It does not work either, but it now displays a character that is not even described in the DS of the display, a double vertical line || in one character

I connected my oscilloscope, and except a small 0 Volt glitch, the pin remains high

I don't know what to do next....

(I will post another message on the topic of being able to run a debugger on the "old" asm code for newer PIC's)

[Rob CJ]

Hi David,

I had a short look yesterday  and I could not spot the error yet. 

I know about the input and I tested it yesterday to make it output but that does not change and by enabling the USART it is automatically made output. I tested it with a 16F1716 which is of the same family.

I find it strange that it does not work since the USART used by your 16F1713 does not seem to be different. It might still be a PPS problem, that happened to me before.

I will have a look at it this weekend.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens David VB <pinhe...@gmail.com>

Verzonden: maandag 3 februari 2025 14:17

To view this discussion visit https://groups.google.com/d/msgid/jallist/ddc4dca4-7056-41d6-9751-f804147af77bn%40googlegroups.com.

[David VB]

Hi Rob,

When you tested with a 16F1716, did it work ?

If so, would you care to share your code, so that I can test it also with the 16F1713 ?

I tested with a brand new 16f1713, on a breadboard, without re-assigning the pins with the PPS.

I tried using serial_hardware_init(), and/or my own instructions, it did not work: Nothing on the output (tested with a logic analyzer and a scope).

Tomorrow, I will add the code for making a LED blink in the forever loop to test if the PIC is running.....

In the meantime, you'll find in attachement the code I used (one of the version, since I made multiple tests by commenting/uncommenting some code)

For the record, I use Jallib 1.9, un-modified, and compiler v25r9 on Linux Mint
MPLAB IPE 6.20 and PicKit3 for the programming itself

Kind regards,

David

[Rob CJ]

Hi David,

I updated your program. I saw that your are now using pins C6 and C7 so I used those. If you put the new device file in the same directory as this program or you just overwrite the existing device files in your Jallib\lib instllation it should work.

I tested it last week by replacing PPS_TX by 0x14 since in the device file it was set to 0x00. In  your new device file it is now set to 0x14. All other PPS values are now also correct in the new device file. I uploaded the updated device files to GitHub so they will be in the next bee-package or the upcoming Jallib release.

BTW. I removed all the code that you used to initialize the serial interface since that is no longer needed and may interfere with the serial library. I also commented out the 'usart_hw_serial = TRUE'  at the start of your program since by default it uses asynchronous mode. The less code, the better 🙂

If you still run into issues let me know.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens David VB <pinhe...@gmail.com>

Verzonden: vrijdag 7 februari 2025 17:38

To view this discussion visit https://groups.google.com/d/msgid/jallist/10a6acbe-5a28-4e14-939d-3fa81fa5e6ccn%40googlegroups.com.

[David VB]

Hi Rob,

I used RC7 and RC6 on the breadboard because they are the default pins for UART, so that I could get rid of the PPS.

Anyway, I tested again your code, once on RC7/RC6, and once on RB7/RB6, but it gives nothing.  

When you tested, did it work ?

 
Tested with my scope, and 4 different logic analyzers (Scanalogic 2, Scanalogic SQ25, Salea16 and LA104 --- Yes I like logic analyzers ;-)   )
I did so many tests because, you'll never know, one input of one logic analyzer could be burnt.....

I give up -- I already lost too much time on this (2 weeks !)

My main project does not use UART for debugging anyway, this was only to have a standalone debugger when no PC is available near the prototype.

Thanks for your help and enloy your week-end.

Kr,

D.

[Rob CJ]

Hi David,

Even if you use the standard pins like RC7 and RC6 you always must use PPS otherwise it will not work.

I tried it with a PIC16F1716 and it works fine but only with the device files that I had sent you.

Attached the test program that I used.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens David VB <pinhe...@gmail.com>

Verzonden: zaterdag 8 februari 2025 15:52

To view this discussion visit https://groups.google.com/d/msgid/jallist/4958a81b-8aca-49d1-a64b-7ed20a0a99fan%40googlegroups.com.

[Rob CJ]

Hi David,

I did a test using pins B6 and B7. Works fine.

Please try with the attached example

Thanks.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob CJ <rob...@hotmail.com>
Verzonden: zaterdag 8 februari 2025 17:06
Aan: jal...@googlegroups.com <jal...@googlegroups.com>

To view this discussion visit https://groups.google.com/d/msgid/jallist/AM7PR02MB6098A480FB8E174F337F8D7BE6F02%40AM7PR02MB6098.eurprd02.prod.outlook.com.

[Pinhead]

Hi Rob,

Thanks again for the effort.   I will test this evening or tomorrow, and keep you informed.

In the meantime, I had a look at Jallib 2.0beta, and indeed, regarding the PPS Ouputs constants, the device file (at least for 16F1713) is now correct.

Do you plan to make the same correction for 16LF1713 and the other ones impacted, or will you wait that Microchip corrects their own device definitions ?
(Note that I will not use 16LF1713 anytime soon, and that I rarely use LF pic's anyway; but other people might)

Kr

David

Le 09-02-25 à 10:52, Rob CJ a écrit :

To view this discussion visit https://groups.google.com/d/msgid/jallist/AM7PR02MB609821E410E0D0B2DBD4EA77E6F32%40AM7PR02MB6098.eurprd02.prod.outlook.com.

[Rob CJ]

Hi David,

You're welcome.

Good point about the LF versions, I forgot those. I will adjuist the script and create them.

Question for Matt: Do you want these 2 LF device files to be added or should I just leave the beta release as it is?

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Pinhead <pinhe...@gmail.com>
Verzonden: zondag 9 februari 2025 14:20

To view this discussion visit https://groups.google.com/d/msgid/jallist/00aec449-b97f-419e-9e4d-9261c0c35933%40gmail.com.