User friendliness #548
User friendliness #548
Conversation
Step 1) Adding control system (pin and if statement).
|
|
|
Memory usage change @ a2ed538
Click for full report table
Click for full report CSV |
|
Hi @Epipeppy ! Thank you for your contribution. As far as I understand you would like to avoid that the string is printed over and over. What if we just move the code to the setup function instead? That way we can avoid that the people need to wire up any external component to test this. |
Hello, and sorry in advance for the upcoming wall of text. My main issue was that after uploading the sketch, I was no longer able to connect to and reprogram my board without putting it into boot loader mode (double tap reset key); which seemed extreme for a simple example program. Secondary was the fact that the program was sending the keys to my computer repeatedly, which was messing with any program I had open that was focused (i.e. not in the background). A tertiary concern was the fact that the example didn't show how to use the Keyboard library for mbed-OS; for example, the Initially I wrote a fully reworked example to show how to use these, but was told I should post them in small chunks (small changes), rather than 1 big change, so that any issues could be more easily resolved. From some of the other posts or comments I read, this example, when done with other boards, usually has a "button" or something to enable the output; that way the output is only sent when the button is pressed. It seemed like a useful feature, because of my secondary issue, so I incorporated it. If you have an idea for something we could put in the setup loop that would solve this, I say that sounds great! I'm happy to work more on this if that would be helpful. I remember feeling a bit frustrated at the time, and I wanted (and still want) to help others avoid that. |
|
Re-reading my reply, I noticed that I probably misunderstood what you said. You said put the print in the setup function (which I called the setup loop for some reason), that way it would only print once and be easily testable. That's a pretty good idea which would solve one of the issues I was listing. In regards to showing how to use the library, do you think creating a different example sketch would be a better solution than heavily modifying this one? |
|
@Epipeppy Hi, I think you should firstly debounce that GPIO otherwise it would bounce and execute the code inside the if statement randomly. Then the issue with the board not responding on flash might be because it is constantly blocked by the code you wrote inside the loop which will keep the microcontroller always busy and so it won't reply to the serial. |
|
Hello @alessandromrc debouncing isn't a bad idea; I personally just connect the GPIO to ground via wire, and leave it unplugged when I'm not testing the condition. I'm not saying this to be rude, but I'm not sure we're looking at the same code. The code I was commenting on was: In that code there is no button control, it is simply an infinitely looping command that uses a function While I have a whole re-written example using commands from the USBKeyboard mbed library, I was told I should make suggestions that include small changes. My change was simply to add a way to control whether the example would execute. I was told this was standard in other keyboard/etc. examples from Arduino, and that this was usually done with a button: |
|
Hi @Epipeppy no worries :) The code I was actually looking was the one you changed in the PR which is this one: #include "PluggableUSBHID.h"
#include "USBKeyboard.h"
USBKeyboard Keyboard;
// Arbitrary pin.
const int CONTROL_PIN = 2;
void setup() {
// We will use this to start/end the prints.
pinMode(CONTROL_PIN, INPUT_PULLUP);
}
void loop() {
// This will run only if the control pin is connected to ground.
if( digitalRead(CONTROL_PIN) == LOW){
delay(1000);
Keyboard.printf("Hello world\n\r");
}
}I was related to the line where you have the if statement that checks if the digitalPin is being pulled down. In any way I might look it in a deeper way using a debugger to see if there's something preventing the reset of the uC. Edit: I just seen that there might be an error within the |
|
I now added debouncing to the sketch you made and everything seems to be working correctly and also the board still gets detected without the need of pressing the reset button to get into the bootloader state.
#include "PluggableUSBHID.h"
#include "USBKeyboard.h"
USBKeyboard Keyboard;
const int buttonPin = 2; // the number of the pushbutton pin
int buttonState; // the current reading from the input pin
int lastButtonState = LOW; // the previous reading from the input pin
// the following variables are unsigned longs because the time, measured in
// milliseconds, will quickly become a bigger number than can be stored in an int.
unsigned long lastDebounceTime = 0; // the last time the output pin was toggled
unsigned long debounceDelay = 50; // the debounce time; increase if the output flickers
void setup() {
pinMode(buttonPin, INPUT_PULLUP);
}
void loop() {
// read the state of the button into a local variable:
int reading = digitalRead(buttonPin);
// check to see if you just pressed the button
// (i.e. the input went from HIGH to LOW), and you've waited long enough
// since the last press to ignore any noise:
// If the button state changed, due to noise or pressing:
if (reading != lastButtonState) {
// reset the debouncing timer
lastDebounceTime = millis();
}
if ((millis() - lastDebounceTime) > debounceDelay) {
// whatever the reading is at, it's been there for longer than the debounce
// delay, so take it as the actual current state:
// if the button state has changed:
if (reading != buttonState) {
buttonState = reading;
// only trigger the keyboard event if the new button state is LOW
if (buttonState == LOW) {
Keyboard.printf("Hello world\r\n");
}
}
}
// save the reading. Next time through the loop, it'll be the lastButtonState:
lastButtonState = reading;
}Anyway we should directly add a print with new line as a feature directly built into the library other than always using \r\n as it can be annoying and even support other data-types instead of only const char*. After updating the library we could add an example for a counter, the hello world and some other stuff like an analogRead so we can let the users see the power of the USBKeyboard library. |
|
Ayy, thank you very much! It does work for me as well, wonder if it was one of the updates to the mbed core (or rp 2040 library) that fixed the issue I was having back then. When I ran it just now I did notice that my board disconnects from whatever COM port it was on (I'm on Windows 10 latest update), and is re-detected on a new one. Either way, I'm glad its not preventing the board from being written to now. If it's of any interest, I made a few modifications to the USBKeyboard library for my own use. Because the old keyboard library used |
I've got literally no time to look into the library so if you want you could post your code too ;) |
Step 1) Adding control system (pin and if statement).