Proton BASIC Community

I KNOW this would be a lot of work but is there information on what resources each Positron command uses e.g.

DELAYMS

Uses:

TimerX, registers X, Y, Z, etc, ADC(X) Port(X).Y and any other registers or system resources.Also, impact on main program i.e. Takes n "T" cycles and is NOT concurrent. By concurrent I mean like HSEROut which you fire a byte at, and the hardware squirts out data whilst the user program continues to run, rather than stalling the user program.

I ask as if I am using tightly controlled loops using nested interrupts, I need to know what resources I have to avoid to not corrupt anything outside my ISR

I suggest you try to learn a little bit of assembly, there was a post on how the compiler is adaptive a few days ago.  The compiler has supported adding assembly for many years and when you need to take control of timings you can.  . Toggle a pin on the start and end of a certain procedure and use a scope.to deduce timings.
 The compiler is adaptive, A  kind of AI in some senses as it tries to improve but there are limits and risks.
The only way you can get exact timing information is to either study the assembly and simulate it or create some kind of interrupt or timer based execution

Quote from: SeanG_65 on Aug 17, 2022, 10:16 PMI KNOW this would be a lot of work but is there information on what resources each Positron command uses e.g.

Only Les would know for certain, but obviously any command with a description that refers to using a Peripheral, i.e. MSSP module, CCP module, ADC will make use of that Hardware and have to use the associated registers to set up the hardware and may also use one or more of the associated interrupts.
Where a device has multiple hardware modules of the same type and it is not explicitly mentioned which would be used then you could reasonable assume that it would be the the one with the lowest number, as that is guaranteed to exist on any device that has them, i.e. Timer0 as opposed to Timer3 which may not exist on a particular device.

I believe that the Delay commands just execute a loop a fixed number of times based on the length of the desired delay and the Xtal frequency, thus may not be as accurate as using a Timer would be but for a delay of the approximate duration is fine, so would therefore block other code that is not an interrupt.

Quote from: SeanG_65 on Aug 17, 2022, 10:16 PMAlso, impact on main program i.e. Takes n "T" cycles and is NOT concurrent. By concurrent I mean like HSEROut which you fire a byte at, and the hardware squirts out data whilst the user program continues to run, rather than stalling the user program.

It is not always easy to determine the number of cycles a command take as that can be dependant upon several variables, such as...

• What effect (if any) the different optimiser levels have
• Whether or not any other commands or hardware are generating interrupts that may interfere with a particular commands execution and how often they occur
• Whether or not it has to access a variable or code located on a different page, as page swapping can add a few instructions

If you understood some assembler then a look at the assembler listing after compilation which should reveal the number of instructions used for a particular command, multiply that by the duration of the clock cycle to give a good approximation, or you may be able to use an available Timer in the PIC to give an approximate value. 

This really isn't at all practical/possible as there are too many conditions to take into account.

Case in point:

Quote from: SeanG_65 on Aug 17, 2022, 10:16 PMBy concurrent I mean like HSEROut which you fire a byte at, and the hardware squirts out data whilst the user program continues to run, rather than stalling the user program.

HRSOut is going to block as soon as you try to send more than 2 chars, and the amount of time the program stalls depends on the current baudrate setting.

What I like in Positron is the ease with what you can write your own hardware procedures/subs and the hardware register access, which gives you the possibility to take full control over the program.

That's why I rarely use peripheral hardware commands! My point being - if you need full transparency and control, start writing your own HW procs/subs.

+1 To JONW
To know in deep what the compiler is doing it would take a to study the assembler, which the compiler produce with elegance, I'd say.
In the other hand, the answer is rather impossible, because of the broad variety of MCU.
So, just imaging like a piano, you press a key to have a note, then you may have to do a sequence of key taps to have the wanted music. Then is the experience to compose nice melodies 
Thus the first step is to know which MCU you will plan to use, upon a certain selection criteria for the project, then start to read the MCU datasheet to understand what possibilities and features are available.

Great explanations all, thanks. No I understand.

I was asking if it could be done, but now realise not as simply at I thought. Reading the assembly code is a great suggestion 👍😃👍😃