Variables on 18f05Q40 - RESOLVED

[Anobium]

I have corrected the 18FxxQ40 chip dat files.

The issue was a typo in the dat file generation process. It was using the source file for a 04Q40 to generate the 05Q40 dat.. oops. Took me ages to find!

I have uploaded. This is within build 1241.

[Bonkers]

Well done old chap, you've fixed the process, not the instance. There's no other way, given the huge range of chips that need supporting. The complexity of the 18F05 means that I'd never use it, were it not for GCB. I can't spend 2 weeks reading the datasheet and setting-up the registers wrong.

Were there any other differences in the DAT file?

I'm asking as it might solve the I2C speed issue mentioned below - it runs at 125kHz only - independent of clock speed (16MHz, 32MHz) and of HI2C_BAUD_RATE (400kHz, 800kHz).

[Anobium]

You have the fix in your DAT already for the memory management.

---

There were minor updates to two other registers. Nothing relative to I2C

---

Re I2C. We fixed the baud at 125kHz to ensure it wortks. To change frequency you need to change the clock source. This is in the Help ( i will add there references to the Q10, Q40 and Q41 chips).

Microchip I2C modules Specific Support - 18F class including the K42, K83, Q10, Q40 and Q41

Clock Sources: The Microchip I2C can select one of ten clocks sources as shown in the table below. I2C1Clock_MFINTOSC is the default which supports 125KHz.

It is important to change the clock source from the default of 125KHz if you want faster I2C communications. Change the following constant to change the clock source. Obviously, you setup the clock source correctly for I2C to operate:

        #define I2C1CLOCKSOURCE  I2C1CLOCK_MFINTOSC

Clock Constants that can be I2C clock sources are

Constant	Clock Source	Default Value
I2C1CLOCK_SMT1	SMT	0x09
I2C1CLOCK_TIMER6PSO	Timer 6 Postscaler	0x08. You MUST setup the timer6 clock source.
I2C1CLOCK_TIMER4PSO	Timer 4 Postscaler	0x07. You MUST setup the timer4 clock source.
I2C1CLOCK_TIMER2PSO	Timer 2 Postscaler	0x0. You MUST setup the timer3 clock source.
I2C1CLOCK_TIMER0OVERFLOW	Timer 0 Overflow	0x05. You MUST setup the timer0 clock source.
I2C1CLOCK_REFERENCEOUT	Reference clock out	0x04. You MUST ensure the clock source generates a within specification clock source. Check the datasheet for more details.
I2C1CLOCK_MFINTOSC	MFINTOSC	0x03 (default). This is the default and will set the I2C clock to 125KHz
I2C1CLOCK_HFINTOSC	HFINTOSC	0x02. You MUST ensure the clock source generates a within specification clock source. Check the datasheet for more details.
I2C1CLOCK_FOSC	FOSC	0x01. You MUST ensure the clock source generates a within specification clock source. Check the datasheet for more details.
I2C1CLOCK_FOSC4	FOSC/4	0x00. You MUST ensure the clock source generates a within specification clock source. Check the datasheet for more details.

This are example of using a Clock Source in the Help. Examples uses the SMTClock source as the clock source, the following methods implement the SMT as the clock source. The defintion of the constant, the include, setting of the SMT period, initialisation and starting of the clock source are ALL required.

'Set the clock source constant
#define I2C1CLOCKSOURCE I2C1CLOCK_SMT1

'include the SMT capability
#Include <SMT_Timers.h>

'Setup the SMT
'400 KHz @ 64MHZ
Setsmt1Period ( 39 )
  ' 100 KHz @ 64MHZ
  ' Setsmt1Period ( 158 )
'Initialise and start the SMT
InitSMT1(SMT_FOSC,SMTPres_1)
StartSMT1

For other clock sources refer to the appropriate datasheet.

[Bonkers]

Thank you so much for the example code, just one known_working_example is priceless when there are so many clock options.
The datasheet has 94 pages on I2C, and taking just one clock source (from ten) - the SMT as you propose - crikey, another 23 pages on that.
I'm definitely warming to the idea of high level languages...

[Jerry Messina]

the Q10 has an MSSP peripheral. Does it belong with the devices with the new I2C peripheral?

[Anobium]

Jerry - Help me understand. I have added the Qxx to the I2C help page. https://github.com/GreatCowBASIC/Help/blob/main/source/hi2coverview.adoc

Got another thought?

[Bonkers]

just a couple of observations, on said help page...
It needs "Example 2 " subheading for the PIC example following the AVR Example1

The example2 code posted :

---

#startup InitPPS, 85

Sub InitPPS

      RC4PPS =      0x22   'RC4->I2C1:SDA1
      RC3PPS =      0x21   'RC3->I2C1:SCL1
      I2C1SCLPPS =  0x13   'RC3->I2C1:SCL1
      I2C1SDAPPS =  0x14   'RC4->I2C1:SDA1

      'Module: UART1
      RC6PPS = 0x0013     'TX1 > RC6
      U1RXPPS = 0x0017    'RC7 > RX1

End Sub

---

This seems to contradict the LockPPS and UnlockPPS mandates in the help file;

You must use both commands UnLockPPS and LockPPS to complete any PPS changes. Great Cow BASIC includes these two macros to ensure this process is handled correctly

Similarly, the PPS tool generates code segments that are devoid of the lock and unlock commands.

The help on PPS seems to have them the wrong way round also:

---

Peripheral Pin Select for Microchip microcontrollers.
Example:

'Please check configuration before using on an alternative microcontroller.

#chip 16f18855,32
#option explicit

'Set the PPS of the I2C and the RS232 ports.
#startup InitPPS, 85
Sub InitPPS
  LOCKPPS
    RC0PPS = 0x0010       'RC0->EUSART:TX;
    RXPPS  = 0x0011       'RC1->EUSART:RX;

    SSP1CLKPPS = 0x14     'RC3->MSSP1:SCL1;
    SSP1DATPPS = 0x13     'RC4->MSSP1:SDA1;
    RC3PPS = 0x15         'RC3->MSSP1:SCL1;
    RC4PPS = 0x14         'RC4->MSSP1:SDA1;
  UnLockPPS
End Sub

For more help, see: UnlockPPS and LockPPS.

---

I'd have thought you need to unlock to make changes, then lock. was it a typo, or is it somehow correct?

---

So, on lockPPS, unlockPPS,
I guess the mandate is incorrect, you can just leave the PPS in its default unlocked state forever? - even though it might not be best practise...

please advise
best regds

[Anobium]

lockPPS and unlockPPS are optional.

I will change the Help to be passive and make the commands optional.

[Jerry Messina]

I'd have thought you need to unlock to make changes, then lock.

Correct

you can just leave the PPS in its default unlocked state forever?

Also correct. Unless you Lock PPS, you don't need to Unlock PPS.

If you do use Lock/Unlock, there's also a CONFIG setting that can prevent it from working more than once (usually called IOL1WAY, but the name can change...)

Leaving it unlocked is probably no more dangerous than relying on any other register to remain set, but YMMV.

[Bonkers]

[Bonkers]

not my question, but "the Q10" ? - I can't find a PIC18F05Q10.
The MSSP peripheral is very different to the new I2C peripheral - which needs a better name, like 18F I2C module.

[Anobium]

The chips are PIC18FxxQ10, PIC18FxxQ40, PIC18FxxQ41 etc.

Yes, the new I2C peripheral was introduced many years ago and from a GCB high level language point of view the i2C command set is the same. If a user wants to create methods to take advantage of the new I2C peripheral then they can.

[Jerry Messina]

The 18F2xQ10/18F4xQ10 was the first Q device (there is no '05Q10'), and it's more like a standard 18F... no vectored intr, has an MSSP peripheral with the standard clock sources, no MOVFF, etc.

Devices with the newer I2C peripheral have the extended clock sources...
K42, K83, Q43, Q40/Q41, Q83/Q84, and Q71

[Bonkers]

In summary of the sub-thread above:
keep to the path
i.e:
avoid spaces in file paths altogether
avoid spaces and hashes in filenames
follow installation instructions exactly - yes OK you can be casual and take a different route, they should be the same - but if there are errors you might be on a path untested, regression testing being what it is. Best option is to get back to the common position.

With regards to the shenanigans above, like GCstudio//GCB compiling, assembling, flashing, and reporting success -- only with no output files and no programmer activity -- I do seem to be over it for now, and can offer the following advice:
If any of it breaks, like it does produce hex files, but doesn't flash them - STOP. Don't be tempted to workaround, like flash the hex files using the programmer in a stand-alone mode. (I did this and had a raft of new issues, the text was garbled but the cadence seemed to work. - use the triage principle - solve or avoid - and choose avoid..)
I found that (in CCB) going to the icons banner, [GC Basic -v] icon, and the dropdown option " CG Studio settings" - you get the "splashscreen" mentioned previously, and the option to restore factory defaults.
Do that.
Early days yet, but I've put two simple programs though the process and it's not broken. Previous high-score was one.

[Anobium]

Great insights in the post https://sourceforge.net/p/gcbasic/discussion/579125/thread/9eb0259f9e/?page=2&limit=25#8697

I would add. Do not manually edit use.ini - use the Preds Editor.

[Bonkers]

Thanks Anobium,
as a final note, I still had trouble, possibly due to Win10 not allowing you to see where a start menu shortcut actually points to - (is it to the previous corrupted install or the new one?)
- so I uninstalled GCstudio, to remove registry items if any, and the shortcut - and also moved all GCstudio and GCB@syn files into the bin, where they can't be found.
Then a fresh clean install from the downloaded GCStudioSetup, specifying legacy mode.
I did need to pull the PICKitPlus directory out of the bin, and copy its files to the new C:GCstudio\PICKitPlus directory, to get the programmer working,
But it looks to be stable now, and I've got proper graphics working (after modifying the maxaddress parameter within PIC18F05Q40.dat chipdata file)

Next task is to write some better graphics exercises, to show off the capabilities.

I do have to report that the I2C speed is 125kHz measured, independent of clock speed (16MHz, 32MHz) and of HI2C_BAUD_RATE (400kHz, 800kHz)