Message |
|
Hi there,
You can signal task manager from anywhere, on any thread, by scheduling or executing work. Or even an event. You can also create a second task manager for that, on the other thread (task). In the thread-proc you would run the second loop. You can interact between taskManager instances using events or by scheduling work on the other one.
Task manager runs all its tasks on a single thread, so it means that the items working on task manager don't need to be thread-safe. However, task manager itself is thread-safe, you can schedule safely from another thread, you can signal from any thread.
Conceptually something like the following:
TaskManager taskManagerThread2;
void myThreadProc() {
while(systemIsRunning) {
taskManagerThread2.runLoop();
}
}
taskManagerThread2.scheduleFixedRate(1000, [] {
if(needToSignalOtherTaskManager) {
taskManager.execute(taskToRunOnOtherTaskManager);
});
Or alternatively, you could create an event that was registered with one of the task managers, and signalled by the other thread. See the events section here: https://www.thecoderscorner.com/products/arduino-libraries/taskmanager-io/
|
|
|
Great, many thanks for getting back to us, it was a major concern for us, given the very wide deployment of the library these days.
|
|
|
Can you please respond on the following report of a critical bug: https://www.thecoderscorner.com/jforum/posts/list/95.page. We have tried to recreate this scenario both on the in-development version, and the production 1.7 version, we cannot recreate it, getCurrentValue always returns the right value. If you are still able to recreate this issue, please provide the library versions, board version from board manager, and the board that you are using.
In terms of the issue, it is more than possible, but it's not trivial, if you are used to C++ programming you could. Another option without waiting is to use a regular text field and format it yourself. However, we were thinking of adding duration anyway, so we could add this at the same time. Please feel free to comment on https://github.com/davetcc/tcMenuLib/issues/90
|
|
|
Here's what the new menu item variable name field looks on Windows UWP, it automatically follows the item's name on new items until you either manually change the variable name, run code generation or save the menu structure. At any time you can manually edit the variable name, and pressing "regenerate" causes it to re-calculate the name immeditaely. If you are using recursive naming, and have overridden the name of a submenu, it will use that overridden value by default. Again, you can manually change it at will. It is fully backward compatible, and if the variable name wasn't previously set, it picks the traditional default.
|
|
|
Here's the rendering running on Adafruit_GFX library, ILI9341, ST7735 and Nokia5110:
|
|
|
Updates this week on tcMenu 2.0, now tested and working on a wider range of displays:
UI fixes and changes for 2.0:
* Make a property editor for the menu item variable name and don't auto-update the variable name after the first publish (just Mac UI left to do).
* Ensure that Divisor and Unit are always sensibly defaulted on Analog items.
* Java - allow user to easily set the Arduino directory, and turn off global libraries.
Library and plugins:
* Resistive touch screen plugin ready and will be bundled in the next release.
* TFTeSPI plugin now tested extensively and will be bundled in the next plugin release
* AdafruitGFX plugin now updated and will be bundled in the next plugin release.
In progress:
* U8G2 and LiquidCrystalIO are in progress
* mbed testing
* runtime menu item editor
* esp32 touch buttons
Unit test coverage
With this release, more of tcmenu, designer, taskmanager and IoAbstraction are covered with unit tests, the embedded code, the Java API and UI, the Xamarin API and designer. Every designer UI release is heavily tested, with some of it now automated.
|
|
|
A bit more background.
Basically, the I2C backpacks are not standard, some use RS-RW-EN and some use EN-RW-RS. We don't try to guess them, instead, we just rely on you trying both options.
|
|
|
In the designer code generator, under display settings, there's an option for the "LCD Pin Layout". I think you've picked the opposite one to which is the default in the HelloI2C sketch. Could you try the other option please and let me know if it works.
It will have options for RS_RW_EN and EN_RW_RS. Basically, can you try the other option?
Many thanks.
|
|
|
Thanks for the information, I'll try and get something done later today or tomorrow.
|
|
|
Thanks for reporting with all the details, I'll try and build the project later today using Arduino and feedback here.
|
|
|
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/
|
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
Ack, to be honest, I don't use native testing mode, instead I just push tests to an ESP32 with a hardware debugger attached. You may be better bringing this up on the platformIO forum if what I suggested doesn't work.
|
|
|
|
|