Activity for GCBASIC
-
Anobium posted a comment on discussion Open Discussion
I have rechecked the moment usage again. All looks ok. The memory and alias usage is compliant with the 0x500–0x24FF range, with only two aliases (AFSR0, AFSR0_H) below the lower bound of 0x500 which is correct as these are FSR0L and FSR0H respectively. No memory addresses exceed the upper limit. I think we have to rule of the ring buffer and the use of HSerReceive(). Currently, you have extensive use of the function HSERRECEIVEFROM(2). This function set the Comport variable then calls sub HSERRECEIVE...
-
I have looked into the Q10 core issues in July 2020. The change log shows two changes 1) Correction of the .DAT to ensure the Sector RAM was excluded from normal RAM operations 2) A correction in the compiler to ensure TBLPTRU was appropriately managed on Q10 chips with less than 32768 bytes of PROGMEM. Neither of these would impact a Q43 as the Q43 does have Sector RAM and the Q43 has more than 32767 bytes of PROGMEM (so, the TBLPTRU is being managed appropriately in the Q43 as we can see from the...
-
ikonsgr74 modified a comment on discussion Open Discussion
i don't remember details after so many years, but according to the old topic: https://sourceforge.net/p/gcbasic/discussion/596084/thread/5398dd8bc1/?limit=25&page=1 quoting: Another thing i noticed is that you place all elements in one row,i use multiple rows in mycode, you think that large amount of elemen lines can cause problems too? UPDATE]: i try to use much lesser lines of elements in each table (i had ~40 elements/line, now i have 1000/line), and it seems that problem is fixed (at least for...
-
i don't remember details after so many years, but according to the old topic: https://sourceforge.net/p/gcbasic/discussion/596084/thread/5398dd8bc1/?limit=25&page=1 quoting: Another thing i noticed is that you place all elements in one row,i use multiple rows in mycode, you think that large amount of elemen lines can cause problems too? UPDATE]: i try to use much lesser lines of elements in each table (i had ~40 elements/line, now i have 1000/line), and it seems that problem is fixed (at least for...
-
i don't remember details after so many years, but according to the old topic: https://sourceforge.net/p/gcbasic/discussion/596084/thread/5398dd8bc1/?limit=25&page=1 quoting: Another thing i noticed is that you place all elements in one row,i use multiple rows in mycode, you think that large amount of elemen lines can cause problems too? UPDATE]: i try to use much lesser lines of elements in each table (i had ~40 elements/line, now i have 1000/line), and it seems that problem is fixed (at least for...
-
I have compiled the .s here. As you say - no errors or warning. Remind me how we resolve the Q10 issue.
-
i made a few more tests using a serial connection between PC and Amstad CPC. Initially it wroks ok (i can get catalogues of directories in PC to Amstrad CPC screen), but when i'm trying to load something it crashes. This really resembles the symptoms we got with 18F47Q10 when it couldn't read correctly bytes from large byte tables written in PIC's flash memory. Btw ,here is the .s file produced
-
i made a few more tests using a serial connection between PC and Amstad CPC. Initially it wroks ok (i can get catalogues of directories in PC to Amstrad CPC screen), but when i'm trying to load something it crashes. This really resembles the symptoms we got with 18F47Q10 when it couldn't ad correctly bytes from large byte tables written in PIC's flash memory. Btw ,here is the .s file produced
-
Ok, i re-update GCB and it works. I compile project with PIC-AS compiler and create an .s file. I didn't get any errors upon compiling.
-
Can we do a conf call to get this sorted? Please
-
i tried modern studio mode but still i got an error when tried to open programmer preferences:
-
btw i'm using Legacy studio mode as i'm used to it for many years :-)
-
When i try to edit programmer preferences (to change the assembler) i get this:
-
You need to compile using PIC-AS as MPASM ( the Q43 is meant to be supported by MPASM ) is throwing some odd errors. You could install PIC-AS from https://sourceforge.net/projects/gcbasic/files/Support%20Files/MicrochipCompilers/xc8-v3.00-full-install-windows-x64-installer.exe/download and then select PIC-AS as the assembler. PIC-AS will validate the ASM generated. Think of PIC-AS validating the ASM and ensure that any potential issues in GCASM are eliminated. PIC-AS takes only a few seconds more...
-
Your chip is a good chip. The Microchip errata did show a mega issue for earlier versions of this chip type. I will look at asm now.
-
The "Rom Code" where the problem occurs, is the Table named: RSX_CODE
-
From PICKIT4 output: Target device PIC18F47Q43 found. Device Revision Id = 0xa0420000 Device Id = 0x74a0 When you say "ASM" you mean the asm file produced by GCB compiler right?
-
From PICKIT4output: Target device PIC18F47Q43 found. Device Revision Id = 0xa0420000 Device Id = 0x74a0 When you say "ASM" you mean the asm file produced by GCBcompiler right?
-
Ok. To get the revision look in the PickitPlus GUI that shows the revision. We need that revision to ensure the silicon is safe to use. So, changing the DAT proves the buffer was not the issue. Send me your ASM. I will inspect the memory allocation.
-
Ok. I understand, thanks. Can you confirm that this resolves your PRINT issue. You can add both routines only the one you actually use will get included in your assembled hex. We have PICKIT2 for sale in my website. www.pickitplus.co.uk Get the hardware and software. I will do a special price so please contact me directly before you proceed.
-
Ok, i change in 18F47Q43.DAT file: 'This constant is exposed as ChipMaxAddress MaxAddress=9471 and re-compile, unfortunately no changes, i still get the same erratic behavior and hung ups... My PIC18F47Q43 has "2032MOC" on it, and purchased from MICROCHIP directly a few years ago.
-
c-conversion posted a comment on discussion Compiler Problems
Thanks for the update and the explanation. I'll be unable to test the HSerPrint routine as this is not something I've used and have no method of connecting a PIC device to any PC. I have something in the back of my mind that suggests a PicKit has this facility, but I no longer have one. The Print routine I should be able to add. I generally use an LCD display for my projects. All my prototyping is done with an LCD, possibly a serial LCD if I'm short of pins, but almost always have an LCD. If not...
-
Can we check the basics? What revision is the Q43? Where was the Q43 sourced from? That old thread refers to chipdata file issue. So, I have compared to Datasheet and JAL. These are my references. The Q43 have a different memory model from the Q10. So, I want you to remove the memory buffer (page 71 in the datasheet) from DAT file. Change and test. 'This constant is exposed as ChipMaxAddress MaxAddress=9727 to 'This constant is exposed as ChipMaxAddress MaxAddress=9471
-
Ok, i'm asking because, despite correct basic funcntion of USART port, i still have problems when trying to connect a CH376 usb host module. I manage to "pinpoint" the problem where code execution freeze (e.g. reading bytes from a large 16k table written in PIC's flash memory, table acts as ROM for the board reading Z80 asm code) when a command byte sequence is sent from PIC to host module, and i never get a response for no obvious reason... I also experience other erratic problems, which reminds...
-
Ok, i'm asking because, despite correct basic funcntion of USART port, i still have problems when trying to connect a CH376 usb host module. I manage to "pinpoint" the problem where code execution stack (e.g. reading bytes from a large 16k table written in PIC's flash memory, table acts as ROM for the board reading Z80 asm code) when a command byte sequence is sent from PIC to host module, and i never get a response for no obvious reason... I also experience other erratic problems, which reminds...
-
Ok, i'm asking because, despite correct basic funcntion of USART port, i still have problems when trying to connect a CH376 usb host module. I manage to "pinpoint" the problem where code execution stauck (reading bytes from a large 16k table written in PIC's flash memory, table acts as ROM for the board reading Z80 asm code) when a command byte sequence is sent from PIC to host module, and i never get a response for no obvious reason... I also experience other erratic problems, which reminds the...
-
Thank you for the code. Really helps. Root Cause of the Compilation Issue The issue stemmed from a missing subroutine to handle a bit parameter passed to a subroutine in GCBASIC. After extensive debugging, the assembly (ASM) code has been corrected, ensuring the generated HEX file is accurate. Why Did One Print Function Work and Not the Other? The behavior is complex and relates to how GCBASIC matches function calls to subroutines: Errant Case: In the original code, GCBASIC selected a subroutine...
-
Thank you for the code. Really helps. Root Cause of the Compilation Issue The issue stemmed from a missing subroutine to handle a bit parameter passed to a subroutine in GCBASIC. After extensive debugging, the assembly (ASM) code has been corrected, ensuring the generated HEX file is accurate. Why Did One Print Function Work and Not the Other? The behavior is complex and relates to how GCBASIC matches function calls to subroutines: Errant Case: In the original code, GCBASIC selected a subroutine...
-
Here is the program I used to test the behaviour.
-
Sure. Not a problem. Attach your source program to a post. I will compile to ensure I get the answer totally correct.
-
Would it be possible to clarify why "Print MyByte.MyByteBit" exhibits a change in behaviour when the program using it is modified please? {By adding the line 'Print " "} If the behaviour is expected to change when an additional line is added to a program, what is the rationale to this change? I don't mind that it is inconsistent, and I don't expect that there are (m)any people using "Print" to print a "bit" of a "byte" where that "bit" is referenced by a variable, but I am intrigued as to why it...
-
There is no real need for PPS lock and unlock unless there is a risk that your program changes these by accident, which is should not.
-
Ignore the USART setup. You know GCBASIC sets this correctly. Unless you config the whole chip in MCC exactly the same as GCBASIC you will run into issues with respect to baud rate registers.
-
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool. Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register: U2BRG = 0x36; // Baud rate for 115200 But when i set deafult usart2 speed @ 115200 in GCB code ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART routine give this: INITUSART ;Set the default value for USART handler - required when...
-
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool. Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register: U2BRG = 0x36; // Baud rate for 115200 But when i set deafult usart2 speed @ 115200 in GCB code ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART routine give this: INITUSART ;Set the default value for USART handler - required when...
-
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool. Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register: U2BRG = 0x36; // Baud rate for 115200 But when i set deafult usart2 speed @ 115200 in GCB code ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART routine give this: INITUSART ;Set the default value for USART handler - required when...
-
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool. Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register: U2BRG = 0x36; // Baud rate for 115200 But when i set deafult usart2 speed @ 115200 in GCB code ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART routine give this: INITUSART ;Set the default value for USART handler - required when...
-
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool. Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register: U2BRG = 0x36; // Baud rate for 115200 But when i set deafult usart2 speed @ 115200 in GCB code ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART routine give this: INITUSART ;Set the default value for USART handler - required when...
-
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool. Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register: U2BRG = 0x36; // Baud rate for 115200 But when i set usart2 speed @ 115200 ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART give this: INITUSART ;Set the default value for USART handler - required when more than one USART ;comport...
-
Great insights. Print MyByte.MyByteBit is working as expected. And your logic is a good approach.
-
I was struggling with a print statement in a program recently which wasn't working as I expected. I kept thinking I had my logic mixed up but eventually it turned out to be an oddity in the 'Print' statement. It may be 'expected' behaviour, if 'unexpected' for me. This works: Print MyByte.0 Let MyByteBit = 0 Let MyReferencedBit = MyByte.MyByteBit Print MyReferencedBit This does not work reliably: Print MyByte.MyByteBit It will print "1" only if the most significant bit of MyByte is set to 1. So if...
-
I was struggling with a print statement in a program recently which wasn't working as I expected. I kept thinking I had my logic mixed up but eventually it turned out to be an oddity in the 'Print' statement. It may be 'expected' behaviour, if 'unexpected' for me. This works: Print MyByte.0 Let MyByteBit = 0 Let MyReferencedBit = MyByte.MyByteBit Print MyReferencedBit This does not work reliably: Print MyByte.MyByteBit It will print "1" only if the most significant bit of MyByte is set to 1. So if...
-
RMW Safety Test Cases (Legacy PICs) # Test Case RWM Explanation 1 dir gpio out No RWM issue. Sets TRISA to make all GPIO pins outputs. No GPIO read/modify. 2 dir gpio in No RWM issue. Sets TRISA to make all GPIO pins inputs. No GPIO read/modify. 3 gpio.n = 0 or 1 Potential RWM issue. Bit-clear/set reads pin state. LATA cache stores intent. 4 PortState = gpio No RWM issue. Reads actual pin states. LATA not updated. 5 PortState = gpio.5 No RWM issue. Reads GP5 pin state. May differ from LATA. 6 gpio...
-
AdaptRMWIssues Function Documentation Overview The new AdaptRMWIssues function is a sub routine within the compiler designed to process assembly code lines generated by GCBASIC for Microchip PIC microcontrollers (e.g., PIC16F819). It adapts instructions that operate on I/O ports (GPIO, PORTA, PORTB) to use software cache registers (LATA, LATB) in RAM, mitigating Read-Modify-Write (RMW) issues and ensuring reliable reads of output port states. This is critical for this type of PIC which lacks hardware...
-
🛠️ New GCBASIC Capability: RMW-Compliant ASM Output creates Safer PIC Code 🚀 Overview I have completed the new capability for GCBASIC that generates read-modify-write (RMW)-safe assembly for PIC microcontrollers—especially useful on chips like the PIC12F675 and may more, which lack LATx registers and are prone to subtle latch corruption when using high-level pin commands. This capability ensures that output operations never corrupt input latches, preserving predictable behaviour and making the generated...
-
Took me way too long to find the executeable, but here's where I found it: https://www.microchip.com/en-us/tools-resources/configure/mplab-code-configurator Knowing Microchip it will be in a different location tomorrow.
-
HackInBlack modified a comment on discussion Open Discussion
WH2002A is a Character LCD 20x2 display which is built in with ST7066 controller IC. https://www.winstar.com.tw/products/lcd-display/character-lcd-display-module/lcd-20x2.html
-
WH2002A is a Character LCD 20x2 display which is built in with ST7066 controller IC the S60069-22 has an 80-pin pinout as well as not seeming to be compatible with the HD44780 chip..eek! https://www.winstar.com.tw/products/lcd-display/character-lcd-display-module/lcd-20x2.html
-
Check if they are HD44780-compatible.
-
Bertrand BAROTH posted a comment on discussion Open Discussion
So, none of these ?
-
GCBASIC-compatible option: Winstar WH2002A – HD44780-compatible, 20x2, parallel interface
-
ST7066U-0A-B : https://www.crystalfontz.com/controllers/datasheet-viewer.php?id=282 S6A0069-22 : https://orientdisplay.com/wp-content/uploads/2018/08/S6A0069.pdf?_ga=2.261917003.716369086.1754919408-1063401245.1754919408
-
Can you share the URL to the specificions?
-
Hello again ... I wanna buy an alpha display and have the choice between 2 controllers : the ST7066U-0A-B and the S6A0069-22 ; which of them is better (in connection mode 4) together with GC Basic ? Thanks for any answer ...
-
A Huge Thank You to the Amazing GCBASIC Supporters! 🎉 I am incredibly grateful for the wonderful support from the community, which keeps the GCBASIC project thriving! Your contributions fuel my passion to make programming microcontrollers accessible and enjoyable for everyone. 🌟Your contributions actually pay the bills for making the software available. Below is a heartfelt shoutout to each of you who have provide support. Your generosity makes all the difference! 💖 My Amazing Supporters 🙌 Henk 🚀...
-
USART - great news. To resolve CLC when GCBASIC with PIC , use the MPLAB Code Configurator (MCC) is a great for setting up peripherals like the Configurable Logic Cell (CLC) and USART. Here’s a quick summary and how you can use MCC’s generated C code in GCBASIC projects. What is MCC? MCC is Microchip’s free tool for configuring peripherals on PIC devices. It comes as a standalone application: - Graphical Interface: Easily configure USART, CLC, ADC, PWM, etc., without diving into datasheets. - C Code...
-
yes i'm using the new usart.h. serial port which seems to work ok, at least all direct I/O with uart works ok. I still have problems connecting with a usb host module though, but most probable this doesn't have to do with the uart function.
-
Can I check. The USART is working at expected? and, you are now using the new usart h?
-
Ok, i think i got it.... Q43 uses complete different codes for declaring CLC outputs as inputs to other clc, for example setting clc1 out, as input to another clc with Q10, code is 0x21 (CLC1SEL=0x21) where for Q43 is 0x33 (CLCNSEL1=0X33), so i had to change such codes in clc declarations too! First tests seem promising, for the first time board worked on Amstrad CPC using a PIC 18F47Q43! @evanvennn thanks again for the help! :-)
-
Ok, i think i got it.... Q43 uses complete different codes for declaring CLC outputs as inputs to other clc, for example setting clc1 out as input to another clc on Q10 code is 0x21 where for Q43 is 0x33, so i had to change such codes in clc declartions too, first tests seem that board worked for the first time on Amstrad CPC! @evanvennn thanks again for the help! :-)
-
Ok, now it seems that both test codes work: https://www.dropbox.com/scl/fi/dvfyeknzz11cjvw33xx3w/uart_test.jpg?rlkey=473iiv1tdug9kgjnrl6nh5gvw&dl=0 This is what i get in windows communication program when i power on Amsrtad CPC with the PIC board connected, so i suppose it's ok. But when i'm trying my code (with the same uart settings) i still don't get a response... Perhaps there is a problem with the CLC definitions, this is what i used for Q43: CLCSELECT = 0x06 clcnGLS0 = 0x02 clcnGLS1 = 0x48...
-
I have also tested EE writes and read. They are correct. I used C:\GCstudio\gcbasic\demos\Vendor_Boards\Great_Cow_Basic_Demo_Board\18f26q43_chiprange_demonstrations\160_showing_eeprom_data_to_serial_terminal.gcb No issues. The issue when we were testing ( see above ) is likely to be caused by the serial USART library not working as expected.
-
Here are my test programs. Summary of ComplexTest.gcb and SimpleTest.gcb SimpleTest.gcb Purpose: Tests basic USART2 functionality on a PIC 18F27Q43 microcontroller. Key Functionality: - Configures USART2 at 115,200 baud with blocking mode and no delay. - Initializes PPS for USART2 (TX2 on RB2, RX2 on RB1). - Continuously checks for incoming data on USART2 and echoes it back to the transmitter. - Sets Comport = 2 explicitly for USART2 operations. Focus: Verifies basic send/receive functionality of...
-
The issue is not the configuration but the USART functions. There was a change that set the comport to a Constant. As Constants cannot change the comport being selected was essentially hard coded. I think I know why the happended but this should not have passed testing. Attached is an update usart.h file. it is an updated version of usart.h with the following change: Updated Default Comport Handling (August 10, 2024): Removed dependency on SCRIPT_DEFAULT_COMPORT constant. Subroutines like HSerGetNum,...
-
Can I check ? You are on the latest build? Inspect USART.H. Last change 24/12/2024 ? Yes?
-
ok, thanks.
-
Ok. let me look at the library again. Please look for an update post from me when i have completed my review.
-
I tried to write eprom byte 0 with the value of U2CON2 and it also gave me '0', so it seems that all 3 values are set to '0' from the UART init
-
So most probable U2CON0 and U2CON1 are set to '0' by init uart routine, but for some reason the 3rd byte is not written to eeprom...
-
eprom byte 0 and 1 have 0x55, 0x44 but all others are 0xff
-
They may be zero. Let us check the EE write operations. EPWRITE 0, 0x55 EPWRITE 1, 0x44 EPWRITE 3, 0x33 Comment out the following. // EPWRITE 0, U2CON0 // EPWRITE 1, U2CON1 // EPWRITE 3, U2CON2 Do you see 0x55, 0x44, 0x33 ?
-
Ok, i've added the extra code for writing eeprom but it doesn't seem to write anything. The bytes i read from eeprom before pugging PIC to the test board are the same with the bytes after ( first 2 eeprom bytes are set to '0' and all others to 'FF')
-
Ok, i've added the extra code for writing eeprom but it doesn't seem to write anything. The bytes i read from eeprom before pugging PIC to the test board are the same with the bytes before ( first 2 eeprom bytes are set to '0' and all others to 'FF')
-
Thanks. Can you write the existing values to eeprom then read the chip to share the results? You will be reading the EEProm with your PK4 to share with me what the USART library is setting. I am reading the important registers - hopefully this will show some differences. Sorry, for delays. I am travelling today! And, the signal is very poor when in the car! Evan This shows the method to write the EEProm. #chip 18F47q43, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q43 #define...
-
Ok,i finish tests. The minimum group of registers needed for proper function of UART port are: // BRGS high speed; MODE Asynchronous 8-bit mode; RXEN enabled; TXEN enabled; ABDEN disabled; U2CON0 = 0xB0; NEEDED!! // RXBIMD Set RXBKIF on rising RX input; BRKOVR disabled; WUE disabled; SENDB disabled; ON enabled; U2CON1 = 0x80; NEEEDED! // BRGL 138; U2BRGL = 0x8A; // BRGH 0; U2BRGH = 0x00; Any of the above removed, UART stops functioning. All others don't seem to affect functioning of the UART.
-
Well, fortunately i have a PICKI4 which reflashes this test program in half a second, so i don't think it would take long :-) Btw, thanks for the explanation about INTON/INTOFF i didn't thought that since there is no interrupt command in source code it will be disable :-)
-
This is because the 'On Interrupt....' is not present.
-
To understand the root cause. I need you to put back each line, one at a time, one by one. Which line makes this work? Once I know what line is required then I can investigate in the serial initialization code. This is exactly what I would be doing to understand the root cause. A bit of a pain, and a slow process, but it will determine what is wrong.
-
btw, i discover another potential bug in the 18F47Q43 asm code: there is no assembly code produced for INTON/INTOFF gcb commands. For example this is the asm i get for 18F47Q410: READ_BYTE ;INTOFF bcf SYSINTSTATESAVE0,0,ACCESS btfsc INTCON,GIE,ACCESS bsf SYSINTSTATESAVE0,0,ACCESS bcf INTCON,GIE,ACCESS ;CLC4POL = 0x80 movlw 128 banksel CLC4POL movwf CLC4POL,BANKED UNPAUSELOOP3 ;if IORQ=OFF Then btfss PORTC,6,ACCESS ;GOTO UNPAUSELOOP3 bra UNPAUSELOOP3 ;END IF ;DIR PORTD IN setf TRISD,ACCESS ;CLC4POL...
-
btw, i discover another potential bug in the 18F47Q43 asm code: there is no assembly code produced for INTON/INTOFF gcb commands. For example this is the asm i get for 18F47Q410: READ_BYTE ;INTOFF bcf SYSINTSTATESAVE0,0,ACCESS btfsc INTCON,GIE,ACCESS bsf SYSINTSTATESAVE0,0,ACCESS bcf INTCON,GIE,ACCESS ;CLC4POL = 0x80 movlw 128 banksel CLC4POL movwf CLC4POL,BANKED UNPAUSELOOP3 ;if IORQ=OFF Then btfss PORTC,6,ACCESS ;GOTO UNPAUSELOOP3 bra UNPAUSELOOP3 ;END IF ;DIR PORTD IN setf TRISD,ACCESS ;CLC4POL...
-
btw, i discover another potentail bug in the 18F47Q43 asm code: there is no assembly code produced for INTON/INTOFF gcb commands. For example this is the asm i get for 18F47Q410: READ_BYTE ;INTOFF bcf SYSINTSTATESAVE0,0,ACCESS btfsc INTCON,GIE,ACCESS bsf SYSINTSTATESAVE0,0,ACCESS bcf INTCON,GIE,ACCESS ;CLC4POL = 0x80 movlw 128 banksel CLC4POL movwf CLC4POL,BANKED UNPAUSELOOP3 ;if IORQ=OFF Then btfss PORTC,6,ACCESS ;GOTO UNPAUSELOOP3 bra UNPAUSELOOP3 ;END IF ;DIR PORTD IN setf TRISD,ACCESS ;CLC4POL...
-
If i remove all the "Set the UART2 module to the options selected in the user interface." section, and left only the 'do loop', i got no response at all.
-
If i remove all the "Set the UART2 module to the options selected in the user interface." section, and left only the 'do loop', i got no responce at all.
-
Ok. Isolate the issue by removing the special init. Leave the do-loop. Does the standard init work?
-
YES! That worked straight!
-
Baud Rate calcs. MPLAB 64Mhz at 115k ~~~ // BRGL 138; U2BRGL = 0x8A; // BRGH 0; U2BRGH = 0x00; GCBASIC 64Mhz at 115k ;U2BRGH=SPBRGH_TEMP2 banksel U2BRGH clrf U2BRGH,BANKED = 0 ;U2BRGL=SPBRGL_TEMP2 movlw 137 movwf U2BRGL,BANKED = 137 So, I think the baud rate is correct. ----------------------------- The setting of Tx, Rx, En and Baud Rate Generator Speed Select look correct. These all set U2CON0 and U2CON1. ---------------------- The OSCFreq looks correct. As this impacts the USART this is an important...
-
I just try the above code but without the wait. I try to send many characters and USART responds back with the same number of characters, but again are completely irrelevant and not the same every time! For example: I sent 3 times '12345' and i got in response: ¿ÿ÷¿ o»÷÷ ßû¿ Even when i send i single same char i got a different respond each time, for example i sent 3 times '2' and got: ÷ ¿ ÿ
-
I just try the above code but without the wait. I try to send many characters and USART responds back with the same number of characters, but again are completely irrelevant and note the same every time! For example: I sent 3 times '12345' and i got in response: ¿ÿ÷¿ o»÷÷ ßû¿ Even when i send i single same char i got a different respond each time, for example i sent 3 times '2' and got: ÷ ¿ ÿ
-
I connect the board with PIC to an amstrad cpc. Using a usb2serial cable (which is verified that works ok) i tried this code instead: RESTART: If USART2HasData Then data_buf=HSerReceive2 // Send the RX to the TX hsersend data_buf,2 wait 500 ms ;HserPrint HSerReceiveFrom(2), 2 End If goto restart The good news is that whenever i send a character to the Amstrad (e.g. PIC's usart port), i get a respond back, BUT not with the character i sent, instead i always get ÿÿ characters as respond to PC terminal......
-
As i don't have a dev board to use HserPrint , but i connect the board with PIC to an amstrad cpc. Using a usb2serial cable (which is verified that works ok) i tried this code instead: RESTART: If USART2HasData Then data_buf=HSerReceive2 // Send the RX to the TX hsersend data_buf,2 wait 500 ms ;HserPrint HSerReceiveFrom(2), 2 End If goto restart The good news is that whenever i send a character to the Amstrad (e.g. PIC's usart port), i get a respond back, BUT not with the character i sent, instead...
-
The PPS and the ASM all looks correct. I was comparing here to MPLAB. So do the following. Do the basic work ? Remove the interrupt. Use a simple get data send data. Does that work ? #chip 18F47q43, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q43 #define USART2_BAUD_RATE 115200 #define USART2_DELAY OFF #define USART2_BLOCKING Sub InitPPS UNLOCKPPS // PPS is correct. RB2PPS = 0x0023 // TX2 > RB2 U2RXPPS = 0x0009 // RB1 > RX2 LOCKPPS End Sub // Not really needed but for testing...
-
The PPS and the ASM all looks correct. I was comparing here to MPLAB. So do the following. Do the basic work ? Remove the interrupt. Use a simple get data send data. Does that work ? #chip 18F47q43, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q43 #define USART2_BAUD_RATE 115200 #define USART2_DELAY OFF #define USART2_BLOCKING Sub InitPPS UNLOCKPPS // PPS is correct. RB2PPS = 0x0023 // TX2 > RB2 U2RXPPS = 0x0009 // RB1 > RX2 LOCKPPS End Sub // Not really needed but for testing...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
-
I'm trying to migrate a code i have for PIC 18F47Q10 to PIC 18F47Q43. I manage to make all needed updates (mostly declare different names for PPS and CLC's) and code is compiled without errors, but for some reason the hw UART port doesn't seem to work (i got no response to either output or input). This is the code i use, regarding USART setup, for PIC 18F47Q10 which works ok: #chip 18F47q10, 64 #option explicit #startup InitPPS, 85 #define PPSToolPart 18f47q10 function #define USART2_BAUD_RATE 115200...
1 >
