Join GitHub today
No multi serial in version 1.0.1 #799
I'm trying to install a Bluetooth JY-MCU / HC-06 module. This works like a charm with version 0.92.8 but not with 1.0.1 with identical Configuration.h. On V1.0.1, oscilloscope shows a straight line of 0 V on Tx pin of the board. On 0.92.8 it shows the "wait+CRLF" sequence once a second. I tried serial ports 1 and 3 without success. Serial0 is OK in both versions.
Hardware is a delta printer with Trigorilla board (mostly pin compatible fork from RAMPS 1.4, without pin D0 & D1). I considered the common tutorials and issues:
While compiling there are warnigs in this sequence:
I modiefied only configuration.h and pins.h. Each other src file is original from release 1.0.1 plus I'm using the TMC2130 library for tree axis.
Many thanks in advance,
Can you comment the
// Can not change buffer size here, need add build flag -D SERIAL_RX_BUFFER_SIZE=128
For me it compiles then without issues. It seems not possible to change RX buffer size, because arduino compiles it with 64bytes by default. So using multi buffer reduces in this case the buffer size to 64, which is important for host software. This at least makes it compile without warnings as all use same definition.
An other thing is that responses are normally only written to the serial that did the query and not to all outputs like it was before. Try
OK, thanks until then. Compiling was without warnings after following your advice. But the serial ports still did not work. M155 S1 had no effect. Even the 'wait+CRLF' sequence had not been sent. Zero communication...
After some fiddling I got Serial1 working by commenting out this statement:
Then in gcode.cpp was
Then I got the first signals to the oscilloscope but many communication errors on Repetier Host:
I solved this in gcode.cpp by replacing this
A test print was successful.
Same problem here. There is a thread on the forum about it also. https://forum.repetier.com/discussion/5317/second-uart-for-bluetooth-isnt-working-after-upgrade-from-0-9-2-to-1-0-1
@ThomasHamke - Thanks so much for the detailed information, however I seem to be unable to reproduce your 'fix' presently. (v1.0.3)
My goal is to have USB free for firmware uploads, and use hardware serial - ideally at faster than 115200 - direct to the RPi's GPIO (via level converter obviously) to control the printing process. I don't care if serial 1 is the ONLY port that works, I just need it to work.
Presently I've got it working using serial 0 and SHARED with the USB-to-serial onboard, which I hate. It makes me very uncomfortable.
I connected a second interface to Z-Min/Z-Max/Gnd and moved Z-Min to Y-Max, connected them to the level converter instead of D0/D1, and applied your code block change - I did not modify hal.h:80 as described above since it had already been, in my code tree.
I'm 100% unable to establish comms on Serial 1 (aka Bluetooth) at any speed. I can, however, connect it to Serial 0 (USB-shared) and everything seems to be working as before - this confirms that the level converter and my wiring are both OK, and yes I verified (and even swapped) TX/RX to be sure it wasn't that.
Is there something I've missed? Thanks for any attention I can get!
Just checked the pin description and for serial 1 it seems correct. Only serial 2 seems to be wrong regarding the pin numbers.
But did you also test the raspberry settings. Do you have /dev/ttyAMA0 and configured linux to not have a serial console for linux (console=null in /boot/cmdline.txt). Otherwise there will be only garbage.
If you have a logic analyser you could check in tx line if you get "wait" every second when not connected.
I did mention that I'm using the same setup with the onboard Serial0 (which is shared with the serial-to-USB chip) so I know the level converter and RPi are working perfectly. It's printing behind me right now, as such. Has stable 5v and 3.3v references on the level converter, good grounding, immaculate wiring and connector work. I did switch to hardware serial for /dev/ttyAMA0 with the overlay change previously, and my waveform shaping on serial data is sharp and clean when using Serial0 - admittedly I didn't actually scope it on Serial1, but it was one of those "it works with the other connector, should work here" dealies in my mind at the time.
Actually since it's running right now, still with the modified code and Bluetooth enabled to Serial1, and the cable is still installed - what is expected behavior on Serial1 during a print? I assume from the code I saw that it's going to show duplicated firmware-side feedback as if it were speaking to the host? No host chatter (Serial0 RX) expected to show on Bluetooth's (Serial1 TX) port? I'll pull out my DSO and see if there's anything, or if it can be resolved to ASCII while I wait to hear your thoughts. (Thank you!)
Okay so here's some fun.
Serial data shows up properly until it's hooked up. I'm using bidirectional level converters because that's what I had on hand, which - paired with the MKS Gen v1.4's inbuilt resistor madness on the endstop pins - results in, apparently, triggering the tristate on the bidirectional converter chip. That's my working theory at least, I'm gonna have to do some physical modifications to verify it, but according to the schematic the endstops (All three sets) are the middle leg in a resistor network between 5v and the MCU.
Very unusual, and explains why it works in some cases but not others - I'm likely using a more tempermental level converter. Sorry to take up your time! Sorry I didn't think to actually look at the signals before coming here, thanks for straightening me out. I'll let you know if this doesn't work out.
EDIT: Fixed. You're awesome, thank you. For future travellers being insane with MKS Gen v1.4;
To 'direct-wire' Y-Max/Y-Min for Serial3;
Standard disclaimer, don't do this unless you're crazy and have a very specific need, DO NOT hook up an endstop to the connector pair EVER AGAIN (without reversing this!) and enjoy.
More or less, yes they are. A weak one, weak enough that the MCU itself can overcome it to idle low with pullups disabled.
I'm as surprised as you are - why in the world would they do that? That's why I straight-up ASSUMED it had to be a firmware thing, haha. RAMPS v1.4 doesn't do that. I really don't get it - it's just as likely your average user is going to make a mistake wiring that as any other pin, it can be configured pull-up or not just as any other pin, or ignored in whatever N/C state it's left. I'm not aware of any special on-powerup tricks any common AVRs do on those pins. The mind boggles!
Clip from the schematic, proof for proof's sake;