Closed ednieuw closed 1 year ago
Please provide a bare-minimum sketch that isolates the issue. There's lots of code in your provided example that doesn't have anything to do with the issue I'm trying to isolate
This bare minimum is working! Will try to isolate the problem and let you know.
#include <SoftwareSerial.h>
SoftwareSerial Bluetooth(7, 6);
void loop()
{
delay(1000);
Bluetooth.println("Test string to BT");
}
void setup()
{
Serial.begin(9600);
Bluetooth.begin(9600);
Serial.println("\n*********\nSerial started");
Bluetooth.println("test string to BT");
}
It is wire.begin If omitted the string is send to the Bluetooth module
#include <Wire.h>
#include <SoftwareSerial.h>
SoftwareSerial Bluetooth(7, 6);
void loop()
{
delay(1000);
Bluetooth.println("Test string to BT");
}
void setup()
{
Serial.begin(9600);
Bluetooth.begin(9600);
// Wire.begin(); // <---- blocks pin 7 output
Serial.println("\n*********\nSerial started");
Bluetooth.println("test string to BT");
}
1) You specifically mentioned pin 7. Is the issue specific to pin 7, or does it impact any pin used as SoftwareSerial TX? 2) What pinout are you using? There are two pin mapping options available for these parts (because the Arduino team got to them before MCUDude did, and as usual, turned what could have been a simple pinout that corresponded directly to the datasheet and was readily usable with other resources without translation into a shitshow and a mess. 3) Why the hell are you using software serial? The 4809 has FOUR HARDWARE SERIAL PORTS. SoftwareSerial sacrifices the ability to make a performant interrupt on any pin (on classic AVR, it does this by defining every pcint vector, on modern AVR it does this by calling attachInterrupt, which is now almost certainly the most evil function in the API.) And it's doing this just to get a single really poor performing (low baud rate) half duplex crapola approximation of a serial port. It's what you use when your back is against the wall, you absolutely need another serial port and there's just nothing you can to to reduce the your serial port requirements (the UART is by far the hardest of the big three interfaces to replace with software),
To be clear though, in none of the pinouts is there a sound reason for starting Wire in master mode to interfere with software serial, so there is absolutely a bug here - Your approach is inefficient and should be a last resort not a first resort - but it certainly should work, and I don't see any plausible route by which it would cause it to not work.
I'd do a sanity check and blink a LED after starting wire... or maybe turn on after starting wire, then after begin()ing the softweare serial, delay for 100ms (to make sure you see the flash) and turn the LED off.
If that passes, move that verification to when you're sending the first data.
That way you confirm that execution is not getting hung up somewhere
I made software for the ATMEGA 328 chip and later the Nano. All components are fitted on a PCB. So pin7 is fixed for TX to a Bluetooth module. Because of memory shortage in some projects I use the Nano Every. It also fits on the same PCB lay-out, is cheaper and has more memory. Of course I can make the program specific for the 4809 but that is not convenient for me at this moment. Beside that there is no problem when compiling with the MegaAvr board of Arduino.
@ednieuw thanks for providing a neat example and for tracing down the issue.
There is indeed a bug in Wire.begin that specifically affects the Nano Every. It's this code right here. I'll look into it to figure out why this is causing issues.
@SpenceKonde is absolutely right though. The Nano Every, when used with MegaCoreX has four(!) hardware serial port. This is obviously much better than having to deal with the limitations a software serial implementation has. But if you're using a Nano Every as a drop-in replacement in an older board where a classic Nano was previously used, your current pinout makes sense.
I've just pushed a commit that resolved this issue. It will be available in the next MegaCoreX boards manager release. Meanwhile, you can run Wire.begin()
before bluetooth.begin()
as a temporary workaround.
Top!Thanks for the quick solution!On 19 Feb 2023, at 18:56, Hans @.***> wrote: I've just pushed a commit that resolved this issue. It will be available in the next MegaCoreX boards manager release. Meanwhile, you can run Wire.begin() before bluetooth.begin() as a temporary workaround.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>
When compiling with MegaCoreX for the Nano Every with Board4809 the string send to pinD7, connected to a Bluetooth HM-10 module with "SoftwareSerial", does not work. When compiling with MegaAVR board the string is transmitted to the Bluetooth HM-10 module.