Serial output can freeze the emulator

[pbfy0]

Large amounts of serial output causes the emulator to slow to a crawl. I'm not sure what the best way to fix this is, but maybe not sending serial output to the GUI thread one character at a time would help.

[mateoconlechuga]

The way I fixed this in CEmu was having a circular buffer inside the emu thread (Which skipped input of any null characters!!). During gui_do_stuff or the relevant function in the emu thread; a null character would be tacked onto the end of the buffer and sent using the console_string or similar function. Also; adding ui->console->setMaximumBlockCount(2000); or something similar for the mainwindow is a must. Also; one thing I haven't figured out how to fix yet though is when the user forgets have a \n escape... It crashes Qt depending on the output speed. Could probably be fixed by when you encounter a null character in the emu thread rather than omitting it treat it as a new line... maybe :P

[Vogtinator]

I noticed this issue as well, especially noticable when having something produce aborts recursively...

I tried some of @MattWaltz's tricks already, but while they helped a bit, they couldn't prevent the final freeze of the application, unfortunately. I guess an intermediate buffer + rate limiting would work. I never heard about anything \n related though, what's up with that?

[mateoconlechuga]

Well I just mean that since Qt freezes because the line becomes too long; perhaps set a limit on the max amount of characters per line. The freeze goes away then; just adding a new line character fixes the issue.

[pbfy0]

It's definitely not because of excessively long lines; my lines are only 50 characters or so, but the program is generating hundreds per second.

[Vogtinator]

I'll add it to the todo list, what do you need it for? File transfer using XModem is available

[Vogtinator]

u-boot

Oh, have fun... Porting that won't be easy, there is no support for the flash yet and while it can use foreign APIs to open files, it won't work directly in this case (I forgot the main reason though).

Also, whatever happened to CAS+ emulation? It's in the code but there is no way to pick that model from the GUI.

While CAS+ emulation is not entirely gone, some snippets didn't survive the refactoring, so it's practically dead.

[Vogtinator]

Yes, that one is written by TI, used to launch early image builds.

[Vogtinator]

Yes, but only the "Nspire", not the "Nspire CAS" or even CX models.

[Vogtinator]

On http://blog.pankajp.com/2013/07/qplaintextedit-with-setmaximumblockcoun.html the author discusses how he works around the abysmal QTextEdit performance by using an internal string buffer and only appending the buffer after a flexible interval (100ms) after the last append finished processing.

Simpy increasing the maximum block count is IMO only delaying the inevitable, the freeze just happens an insignificant amount of time later.

[mateoconlechuga]

This is precisely why I said this forever ago :P

The way I fixed this in CEmu was having a circular buffer inside the emu thread (Which skipped input of any null characters!!). During gui_do_stuff or the relevant function in the emu thread; a null character would be tacked onto the end of the buffer and sent using the console_string or similar function

[pbfy0]

Only appending after a fixed interval will result in the screen never updating if output keeps coming. There would have to also be a maximum time or amount of characters which would force an append.

[mateoconlechuga]

During gui_do_stuff or the relevant function in the emu thread

I mean I have already given you everything you need for this I may as well just implement it myself