| Menu | JAQForum Ver 19.10.27 |
| Menu | JAQForum Ver 19.10.27 |
Forum Index : Microcontroller and PC projects : MMEdit V5.3.4
Page 1 of 3   |
||||||
The download from Geoff's site has been updated. The accuracy of the mouse in MMCC has been improved. It also now responds to button down and button up for left, middle and right buttons. You might find an issue with the pop-up menu appearing with right mouse button clicks. This should get disabled when sending mouse movements to the attached device but the pop-up occasionally has a mind of it's own. PIO code formatting should be better. There was a bug when copying code between tabs with large files under some conditions. This has been fixed. The update to syntax files and inclusion of YMODEM will be in the next update. Jim VK7JH MMedit |
||||||
Nice Jim, The auto formatting of PIO commands is perfect. Volhout Edited 2025-10-21 17:54 by Volhout |
||||||
Good, I've just updated. Thank you Jim! Regards, IanT |
||||||
Gosh, how excellent! No screams of outrage from Windows Defender; no claims of virus embedding; it just simply installs! |
||||||
Is MMCC designed to also work over TCP/IP? I see the dropdown box where one can select a com port or TCPIP, however when trying to connect to a PicoW or Pico2W, I get "connection to <ip number> failed!!". I get this message when trying to connect via the inbuilt VT Terminal mode or the external VT Helper mode. I can connect successfully if just using Teraterm Pro, or if I revert to USB/serial connection and use either the inbuilt VT Terminal mode or the external VT Helper mode. I've also checked my firewall rules to ensure MMCC is allowed. |
||||||
with some more perseverance I've solved my own dilemma. I needed to put port 23 after the IP number ie 10.0.0.18:23 All is now working as expected. |
||||||
I have updated MMEdit to V5.3.5 Linux users now have ttyS0 to ttyS5 available There is now support for AUTOSAVE (provided your device allows it). Users don't have to do anything. It will be used when available and revert to the old AUTOSAVE if needed. The upload speed improvement is significant. Jim |
||||||
Hi Jim, Peter, Amazing upload speed difference. For larger programs, I could take a sip of coffee while uploading, even take a bite out of a biscuit. No, not any more.. From 40-ish seconds to less than five with MMedit535 and V6.01.00RC7.. Thank you very much for this combined implementation. Volhout |
||||||
@Volhout, could you try this MMCC I have changed it to drop DTR 100mS before disconnecting. I used this test program ' SETPIN GP18, DOUT 'LED DO n = n + 1 IF n MOD 500 = 0 THEN PIN(GP18) = p p = 1-p ENDIF PRINT"the quick brown fox played with his picomite all day long" LOOP The LED is a good visual indication of what the USB is doing. When I disconnect in MMCC, the loop runs faster suggesting that the USB knows it is "full" and stops sending data. AS soon as I reconnect, the LED slows down and the data resumes. My Linux serial is noticeably different to Windows but that is likely to be due to the VM. MMCC.zip Jim Edited 2025-10-28 12:49 by TassyJim |
||||||
Yes Jim, That totally fixed it. Volhout |
||||||
For reference this is the code handling this in the latest firmware if (Option.SerialConsole == 0 || Option.SerialConsole > 4) { if (tud_cdc_connected() && (tud_cdc_get_line_state() & 0x01)) //check for CDC enumerated and DTR asserted { while (!tud_cdc_write_available()) //Buffer full or other CDC problem { busy_wait_us(250); // USB packets are every 1000mSec so no point checking immediately if (!(tud_cdc_connected() && (tud_cdc_get_line_state() & 0x01))) //recheck for CDC enumerated and DTR asserted { break; //ignore the character if CDC no longer there } tud_cdc_write_char(c); if (flush) { tud_cdc_write_flush(); } } } |
||||||
Hello, I don't want to hijack this thread, but I have a question about MMEdit. Can I change the cursor? I created a new color scheme and can't see the cursor because it's black on a dark blue background ;) Best regards, Thomas (beginner in mmedit) |
||||||
Hello Jim, your MMCC application, I tested the Linux version, seems to send chr$(27) twice, when pressing esc in the VT-100 terminal. Is there a reason? I'm new to VT-100 and don't know if it is required for some device. Regards |
||||||
A VT-100 (and the older VT-52) uses the ESC-character chr$(27) to introduce the control codes (escape sequences) - thus the name "escape sequence". https://vt100.net/docs/vt100-ug/contents.html https://fruitoftheshed.com/wiki/doku.php?id=platform_agnostic:vt100_escape_sequences So probably to "cancel" an "escape sequence", a second ESC-character is sent which then will be passed through to the PicoMite? Regards |
||||||
That would be an interesting Escape Sequence! An Escape Sequence that cancels a previous, inflight Escape Sequence!!! I'm pretty sure that doesn't exist! AndI don't think I would want to be the one responsible for coding that and getting it to work reliably. . Edited 2025-10-29 02:53 by EDNEDN |
||||||
Some comms protocols are along those lines (*) but I think seeing an Esc as an Esc was to detect that the next character didn't arrive in time (or was not a valid char for any recognised esc sequence). (*) e.g. DLE STX for the start of a packet, DLE ETX for the end, and DLE DLE to mean one DLE - it's known as byte stuffing John |
||||||
You never could "cancel" an escape sequence. You typed in the sequence then terminated it with CRLF or whatever and it was actioned. A couple of backspaces will take out Esc[ without actioning it as it isn't an escape sequence at that point. After the CRLF it's gone - too late to change anything. :) |
||||||
"Cancel" wasn't meant to undo an already executed escape sequence! By "cancel," I meant the following: When the VT-100 receives an ESC, it assumes that an escape sequence is about to be started and waits for the next character, which then further specifies what should be done—e.g., a '[', which many escape sequences begin with. The output is therefore initially after the first ESC character. If another ESC character follows, it's clear that there is no escape sequence, because there is no "ESC ESC" sequence! Just like you write "\\" in C strings when you want to insert a '\' into the string. '\' is the escape character, and this is canceled out by another '\'. https://vt100.net/docs/vt100-ug/chapter3.html "The processing of the control sequence then continues with the next character received. The exceptions are: if the character ESC occurs, the current control sequence is aborted, and a new one commences beginning with the ESC just received. If the character CAN (308) or the character SUB (328) occurs, the current control sequence is aborted." Perhaps many "compatible" terminal programs just abort when a 2nd ESC received within the sequence? Regards |
||||||
You cannot change the colour but you can change the width about line 130 in MMEdit.inf Insert cursor width = 2 Make any changes with MMEdit shut down. Jim |
||||||
MMCC only sends one <ESC> for each key-press <ESC> is also used to escape from some sequences such as AUTOLOAD so is treated slightly differently to normal keys. This might result in a line feed on the MMCC terminal but nothing extra is being sent. Depending on the device, you may be seeing escape sequences that the pico is sending. Jim Edit dddns is correct, the Linux version is sending most of the control characters twice. It uses the same source code as Windows so I am not sure how that can happen. I will investigate further. Edited 2025-10-29 09:36 by TassyJim |
||||||
| Page 1 of 3 |
||||||
 |
The Back Shed's forum code is written, and hosted, in Australia. |
