Proton BASIC Community

The PDS support the Positron Basic of course,
As well as assembler with the ASM ENDASM commands

Is the C language supported in any way ?

If this was possible then perhaps an existing code for something existing in C... C++ may be included to perform that function ?

If you write code for a processor, then you can include a C-file that performs a function.  The author then offers commands you use in your program, that uses his code to perform the function.
In C there exist a huge verity of such includes created for all sorts of things.

For the ESP32-S3 I used EEPROM.h, OneWire.h, LiquidCrystal.h and uTimerLib.h as includes, each have a set of commands that does that function.
For example, to write to EEPROM - EEPROM.writeInt(10, Set_Temperature);             // Save temp set value
                                                        EEPROM.commit();  // save it !

It means the timing and other issues which may exist is handled by the include, you just use the commands.

The off side is that some of these includes exist for only specific processors and cannot not be used universally...

It's pretty much the same as procedures in Positron, where you can easily produce custom standalone include files, thus the same as functions and a .h file.

I have many libraries written in Positron that are just like you describe, here is a basic example of a Flashwrite include file.  All declarations and procedures exist in the include file, enabling easy reuse.


Include PXXXFlash_ROUTINES.inc

Var = FlashRead(MEMLOC)
Flashwrite(VAL,MEMLOC)
EraseFlash(MEMLOC)



I code in both CCS C and Positron and find both are excellent. CCS has some extremely powerful functions and libraries but I still prefer the basic syntax as I was brought up on the C64.

How about include files with a working fuse setting that actually have a pic run the first time.  Everyone I know have problems with this.  You can always change the fuse settings below the include setup.

Do one just save the code in a text file with that .inc extension ?

Tested and it works.

In the IDE under View ... Options... Default Startup Source Folder
Tic Enable and select the include file source folder.

All the includes can now be in this folder.

Each device has default config fuses in its .ppi file, so even without adding config fuses to a program, it will operate.

Each device's .ppi file is located at: "C:\Program Files (x86)\ProtonIDE\PDS\Includes\PPI\"

Opening a device's .ppi file, go to the end of the file and the default config fuses are there. For example, on a PIC18F14K22, they are:

Default Configuration Definitions
[DEFCONFIGSTART]
ifndef CONFIG_REQ
ifdef WATCHDOG_REQ
CONFIG WDTEN=ON         ; WDT enabled
else
CONFIG WDTEN=OFF        ; WDT disabled (control is placed on SWDTEN bit)
endif
ifdef PLL@REQ
CONFIG FOSC=HS          ; HS oscillator
CONFIG PLLEN=ON         ; Oscillator multiplied by 4
else
CONFIG FOSC=HS          ; HS oscillator
CONFIG PLLEN=OFF        ; PLL is under software control
endif
CONFIG MCLRE=ON         ; MCLR pin enabled, RE3 input pin disabled
CONFIG PCLKEN=ON        ; Primary clock enabled
CONFIG FCMEN=OFF        ; Fail-Safe Clock Monitor disabled
CONFIG IESO=OFF         ; Oscillator Switchover mode disabled
CONFIG PWRTEN=ON        ; PWRT enabled
CONFIG BOREN=ON         ; Brown-out Reset enabled and controlled by software (SBOREN is enabled)
CONFIG BORV=19          ; VBOR set to 1.9 V nominal
CONFIG WDTPS=128        ; 1:128
CONFIG HFOFST=OFF       ; The system clock is held off until the HFINTOSC is stable.
CONFIG STVREN=OFF       ; Stack full/underflow will not cause Reset
CONFIG LVP=OFF          ; Single-Supply ICSP disabled
CONFIG BBSIZ=OFF        ; 1kW boot block size
CONFIG XINST=OFF        ; Instruction set extension and Indexed Addressing mode disabled (Legacy mode)
CONFIG CP0=OFF          ; Block 0 not code-protected
CONFIG CP1=OFF          ; Block 1 not code-protected
CONFIG CPB=OFF          ; Boot block not code-protected
CONFIG CPD=OFF          ; Data EEPROM not code-protected
CONFIG WRT0=OFF         ; Block 0 not write-protected
CONFIG WRT1=OFF         ; Block 1 not write-protected
CONFIG WRTB=OFF         ; Boot block not write-protected
CONFIG WRTC=OFF         ; Configuration registers not write-protected
CONFIG WRTD=OFF         ; Data EEPROM not write-protected
CONFIG EBTR0=OFF        ; Block 0 not protected from table reads executed in other blocks
CONFIG EBTR1=OFF        ; Block 1 not protected from table reads executed in other blocks
CONFIG EBTRB=OFF        ; Boot block not protected from table reads executed in other blocks
endif
[DEFCONFIGEND]

When config fuses are placed in a user's code listing, the compiler does not use the default settings.

Thank you Les.  That was what I did, but the settings are not always obvious.

Once you have it working, however it is going to be very easy even if some of the settings have to be changed for another application.

The configuration settings is one possible include.
Other includes could be supporting many other components like sensors, displays etc.

This could make programming a pic with external components a lot easier, especially for unskilled programmers like myself.  C uses includes, and imo is one of the reasons it is so popular.  Even a beginner can connect the micro to a perhaps complicated sensor and get a usable value from it.

hi,

QuoteC uses includes

Positron uses includes and in my opinion is a lot easier to understand than C.

QuoteEven a beginner can connect the micro to a perhaps complicated sensor and get a usable value from it.

The problem with this is they will never learn how the device works if everything is just drag and drop.

Look at Arduino for a similar scenario, there are libraries for pretty much everything but the code is pretty awful compared with how neat and tidy it is using Positron.

Bob

Hi Bobby,
I have used many 18B20's in various applications, and I have no idea how the 18B20 internally work !
I know it's a one wire and you write a value to it and that writes a value out representing the temperature.
I got the code from the forum, probably done by Les because these code interactions is clear to him, and used it ever since.

I once made a barometer with a dog display (I got them for cheap), and it took me a week to figure out from the data sheet how it works and how to write to it.  I created two sizes text for it and even drawed a graph with 24hr history.  The instrument works very nicely.
The sensor I used had serial data as well as an analog output.
I used the analog value because it was so much easier to use.
If I used the data function, it would have probably been slower and another week or two to figure out how to do it.

Why ?

I use this basic to make my life easy and to produce working items for customers in a short time.  Knowing exactly how the sensor works inside is of a lesser importance than to be able to use it.

With the help of my brother I managed to get one of the best processors the Chines make, and a 32 bit dual processor at that ! going in a week, and also because it used includes.  It was an experience, just that the C sucks and I wasn't going to do it in assembler.  But, they make it easy to use their products.

With the interrupts on the 18F14k22 I used

Dim Timer0 As TMR0L.Word         ' Create a 16-bit Word from registers TMR0L/H

Timer0 returns the value of timer 0 in it.

Can I perhaps use

Dim TempDegC as TemperatureDegC.word     'get the temperature value from the 18B20include ?

So every time I use the TempDegC variable it execute the include and return with the value ?

How is this done ?

Double post, how to delete ?

Hi,
I think you want to use a procedure to do that, you could have the procedure as an include. If you look at the ENS160 code I posted i have a definitions include and a procedures include. There is no reason (i can think of) why the definitions are not in the procedure include, I just think it is neater.

Bob

Hi,
Try this, it might need a bit of refining as done quickly from a very old program I had. It works in a VSM.

Update, it does not need Dim Temp_F As Float in the INC file.

Bob

Hi,
Found a few little errors so updated.

Bob

Hi,
I have added the code for the main program to the include so you do not need to remember it, just copy, paste and uncomment.

Quote' *** Copy and paste this part in the main program ***
'Temperature = DS_18B20()   'Get the temperature from the procedure
'Temp_W = Temperature / 10                              ' Calculate the Integer portion
'Temp_D = Temperature - Temp_W * 10                     ' Calculate the decimal portion

QuoteIs the C language supported in any way ?

If this was possible then perhaps an existing code for something existing in C... C++ may be included to perform that function ?

OK, I haven't tried it but ask a couple of AI to do a translation and see what happens

Interesting idea Charlie !

If we bug AI enough with specifically the Positron pic basic it may well study it and write our codes for us 

I tried and got this response
Search for "code for PWM output in Positron pic basic".

Positron PIC Basic code example
'--- Positron PIC Basic PWM Example ---
' Configure your PIC microcontroller settings here,
' typically in a separate header file or at the top of your code.
' For example, setting the oscillator and other options:
' $config WDT_OFF, PWRTE_ON, HS_OSC, LVP_OFF

'--- Variable definitions ---
duty VAR WORD       ' Use a WORD for the duty cycle value.
frequency VAR WORD  ' Use a WORD for the frequency.

'--- Main program starts here ---
main:
    ' Set the frequency and duty cycle.
    ' Adjust the values as needed for your specific application.
    frequency = 5000       ' Set PWM frequency to 5kHz.
    duty = 512             ' Set PWM duty cycle to approximately 50% (1024-step resolution).

    ' Initialize PWM on the selected channel (e.g., CCP1) with the desired frequency.
    ' The actual pin is determined by the PIC's datasheet.
    HPWM 1, duty, frequency

    ' Loop to demonstrate a change in the PWM duty cycle
    FOR duty = 0 TO 1023 STEP 10
        HPWM 1, duty, frequency    ' Update the duty cycle.
        DELAYMS 50                 ' Wait for 50 milliseconds.
    NEXT duty

    ' Loop to demonstrate a fading effect.
    FOR duty = 1023 TO 0 STEP -10
        HPWM 1, duty, frequency
        DELAYMS 50
    NEXT duty

    GOTO main

And
"code for 18B20 temperature read in Positron pic basic"
' DS18B20 temperature read on Positron PIC Basic
' Hardware setup:
' DS18B20 DQ pin -> PORTA.0 (or any suitable I/O pin)
' DS18B20 VCC pin -> +5V
' DS18B20 GND pin -> GND
' 4.7Kohm pull-up resistor between VCC and DQ pin

'--- Pin definition ---
Symbol DQ_PIN = PORTA.0   ' Change to your chosen pin
Symbol DQ_TRIS = TRISA.0

'--- Variable definitions ---
temp_word VAR WORD       ' Raw 16-bit temperature data
temp_low VAR BYTE        ' Low byte of temperature data
temp_high VAR BYTE       ' High byte of temperature data
DQ_state VAR BIT         ' Holds the state of the DQ pin

'--- Main program ---
main:
    ' Initial setup:
    ' Set up for serial output if you want to display the temperature on a terminal.
    ' HSer_Baud = 9600
    ' HSerOut "DS18B20 Test", 13, 10

    GoSub Read_DS18B20  ' Read the temperature from the sensor.
   
    '--- Display the temperature (example for a debug terminal) ---
    ' HSerOut "Temperature: ", Dec temp_word, " raw", 13, 10
   
    ' You can add your own conversion logic here to display
    ' the temperature in Celsius or Fahrenheit.
    ' For example:
    ' If (temp_high & $80) Then
    '   HSerOut "Negative Temperature", 13, 10
    ' Else
    '   temp_word = temp_word >> 4 * 100
    '   HSerOut "Temperature: ", Dec temp_word, " C", 13, 10
    ' End If

    DelayMS 1000        ' Wait 1 second before next reading.
    GoTo main

'--- Subroutines ---

' Read the raw 16-bit temperature data
Read_DS18B20:
    GoSub OneWire_Reset
    OWrite DQ_PIN, 1, [$CC, $44]   ' Skip ROM command, then Convert T
   
    ' Wait until conversion is complete (up to 750ms for 12-bit).
    ' A simple delay is often sufficient.
    DelayMS 800
   
    GoSub OneWire_Reset
    OWrite DQ_PIN, 1, [$CC, $BE]   ' Skip ROM command, then Read Scratchpad
   
    ' Read the two temperature bytes from the scratchpad
    ORead DQ_PIN, 2, [temp_low, temp_high]
   
    temp_word.LowByte = temp_low   ' Store the low byte
    temp_word.HighByte = temp_high ' Store the high byte
   
    Return

' Manual 1-Wire reset sequence
OneWire_Reset:
    DQ_TRIS = 0         ' Set pin to output
    DQ_PIN = 0          ' Drive low
    DelayUS 500         ' Hold low for >480us for reset pulse
    DQ_TRIS = 1         ' Set pin to input (release bus)
    DelayUS 80          ' Wait for presence pulse response
    DQ_state = DQ_PIN   ' Check for presence pulse (low)
    DelayUS 420         ' Complete the 480us+ recovery slot
    Return

And just when I started to like AI it came up with this unacceptable solution

QuoteCreate ESP32-S3 support for Proton pic basic
Thinking
Kicking off 5 searches
Looking at 118 sites
Putting it all together
It is not possible to create ESP32-S3 support for the Proton PIC Basic compiler, as it is fundamentally incompatible with ESP32-S3 microcontrollers
. Proton Basic is a legacy compiler designed exclusively for Microchip PIC microcontrollers, which have a completely different hardware architecture than Espressif's ESP32 family.
Here is a breakdown of why this is not feasible and the alternatives you should consider.
Key differences between PIC and ESP32-S3
Feature    PIC microcontrollers    ESP32-S3 SoC
Compiler   
Proton Basic is a proprietary compiler designed specifically for the 8-bit, 16-bit, and dsPIC architecture of PIC microcontrollers.   
The ESP32-S3 uses the Xtensa LX7 dual-core processor. It requires a compiler based on the ESP-IDF framework, such as C/C++, Rust, or MicroPython.
Instruction set    PIC devices use a proprietary instruction set that is completely different from the ESP32's.   
The ESP32-S3 uses the Xtensa instruction set. It would require a complete re-engineering of the Proton compiler to translate PIC instructions into Xtensa instructions, a task that is not realistic.
Architecture   
PIC microcontrollers are relatively simple and use a highly different peripheral set from ESP devices.   
The ESP32-S3 is a complex "System on a Chip" (SoC), featuring integrated Wi-Fi, Bluetooth LE, and advanced peripherals like native USB. This is fundamentally different from the PIC architecture.
Ecosystem   
The Proton Basic ecosystem is built around Microchip PICs, their specific commands, and their peripheral structure.   
The ESP32 ecosystem revolves around the open-source ESP-IDF, Arduino IDE, and other modern development environments.
Recommended alternatives for ESP32-S3
If you are comfortable with Basic syntax, several more modern options are available for the ESP32 platform that are similar to Proton Basic.
1. B4R (Basic for Arduino)

    Description: This is a robust, modern alternative for those who prefer a Basic-like syntax. It is a derivative of the "B4X" line of development tools and specifically targets Arduino-compatible boards, including the ESP32.
    Pros:
        Designed for modern microcontrollers like the ESP32.
        Provides libraries and syntax that will feel familiar to Basic programmers.
        Active community support.
    Cons: It is not a direct, drop-in replacement for Proton Basic.

2. MicroPython

    Description: MicroPython is a lean implementation of Python 3 that runs directly on microcontrollers like the ESP32-S3. While it uses Python syntax, it has a simple, accessible structure and an extensive library of hardware drivers.
    Pros:
        Easy to learn and very readable.
        Vast amount of online tutorials and resources for the ESP32.
        Allows for rapid prototyping.
    Cons: Python is a different language from Basic, so there will be a learning curve.

3. C++ with the Arduino IDE

    Description: This is the most common and robust way to program the ESP32. The Arduino IDE provides a simplified C++ environment with a massive collection of libraries.
    Pros:
        Largest user base and library support.
        Access to all the powerful features of the ESP32-S3, including Wi-Fi and Bluetooth.
        The Arduino "wiring" API simplifies many tasks.
    Cons: It uses a different syntax (C++) than Basic.

Conclusion
Your best course of action is to move to a development environment and language that is natively compatible with the ESP32-S3. The architecture and toolchain differences are too fundamental to bridge with a legacy compiler like Proton PIC Basic. For those who prefer a syntax similar to Basic, B4R is the most direct modern alternative.

It does however mension -

Quote1. B4R (Basic for Arduino)

    Description: This is a robust, modern alternative for those who prefer a Basic-like syntax. It is a derivative of the "B4X" line of development tools and specifically targets Arduino-compatible boards, including the ESP32.
    Pros:
        Designed for modern microcontrollers like the ESP32.
        Provides libraries and syntax that will feel familiar to Basic programmers.
        Active community support.
    Cons: It is not a direct, drop-in replacement for Proton Basic.

REFUSED to do the development for it.

Came up with the same excuse for supporting 32-bit pics.

The I in AI is not that I after all.  It can only present what has been done already, hence someone else's I.

What has AI actually got wrong?