Message |
|
Can you check if the taskManager.h and cpp are empty in the IoAbstraction library directory. And that IoAbstraction was also updated.
TaskManager became so big that we moved it into another library quite a while back now, given this was many moons ago, I imagine this is an update issue..
We left empty shell files in Ioabstraction so that updating should avoid compile errors for existing users. However, we’ve had one case a few months ago where the files did not update properly. let’s rule this out first.
If all is not well after that, please let me know what board you’re targeting and library versions for taskManager, IoAbstraction and tcMenu.
|
|
|
The issue we normally see with eeprom loading is that it is done too early, before the application is initialised. This then causes a problem in one of the callbacks. Without any change you can make this less likely by moving load after setupMenu() and your core initialisation. We are looking at ensuring no callbacks are called during load as that would prevent these early callbacks.
|
|
|
There's quite a lot there to go through, but in terms of the crash, it's because the EEPROM load function is wrongly calling the callback (too early in the cycle before anything was ready); which we are fixing in the next version. Given that the use case for eeprom load is to work at start up only, calling the callbacks is dangerous as they may rely on things being initialised. We'll do a commit onto master when we've tested this change, its lined up for 1.8 but you could just overwrite the file locally once it's available, fully backward compatible i think.
You can register a commit hander. Either a class that implements an interface or function, see: https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menumanager-and-iteration/ section "listening for changes".
Keyboard wise, I'll need to look in a bit more detail and get back to you about how you could extend the keyboard class, there are functions for next and back on menuMgr, I just need to remind myself how they would be mapped in to the keyboard class.
|
|
|
|
|
|
Many thanks for that, I'll point the github issue at this forum entry for now.
For the next release of the Java UI, we'll actually build the package on a Linux VM using the same instructions, similar to how we build the Win10 image on an actual windows box. Maybe that is needed to pull the correct native libraries.
|
|
|
To be honest, the libraries showing as out of date should not be a problem, it should be able to generate code just fine in that situation. It's really just a warning so you know they are not current. But platformIO keeps things up to date, so less of a problem there. Let me know if the UI is blocking code generation because of this, if so we'll put a patch in the next version so it ignores the lack of globally installed libraries.
Another quick fix, for now, would be just to put the libraries in place in the usual Arduino directory: ~/Documents/Arduino/libraries and it won't complain. Even if just the libraries.properties was in the right place!
In the newer Xamarin based UI (that we've not been able to port to Linux yet), it actually has an option for platformIO and mbed studio, where it stops looking for globally installed libraries. We'll see how much work it is to get that back into the Java UI.
BTW, we've got a few people having major problems trying to get JavaFX working on Linux. If you could spend a couple of minutes telling us how to set it up that would be very helpful to a few others who are struggling.
|
|
|
It does have acceleration BTW, but once you get much over a thousand it starts to get difficult to accelerate enough for that. That's why we added large numbers.
|
|
|
|
|
|
Sorry for the rant. I'm sure the documentation is instantly understandable by people that use Class and Object and other C++ / OOPS constructs every day.
But I don't even though I have used plain C and a dozens of other languages for 50 years.
tcMenu can't solve everyone's problems, and we don't pretend that it does. Using the library assumes a full understanding of OO, we cannot provide that here.
As per the last message, the return value will be a pointer to a type extending from MenuItem. In the menu types documentation (linked in the last reply) each type is documented fully, theres is also full reference documentation linked from the tcMenu project page, this shows the hierarchy of menu items.
As an example, if you wanted to deal with an AnalogMenuItem you would do:
AnalogMenuItem* analogItem = reinterpret_cast<AnalogMenuItem*>(getMenuItemById(myId));
For text menu item, that would be TextMenuItem instead of AnalogMenuitem.
MenuItem types:
https://www.thecoderscorner.com/ref-docs/tcmenu/html/class_menu_item.html
https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menu-item-types/editabletext-menu-item/
https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menu-item-types/
Making the IDs changeable after initialization will not be possible as they are treated as immutable data by the API, rendering classes and also remote interfaces. However, you can add extra items at runtime yourself. Many examples add an extra item to an existing menu.
|
|
|
|
|
|
Without the support for analog readings it has no point for me, but others might appreciate it already now if they want to use it for digital I/O. Meanwhile, I can use other library.
I'm not really aware of any combined serial IO device that combines both Analog and Digital IO on the same I2C/SPI chip, there could well be devices I'm not aware of (because in this game you're only really aware of what you've used / may need). In terms of I2C and SPI ADC, Potentiometer, and DAC devices, we need that support ourselves for a few projects we've got lined up, but we just don't have the bandwidth to implement them at the moment. You can see our priorities in the road map section on the main site under the Products menu.
IoAbstraction coexists with most other libraries quite well, so you could use it for the encoders and switches, and use another library for the serial offboard analog devices.
|
|
|
Apologies I had missed this reply.
However, I had to look into the sources, since the documentation is rather confusing in a lot of details - a mix of obsolete and more up-to-date information.
We are trying to clean up the documentation as best that we can, I'll take another look at the section on creating rotary encoders if it's still confusing, but you've got to understand that some of the legacy features such as the old setup methods cannot be removed as they are heavily used in 1000s of projects.
In terms of the getEncoder() method, you're right it should take an int and have a default encoder of 0. We'll try and address that in a patch, please feel free to raise an issue on the IoAbstraction repo for that. The multiple encoder support was kindly contributed some time back, so there are some areas where things are still a little rough around the edges.
|
|
|
Happy new year to you as well!
In terms of the PCF8575, it looks so similar to the PCF8574 that I can probably make the existing class handle both cases with some configuration flag, as it's just essentially like programming the existing device with two ports. I'll see if I can pick one up at some point and add it.
At the moment we don't support I2C or SPI based analog devices, we have a plan to do so, but we are not there yet. For the analog joystick option (AnalogSwitchInput.h) you just create an analog abstraction as in the example that's packaged with IoAbstraction. The main benefit of this abstraction is that for most of the hardware we support, we've standardized the range of values using floating points between 0 and 1.
|
|
|
And it only concerns the encoders? Well, I think I do not care that much about switches
all encoders and switches are on the same IoAbstraction. So the multi Io would be for all switches and encoders. It doesn't matter because if you use multiIo, the first 100 pins by default are for Arduino. Then each expander in turn.
The library does allow for analog joysticks configured to map a range of values like a rotary encoder, if that is what you wanted. It also has an analog abstraction that provides a few helper functions too. I think you'd be better trying a few of the examples and seeing if the provided support does what you need.
Thanks,
Dave.
|
|
|
But if I understand the idea correctly, I could also combine two MCPs with a few additional native input pins of the MCU
If you’re using a 2560 you would have limited interrupt pins. However, you could run switches in non interrupt mode, and just put all the encoder buttons on Arduino pins while connecting all the encoder A and B pins to the expanders, as at least Pin A must be interrupt capable . That way I think two devices would suffice.
|
|
|