Message |
|
so the statement that it is necessary to have all encoders connected to a single physical expander/device/interrupt is not valid anymore?
There can only be one ioexpander associated with switches, but it can be a multi io allowing several devices and even Arduino pins at the same time.
In terms of connecting more than one Int pin together I would double check the data sheet as I’ve never physically tried it. From a library perspective it should be fine.
|
|
|
The best way to do this is to use a multi-io abstraction and connect to it as many MCP23017's as needed, see: https://www.thecoderscorner.com/products/arduino-libraries/io-abstraction/arduino-pins-and-io-expanders-same-time/
You can then use (I think) the open drain mode the interrupt pin of the device and chain many devices interrupt pins together. That way you could have up to 8 devices on the bus.
Switches will grow its internal state storage automatically, so there is no need to adjust the number of switches.
However, we get few requests for more than 4 encoders, so to use 10 or 12, you'll need to adjust the array size by defining MAX_ROTARY_ENCODERS to the size you need. If you are using regular Arduino IDE instead of a full build system, you'll need to alter SwitchInput.h in the library.
#ifndef MAX_ROTARY_ENCODERS
#define MAX_ROTARY_ENCODERS 4
#endif // MAX_ROTARY_ENCODERS
|
|
|
Hi there, it's difficult to say what happened without diagnostics or debugging, but the most likely case is that one of the pins was somehow floating and causing switches to constantly fire, in this case switches cannot handle that particularly well. Or even a pin that was used by a shield or something like that. Any pin that successfully configured as pull-up should not cause problems, as it is essentially in the off state.
If you have a scope to hand, you could take a look at each of the pins and see if one of the pins was floating / changing value.
|
|
|
Many of the problems raised in this post should now be fixed. Going forward there are two choices:
1/ Use the app store version (recently released with fixes for many of the issues raised).
2/ Use the packaged version provided by us, see Products/tcMenu Designer from the main site.
|
|
|
It’s a bug, there was an assumption that the additional allocation always works. We’ll fix it in the next patch. See the link in the last message.
Thanks for reporting.
|
|
|
I suspect it may be running out of memory either allocating the additional tasks, or switches. Using 76% of RAM before the app starts is very high, as we need a few hundred bytes at runtime to start, and that would take you to about 90% immediately.
Could you do a test in the menu setup that allocates tasks until the schedule function returns TASKMGR_INVALIDID and let me know how many times you get to before it fails I suspect it will be 18?
If this is the case, you'd have little option than to either reduce the number of tasks or get a bigger board such as the Mega2560.
I mean there is a slight issue here, in that if the call to new fails in taskmanager it should not try and continue, so I've raised a bug for that, but it is unlikely to occur on anything other than an Uno.
To fix the issue in task manager: https://github.com/davetcc/TaskManagerIO/milestone/8
|
|
|
I'm sorry but we'll need a lot more details than that to be able to help. You'll need to provide the board, the configuration, some idea of what sketch is running. Even an example sketch that produces this situation on the board in question.
On most 32-bit boards, you can use a large number of tasks (usually around 256) and switches grow on-demand as long as you have enough RAM, without too many issues.
However, on Uno, because of memory limitations, the limit is around 24, and that requires you to be able to allocate that much RAM!
|
|
|
Can you make it easier on us both by providing a link to buy a single user version? This is one of things that if not listed or easy to buy... some people can be too afraid to ask. In my case I want a stable commercial product to build the framework for application that is not going to be commercialized.
Bear with us for another week, we are fixing the Windows version first and foremost and setting up a new release repo that will be available soon, and at the same time we are discussing three standardized offerings to start with, they will be optional.
* A way for non-commercial people to get a basic level of help, that just gives a few extra features and boosted priority in the forum. Low, flexible quarterly pricing.
* Professional offering for people who need our time, with email, conference and project level support, flexible monthly pricing for only when needed.
* Custom enterprise solution for larger companies that is essentially pick-and-mix.
In this case, for interested parties at this moment, who need to purchase support, please DM me while I set up a suitable page.
|
|
|
We've made a call on this overnight. We are going to make all the patches of a major release available on our website somewhere. We will keep the app store versions too, but they will be updated FAR less often and only after a release has been in the wild for a while. Below is the plan:
Store version -> A slower-moving target for people who just rather someone else keeps it up to date. Maybe it updates only when there's either a serious bug or otherwise every couple of months - to a known working version.
Download version -> This will mean that almost immediately we'll put out all 1.7.x builds onto a site within the tcMenu structure somewhere (including the Java versions). When in the future we move 1.8, then we'd keep the last few 1.7.x builds around for a while to let people move over. You'd not be forced to move over, and nothing will auto-install. For Windows we need to look into how these would be signed (initially probably with our own certificate that you could download and trust). For Mac, they would be Notarized.
|
|
|
but if the most recent free "App" version works poorly or inconsistently I think you will agree that it doesn't serve your brand very well.
Completely agree, we've fallen way short of the mark on this, and we are doing everything we can to correct it. For now we recommend everyone affected to do as follows:
* Get and install the Windows 7 - 1.7.0 release from github - https://github.com/davetcc/tcMenu/releases/tag/1.7.0
* Make a backup of your project files
* Run the designer app and open the EMF file that you wish to edit, it should be fully compatible with your menu structure, it uses the same XML code plugins.
We'll be providing a fuller update later once we've had a bit more time to work through this.
|
|
|
I've moved the designer part of this to a new thread.
http://www.thecoderscorner.com/jforum/posts/list/0/87.page
It's a bit like whack-a-mole at the moment. The documentation is now updated. But the latest window store version has a severe problem, my tester was away during the last release, and unfortunately, it showed! I'm sorry for that.
A very early beta for evaluation of Embed control is undergoing certification now. But we'll do nothing more on that until the windows store version is sorted.
|
|
|
We are sorry that there is a bug in the Windows UWP version of the app that causes menu items to sometimes not be created.
We are also adding a save as button onto the toolbar, and a label on the root properties panel that shows you what directory the designer is working in.
We are now treating this as the top priority, we've stopped all other work and sprints until this is sorted. The outcome of this will be stability on the Windows store version.
We are also aware that commercial users need more certainty around the versions of the app that they can use, or sometimes cannot even access the store directly. We are looking into how this is possible too, we will probably provide a repository of back-dated versions for anyone who has taken any kind of commercial offering from us in the past year. We cannot offer this for free, we are already starting to struggle with the weight of people using the free version on the store, and they are all on the same version! When we had several versions to look after at once, it was nearly impossible to handle.
If you are affected by this please post here providing us as much detail to recreate what you have seen as possible.
|
|
|
|
|
|
The compiler for AVR on Arduino is supposed to move all progmem definitions into the lower 64K so I doubt it's that to be honest, many well-known libraries also assume progmem data to be in the lower 64K. So I assume the compiler does that automatically.
https://www.arduino.cc/reference/en/language/variables/utilities/progmem/
The common error is that the constant string referred to is not defined globally, make sure you define it outside of any function.
In fact in the gnu guide, they make it even clearer in the note about 30% of the way down the page, the progmem string manipulation functions only work on the lower 64K. So I assume the compiler arranges the constant data segments first in memory. It's the problem with having > 64K bus on an 8-bit device!
|
|
|
That is rather strange as I've not seen that fail before if the text is stored in program memory, I'm wondering if there is some kind of issue here.
What size is your sketch when you upload it (flash size)? Is it over 64K? I'm wondering if there's something wrong with the near addressing. Easily fixed if it is that.
|
|
|