Message |
|
To be honest, I gave it more thought, and given how cheap it is to include IR, I would probably do both. That way you've got the simplicity of IR for simple volume adjustments.
|
|
|
In this topic we discuss the possible methods for remote control of an amplifier, based on issue #105 in tcMenu repo. I can see a few initial options:
Control of the amplifier using IR with a standard Infra-red remote control unit:
This would entail generating a class that could understand a common IR protocol and decode a few of the button presses. For example, to change channel and volume would probably be the first two things that would be needed. This would probably be achieved by performing "delta changes" onto volume and channel. Lets take an example of the button press for volume down:
void onVolumeDown() {
menuVolume.setCurrentValue(menuVolume.getCurrentValue() - 1);
}
Control of the amplifier using an early version of embedCONTROL app on iOS, Android or UWP.
In this case, you would include some kind of ethernet or bluetooth serial unit into your device, depending on the board you've chosen the easiest path may be WZ5xxx, ENC28J60, ESP* or HC-05 bluetooth module. Any of those options can be configured to work with the embedCONTROL UI with minimal set up. This is a different solution, it is based around an app that will be released very soon that gives more or less full control of the menu on your mobile phone or computer. It can currently run on iOS, Android and UWP. It is further ahead on iOS and UWP, than Android. It is probably also possible to build a Mac desktop version, but no effort has been spent on this, as with Big Sur the iOS version would probably work there without issue.
If you used the wired ethernet approach into your pre-amplifier, and the digital power lines are completely isolated, then noise should not be a problem. If you decided to use bluetooth, careful shielding would be required. Personally, for my units, I would either go ESP32 and carefully shield the Analog side, or use an ENC28J60 wired module carefully placed away from the Analog side.
|
|
|
I have added an analog item, that I want to use just to display a value - so I've ticked Read-only for it, and now I can't update its value from the sketch, am I doing it correctly
Having the maximum value set to 0 by default was not a good choice, from now on we'll default it to the maximum value of a signed short, which is probably a more reasonable default.
I'm using DFRobot LCD shield input, and when I try to change the value - buttons work upside down
I think what's needed here is an invert menu navigation option, so that we can correctly set the up / down buttons. Most people up until now have used rotary encoders, but yes, the editing works oddly for up / down. It's a fairly simple fix that we can probably do in the next patch release.
https://github.com/davetcc/tcMenuLib/issues/76
|
|
|
Thanks for confirming that the example works, so it is unlikely a hardware incompatibility problem in the library; which I was originally concerned about.
If you could break out a small piece of code showing how you are trying to use it, I may be able to determine what was wrong. IE the setup of the encoder, and how you're trying to acquire values from it.
|
|
|
and it wasn't clear to me that I had to create that IOAbstraction (object/interface/variable) for the 8574 and then use the 0 through 7 pins on the encoder. For some reason I thought the TcMenu app would generate that too. I kept looking for something to tie it all together and I just wasn't finding it because clearly I don't fully grasp how "switches" knows how to do what it does.
Agreed, there's probably some middle ground where the simplest of IoExpanders can be created automatically during code generation. But at the moment, we haven't got that sorted out. For now, you do have to create the IoAbstractionRef in your main source file, with the same name as you enter into the IoAbstraction Reference field in the UI. It's not particularly intuitive.
We have shifted focus recently to stability and usability, instead of building out any more large features. The libraries are already fully-featured and the feedback is always, they have all the features people could ever use, but they are not well enough documented, and usability has traditionally been a bit off for new users, and this has to be the priority.
This will mean that the documentation will get better quite quickly and that some small usability features will be forthcoming.
If you had any ideas on how we could improve the experience for users using an IO expander that would be great to hear.
|
|
|
|
|
|
I wasn't able to get 2 encoders to work on my SAMD21 Arduino Zero
Did you try the simple example sketch that I sent to you? That just printed to the console every time there was a callback? I ask because I tested that sketch on a couple of boards before I sent it to you? I think it is useful to know at this point if there is some kind of hardware integration problem with your SAMD board, or if the problem was elsewhere. It would be very useful for me if you could run that example sketch, you should only need to change the pins to match your situation, nothing more. I ask because there are many possible modes of failure here: pin not a pull-up pin, pin not available for interrupt input, a problem in IoAbstraction with that board etc.
Is it possible to setup the navigation rotary encoder (slot 0) on pins of an 8574 expander?
Yes, you would create a PCF8574 abstraction as per the example sketches that work with that I2C expander. For example https://github.com/davetcc/IoAbstraction/blob/master/examples/example8574/example8574.ino
You would then provide that variable name as the IO expander reference in tcMenu Designer rotary encoder configuration. At that point any pins you provide are the data pins on the I2C device you provided. EG 0-7.
I come back to the thing that concerns me here. We did not establish the cause of the problem on the other board, we don't know if it's a problem in the sketch, a hardware issue, or a bug in IoAbstraction somewhere.
|
|
|
BTW You can also use the keyboard support along with a rotary encoder or the dfrobot shield. We often do that. Otherwise choose no input in the designer, then add the code as described in the keyboard article.
|
|
|
You could use the regular tcMenu matrix keyboard support class, there's an example that shows it's use in KeyboardEthernet or something similarly named in the examples.
That would be the quickest way to get things working, and if you wanted something more custom than that could provide, you could use it as a starting point to write something of your own.
With a 4x4 arrangement, someone recently submitted a patch that uses the A and B keys to do the up and down, * and # are used to start edits and reset. Admittedly it's not super well documented at the moment, but it's on the list to fully document soon.
Maybe take a look at:
https://www.thecoderscorner.com/products/arduino-libraries/tc-menu/menu-control-using-matrix-keyboard/
Does that do what you want?
|
|
|
I you a message through your site forum asking about commercial options. I'd be interested to know what's available.
I sent you a private message around this in the forum. Just go to private messages at the top of the page to view it. I’ve tried to provide a bit of constructive feedback and some options.
Thanks
Dave
|
|
|
You're a fan of the lambda functions. I understand them when I read them in general but I just don't use them but no need to get hung up there.
Yep comes from doing a lot of Java, C# and Scala!
What does "auto" for us here?
It is C11 type inference, it basically infers the type at compile time without needing write it out twice, so in this case:
auto secondEncoder = new HardwareRotaryEncoder(enc2pinA, enc2pinB, [](int newVal)
could be thought of as:
HardwareRotaryEncoder* secondEncoder = new HardwareRotaryEncoder(enc2pinA, enc2pinB, [](int newVal)
On the same example before you put the 2nd encoder in slot 1 you add the interrupt using
Yep apologies, my mistake, I should really have used switches.getIoAbstraction()
There is no difference in this case, because when we initialised switches we set the IoAbstraction parameter to ioUsingArduino()
So far I'm not understanding what "switches.getIOAbstraction()" actually returns in the previous line of code vs the other where ioUsingArduino()
"switches.getIoAbstraction()" returns whatever was passed to the switches.initialise(..) function. In this case it was:
switches.initialise(ioUsingArduino(), true);
The IoAbstraction is nothing more than a means of setting up and using a devices IO, there are abstractions for Arduino pins, and there are abstractions for IO expanders, there's even one that combines both into a single IoAbstraction.
|
|
|
I've just done the most simple sketch that uses two encoders. I have to say I'd not really tried this before, as this was contributed
It works well for me.
Can you try this sketch with your arrangements, ensure that enc1pinA and enc1pinB are on their own interrupt capable pins.
https://github.com/davetcc/tcLibraryDev/blob/master/twoEncodersMega/twoEncoders.ino
EDIT forgot to say that no expander was used here, everything directly connected to pins. However, you could very easily convert this sketch to use an expander should you want to. Let me know what your end goal is in terms of connecting the encoders, and I'll adjust accordingly and try again. I have a couple of PCF8574 and MCP23017's on hand to try it with.
Output of sketch from mega2560 (what I had to hand, but should work on most boards without change):
Starting setup
Adding switches
0:add 0 57 0
0:add 1 58 0
Setup encoder 1
Encoder 1 change 100
Setup encoder 2
Finished setup
Encoder 2 change
-1
Encoder 2 change
1
Encoder 2 change
-1
Encoder 2 change
1
Encoder 1 change 101
Encoder 1 change 105
Encoder 1 change 107
Encoder 1 change 109
Encoder 1 change 111
Encoder 1 change 113
Encoder 1 change 115
Encoder 2 change
-1
Encoder 2 change
-1
Encoder 2 change
1
|
|
|
I'm really sorry for the lack of responses this week, we've had a really busy few days, I've put some time aside to build the double encoder circuit later today and test it.
|
|
|
I'm really sorry for the delay in responding, it's been a busy week one way and another.
I was right that some artefacts of 1.7 have been accidentally merged into the release you are using. Sorry you've hit this, we are normally careful that all examples work with the same version but this one was somehow missed, if you replace the INO file with the code below it should work for you:
As 1.7 is less than a week away, it's probably not worth patching the current release.
Again sorry for the inconvenience and we'll make sure it's working in 1.7
EDIT: code adjusted slightly
===== 8< start code =======
/**
* ESP8266 example of the *simplest* possible menu on u8g2.
*
* This example shows about the most basic example possible and should be useful for anyone
* trying to get started with either adafruit graphics or u8g2. It is missing title widgets,
* remote capabilities, EEPROM storage and many other things but makes for the simplest
* possible starting point for a graphical build.
*
* The circuit uses a PCF8574 for the input using a rotary encoder, a common configuration.
*/
#include "simpleU8g2_menu.h"
#include
#include
// the width and height of the attached OLED display.
#define OLED_WIDTH 128
#define OLED_HEIGHT 64
// Here we declare the variable using exactly the name that we used in the
// designers code generator panel for the graphics variable. The name and
// type must match exactly
U8G2_SSD1306_128X64_NONAME_F_SW_I2C gfx(U8G2_R0, 5, 4);
// this is the interrupt pin connection from the PCF8574 back to the ESP8266 board.
#define IO_INTERRUPT_PIN 12
// as we've attached the rotary encoder to an I2C PCF8574 device we need to
// declare it here. We've told the designer that we would when we set the
// switch IO device.
IoAbstractionRef io8574 = ioFrom8574(0x20, IO_INTERRUPT_PIN);
//
// In a tcMenu application, before calling setupMenu it's your responsibility to ensure
// that the display you're going to use is ready for drawing. You also need to start
// wire if you have any I2C devices. Here I start serial for some printing in the callback.
//
void setup() {
// If you use i2c devices, be sure to start wire.
Wire.begin();
Serial.begin(115200);
// start up the display. Important, the rendering expects this has been done.
gfx.begin();
// This is added by tcMenu Designer automatically during the first setup.
setupMenu();
// Note:
// during setup in a full menu application you'd probably load values
// back from EEPROM and maybe initialise your remote code (see other examples)
}
//
// In any IoAbstraction based application you'll normally use tasks via taskManager
// instead of writing code in loop. You are free to write code here as long as it
// does not delay or block execution. Otherwise task manager will be blocked.
//
void loop() {
taskManager.runLoop();
}
//
// this is the callback function that we declared in the designer for action
// "Start Toasting". This will be called when the action is performed. Notice
// instead of using callbacks for every toaster setting, we just get the value
// associated with the menu item directly.
//
void CALLBACK_FUNCTION onStartToasting(int id) {
Serial.println("Let's start toasting");
Serial.print("Power: "); Serial.println(menuToasterPower.getCurrentValue());
Serial.print("Type: "); Serial.println(menuType.getCurrentValue());
Serial.print("Frozen: "); Serial.println(menuFrozen.getCurrentValue());
}
|
|
|
I see, could you zip up the test sketch that you have please and attach it here. I'll take a look over it and work out what went wrong.
Apologies for this, taking quite a while to track down what has gone wrong.
Dave
|
|
|
|
|