Proton BASIC Community

Just to let you know, the up and coming "upgrade" to the compiler will add many new devices, listed below:

PIC16F15213, PIC16F15214, PIC16F15223, PIC16F15224, PIC16F15243, PIC16F15244, PIC16F15245, PIC16F15256, PIC16F15274, PIC16F15275, PIC16F15276

PIC18F04Q40, PIC18F04Q41, PIC18F05Q40, PIC18F05Q41, PIC18F06Q40, PIC18F06Q41, PIC18F14Q40, PIC18F14Q41, PIC18F15Q40, PIC18F15Q41, PIC18F16Q40, PIC18F16Q41, PIC18F26Q84, PIC18F27Q84

PIC24FJ64GA406, PIC24FJ64GC006, PIC24FJ64GL306, PIC24FJ128DA106, PIC24FJ128DA206, PIC24FJ128GA406, PIC24FJ128GA606, PIC24FJ128GC006
PIC24FJ128GL306, PIC24FJ128GL406, PIC24FJ128GU406, PIC24FJ256DA106, PIC24FJ256DA206, PIC24FJ256GA406, PIC24FJ256GA606, PIC24FJ256GL406
PIC24FJ256GU406, PIC24FJ512GA606, PIC24FJ512GL406, PIC24FJ512GU406, PIC24FJ1024GA606

The new 18FxxQ40 and 18FxxQ41 devices have some differences inside them from standard 18F devices, but they are very good differences that make them more efficient, and the compiler makes the differences invisible to the user, so you cannot tell one 18F device from another, except the efficiency of the compiler comes in even more with them. The work I have had to do for them inside the compiler has been very worth while, because they are really nice devices and offer small packages with lots inside them, and some extras that are long overdue with 18F devices.

Also, the newer enhanced 14-bit core devices added have extra RAM and peripherals.

The PIC24 devices are "really good" anyway, so I have added more "really good" PIC24 devices. LOL.

Below is a picture of my simple test setup for the 18FxxQ4x devices, so I could test them out with the compiler by adding serial interfaces and the oscilloscope, and test speeds etc... Sometimes, you cannot beat an LED. LOL.

Hi Les,

I  hope this is a paid upgrade, we want to keep you in business!

John

Hello Les,

I am too looking forward to purchasing the latest upgrade.

A question I wanted to ask - if you ever wonder what new cool future to implement and if it is an easy task to do - a dynamic crystal frequency change would be wonderful - thus being able to use multiple "Declare Xtal" in the code.

I have devices working in both - full speed and low power mode, so depending on the requirements, I switch for example between 48MHz HSPLL and say 1MHz INTOSC and in all subs/procs with 1MHz I adjust (prorate) manually the timing.

A dynamic oscillator frequency that the time critical commands can follow is not possible for several reasons. But the main reason is that the assembler code created by the compiler is created at "compile time", so it has to alter the assembler mnemonics and timing values to match the crystal frequency for the device's fOSC (instruction time relation to oscillator time), otherwise it has no idea what to create. :-)

For example... How to create a delay of 1 microsecond, when the fOSC is not known for the microcontroller, so it is not known how long to wait because it is not known how long an assembler instruction mnemonic takes to operate? Using variables would not help because the calculation itself to work out what frequency is being used would take time and alter how long it takes to operate when the frequency altered because of division iterations etc... And be Sooooooooo complex I would not like to be the one creating all the "multitude" of iterations in "everything" it would require. :-)

With procedures now in place, the user can create libraries that have some frequency dynamics in them, but a frequency of operation is a constant, so it will be difficult to make it dynamic on more complex routines. The preprocessor could work for you automatically depending of the _xtal value for default, but they will also have to be constant frequency values to adjust the timings for time critical commands.

Ideas for a, possible, dynamic frequency mechanism would be good to see, and I would see if I could re-create them somehow.

Quote from: top204 on May 26, 2022, 12:09 PMIdeas for a, possible, dynamic frequency mechanism would be good to see, and I would see if I could re-create them somehow.

Thank you for your explanation Les,

Just an idea - if the preprocessor sees two different xtal declares, then it creates in assembler two sets of labels and mnemonics for time sensitive routines with let say a prefix or suffix of the crystal frequency. Then as the compiler works at compile time and "hits" a "Declare Xtal" it uses the one set of mnemonics until another "Declare Xtal" is set.

With your example, if the preprocessor sees "Declare Xtal = 48" and "Declare Xtal = 2", then when "DelayMS 1" is compiled and called, in assembler it creates __delay_ms_48 and __delay_ms_2 and so fort and their corresponding subroutines. 

I understand that this will require more code space, but it may be acceptable in many instances, especially with the newer PICs.

P.s. Les, is there a reason why 1 MHz and 2 MHz (internal and external oscillator) frequencies are not supported?

So what would you do if you had a routine using delay calls that was called from both "delay contexts"?

Declare Xtal = 48
call mysub_with_delay1ms()

Declare Xtal = 2
call mysub_with_delay1ms()


Quote from: tumbleweed on May 26, 2022, 01:01 PMSo what would you do if you had a routine using delay calls that was called from both "delay contexts"?

Code Select Expand

Declare Xtal = 48
call mysub_with_delay1ms()

Declare Xtal = 2
call mysub_with_delay1ms()


I think you misunderstood the idea. Something like this:

If the preprocessor scans and sees in the code both (or more) "Declare Xtal = 48" and "Declare Xtal = 4" then when the assembler code for DelayMs is created, it will create two sets of assembler routines:

__delay_ms_4
    clrf PP1H
__delay_ms_wreg_4
    movwf PP1
__delayms_from_regs__4
    movlw 255
    addwf PP1,F
    addwfc PP1H,F
    bra $ + 2
    btfss STATUS,0
    return
    movlw 3
    movwf PP0H
    movlw 222
    rcall __delay_us_wreg_4
    bra __delayms_from_regs__4
__delay_us_4
    clrf PP0H
__delay_us_wreg_4
    addlw 233
    movwf PP0
    movlw 252
    bnc $ + 12
    nop
    nop
    addwf PP0,F
    bc $ - 4
    nop
    addwf PP0,F
    decf PP0H,F
    bc $ - 12
    btfsc PP0,0
    bra $ + 2
    btfss PP0,1
    bra $ + 6
    bra $ + 2
    nop
    return


and

__delay_ms_48
    clrf PP1H
__delay_ms_wreg_48
    movwf PP1
__delayms_from_regs__48
    movlw 255
    addwf PP1,F
    addwfc PP1H,F
    bra $ + 2
    btfss STATUS,0
    return
    movlw 3
    movwf PP0H
    movlw 230
    rcall __delay_us_wreg_48
    bra __delayms_from_regs__48
__delay_us_48
    clrf PP0H
__delay_us_wreg_48
    addlw 254
    movwf PP0
    nop
    clrf WREG
    subwfb PP0H,F
    btfss STATUS,0
    return
    decf PP0,F
    bra $ + 2
    bra $ + 2
    bra $ - 16

Then while compiling, the compiler keeps track what is the current "Declare Xtal" until new "Declare Xtal" is hit, for example:

...
Declare Xtal = 4 
DelayMs 1
....
Declare Xtal = 48
DelayMs 1 
...

will result in:

movlw 1
rcall __delay_ms_4
...
movlw 1
rcall __delay_ms_48

I understood the idea, but you didn't get what I meant.

Let's say you had something like this:
Proc MyProc()
  // some code...
  delayms 1
EndProc

Declare Xtal = 48
MyProc()

Declare Xtal = 2
MyProc()

How could the compiler deal with that? "xtal" is two different values when MyProc is called.

Quote from: tumbleweed on May 26, 2022, 01:48 PMHow could the compiler deal with that? "xtal" is two different values when MyProc is called.

When you call the Proc, you are jumping to the corresponding label in assembler, there you still call the __delay_ms_ routine.

Which routine will be called, __delay_ms_2 or __delay_ms_48, will depend on a system variable, set by the compiler and changed to a corresponding value every time a "Declare Xtal" is met.

Thus, a crude description of the idea is to create a system variable, if more than one "Declare Xtal" exists in the code, which variable will be assigned a certain value every time when "Declare Xtal" is met to. At compiling time it will mimic the "If-Then" code and where time sensitive routines are called, the comparison will be examined and jump to the corresponding assembler routines.   The need of this system variable and the double (or multiple) set of assembler routines will be determined by the preprocessor if more than one "Declare Xtal" exists in the code.

Edit. By "Time sensitive" routines I mean oscillator depending.

That type of mechanism is not possible in the compiler itself.

The Xtal timings are not just for Delay commands, they are also for all the commands that require timings based upon the microcontroller's operating frequency. i.e. Serial commands, Timeouts, Pulse commands etc, and these reside in the compiler's library subroutines that are created at compile time. If you could see the amount C lines: if(Xtal_Value == xxxx) and if(Xtal_Value >= xxxx) and if(Xtal_Value <= xxxx) in the compiler's source code it would amaze you, because even the simplest of routines sometimes need to know what timing the device's mnemonic instructions have. Even for a low value DelayUs command I had to create inline mnemonics for the timings because a device operating at low frequencies cannot call/return a subroutine for a particular delay because each instruction requires 1 or 2 or 3 us to operate so would not get the delay required. That's also why I stopped at 4MHz for the compiler, because below that, a lot of commands cannot work as they should, and the compiler would get the blame. :-)

The type of mechanism you are suggesting could easily be done by procedures, where, instead of using the DelayUs command, create a procedure named Delay_Us() and add the delay code within that based upon a variable that is changed whenever the oscillator is changed.

Hello Les,

Thank you for your thorough explanation. Another problem I stumble with is the HEF and procedures. We already discussed it before and came to a solution, although a bit complex, so another question from me ... 

Is it possible to implement a "Declare" that will limit the compiler up to that address (block) and the rest can be used as HEF data storage, like in the AN1673 --ROM command?

Hi Les, Looking forward a lot for this..

And  (as you already might know) I am with John on this : we do not mind paying for this great compiler to keep you in business for many, many years to come..

I would be lost without it..

I almost do not dare to ask (and do not want to give you pressure) but you have any idea when you might bring this update?

Les
You are doing a truly remarkable job and I look forward to paying for the upgrade.

Many thanks GDeSantis.

trastikata... The HEF mechanism that is in some of the devices, instead of good old EEPROM, is an extremely stupid idea by Microchip, and it looks like it is being dropped from them in some of the more recent devices, and they are going back to standard EEPROM (thankfully). Because each device has a totally different mechanism for erasing and writing flash memory, and the amount that must be erased first and the amounts that must be written, the logistics involved for incorporating them into the compilers as commands would be crazy, and probably not possible with some devices with less RAM, and extremely inefficient. With procedures now in place, there is no reason a user cannot create a library of HEF manipulating routines for a particular device, or device family, if microchip have not screwed around with them as well (which they do on a regular basis). I have posted a few techniques here on the forum for reading and writing HEF memory for particular devices, but it is something I would "never" use myself on a device and will always choose a device with true EEPROM. The wastage of RAM and code memory is staggering, and it was obviously thought up by someone who has no clue to working in the "real world", and obviously has never actually used a PIC device. :-)

I am on the final stages of the installer for the upgrade that actually adds more devices than listed in the first post. :-)

I will post the price and PayPal details as soon as I have the intsaller working as I want, and of course, the compilers.

For users who have purchased the compilers within 1 month of the upgrade being made available, the upgrade will not need to be paid for, and I will check in my records when the compilers were purchased by a user.

I really enjoy working with the new Q40 and Q41 devices, because they contain so much.

Unfortunately some of us have used those devices, in my case recently the 18F24J50 and then had real  problems as you describe... I also once used the 16F1779 because it had lots of hardware PWM channels, but no EEPROM so I ended up using an external EEPROM on that one as using HEF was problematic.

I still think it would be good if you could address, if possible, the idea of a declare that would ensure free block space for HEF use as Trastikata mentioned.

I once used an 18F J device, because, at the time, they were the only devices that could reach 48MHz, and I also had to resort to an external EEPROM chip, because manipulating the flash memory was staggeringly wasteful, and I was already filling up the device with its real program, so I  could not afford to waste valuable code memory and RAM on a stupid design flaw. :-)

I'll see about adding a declare to dictate the size of actual flash memory on a device, so that it can be moved down to accommodate for the HEF memory, and a declare so the size of the HEF memory block can be issued in a program.

I was working on a mechanism the same as Edata, but named HeData, so that constants can be placed in HEF memory at compile time. I'll see if I can get back into it, because it did have logistic problems around it, because I would need to go through every device's .ppi file and add a new directive for "HEF_Size". I'll see if I can knock up a program to scan the microchip XML files and add the new directive to the relevant .ppi files.

However, I placed on the forum a mechanism to do that so the EEPROM's address is changed with a declare so that it sits in the HEF memory block instead, so Edata would work, but user procedures would need to be created to read, erase and write the HEF block.

Just popped into this discussion, are the new PIC devices already included in the current Proton?
If not, when to expect the upgrade? I'd be happy to pay for it.

Kind regards

Sommi

Some of these Chips are much lower cost so in the long run we may save Money, Thanks Les.

I see the PIC18F27Q84 is already supported.

I could get hold of a batch PIC18F27Q83, they seem very similar, can I use PIC18F27Q84 in the compiler to write a program for PIC18F27Q83?

Regards

Sommi

There's a device file for the 18F27Q84 but it doesn't work... if you try to compile it'll crash the IDE.

New 18F devices (Q40/Q41/Q83/Q84) require a different assembler (or modifications to get them to work with MPASM).