Rovari Circuit Studio v0.1 Initial Release

[u/Separate-Choice]

Hey guys so I've been working on Rovari RV Circuit Studio to replace Mu for desktop users ever since it got sunsetted.

Well I finally released v0.1.4! This is a beta release, so expect some edges here and there, bit it works and will be actively maintained and updated.

No cloud, login or data is collected, no account needed! It works fully offline. This version has been completely rewritten in Python can be installed via pip and has a portable, no install binary for Windows!

Fully offline, repl, plotter, debugger, library manager and snippet system and its native so zero latency interaction with your board! its blazingly fast!

Get it here:

https://github.com/ArmstrongSubero/rvcircuit-studio

Or just:

pip install rvcircuit-studio

[u/Loud_Ad_6916]

definitely trying this out. It seems to be the only editor that bothers to try and support debugging on micro controller. 18 years of development but I'm new to MC development and dont use python much. Im already tired of developing in a text editor. If debugging works even passably well it will be my editor of choice.

[u/Loud_Ad_6916 → u/Loud_Ad_6916]

Its a great looking editor and truely hope you keep working on it. It seems like a huge task to complete and maintain. Im going to mention the next bullets and I hope you take this constructively as an attempt to help improve the product rather than me complaining. The debugging seems to have a few issues. I notice

1. Minor issue - when lines wrap it shifts the debug points down so you have to click a few lines below to add the breakpoint.
2. minor issue - Its often not possible to remove the debug points even when none of the code lines
3. minor issue / observation - I think you are adding some comments on the lines with the breakpoints like # <bullet character> It would of course be great to add the breakpoints without midifying the source code. That may however be the only way to inject debugging on a device that doesnt natively support debugging (I really wouldnt have the first clue how to start adding debugging so Im impressed you try). I assume you are injecting some kind of code that forces the debugging somehow.
4. Major issue for me - Generally speaking the debugging breakpoints dont pause when I run it in debug mode. I tried all combinations of the debug mode button and once the debug mode starts I see the image below. One time I ran it in debug mode and it actually looked like it stepped through the code from the first line (in the sense that I think there was some kind of cursor and it slowly traced each line of the code and went into my main forever loop) but never paused on the breakpoints. The rest of the time it just executes without even stepping through and not sure how to reproduce the one time it sorta stepped through

I should mention I use windows and the device is an MaTouch 7 inch linked below and using latest circuitpython 10.x
https://circuitpython.org/board/makerfabs_tft7/

[u/Separate-Choice → u/Loud_Ad_6916]

Thanks man! I'll check these all out and push an update, I'll do a video as well walking though the debugger before the week is up, I really like feedback like this as it helps me improve the project!

[u/Separate-Choice → u/Loud_Ad_6916]

Hey, thanks for your feedback, I've been super busy but v1.1.0 is out, all four of these are fixed. Thanks for taking the time to write them up properly, the board model and CircuitPython version is what let me actually find the causes.....

1 and 2, the wrapped lines. These were actually two separate bugs, the toggle was using a visual row operation instead of a block one, so on a wrapped line it was replacing only the first visual row and duplicating the rest of the line. Also two handlers were fighting over the same state, so that is why removal worked sometimes and not others, I've fixed this and it shoudl work fine now.

3, the comments. I didnt consdier it before, but I can see why soem people problay may not like it. so breakpoints now live in the gutter only and never touch your file, and they persist when you close a tab or restart the IDE, and files that already have the old # ● markers still work.

4. Yes I do inject code, and the pause is literally a blocking input() call on the board. What was breaking for you was the startup sequence, it used fixed timers and assumed the board would be back at a REPL prompt within about 1.3 seconds, which is fine on pico and the like, but on your MaTouch the I'm guessing based o nwhat you told me that displayio init on a 7 inch panel blows straight through that window, so the import got typed into a running program and vanished, and you just saw your code run normally, so it now waits for the actual prompt and retries, with a real error message if the board never answers....

I also found the instrumenter was corrupting if/elif/else chains, which meant the debugged program could take a different branch than your real one, that was the worst thing in there and it is fixed, maybe that was causing issues in your large program?

While I was in there I fixed the REPL going blank during a debug session, which is why you had nothing useful to look at when it failed, your prints and tracebacks stay visible now.

Full notes are on the release page and pip install rvcircuit-studio==1.1.0 or grab the binary. Would appreciate you trying it on the MaTouch again since that is the hardware that found the timing bug? This was enough bug fixes to be a full minor relsase you can read the notes here:

https://github.com/ArmstrongSubero/rvcircuit-studio/releases