Code that compiles in ram does not in Flash

[bmentink]

Hi, I have a module that compiles to ram just fine, but it fails when compiling to flash with a stack underflow error, the code that fails is:

0 :noname     \ loop time overhead of task is ~47us
   begin
    bemf @ prev-bemf !      \ store current bemf 
    step @ neutral [@] @ 0 buffer [@] 1 buffer [@] + 2 buffer [@] + 3 / - bemf !
    \ Run the commutate State Machine,  first openloop, then closed
    commutate
    pause         \ Yield, but do this task as fast as we can 
  again ; 256 128 512 spawn motor-task !

Do I have to declare that differently for flash?

[tabemann]

On Mon, May 20, 2024 at 5:46 PM bmentink ***@***.***> wrote: Hi, I have a module that compiles to ram just fine, but it fails when compiling to flash with a stack underflow error, the code that fails is: 0 :noname \ loop time overhead of task is ~47us begin bemf @ prev-bemf ! \ store current bemf step @ neutral [@] @ 0 buffer [@] 1 buffer [@] + 2 buffer [@] + 3 / - bemf ! \ Run the commutate State Machine, first openloop, then closed commutate pause \ Yield, but do this task as fast as we can again ; 256 128 512 spawn motor-task ! Do I have to declare that differently for flash?

Setting variables in code compiled to flash is no está bien in most cases, because the variable likely won't actually really exist yet, and its value will not persist across reboots. In this case, I would rewrite it as: : make-motor-task ( -- ) 0 [: \ loop time overhead of task is ~47us begin bemf @ prev-bemf ! \ store current bemf step @ neutral [@] @ 0 buffer [@] 1 buffer [@] + 2 buffer [@] + 3 / - bemf ! \ Run the commutate State Machine, first openloop, then closed commutate pause \ Yield, but do this task as fast as we can again ;] 256 128 512 spawn motor-task ! ; initializer make-motor-task Travis Message ID: ***@***.***>

…

[bmentink]

Thanks. So that code is within a module, as is another task, plus all the rest of the code.
What is the best way to set that up, do I have to pull those tasks out of the module and run initializer on them?
How then do I setup turnkey etc.

I can't find any info on initializer apart from your example. What does it do?

Here is what I have currenly ... a lot of code has been removed from the module to keep it short:

begin-module bldc
....
...
...

  \ Motor task -- we are in this task when running
  0 :noname     \ loop time overhead of task is ~47us
   begin
    bemf @ prev-bemf !      \ store current bemf 
    step @ neutral [@] @ 0 buffer [@] 1 buffer [@] + 2 buffer [@] + 3 / - bemf !
    \ Run the commutate State Machine,  first openloop, then closed
    commutate
    pause         \ Yield, but do this task as fast as we can 
  again ; 256 128 512 spawn motor-task !

  \ Speed task, will need to make this torque control, then later PID speed.
  0 :noname     
   begin
    \ set the duty cycle from buffered value
    3 buffer [@] s>f 3,5 f* f>s pwm-duty !      \ 3.5 is dependant on operating frequency
    10,0 pwm-duty @ s>f DEMAG_DELAY f/ d- 1,0 dmax f>s com_delay !   \ calc commutation delay based on pwm-duty 
    pwm-duty @ THROTTLE_THRESHOLD < if 0 state ! then                \ reset the state machine if we throttle right off
    60_000_000,0 120deg-time @ s>f 3,0 f* f/ 4,0 f/ f>s rpm !        \  calc rpm 4-pole motor
    40 ms         \ Update speed every 40 ms
  again ; 256 128 512 spawn speed-task !

  \ Do all the init stuff and run
  : init-bldc 
    init-array
    init-gpio
    init-pwm
    motor-task @ run
    speed-task @ run
  ;

  : off
    motor-task @ stop
    0 0 0 0 0 0 writePhases
  ;

 initializer init-bldc
    
end-module> import

[tabemann]

On Mon, May 20, 2024 at 7:32 PM bmentink ***@***.***> wrote: Thanks. So that code is within a module, as is another task, plus all the rest of the code. What is the best way to set that up, do I have to pull those tasks out of the module and run initializer on them? How then do I setup turnkey etc.

What TURNKEY is is a word that, if defined, is called after INIT is called but before WELCOME is called and the REPL is started (which will occur if TURNKEY returns). It is meant for creating turnkey applications that start on boot-up, which are guaranteed to execute after everything is initialized even if INIT is defined after it.

I can't find any info on initializer apart from your example. What does it do?

What INITIALIZER does is take the name of a word as an argument and, if compiling to RAM, executes that word immediately or, if compiling to flash, compiles to the FORTH module (regardless of whichever module you are currently defining words for) a new INIT word that calls the previous INIT word and then calls the word you named, so that word will always be called in-order on boot in the initialization process. Travis

…

Message ID: ***@***.***>

[bmentink]

Ok so with initailizer you don't need to include init like this:

: init init bldc::init-bldc ;

.. as described in the wiki.

So the tail end of my code above could look like?

  \ Do all the init stuff and run
  : init-bldc 
    init-array
    init-gpio
    init-pwm
    make-motor-task
    make-speed-task
    motor-task @ run
    speed-task @ run
  ;

  : off
    motor-task @ stop
    0 0 0 0 0 0 writePhases
  ;

  initializer init-bldc
    
end-module> import


: turnkey begin 1000 ms key? until ;

compile-to-ram

Is this correct? (I have created the two tasks as you specified)

[tabemann]

On Mon, May 20, 2024 at 9:08 PM bmentink ***@***.***> wrote: Ok so with initailizer you don't need to include init like this: : init init bldc::init-bldc ; .. as described in the wiki. So the tail end of my code above could look like? \ Do all the init stuff and run : init-bldc init-array init-gpio init-pwm make-motor-task make-speed-task motor-task @ run speed-task @ run ; : off motor-task @ stop 0 0 0 0 0 0 writePhases ; initializer init-bldc end-module> import : turnkey begin 1000 ms key? until ; compile-to-ram Is this correct? That is almost correct. The only issue with this code is that I presume

you are defining MOTOR-TASK and SPEED-TASK above this code. You will need to reboot after compiling code to flash before you can use these variables safely, so I would suggest replacing COMPILE-TO-RAM with REBOOT. Note that this will trigger the TURNKEY, so I would only reboot when you are done compiling all of your code you want to live in flash. Travis

…

Message ID: ***@***.***>

[bmentink]

Hi, yes all code is in flash by this point. So just to confirm, I don't need to call init in my above code as per the wiki description on turnkey? Or do I still have to add : init init ; in my code just below the end-module?

Thanks

[bmentink]

Ok, so I presume that TURNKEY and INITIALIZER are two ways to get your software to boot from flash. I have tried both and nothing happens (no program runs and no REPL) I tried both the TURNKEY method and INITIALIZER ..

For TURNKEY I tried this after the module declaration and import:

: init init init-bldc ;

: turnkey begin 1000 ms key? until ;

init-bldc is the main entry point for my software .. nothing worked so had to put zeptoforth back on the rp2040 ..

I then tried just declaring initializer init-bldc by itself ... no trurnkey or init .. and that did not work either, same result.
Am I doing this correctly, or is there something in my code that compiles but does not run in flash ...?

[tabemann]

On Tue, May 21, 2024 at 3:52 PM bmentink ***@***.***> wrote: Ok, so I presume that TURNKEY and INITIALIZER are two ways to get your software to boot from flash. I have tried both and nothing happens (no program runs and no REPL) I tried both the TURNKEY method and INITIALIZER .. For TURNKEY I tried this after the module declaration and import: : init init init-bldc ; : turnkey begin 1000 ms key? until ; init-bldc is the main entry point for my software .. nothing worked so had to put zeptoforth back on the rp2040 .. I then tried just declaring initializer init-bldc by itself ... no trurnkey or init .. and that did not work either, same result. Am I doing this correctly, or is there something in my code that compiles but does not run in flash ...?

There must be something wrong in what INIT-BLDC calls that is not working, which without seeing all of your code I would not be able to see how and why. Travis

[bmentink]

Ok, since this will be hard to debug. Can you suggest what sort of things to look out for that don't play well with running from flash, but is fine for running from ram? I don't have any more :noname ; constructs now, all replaced with [: and ;], anything else that would trip me up ..

[tabemann]

On Tue, May 21, 2024 at 8:14 PM bmentink ***@***.***> wrote: Ok, since this will be hard to debug. Can you suggest what sort of things to look out for that don't play well with running from flash, but is fine for running from ram? I don't have any more :noname ; constructs now, all replaced with [: and ;], anything else that would trip me up ..

The biggies are setting or getting VARIABLE's, VALUE's, and BUFFER:'s that you have defined during compilation before having rebooted. Doing these things is guaranteed to result in undefined behavior. Also note that replacing :NONAME ; with [: ;] is not a solution by itself; rather, putting those [: ;] inside other words that will be executed at runtime is what is needed. Travis

…

Message ID: ***@***.***>

[bmentink]

Thanks. By selectively isolating lines in init-bldc I have tracked it down to the following code, if I remove the call to this word then I can get into the REPL ok,

: make-speed-task ( -- )
  0 [:    
    begin
      \ set the duty cycle from buffered value
      3 buffer [@] s>f 3,5 f* f>s pwm-duty !      \ 3.5 is dependant on operating frequency
      10,0 pwm-duty @ s>f DEMAG_DELAY f/ d- 1,0 dmax f>s com_delay !   \ calc commutation delay based on pwm-duty 
      pwm-duty @ THROTTLE_THRESHOLD < if 
        0 state ! 
        0 0 0 0 0 0 writePhases 
      then  \ reset the state machine and stop the motor, if we throttle right off
      60_000_000,0 120deg-time @ s>f 3,0 f* f/ 4,0 f/ f>s rpm !        \  calc rpm 4-pole motor
      40 ms         \ Update speed every 40 ms
    again ;] 256 128 512 spawn speed-task !
  ;

The task before that was defined in exactly the same way, does it look ok? As I mentioned earlier, this is part of a module like all my code, and the module compiles to flash ok. The module contains all VARIABLES and CONSTANTS, buffers etc

The code above compiles ok. But when I include the line speed-task @ run
it fails ..... but not when in ram.

[tabemann]

On Tue, May 21, 2024 at 10:00 PM bmentink ***@***.***> wrote: Thanks. By selectively isolating lines in init-bldc I have tracked it down to the following code, if I remove the call to this word then I can get into the REPL ok, : make-speed-task ( -- ) 0 [: begin \ set the duty cycle from buffered value 3 buffer [@] s>f 3,5 f* f>s pwm-duty ! \ 3.5 is dependant on operating frequency 10,0 pwm-duty @ s>f DEMAG_DELAY f/ d- 1,0 dmax f>s com_delay ! \ calc commutation delay based on pwm-duty pwm-duty @ THROTTLE_THRESHOLD < if 0 state ! 0 0 0 0 0 0 writePhases then \ reset the state machine and stop the motor, if we throttle right off 60_000_000,0 120deg-time @ s>f 3,0 f* f/ 4,0 f/ f>s rpm ! \ calc rpm 4-pole motor 40 ms \ Update speed every 40 ms again ;] 256 128 512 spawn speed-task ! ; The task before that was defined in exactly the same way, does it look ok? As I mentioned earlier, this is part of a module like all my code, and the module compiles to flash ok. The module contains all VARIABLES and CONSTANTS, buffers etc From looking at this code, the only obvious issue is 0 STATE ! simply

because STATE is a special variable that determines whether one is in interpretation versus compilation mode. (I do use STATE in my own code, to be honest, but it is always as a local variable, and this is not a local variable.) Travis

…

Message ID: ***@***.***>

[bmentink]

Ok thanks, I will rename state .. However, is it not local when defined in a module?

The other thing I notice that does not work when compiled to flash. I have the following array defining words:

\ Array defining words
  : [] ( size tib:"name" -- ) create dup , cells allot ;
  : [!] ( value index array -- ) swap cells + cell+ ! ;
  : [@] ( index array -- value ) cell+ swap cells + @ ;
  : [A] ( index array -- address ) cell+ swap cells + ;

defined a couple of arrays like this:

 5 [] buffer   
  6 [] neutral  

And they are used like this:

2 buffer [A]  0 neutral [!]

I am storing the address of 2 buffer in the array neutral at index 0. This works fine compiled to ram. Running from flash I get 0 neutral [@] returning -1 not the address of 2 buffer ..

[tabemann]

On Tue, May 21, 2024 at 10:22 PM bmentink ***@***.***> wrote: Ok thanks, I will rename state The other thing I notice that does not work when compiled to flash. I have the following array defining words: \ Array defining words : [] ( size tib:"name" -- ) create dup , cells allot ; : [!] ( value index array -- ) swap cells + cell+ ! ; : [@] ( index array -- value ) cell+ swap cells + @ ; : [A] ( index array -- address ) cell+ swap cells + ; And they are used like this: 2 buffer [A] 0 neutral [!] I am storing the address of 2 buffer in the array neutral at index 0. This works fine compiled to ram.

Yes, this won't work when compiled to flash. The normal word for defining buffers is BUFFER: -- note that when compiling to flash, you need to reboot before you can use the buffer defined. Travis

[bmentink]

Ahh, thanks. Would be helpful to know the `why' my words won't work in flash.

I tried buffer: as in say 10 buffer: buffer but when accessed from an interrupt routine (e.g: data index buffer ! ) crashes the cpu .... even running from ram.
What needs to be done to access it correctly .... I can't have much overhead in the interrupt routine as this is a real-time application.

The documentation states:

##### `buffer:`
( # "name" -- )

Specify a buffer of a given size

... but gives no clue to access, can it be used as an array?

Cheers, Bernie

[tabemann]

On Wed, May 22, 2024 at 3:44 PM bmentink ***@***.***> wrote: Ahh, thanks. Would be helpful to know the `why' my words won't work in flash.

One reason why CREATE-ing a buffer doesn't work when done from flash is that CREATE creates the buffer *in flash*, which cannot be written to at runtime. CREATE-ing things in flash is only useful if you plan on creating a constant table which will not change at runtime.

I tried buffer: as in say 10 buffer: buffer but when accessed fro an interrupt routine crashes .... even running from ram. What needs to be done to access it correctly .... I can't have much overhead in the interrupt routine as this is a real-time application.

The problem I see with 10 BUFFER: BUFFER is that you aren't allotting a multiple of four bytes, which can cause problems due to alignment (alignment matters, especially on the RP2040 since it is Cortex-M0+ where improper alignment will cause a hard fault). Travis

…

Message ID: ***@***.***>

[bmentink]

Wow this is difficult! I expected to be able to do the same as FlashForth where CREATE DOES> works in flash.

You still have not told me how to create an array in flash.

If I do 3 cells buffer: buffer then I would expect to be able to do 10 2 buffer ! to store 10 to the 3rd element in the array. But it seems my created word buffer only takes a single argument ..... how do I use it? Example please.
(I tested in ram, but assume it is state smart)

[bmentink]

Ok, got it going. I had to implement my array this way.

  5 cells buffer: buffer   
  6 cells buffer: neutral  \
  : [!] ( data index buffer_addr -- ) swap cells + ! ;
  : [@]  ( index buffer_adr -- ) swap cells + @ ;
  : [A]  ( index buffer_adr -- ) swap cells +  ;

Usage:
1234 3 buffer [!]
3 buffer [@]

That worked both in ram and flash.
It does put more overhead for my interrupt routine though, which means my top speed is now reduced ... or maybe just running out of flash is slower than ram. (I get 3000 rpm running in ram, 2500 rpm flash)

[tabemann]

On Wed, May 22, 2024 at 7:55 PM bmentink ***@***.***> wrote: Ok, got it going. I had to implement my array this way. 5 cells buffer: buffer 6 cells buffer: neutral \ : [!] ( data index buffer_addr -- ) swap cells + ! ; : [@] ( index buffer_adr -- ) swap cells + @ ; : [A] ( index buffer_adr -- ) swap cells + ; That worked both in ram and flash

Good to hear that you got it working. About creating arrays in flash, there are two types of arrays -- arrays whose words are compiled to flash but which live in RAM, and constant arrays that are programmed into flash. The former are created with BUFFER: and the latter are created with CREATE. In the former case, they take a number of bytes as an argument (but should normally be a multiple of four), and the word that is compiled is simply the address of the buffer in RAM ─ it is up to the user to figure out what to do with it. In the latter case, you typically want to use words such as , H, and C, to compile values into flash starting at the address compiled by CREATE. Note that CREATE also works in RAM, but to make sure that your code works both when compiled to RAM and compiled to flash, you still typically want to use BUFFER: with mutable arrays and CREATE with immutable arrays. Travis

…

Message ID: ***@***.***>

[tabemann]

On Wed, May 22, 2024 at 9:10 PM Travis Bemann ***@***.***> wrote: On Wed, May 22, 2024 at 7:55 PM bmentink ***@***.***> wrote: > Ok, got it going. I had to implement my array this way. > > 5 cells buffer: buffer > 6 cells buffer: neutral \ > : [!] ( data index buffer_addr -- ) swap cells + ! ; > : [@] ( index buffer_adr -- ) swap cells + @ ; > : [A] ( index buffer_adr -- ) swap cells + ; > > That worked both in ram and flash > Good to hear that you got it working. About creating arrays in flash, there are two types of arrays -- arrays whose words are compiled to flash but which live in RAM, and constant arrays that are programmed into flash. The former are created with BUFFER: and the latter are created with CREATE. In the former case, they take a number of bytes as an argument (but should normally be a multiple of four), and the word that is compiled is simply the address of the buffer in RAM ─ it is up to the user to figure out what to do with it. In the latter case, you typically want to use words such as , H, and C, to compile values into flash starting at the address compiled by CREATE. Note that CREATE also works in RAM, but to make sure that your code works both when compiled to RAM and compiled to flash, you still typically want to use BUFFER: with mutable arrays and CREATE with immutable arrays.

Terry Porter alerted me to your message about using the RP2040's ADC on the Mecrisp forum on SourceForge, so I responded over there. I have never used the ADC's FIFO, with or without DMA, but I tried to provide what I do know about it in case it could be helpful. If you wish to respond I would suggest you respond here, as I can reply to messages on GitHub through my email, which I have access to at work, but I would prefer to not log into SourceForge while I am at work during the day. Travis

…

Message ID: ***@***.***> >

[bmentink]

Ok, thanks, will have a look. I don't know if it will help in my case, the ADC module is rubbish on the rp2040, so actually thinking to re-port my application from rp2040 to Blackpill board (stm32f411)

It has much better ADC's. I was just looking to see what is involved and notice that you do not have a PWM driver for the Blackpill yet, do you intend writing one anytime? If not I will give it a go ..

[tabemann]

On Thu, May 23, 2024 at 11:38 PM bmentink ***@***.***> wrote: Ok, thanks, will have a look. I don't know if it will help in my case, the ADC module is rubbish on the rp2040, so actually thinking to re-port my application from rp2040 to Blackpill board (stm32f411) It has much better ADC's. I was just looking to see what is involved and notice that you do not have a PWM driver for the Blackpill yet, do you intend writing one anytime? If not I will give it a go ..

I have not done much to the STM32F411 myself recently; I haven't actually tested my Black Pill board in a while. There are a few issues with it (e.g. zeptoforth on it does not leave much room left for user code, so you may want to put in a custom build that strips out unneeded stuff, e.g. FAT32). The STM32F411 has only 512 KB of flash as opposed to the 1 MB of flash on the STM32F407 or STM32F746. This is why I have been largely avoiding working with the STM32F411 myself. If you are interested I would very much appreciate a PWM driver for the STM32F411 ─ I'd include it with zeptoforth. I personally have been hesitant to work on the timer/counter peripherals on the STM32 platforms simply because of Terry recounting their complexity combined with hearing little demand for support for zeptoforth on STM32 platforms (so it has often seemed like putting work into them might be wasted effort). Travis

…

Message ID: ***@***.***>

[bmentink]

Thanks. I have just built from source, I guess that will be only the base system, then add extras during setup_xxxx.fs ?

At a glance could not see the FAT32 stuff, is that in core?
I will attempt the PWM when I get a bit of time ..

By the way, what do I need to tweak to get 921,600 baud for the F411 target. My USB->Uart can handle that ... will the F411? ... or am I best to use swdcom. Is there a way to use that with zeptocom.js?

Cheers

[tabemann]

On Fri, May 24, 2024, 00:10 bmentink ***@***.***> wrote: Thanks. I have just built from source, I guess that will be only the base system, then added during setup_xxxx.fs ? At a glance could not see the FAT32 stuff, is that in core? I will attempt the PWM when I get a bit of time ..

FAT32 is pulled in by: #include src/common/forth/full_extra.fs in src/stm32f411/forth/setup_full.fs and like. Travis

…

[bmentink]

Hi Travis,

As mentioned in the sourceforge forum, I might persevere a bit longer with the rp2040 adc's, with moving some code onto the 2nd core. With that in mind, what is the best(fastest) way to share variables between cores? Also, can you point me to some guides for running on the 2nd core .. thanks.

Bernie

[tabemann]

On Fri, May 24, 2024, 19:44 bmentink ***@***.***> wrote: Hi Travis, As mentioned in the sourceforge forum, I might persevere a bit longer with the rp2040 adc's, with moving some code onto the 2nd core. With that in mind, what is the best(fastest) way to share variables between cores? Also, can you point me to some guides for running on the 2nd core .. thanks

if you are going to use the second core in a critical section as I recommended and you have a tight realtime need what you really need to do is to share variables directly in memory and use task notifications to synchronize the second core with tasks on the first core. (This is because task notifications can be done from within critical sections -- and interrupt handlers -- unlike other synchronization constructs and are the most lightweight synchronization construct made available by zeptoforth.) In general though working with the second core is like working with the first core except that by default most interrupt handlers along with the USB CDC pending operation run on the first core, so if you are going to have interrupts off or be in a critical section for any extended period of time I would highly recommend doing it on the second core. (In particular the USB CDC console will not function if interrupts are disabled or one is in a critical section on the first core.) Note that outside of interrupts being disabled or being in a critical section communication and synchronization between tasks on different cores is just like communication and synchronization between tasks on the same core. I have put a good amount of effort into making zeptoforth on the RP2040 act pretty much like an SMP system aside from which cores interrupts and pending operations run on and the fact that tasks are bound to particular cores. Travis

…

[bmentink]

Brilliant Thanks. :)

[bmentink]

Hi Travis,

Regarding shared variables and critical-sections. If I have the following interrupt routine running on core0:

: pwm_wrap_int ( -- ) 
    \ high test_pin pin! 
    adc-mux @  mux 1 adc@@ adc-mux @ buffer [!]              \ save adc1 values in buffer array 
    1 adc-mux +!
    adc-mux @ 3 > if 2 adc@@ 3 buffer [!]  0 adc-mux !  then             \ save throttle
    \ low test_pin pin! 
    %00000001 clear-pwm-int    \ Clear interrupt
  ;

The only variable I want to access is the buffer array, is this correct for access on core1?

: make-motor-task ( -- )
  0 [:    
    \ 0 current-task task-priority!
    begin
      bemf @ prev-bemf !      \ store current bemf 
    BEGIN-CRITICAL
      step @ neutral [@] @ 0 buffer [@] 1 buffer [@] + 2 buffer [@] + 3 / - bemf !
    END-CRITICAL
      \ Run the commutate State Machine,  first openloop, then closed
      commutate
      \ pause         \ Yield, but do this task as fast as we can 
    again ;] 256 128 512 1 spawn-on-core motor-task !
  ;

I tried this and it does not work at all ..

[tabemann]

On Sun, May 26, 2024 at 4:18 PM bmentink ***@***.***> wrote: Hi Travis, Regarding shared variables and critical-sections. If I have the following interrupt routine running on core0: : pwm_wrap_int ( -- ) \ high test_pin pin! adc-mux @ mux 1 adc@@ adc-mux @ buffer [!] \ save adc1 values in buffer array 1 adc-mux +! adc-mux @ 3 > if 2 adc@@ 3 buffer [!] 0 adc-mux ! then \ save throttle \ low test_pin pin! %00000001 clear-pwm-int \ Clear interrupt ; The only variable I want to access is the buffer array, is this correct for access on core1? : make-motor-task ( -- ) 0 [: \ 0 current-task task-priority! begin bemf @ prev-bemf ! \ store current bemf BEGIN-CRITICAL step @ neutral [@] @ 0 buffer [@] 1 buffer [@] + 2 buffer [@] + 3 / - bemf ! END-CRITICAL \ Run the commutate State Machine, first openloop, then closed commutate \ pause \ Yield, but do this task as fast as we can again ;] 256 128 512 1 spawn-on-core motor-task ! ; I tried this and it does not work at all ..

There is a big 'but' about BEGIN-CRITICAL ... END-CRITICAL (and their convenience routine, CRITICAL) - they only apply to a single core. I originally wrote the docs before zeptoforth supported multicore, so I probably did not make this clear enough. Unfortunately, most synchronization means are simply too slow for what you are trying to do here, so you will have to get really low-level. The routine you want for this is MULTICORE::TEST-SET, which (of course) is multicore-aware. It will enable you to implement a very tight spinlock. How I would rewrite your routines is as follows: variable sync 1 constant pwm-wrap-sync 2 constant motor-task-sync : pwm_wrap_int ( -- ) \ high test_pin pin! begin pwm-wrap-sync sync multicore::test-set until \ BEGIN OUR CRITICAL SECTION adc-mux @ mux 1 adc@@ adc-mux @ buffer [!] \ save adc1 values in buffer array 1 adc-mux +! adc-mux @ 3 > if 2 adc@@ 3 buffer [!] 0 adc-mux ! then \ save throttle \ low test_pin pin! %00000001 clear-pwm-int \ Clear interrupt false sync ! \ END OUR CRITICAL SECTION ; : make-motor-task ( -- ) 0 [: \ 0 current-task task-priority! begin bemf @ prev-bemf ! \ store current bemf begin motor-task-sync sync multicore::test-set until \ BEGIN OUR CRITICAL SECTION step @ neutral [@] @ 0 buffer [@] 1 buffer [@] + 2 buffer [@] + 3 / - bemf ! false sync ! \ END OUR CRITICAL SECTION \ Run the commutate State Machine, first openloop, then closed commutate \ pause \ Yield, but do this task as fast as we can again ;] 256 128 512 1 spawn-on-core motor-task ! ; Note that this code will *only* work properly if PWM_WRAP_INT runs on core 0. Otherwise this will hang forever (because if the PWM wrap interrupt occurs inside the spinlock protected section it will wait forever). Also note that I have not tested this code, so I am not guaranteeing it will work. Travis

…

Message ID: ***@***.***>

[bmentink]

Thanks. But unfortunately failed to even run the motor. After some debugging, found it failed at the point the pwm interrupt was enabled ..

At that point cpu was hung, not even REPL was working, had to do a physical reset of the board.
Yes, the interrupt is only run on core 0 ..

[tabemann]

On Sun, May 26, 2024 at 5:58 PM bmentink ***@***.***> wrote: Thanks. But unfortunately failed to even run the motor. After some debugging, found it failed at the point the pwm interrupt was enabled .. At that point cpu was hung, not even REPL was working, had to do a physical reset of the board. Yes, the interrupt is only run on core 0 ..

Oh I forgot a very important detail - you have to initialize SYNC to FALSE first. Yes, it won't work at all if you don't do that. Travis

…

Message ID: ***@***.***>

[bmentink]

Same fault ...

[tabemann]

On Sun, May 26, 2024, 18:33 bmentink ***@***.***> wrote: Same fault ...

My thought then is that there is an issue with clearing the interrupt. This probably isn't the right solution, but try clearing the pending PWM interrupt at the end of the handler as a test. Travis

…

[bmentink]

I don't see where sync get's set to true ..?

[tabemann]

On Sun, May 26, 2024 at 6:59 PM bmentink ***@***.***> wrote: I don't see where sync get's set to true ..?

MY-VALUE SYNC MULTICORE::TEST-SET tests SYNC as to whether it is FALSE (i.e. zero), and if it is it sets SYNC to MY-VALUE and returns TRUE, else it returns FALSE, in a task-and-multicore-safe fashion. It turns off interrupts while doing this, and makes use of a hardware spinlock on the RP2040 to ensure that the other core is not doing the same at the same time. Using this inside a BEGIN ... UNTIL look will form a tight spinlock which will test SYNC's value for being FALSE as fast as possible while maintaining multitasking and multicore-safety. Travis

…

Message ID: ***@***.***>

[bmentink]

Ok, thanks. Regarding your earlier response, I do have %00000001 clear-pwm-int \ Clear interrupt at the end of my interrupt as above, should I be doing something else?

[tabemann]

On Sun, May 26, 2024 at 7:48 PM bmentink ***@***.***> wrote: Ok, thanks. Regarding your earlier response, I do have %00000001 clear-pwm-int \ Clear interrupt at the end of my interrupt as above, should I be doing something else? If you are using PWM channel 0, then that's correct. How fast do you have

your PWM wrapping around? If it wraps around before the handler can complete, it will freeze the system, because the PWM interrupt will be raised before the pWM handler can return. Travis

…

Message ID: ***@***.***>

[bmentink]

No, the interrupt handler take about 6..7us, the pwm is 20khz (50us) ... works perfectly fine before these mods you suggested. I will try to measure with the mods ... if I can get it to run ... ;)

EDIT: I removed the critical section from the task side, and the motor runs .. sort of .. but that allows me to see the time it takes in the interrupt routine. I measured 11us worse case and 6us best case ..

When I add the task critical section code back in, it does not run at all ... strange ..

[tabemann]

On Sun, May 26, 2024, 20:24 bmentink ***@***.***> wrote: No, the interrupt handler take about 6..7us, the pwm is 20khz (50us) ... works perfectly fine before these mods you suggested. I will try to measure with the mods ... if I can get it to run ... ;)

If there is a way you can get these to work without any kind of critical section (i.e. without a TEST-SET loop) I would do it that way. The whole purpose of the TEST-SET loops was to enable a critical section across cores, that is all. Travis

…

[bmentink]

Hi Travis,

I have gone back to single core (0) and have disabled multitasking with BEGIN-CRITICAL and everything is working much better. I will do the tried and true method of counter based delays ,to do the less critical things which I had originally left for tasks.

I have managed to get to the rpm limit for this motor, so can't test further until I get a higher KV motor. Will order one soon.
Thanks again for all your valuable help.

Bernie

[tabemann]

On Mon, May 27, 2024 at 8:30 PM bmentink ***@***.***> wrote: Hi Travis, I have gone back to single core (0) and have disabled multitasking with BEGIN-CRITICAL and everything is working much better. I will do the tried and true method of counter based delays ,to do the less critical things which I had originally left for tasks.

I was going to say that if it doesn't work for you to go back to one core, but I would have suggested doing everything on the second core, so you can have BEGIN-CRITICAL on permanently without interfering with things like the USB CDC console.

I have managed to get to the rpm limit for this motor, so can't test further until I get a higher KV motor. Will order one soon.

Good luck with that!

Thanks again for all your valuable help.

You're welcome! Travis

…

Message ID: ***@***.***>

[bmentink]

I was going to say that if it doesn't work for you to go back to one core,
but I would have suggested doing everything on the second core, so you can
have BEGIN-CRITICAL on permanently without interfering with things like the
USB CDC console.

I am running nearly everything in the interrupt handler now, how do I run that on the 2nd core?

[tabemann]

On Tue, May 28, 2024 at 3:29 PM bmentink ***@***.***> wrote: I was going to say that if it doesn't work for you to go back to one core, but I would have suggested doing everything on the second core, so you can have BEGIN-CRITICAL on permanently without interfering with things like the USB CDC console. I am running nearly everything in the interrupt handler now, how do I run that on the 2nd core?

You start a task on the second core, you specify the RP2040 interrupt configuration registers so they specify the second core (you should in the refman see things named stuff like PROC0 and PROC1), and you execute the NVIC words for configuring the interrupt on that core. Note that if you are doing everything in interrupt handlers you don't need BEGIN-CRITICAL anyways provided your interrupt handlers have a higher priority than the PendSV hardware exception (which is used by the multitasker and the USB CDC console), because your interrupt handlers will take priority over the PendSV handler. Travis

…

Message ID: ***@***.***>

[bmentink]

Ok. So there is no forth words defined for running interrupts on the 2nd core?

I did notice that in the pwm driver you do enable pwm on the 2nd core .. I had a look in the test folder, but did not see any pwm example of running on the 2nd core, or interrupts on the 2nd core. Are these still to be done at some stage?

If so, I will do as you say and do direct register access ..

I note that the PWM_IRQ_WRAP interrupt is routed to the second core, as well, so nothing to be done there, I have not found out how to enable that interrupt on the 2nd core.

I found PROC1_NMI_MASK and have defined that, but cannot see where it's bits are defined to enable PWM_IRQ_WRAP ..

[tabemann]

On Tue, May 28, 2024, 19:05 bmentink ***@***.***> wrote: Ok. So there is no forth words defined for running interrupts on the 2nd core? I did notice that in the pwm driver you do enable pwm on the 2nd core .. I had a look in the test folder, but did not see any pwm example of running on the 2nd core, or interrupts on the 2nd core. Are these still to be done at some stage? If so, I will do as you say and do direct register access .

Know what - that is a relic of when I wanted to enable the user to be able to use interrupts on any core but I found it to cause interrupts on both cores simultaneously which invariably broke things. I got rid of that functionality with other peripherals but forgot to remove it for PWM. As a result, if you are using PWM, do not even try to use the second core and I will remove this functionality from the repository now and from the next release. And yes, I did not actually test PWM with multicore, which is why I did not catch this. My apologies, Travis

…

[bmentink]

No Problem ... thanks, will stay with the core 0 for now ..

[tabemann]

On Tue, May 28, 2024 at 7:28 PM bmentink ***@***.***> wrote: No Problem ... thanks, will stay with the core 0 for now ..

I have made a new release, 1.5.5.1 ( https://github.com/tabemann/zeptoforth/releases/tag/v1.5.5.1) which removes enabling the PWM interrupt on the second core to avoid the PWM interrupt being raised simultaneously on both cores when both cores are in use. Travis

…

Message ID: ***@***.***>

[bmentink]

Thanks ..

[tabemann]

On Fri, May 31, 2024 at 5:42 PM bmentink ***@***.***> wrote: Thanks ..

I know it isn't an ideal solution, where which core the interrupt is raised on ought to be user-configurable, but it at least will keep the PWM interrupt from resulting in undefined behavior just because one happens to be using both cores. However, there is nothing stopping the user from using the NVIC words to disable the PWM interrupt on core 0 and then enable the PWM interrupt on core 1 to achieve the desired effect. Travis

…

Message ID: ***@***.***>

[bmentink]

Hi Again Travis,

I have used the following word to set/clr bits of a port, but it is not very efficient as I am setting/clearing each bit. Is there a better Forth word that I can use that directly masks the GPIO registers?

 : mux ( sel -- )
    case 
      0 of [ mux0_pin bit ] literal GPIO_OUT_CLR ! [ mux1_pin bit ] literal GPIO_OUT_CLR ! endof
      1 of [ mux0_pin bit ] literal GPIO_OUT_SET ! [ mux1_pin bit ] literal GPIO_OUT_CLR ! endof
      2 of [ mux0_pin bit ] literal GPIO_OUT_CLR ! [ mux1_pin bit ] literal GPIO_OUT_SET ! endof
      3 of [ mux0_pin bit ] literal GPIO_OUT_SET ! [ mux1_pin bit ] literal GPIO_OUT_SET ! endof
    endcase
  ;

This word uses a 2-bit selector to select an ADC mux. mux0_pin is say bit6, mux1_pin bit7.
Is there a faster way to do this?

[tabemann]

The only real improvement I can suggest is:

: do-mux-0 ( -- ) [ mux0_pin bit mux1_pin bit or ] literal GPIO_OUT_CLR ! ;
: do-mux-1 ( -- ) [ mux0_pin bit ] literal GPIO_OUT_SET ! [ mux1_pin bit ] literal GPIO_OUT_CLR ! ;
: do-mux-2 ( -- ) [ mux0_pin bit ] literal GPIO_OUT_CLR ! [ mux1_pin bit ] literal GPIO_OUT_SET ! ;
: do-mux-3 ( -- ) [ mux0_pin bit mux1_pin bit or ] literal GPIO_OUT_SET ! ;
create mux-table ' do-mux-0 , ' do-mux-1 , ' do-mux-2 , ' do-mux-3 ,
: mux ( u -- )
  dup 4 u< if cells mux-table + @ execute else drop then
;

This gets around some of the inefficiencies of the implementation of case ... endcase in zeptoforth.

[bmentink]

Thanks, will time that compared to my mux ....
That Set/Clear ARM model has always bugged me ... oh for the days of read-modify-write CPU's ..

Hmm, I don't think your example will work as execute can't be used in an interrupt, correct? It crashes the CPU ..

[bmentink]

I did the following:

: mux
    mux0_pin lshift
    dup 
    GPIO_OUT_SET !
    $3  mux0_pin lshift
    xor GPIO_OUT_CLR !
  ;

It ended up being twice as fast as the case statement version (800ns versus 1.6us)
Of course, the above example assumes mux1_pin is mux0_pin +1. :)

[tabemann]

Thanks, will time that compared to my mux .... That Set/Clear ARM model has always bugged me ... oh for the days of read-modify-write CPU's ..

Hmm, I don't think your example will work as execute can't be used in an interrupt, correct? It crashes the CPU ..

Oh there was just a very stupid bug in my example code - I had accidentally forgotten the ,s when setting up the jump table. It should work now.

[bmentink]

Thanks. Will time it compared to my latest ..
EDIT: Your version takes 1us, slightly slower than my pretend read-modify-write ..

[tabemann]

Yeah, from second thought your latest version is obviously better assuming there is no need for validation. (My code can be made faster through removing the validation but it still will be slower.)

[bmentink]

Yeah, from second thought your latest version is obviously better assuming there is no need for validation. (My code can be made faster through removing the validation but it still will be slower.)

Yep, the time I gave above was for a version of your code with the validation removed.

On another issue: Do you have any documentation for the PIO forth code. I am having trouble understanding it compared to the asm version ... if not, the examples probably need more comments on each instruction to be clear .. thanks.

[tabemann]

Are there any particular improvements you would suggest upon the PIO documentation?

[bmentink]

No, the documentation is fine. Just a few comments in the examples would be good, otherwise you have to continuously refer to the documentation to work out what each line of code does .. especially confusing is the jmp labels, still have not worked that out ..

[tabemann]

On Sun, Jun 16, 2024 at 3:34 PM bmentink ***@***.***> wrote: No, the documentation is fine. Just a few comments in the examples would be good, otherwise you have to continuously refer to the documentation to work out what each line of code does .. especially confusing is the jmp labels, still have not worked that out ..

I apologize for the belated response, but I have now added comments to the PIO programs in the zeptoforth codebase. They are not in a release tarball yet, but are in the git master and devel branches. Travis

…

Message ID: ***@***.***>