2: The cursor is off after the idle period. When you click on a number, you jump directly to that item. Wehen you press * the first item goes into edit mode. When you press # nothing happens. When you press "Up" you get the first field w. Cursor, when you pree down you get the second with Cursor. Cursor = Menupointer (in my case a arrow like i took out of one of your examples).

I'll be honest with you, you're probably one of the first to use the keypad support in anger, most people use rotary encoders or up down buttons. I designed it thinking that we needed it for a project, but it never materialized. Probably best if you contact me and we discuss it in more detail there, as I'd like to get a view on how you think it should work. I think it would be beneficial for both of us to get this working better.

To contact me click on the company icon at the top to get back to the main site, use the "help" button on the right corner to send me a message and we'll take it from there.

I love to be your beta tester

Ill drop you a email.

Btw. after doing some absolutely non TC menu related things my eeprom load problem is back and crashes the menu ....

In order to proceed, I suggest that we exchange mails using the contact form on the main site. I have a potential fix that does not call the callbacks during load, because that is quite dangerous and causes problems. But if it is not working at the end of setup() it suggests that something else is wrong, to be honest.

BTW: If you have a debugger to hand you could just break on exception and the board should stop at that point before crashing. I have both an ESP32 and STM32 debugger setup, they cost very little to set up (about £20 each) and work perfectly with platformIO on the Mac.

Hello Dave!

I tried https://www.thecoderscorner.com/all-contact/ but at least with brave browser (chromium engine) nothing happens when i click on "contact us directly).


Regarding the crashing:

i commented out the menuMgr.load command and enabled my hack:

...
   flex_mode = eeprom.read16(4);                  // 0 = one shot, 1 = single, 2 = multi
    flex_preset = eeprom.read16(6);
...

...
menuFlexMode.setCurrentValue(flex_mode);                  // 0 = one shot, 1 = single, 2 = multi
menuFlexPreset.setCurrentValue(flex_preset);
...

and like this its working ... for now, But its not bulletproof cause it gave me some days ago also the same problem


Sometimes i believe it is less code and more compiler related. I change parts in the code which have nothing at all to do with tcmenu or the eeprom and on the next compile tcmenu crashes....

One more thing

Dont know how many people are using this quirky arduino style to break up projects in smaller parts (using multiple .ino files in the project folder), but in this case tcmenu generator just checks the main ino file and does its inlusion of callbacks there, even if they exist already in another ino file

Dont know how many people are using this quirky arduino style to break up projects in smaller parts (using multiple .ino files in the project folder)

Don't do that, use .cpp & .h files instead, you can then include them at will. There should never be more than one .ino file in a folder, it's in the Arduino spec IIRC. There is currently a limitation though, that all callbacks must be in the main INO file. However, they would normally just call helper methods elsewhere (EG in another file), not be the full implementation.

To contact me, just use the "? help" button the bottom right corner, I need to make this a bit clearer, we've recently moved to zendesk from an email form, and still to get everything quite right there.

I've just sent you a PM via the forum, no need to try and use the contact form.

Thanks, came back right now, will check it.

I found another "feature"

I am using the accelstepper library to drive a stepper via external hw driver (just step and dir pulsing).

Maximum speed is 1000 steps per second or 300umin on a single step driven 1.8deg stepper (really not much on a 84MHz Due)

When i enable some switches

switches.addSwitch(g_b_start, onStartButton);
  switches.addSwitch(g_b_lock, onLockButton);
  switches.addSwitch(g_b_release, onReleaseButton);

  switches.initialise(ioUsingArduino(), 1);

it affects already the stepper a little bit. I can hear its not running as smooth as it should be.

But when i enable the keyboard

keyboard.initialise(ioUsingArduino(), &keyLayout, &menuKeyListener);
    // repeat the pressed key after 850ms every 350ms 
    keyboard.setRepeatKeyMillis(850, 350);

its just a stuttering mess. Even on low speeds with 45 steps/second its audible, with the higher speeds it sounds like the stepper is falling apart.

I checked the Stepper Pulses on the Oscilloscope. Normally its nicely spaced pulses with about 8uS pulse width and spacing depending the set speed.

As soon as i include ioabstraction & tcmenu i need to widen the pulses a little bit, still no problem.

But when the switches and much worse the keyboard is enabled the pulses are coming with random spaces....

For a quick hack, is there a way to temporarly disable the keyboard? During stepper moves i dont need it, so i could just deactivate it before and reactivate afterwards.



This is the init, just to have everything related here:

#include <TaskManager.h>
#include <KeyboardManager.h>
#include <tcMenuKeyboard.h>
// Keyboard Layout for green 5x4 keyboard
const char KEYBOARD_STD_5X4_KEYS[] PROGMEM = "WXYZ123A456B789#L0R*";
KeyboardLayout keyLayout(5, 4, KEYBOARD_STD_5X4_KEYS);
// We need a keyboard manager class too
MatrixKeyboardManager keyboard;
// tcMenu keyboard listener
MenuEditingKeyListener menuKeyListener;

KeyboardManager has a 500uS task manager yield that would let other tasks run but not your loop, but even the fastest display tech will add a few millis of delay, and slower ones add 10's of millis at least, comfortably exceeding any other delays.

We've been going through fixing display tech up slowly. Firstly, we forked and fixed up LiquidCrystal (LCD displays), to make it even usable in a program that did anything else, in the next release we'll add a yielding I2C helper for U8G2, that yields every 16 bytes. But color displays are more problematic, in the next version we'll be supporting TFT_eSPI which is much faster on ESP32 but at the frequency you want, still may not be enough.


IIRC you're on ESP32 I can see two options there:

* Spin up another thread (task) and do the work in that, but at the frequency you want, you may need to use an unmarshalled interrupt to update that quickly. In that case, make sure you only ever use that library on that task, to ensure thread safety.
* If you need such accurate timings why not use the hardware LEDC support, where you can set the pulse width and frequency and leave the processor to do it? I don't know if it can do what you need though.

EDIT I see you're using Due, less familiar with the specifics here, I suspect the two options would be the Atmel PWM support - very thorough and may do what you need, or using interrupts.

For a quick hack, is there a way to temporarly disable the keyboard? During stepper moves i dont need it, so i could just deactivate it before and reactivate afterwards.

Another thought, you could entirely disable tcMenu by not calling the runloop for a while in your loop method, if you don't need the menu for a while, that would work. That would ensure your library ran at full speed, you could have a "wake up button" somewhere connected to an interrupt pin, and restart task manager when it was pressed.

Procedure would be something like:

Upfront:
* Create a raw interrupt handler that just sets a volatile boolean to wake up the menu.

On start stepping:
* Take over the display and put something on there indicating the menu was stopped
* Call yieldForMicros on taskManager for long enough to ensure the display is updated
* Set a flag that stopped you from calling taskManager.runLoop() in loop()
* Ensure that your interrupt is registered on the "wake up" pin
* Do the timing specific work until the button is pressed
* Enable task manager
* Give back the display


But we could add a disable option to the keyboard support, and you could then take over the display and do nothing with it, ensuring that it is beyond use.

Hello Dave!

Im taking over the renderer already during stepper moves. The main problem is the keyboard polling (which i also dont need during stepper moves).

To disable the taskmanager is one working solution (did that already), for sure. But it leads to another problem: i need to read some switches which i connected with the ioAbstraction lib.

Maybe i will poll the inputs directly and do my own debouncing or just add some hardware debouncing, this seems to me the quickest solution. Need to check, the switches are connected by optocouplers, maybe they smooth out the signal enough and i dont need debouncing at all.

I was just surprised that the lib is taking so much time for processing, did think on the Due it will not matter.

I was just surprised that the lib is taking so much time for processing, did think on the Due it will not matter.

It's not really that it's taking up time, it's yielding but only to task manager, not to the arduino loop. None of our new stuff does this, we could refactor it to remove the yield, but we can't do it immediately, another option would be to poll the library using task manager.

for example

taskManager.scheduleFixedRate(10, [] { serviceYourLibraryHere(); }, TIME_MICROS);

Would call your libraries loop every 10 micros, if it was able to. That would remove any liquid crystal delays, because I've already fixed our fork of liquid crystal. It would also get rid of that 500 micros yield I discussed earlier.

EDIT But at those sort of timings, if the accuracy is that important, I would drive the stepper from a timer interrupt.

We are starting to get out of the domain of tcMenu here and into application development, but given we've got this far, I'll give you my opinion on this.

I've been thinking about this, let's say you want to trigger a state transition for steppers every 10 microseconds. That gives you about 850 machine-level instructions per trigger. If you think about that for a moment, even if you use an interrupt, at that frequency you will have used a lot of cycles executing that code over 100,000 times per second, any inefficiency will add up very quickly indeed.

If you need absolute control and cannot use the Atmel/CMSIS provided PWM libraries (and they provide very detailed support for phase, frequency, and duty, we're not talking about analogWrite here), then I would write this code using a raw ISR (I rarely say this, but even consider assembler as you have a lot to gain by small improvements), stack as few registers as possible, and write directly to the hardware using CMSIS.

But that's just my $0.02, other views will probably differ.

Notes:
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/beginner-guide-on-interrupt-latency-and-interrupt-latency-of-the-arm-cortex-m-processors
https://www.allaboutcircuits.com/projects/pulse-width-modulation-with-the-sam4s-xplained-pro/