Running code at 1 ms interval

[shodan8192]

Hello,
I'm refurbishing 40 years old welding turntable machine which was driven by 160W brushed DC motoreductor, it's controller is completely damaged.

New control module will be build on ESP32-S3, H-bridge, ACS711EX sensor plus opamp comparators for over- and reverse current, photoelectric tachometer, two TM1650 displays, potentiometers (for diameter and linear speed), direction switch and start/stop foot switch.

One part of program is PWM output control loop, which is responsible for ramp control (eg soft start/stop, rotation reversing) that takes into account overcurrent and reversed current (when decelerating) signals from comparators. To keep PWM steps small and to not miss motor current error conditions this code has to be called frequently, so I choose 1 ms interval for it.

On ESP32 Toit sleep (and in turn Duration.periodic) has real resolution 10ms, which I believe is consequence of CONFIG_FREERTOS_HZ=100 and xTaskNotify used by underlying timer implementation. To achieve 1 ms interval, I've ended up with :

while true:
	/*
	PWM output control code
	*/
	X.repeat: yield

where X was chosen by trials. My program works as expected, but maybe there is more "elegant" solution for this ?

[kasperl]

Hi @shodan8192!

I've shared this piece of code on Discord before and maybe it is useful in this context too:

blocking-sleep duration/Duration -> none:
  limit := (Time.monotonic-us --since-wakeup) + duration.in-us
  while (Time.monotonic-us --since-wakeup) < limit:
    // Busy wait.

It can be improved in various ways - maybe yield every now and then - but using the monotonic microsecond clock seems nice to avoid a fixed number of iterations.

It isn't hard to build a firmware envelope with CONFIG_FREERTOS_HZ=1000, so maybe we should give that a spin too.

[floitsch]

(Kasper responded while I was writing my reply. So some here is repeating what he wrote).

Unfortunately that's currently the best approach.
You could change the CONFIG_FREERTOS_HZ in the sdkconfig, but I doubt you want to go to 1000Hz and you would require a special envelope. It's an option, though. (Although we never tested with different freertos-hz).

Instead of yielding a specific amount of times you could use Time.monotic-us to loop/yield for a specific amount of time.

Since the control loop is probably the most important thing, consider moving that one into a different container and thus process. This way, there isn't any other task that could take longer (when you yield). Alternatively, you could use spawn to create different processes from within the same container.
That said: these are "optimizations" and not necessary. Just giving you options.

Also be aware that garbage collections can take more than 1ms. Depending on your code these slower GCs don't happen often, but they can happen. From your description that sounds acceptable, but be aware of it.

[shodan8192]

Thanks for your responses !

So I will stay with my current solution, just wanted to be sure that I wasn't missed something better. I'm aware of some deviation from 1 ms in my loop, rarely it's 2ms but most often no more than 200us - it's acceptable and has no side effects. In my spare time maybe I'll build envelope with CONFIG_FREERTOS_HZ=1000 just for test or future use.

As an endnote I want to say that this is my first project with Toit, but I found it absolutely fantastic and by far best from what I've try or use for microcontroller programming for years now. Excellent job - thank you !

[shodan8192]

Let's consider following code:

import gpio

output-loop:
  out := gpio.Pin.out 11
  x := 100

  while true:
    x.repeat:
      out.set 0
      out.set 1
    sleep --ms=10

main:
  spawn:: output-loop

What would be the simplest possible way to communicate with such process (eg to change x) from main function, not involving Services ?

[shodan8192]

While sharing data between processes via RAM Bucket works, it turns out that reading and writing to it takes substantial amount of time and it can't be used in a tight loop. Read takes about 2-3 ms and write 3-5 ms.

[floitsch]

It probably goes through a service.

I'm afraid we don't have a really efficient way to communicate between two processes yet. A new item on the TODO list...

[shodan8192]

I've come into a nice solution using simple implementation of SystemMessageHandler_. Communication is two-way and sending value to another process takes 200us on average.

import gpio

class IPCMap implements SystemMessageHandler_:
  static IPC-MAP-STORE_ ::= 1000

  map_/Map := {:}
  receiver-pid_/int

  constructor --receiver-pid/int:
    receiver-pid_ = receiver-pid
    set-system-message-handler_ IPC-MAP-STORE_ this

  on-message type/int gid/int pid/int message/any -> none:
    map_[message[0]] = message[1]

  operator [] key/string -> any:
    return map_.get key

  operator []= key/string value/any -> bool:
    return process-send_ receiver-pid_ IPC-MAP-STORE_ [key, value]

output-loop spawner-pid:
  out ::= gpio.Pin.out 11

  ipc-map ::= IPCMap --receiver-pid=spawner-pid

  cnt := 0
  while true:
    x/int? := ipc-map["x"] // read "x" value sent from main process (null if not sent yet)
    (x ? x : 0).repeat:
      out.set 0
      out.set 1
    cnt++
    sleep --ms=10
    
    ipc-map["counter"] = cnt // send "counter" value to main process

main:
  main-pid    ::= Process.current.id
  output-loop ::= spawn:: output-loop main-pid
  ipc-map     ::= IPCMap --receiver-pid=output-loop.id

  ipc-map["x"] = 100 // send "x" value to output-loop
  
  while true:
    print ipc-map["counter"] // read "counter" value sent from output-loop (null if not sent yet)
    sleep --ms=1000

[kasperl]

Cool stuff! You can simplify return map_.get key --if-absent=: null to return map_.get key and I'd consider caching ipc-map["x"] in a local variable, but that is just my style :)

[shodan8192]

Thanks ! You're right, map_.get key is enough, I overlooked that. I've updated my example with your suggestions.