Question: I have an RPi Model B (I think); would instructions produced for that also work for the 3?
As far as I know it will work identically, everything I have done with my RPI1 and RPI2 have worked (even better) under RPI3. Its just a faster cpu, with more ram, and a better gpu. It also has 4 cores and they are 64-bit capable. Raspbian has dealt with multiple cores automagically, swapping processes to less used cores without me noticing, except that everything runs much faster. I have encoded 4 MP3's simultaneously, and the OS serves each encoder to a new cpu, no effort on my part.
I am running latest version of Raspbian Jessie, just ran apt-get dist-upgrade yesterday. 64-bit support is just like windows, the OS needs to support it, and last I saw, the rpi foundation figured with only 1 gig of rpi3 ram, the need to go 64-bit OS was overkill. The benefit to RPI3 is wireless built in, faster quad core cpu, and faster gpu, also the microsd card slot isn't spring loaded (won't pop out easily now)
I don't think there is any difference between RPI1, 2, 3, at least not for propellerIDE, unless it implements some cpu heavy function.
I have 2 virtual desktops running X, over wireless on my RPI3, one desktop running a webcam, and the other desktop running Putty and PropellerIDE, and all is smooth, 30% cpu use. Multi-cpu makes a world of a difference when multitasking.
Some time around 0.37 (not yet available for RPi), PropellerIDE now attempts to open your last selected device on startup, so if the device didn't change, it would auto-select ttyUSB0. You can try it out on desktop to see it in action.
Great, when it comes out, I won't need to kick myself for forgetting to switch to ttyUSB0.
Hi !
I'm using PropIDE (Win10 0.36.5) to push the Tachyon 'kernel' to a board based on a parallax USB protoboard. It has worked tempermentally, now very poorly. When trying to download it quickly flashes a dialog box, shows 'Build Succesful', then the dialog disappears and there is no evidence of a download. Prop tool can communicate with the board sending spin, other boards too. I tried using simple manual examples with PropIDE and these are showing the same behaviour (ie flashes the dialog, no download).
At one point I thought the fix was not using a USB hub, but now it fails with the hub, or directly plugged into the PC's USB port.
Thanks for your help!
pr
Hi !
When trying to download it quickly flashes a dialog box, shows 'Build Succesful', then the dialog disappears and there is no evidence of a download.
I get that a lot. Always after Win10 sleeps, then resumes. And also at other pattern-yet-unidentified random times too. As I recall, running SimpleIDE at the same time can also cause this... perhaps there's a fight between the port in certain scenarios
Anyways... Closing/restarting PropellerIDE always solves it (temporarily) for me. I'm curious if a restart helps your situation too?
More generally... I don't recall seeing this behaviour prior to the last couple PropellerIDE updates. Although, a lot of other things have changed my side since then, so I can't say with any science that the issue is with the IDE. Could be a serial port driver issue, for example. Sadly I've not found time to diagnose and resolve the real cause yet, so just been livin' with it!
One immediate observation I note is the change from using openspin to bstc as the background spin compiler. Given the age of bstc, it's a testament to Brad's skills I guess.
I am running the latest 0.38.5 PropellerIDE on a MAC (OS X 10.10.5) and am seeing incorrect behavior in the Serial Terminal when cursor commands are sent from the application on the Propeller. The display screen jumps around and does not display its output properly. Dropping the baud rate down to 9600 from 115200 didn't help. Resizing the screen doesn't really help either. Echo on or off doesn't help it.
For example this snippet of test code below from a USB host project would always trigger the problem every time and generates the follow output with weird gaps in places instead of nicely formatted text. I don't know if the QT library is buggy on the MAC or this is something in PropTerm console code. It is kind of annoying to not be able to interpret the cursor movement/positioning commands. Anyone else seeing bad cursor issues with MAC OS X and PropellerIDE serial terminal?
Non cursor based console output seems to work ok, and Newline and clear screen work OK too thankfully.
This is the bad output pasted just like I see it on the console. Scroll down to see some more text at the end too.
Bau d Rate: [Q/A]Success:
Burst Size: [W/S]CRC:
Patte rn: [E/D]PID:
HC Debug: [R/F] Timeout:
Bad Data:
Too Short:
Too Long:
O ther:
L ast bad data buffer:
Error rate chart:
ttingsrors
Not sure if PropellerIDE is being maintained anymore but I have added a feature that "improves" the somewhat borked code completion in the editor window to become something a bit more usable, at least in my opinion. Code completion was starting to drive me insane as I had to keep moving the mouse to get rid of the pop up until I added this change, or turn off the feature completely. I have only tried my changes out on a MAC platform and it does appears to help usability now.
What it is now doing is the following...
When you press # or . it will trigger the code completion popup as before.
But now when you press <return> or <space> or <tab> it will paste in the currently selected text as chosen by the cursor arrows or mouse click instead of mouse click alone. Pressing <escape> cancels everything including the first character you pressed. The <up> and <down> cursor keys also allow selection choice and an alpha character will select the next entry starting with that character (this is actually an automatic behaviour of the QComboBox class).
I have also made it nicer when entering constants in PASM code.
If you press # or . and then any character in this group: (, @, $, & #, %, >, 0-9
it will immediately continue on and close the dialog box but keep the two characters you entered. This lets you not be interrupted as much when entering numeric constants, and you don't need to touch the mouse. [In future it would be nice to have dynamically disabled if you are typing in a DAT section but right now it doesn't do that.]
If you just wanted to enter a single hash (#) or period (.) without any completion, you can either press the key twice, or that key followed by a tab or space or return.
As before it still has some difficulty with the positioning of the code completion pop up on screen depending on the size of the list as I've not paid so much attention to that issue which can be annoying if it ever covers over what you are typing.
I'm not a QT guy in any way and this is my first actual venture into its API and there's probably a better way to do such things, but hopefully this is an improvement at least.
Below is my diff attached below for my changes to propelleride/views/editorview.cpp
Feel free to use and improve it as you see fit.
Roger.
diff editorview.orig editorview.cpp
33a34,101
> // Attempt to filter and support useful characters within code completion dialog
> class MyFilter : public QObject
> {
> public:
> MyFilter(QComboBox *p, int *key) :QObject()
> {
> parent = p;
> lastkey = key;
> }
>
> protected:
> bool eventFilter(QObject *obj, QEvent *event)
> {
> if (event->type() == QEvent::KeyPress)
> {
> // add special key handling here
> //qDebug() << "key event" ;
> QKeyEvent *ke = static_cast<QKeyEvent *>(event);
> int index = parent->view()->currentIndex().row();
> //qDebug() << "key index = " << *lastkey;
> *lastkey = 0;
> Qt::Key key = (Qt::Key)ke->key();
> if ((key >= Qt::Key_0 && key <= Qt::Key_9) ||
> key == Qt::Key_Dollar || key == Qt::Key_Percent || key == Qt::Key_Ampersand ||
> key == Qt::Key_Greater || key == Qt::Key_Less || key == Qt::Key_At || key == Qt::Key_ParenLeft)
> {
> *lastkey = (int)key;
> emit parent->activated(0);
> return true;
> }
> if (key == Qt::Key_Period || key == Qt::Key_NumberSign)
> {
> emit parent->activated(0);
> return true;
> }
> if (key == Qt::Key_Space || key == Qt::Key_Return || key == Qt::Key_Tab)
> {
> if (index < 0) // protect ourselves in case of empty list?
> index = 0;
> emit parent->activated(index);
> return true;
> }
> }
> return QObject::eventFilter(obj, event);
> }
> private:
> QComboBox *parent;
> int *lastkey;
> };
>
> class MyComboBox : public QComboBox
> {
> public:
> MyComboBox(EditorView *editor) : QComboBox(editor)
> {
> codeEditor = editor;
> filt = new MyFilter(this, &lastkey);
> view()->installEventFilter(filt);
> }
> ~MyComboBox() {delete filt;}
>
> virtual int getLastKey() { return lastkey;}
> private:
> EditorView *codeEditor;
> MyFilter *filt;
> int lastkey;
> };
>
67c135
< cbAuto = new QComboBox(this);
---
> cbAuto = new MyComboBox(this);
198c266
< int row = cursor.blockNumber() + 1; // show just below line
---
> int row = cursor.blockNumber() + 2; // show just below line
387a456
> qDebug() << "finishAutocomplete " << index;
388a458
> qDebug() << "finishAutocomplete text is:" << text;
396c466
< if (text.length() > 0)
---
> //if (text.length() > 0)
398,399c468,469
< else
< cur.insertText(s.trimmed());
---
> //else
> //cur.insertText(s.trimmed());
403c473,476
< cur.insertText(cbAuto->itemText(0));
---
> if (((MyComboBox *)cbAuto)->getLastKey())
> cur.insertText(cbAuto->itemText(0) + (char)(((MyComboBox *)cbAuto)->getLastKey()));
> else
> cur.insertText(cbAuto->itemText(0));
415c488
< cbAuto->hide();
---
> cbAuto->hidePopup();// modified
Since I was looking into the PropellerIDE codebase recently I also started digging into the problem I encountered a year ago (mentioned in my second last post above) related to the weirdness of the Propeller Serial Terminal implementation in PropellerIDE's Terminal application. I found it just didn't display text properly and there were some bugs with the cursor handling in particular. The main problem was that the way the QPlainTextEdit class with all it's variable text line lengths got used for text insertion was not really suitable with a terminal that works best with fixed rows/columns. So I have patched the code in places to make the implementation work more like a real terminal, assuming 80x25 screen size. All the regular terminal controls - up/down/left/right/home/clear screen/clear to end of line/clear to end of file/return/backspace/tab, and scrolling up at the end of the screen now appear to be working to my satisfaction and I can now display text from Propeller's using the Parallax Serial Terminal class reasonably nicely. If anyone wants the source of this fix I can make it available.
Ideally PropellerIDE would have had some additional GUI controls that would allow terminal screen size adjustments, and more flexible CR/LF option handling. Right now, the LF is ignored and CR is used to move to the new line. The PST Spin object sends CR anyway so that fixed choice is mostly okay. Another good thing would be having a way to turn PST mode on or off. It appears that the code as originally written was intended to allow for something like that but there is no GUI control to enable/disable the PST control mode, it is always on.
It's a real shame this PropellerIDE code does not appear to be maintained by anyone these days. I do find it's actually pretty nice to use for Propeller development, at least on a Mac where your choices tend to become limited anyway.
Nice job - this is something that I had wanted to look into, as I use the terminal during development a lot. I got as far as branching PropellerIDE on github...
I don't really "know" C++, and certainly not QT, but reading through the source, I find I can understand bits, and feel like with enough time digging into how each function works, I can make sense of it, but it's not SPIN!
I'd definitely be interested in the code if you're willing to share. Sometimes, "repainting" and clearing the whole terminal for every change just doesn't cut it so it'd be nice to have working position code.
FWIW, I spoke to Brett over email late this past fall and he expressed interest in continuing development on it, but real life happened, which from what I gather, has consumed a lot of spare time that he'd otherwise be able to spend here. I'd bought a Lamestation kit and supported him on his Patreon (though not much, I still do a monthly donation as I use PropellerIDE almost every day) hoping that it'd all pick up steam for him, but sadly, I don't think any of that happened. It's a shame - seems every independent IDE purpose-made for the Propeller has faded (bst, pzst, now PropellerIDE...may've forgotten others) :depressed: I hope he will some day return.
Thanks Jesse. It's always interesting to know what the history of this was. Brett did some good work.
I can give you these changes soon. I am just playing with a couple of other possible niceties right now so my changes are a state of flux and I didn't have an early snapshot before I made additional changes. However some of this new stuff appears to be now working...
- console window now gets focus when Terminal app starts instead of the baud rate drop down, letting you start typing right away without an extra mouse click if you are happy with the 115200 default.
- added a checkbox to enable/disable PST mode, PST mode is enabled by default
- generic serial mode always shows the bottom of screen, while PST mode shows top of screen when you resize
- echo mode is now disabled by default
(Ideally the default settings would also be customizable and persist but I'm not likely to go that far right now)
Right now I am also experimenting with a dynamic console window size control by scaling the outer window. If that pans out I'll include it otherwise I'll just have to revert back to what was working before without that extra row/column adjustment stuff. It starts to get a bit tricky as you need to decide what to do with all the text already present if you resize. It's probably easiest just to clear everything out but that feels a bit brutal and won't look as nice as you do it. I'm finding there are other complexities with external events such as clear and active button presses too. Still learning stuff about QT.
- console window now gets focus when Terminal app starts instead of the baud rate drop down, letting you start typing right away without an extra mouse click if you are happy with the 115200 default.
lol - this, as they say nowadays.
In Linux, it seems to be just a bit different - for me anyway, it's the 'Active' button that first gets the focus, so I'll hit the spacebar a couple times, and find I've reset the Prop. This'll be a nice tweak.
- added a checkbox to enable/disable PST mode, PST mode is enabled by default
- generic serial mode always shows the bottom of screen, while PST mode shows top of screen when you resize
- echo mode is now disabled by default
(Ideally the default settings would also be customizable and persist but I'm not likely to go that far right now)
Right now I am also experimenting with a dynamic console window size control by scaling the outer window. If that pans out I'll include it otherwise I'll just have to revert back to what was working before without that extra row/column adjustment stuff. It starts to get a bit tricky as you need to decide what to do with all the text already present if you resize. It's probably easiest just to clear everything out but that feels a bit brutal and won't look as nice as you do it. I'm finding there are other complexities with external events such as clear and active button presses too. Still learning stuff about QT.
Thanks for picking up the ball. Shoot, the funny code completion popup has been a nagging annoyance for me too. I've been using PropIDE 0.33.3 (the version endorsed on the Parallax web site), on OS 10.12.3, and using the FTDI driver (not Apple's clone). I'll have to give 0.38.5 another try, but some time in the past I got the idea that it wasn't yet stable. I haven't been using the built-in PropIDE terminal, instead switching out to CoolTerm.
As mentioned here's a zip file of my file changes to the Terminal app in PropellerIDE that I've been playing with. I've tested it out a bit but consider it still somewhat experimental. It does appear to work okay on my MAC but is untested on other platforms so YMMV.
Summary of changes:
- Fully enabled PST mode that interprets and processes PST cursor/screen handling better
- Dynamically resizable rows and columns from 80-255 and 25-100, dimensions displayed in Title bar until overwritten by port change etc
- Can optionally send the up/down/left/right control characters to the Prop via host keyboard's cursor keys, can be useful for navigation
- Optional local echo of typed characters now including BS, for situations where the Prop doesn't return the received data
- Received DELs (127) interpreted as BS (8) character
- Non-PST (raw) mode only interprets CR (LF is ignored) and BS/DEL plus the printable ASCII characters
- focus set to console widget on window startup
- default to 80x25 size initially
- added support for text drag-and-drop and pasted data to the console window to be transmitted to the Prop (but no pacing yet, so be sure your app is fast enough to keep up!)
- can optionally append LF to CR's sent from keyboard/clipboard paste, plus LF terminated pasted data from Linux/MAC is translated to CR terminated lines (or to CR+LF if LF append option is checked)
A few other things I might mention...
There might potentially be some console screen width/scroll box issues with different platforms or font options, not really sure as it's untested on other systems. I know I had a few issues getting the text character dimensions correct during window resize and needed a couple of magic numbers. Ideally these numbers would come from the Qt API to determine these dimensions consistently if I only knew which one to use...
I'd like to add a data pacing option (i.e. to pause slightly after each line sent) so pasted data can be kept up with on the Propeller. During some testing I found a SPIN program echoing back received data at 115200 is not quite able to keep up with the transmitted rate from the host sending the bulk data. Slower rates and or faster Propeller programs probably would be okay. Ideally HW based flow control would help resolve it but PropPlugs don't support that.
I'd also like to put in a decent scroll back buffer for the non-PST mode and have the window resize operation keep all the original data available until the mouse is actually released during shrinking/expanding operations rather than lose the data if you shrink too far. The original Terminal code had 100 lines of buffer, while right now my version is just the window height. I'm still experimenting a little with that. The dynamic resize and two modes affects this sort of thing quite a bit so it needs more work to get that part going right.
There's also no support to send control characters from the console to the Propeller interactively. I think it would be nice in Raw mode to open that option up as well. PST mode probably is less likely to need it, but it would be another nice feature to put in at some point.
Enjoy! Let me know if you get it to work or have other issues etc.
Roger.
@rogloh, since you are now the designated maintainer of PropellerIDE (designated by me ), I'd be happy to add automated builds of PropellerIDE to my TeamCity server. All you have to do send me the link to your public git repository. I bring this up because it will at least you the confidence that your changes still compile for other platforms.
Thanks @DavidZemon, though I was able to build for a Linux box here in the end.
I found my change does compile and mostly work under Linux however I did notice some small differences with the focus on Linux vs MacOS. Qt on both platforms is not identical unfortunately. In Linux you can select a checkbox and the focus will change out of the console area, preventing you from typing until you click the console again. I don't like that behaviour at all and might try to resolve that somehow to keep the focus in the console after you select any checkbox. As feared the character row/columns count was slightly different too and is messed about with font size changes. To fix the cosmetics I need to figure out the true font metric calculations and will try to play with it further if I get time. My other PST related changes seem to work okay under Linux. Just a pity there are some Qt variations between platforms with respect to window layout sizes. That must really mess software developers up during testing on the different platforms and create some extra headaches.
Another difference I noticed in the original auto-completion is that it seems to work better in Linux whereas the MAC has issues and I needed to make changes to get it to behave in a useable way. Annoying.
I just realized I grossly misworded my previous comment (now fixed) and mistakenly implied that I am the new maintainer. I meant (in a half joking fashion) to imply that rogloh is the new maintainer, NOT me.
To try to consolidate things a bit, I've added rogloh's above changes (the terminal changes and the earlier code completion changes) as well as my change that "fixes" uploading code to the Propeller to two separate branches of a fork of PropellerIDE: https://github.com/avsa242/PropellerIDE
and also merged both of those branches into a 'testing' branch.
It builds (Ubuntu 18.04 64bit), and so far, all of the changes seem to work together...
As I've noted in the modified README.md, none of this is official or endorsed by Parallax - it's just an effort to fix a few issues. As things progress, maybe a PR can be submitted for inclusion into their official repository...
To try to consolidate things a bit, I've added rogloh's above changes (the terminal changes and the earlier code completion changes) as well as my change that "fixes" uploading code to the Propeller to two separate branches of a fork of PropellerIDE: https://github.com/avsa242/PropellerIDE
and also merged both of those branches into a 'testing' branch.
It builds (Ubuntu 18.04 64bit), and so far, all of the changes seem to work together...
As I've noted in the modified README.md, none of this is official or endorsed by Parallax - it's just an effort to fix a few issues. As things progress, maybe a PR can be submitted for inclusion into their official repository...
Cheers
Hi there,
I'd be happy to help you to get stuff merged in. I don't have much time to work on PropellerIDE these days, but these issues bug me too, especially since I've started on a new project.
You don't need to wait and collect a lot of changes to submit a PR. Smaller changes are actually easier to review and merge, and you can make as many as you want; I don't mind! I do review PRs from people (I just haven't received any). When you make pull requests, it will trigger the build automation so I can see if your changes build for all supported platforms (Windows, OS X, Debian, Raspbian).
This goes for anyone else that wants to get changes merged into PropellerIDE: Don't be shy, send a pull request! I don't post much on here lately, but I still get notifications from GitHub, and it's the fastest way to reach me. There's also a contact form on my site at lamestation.com/contact that goes directly to my email.
Done...and *double-take* great to see you around, again!
(note this would be my first PR, so feel free to let me know if I've done it in a way that doesn't jive with the repository)
@avsa242 good job porting this code into GitHub. Glad to hear my changes apparently worked for you too.
I really like PropellerIDE as a tool. It mostly works okay now on my Mac. Only a couple of annoyances remain...
1) PropellerIDE always crashes when I disconnect the USB serial port to the Propeller from my machine. Not sure why but at some point I'd like to chase that down.
2) I recall I read somewhere it has issues working on the latest OS X. I use Yosemite and have held off upgrading my OS basically because of this concern. I have to be able to keep using it for Prop development.
Other that those I'm pretty happy using it at the moment. Oh and it would be really cool to support the new wifi based download method at some point, but I guess that can wait.
is incorrect because "basefile.append" modifies the original basefile, so "retfile" ends up having *both* pattern_out and pattern_ret as suffixes. I think this is behind some of the problems with running code built via openspin.
The other change is to add fastspin to the list of supported Spin compilers.
Done...and *double-take* great to see you around, again!
(note this would be my first PR, so feel free to let me know if I've done it in a way that doesn't jive with the repository)
Cheers,
Jesse
Thanks! I'm just happy to see people submitting changes. Looks like all my build automation stuff rotted away from disuse. I'm going to try getting the build green again and then I'll take a look at some merges.
Also, somehow I hadn't made the connection that avsa242 was the same Jesse, haha. Hi there!
@avsa242 good job porting this code into GitHub. Glad to hear my changes apparently worked for you too.
I really like PropellerIDE as a tool. It mostly works okay now on my Mac. Only a couple of annoyances remain...
1) PropellerIDE always crashes when I disconnect the USB serial port to the Propeller from my machine. Not sure why but at some point I'd like to chase that down.
2) I recall I read somewhere it has issues working on the latest OS X. I use Yosemite and have held off upgrading my OS basically because of this concern. I have to be able to keep using it for Prop development.
Other that those I'm pretty happy using it at the moment. Oh and it would be really cool to support the new wifi based download method at some point, but I guess that can wait.
In the last couple years, I've become a big fan of automated testing. Unfortunately, I worked on PropellerIDE before then, hah! With every release, random stuff would get broken that I wouldn't find out about until later. It only got more complicated with all the platforms I was trying to support. It wouldn't surprise me if the Mac version wasn't working.
Still don't have time to work on this like I used to, but if I get a I think the single biggest thing the IDE needs at this point is some automated testing. Even just dumb stuff, like a script that runs the installer and makes sure all the files end up in the right place. That would save me soooo much time.
But let's see if I can get it building again first... =P
In the last couple years, I've become a big fan of automated testing. Unfortunately, I worked on PropellerIDE before then, hah! With every release, random stuff would get broken that I wouldn't find out about until later. It only got more complicated with all the platforms I was trying to support. It wouldn't surprise me if the Mac version wasn't working.
...
Agree, for quality software some automation is required especially if an application needs to support cross platform. The number of platforms and testing rapidly gets too large to manage otherwise.
Unfortunately as I found, QT itself has its own quirks and can behave differently on different platforms as well, so seemingly minor changes may not always behave the same on all systems. Only testing on all platforms could really expose these differences in advance.
In the name of automated testing, I'm happy to lend my hand in the form of TeamCity configurations and/or Docker builds. I know Travis is great and nicely integrated, and I know it does a lot, but if there's ever a "boy I wish it would just do..." let me know. Maybe TeamCity can do it. And though Docker won't help you build or run natively on Windows or Mac, it might help with consistent builds at least. I'd be happy to setup a Docker image capable of building PropellerIDE if that would be useful.
@avsa242 good job porting this code into GitHub. Glad to hear my changes apparently worked for you too.
Thanks! Though that build/test suite (travis) seemed to reject it. I'm looking into it...
Nooo, it didn't reject *your* change. The automation is broken. I fixed the Linux stuff yesterday, but Mac and Windows is still broken. It's a case of code rot.
I finally had the time to test out @ersmith 's PR and confirmed it works for me, as well - it seems to fix #43 (sources building but not uploading to the Prop)
@rogloh
Have you seen any issues with the terminal and setting cursor position with your propterm code changes? Trying to set the position to either column 13 or 14 results in some unexpected behavior here. Setting the column to 13 actually prints text at column 0 and setting the column to 14 prints the first bit of text at the rightmost column of the terminal, and the rest at the beginning of the next line. I'm using this code:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
OBJ
ser : "com.serial.terminal"
time : "time"
VAR
long _ser_cog
PUB Main
Setup
PosTest
PUB PosTest
ser.Clear
repeat
' ser.Position (13, 2)
ser.PositionX (14)
ser.Str (string("TEST"))
time.MSleep (1000)
PUB Setup
repeat until _ser_cog := ser.Start (115_200)
ser.Clear
Just to rule out other possible causes, I've tried:
* Three different Prop boards to rule out hardware (FLiP, Parral, Activity)
* Parallax Serial Terminal.spin in place of com.serial.terminal, which is based on the former
* Baud rates down to 9600
and they all behave the same way.
I took a look at the code in the PropellerIDE source console.cpp for cursor movement as well as the switch block in Console::putData, but I haven't been able to figure it out... any ideas?
Comments
As far as I know it will work identically, everything I have done with my RPI1 and RPI2 have worked (even better) under RPI3. Its just a faster cpu, with more ram, and a better gpu. It also has 4 cores and they are 64-bit capable. Raspbian has dealt with multiple cores automagically, swapping processes to less used cores without me noticing, except that everything runs much faster. I have encoded 4 MP3's simultaneously, and the OS serves each encoder to a new cpu, no effort on my part.
I am running latest version of Raspbian Jessie, just ran apt-get dist-upgrade yesterday. 64-bit support is just like windows, the OS needs to support it, and last I saw, the rpi foundation figured with only 1 gig of rpi3 ram, the need to go 64-bit OS was overkill. The benefit to RPI3 is wireless built in, faster quad core cpu, and faster gpu, also the microsd card slot isn't spring loaded (won't pop out easily now)
I don't think there is any difference between RPI1, 2, 3, at least not for propellerIDE, unless it implements some cpu heavy function.
I have 2 virtual desktops running X, over wireless on my RPI3, one desktop running a webcam, and the other desktop running Putty and PropellerIDE, and all is smooth, 30% cpu use. Multi-cpu makes a world of a difference when multitasking.
Great, when it comes out, I won't need to kick myself for forgetting to switch to ttyUSB0.
I'm using PropIDE (Win10 0.36.5) to push the Tachyon 'kernel' to a board based on a parallax USB protoboard. It has worked tempermentally, now very poorly. When trying to download it quickly flashes a dialog box, shows 'Build Succesful', then the dialog disappears and there is no evidence of a download. Prop tool can communicate with the board sending spin, other boards too. I tried using simple manual examples with PropIDE and these are showing the same behaviour (ie flashes the dialog, no download).
At one point I thought the fix was not using a USB hub, but now it fails with the hub, or directly plugged into the PC's USB port.
Thanks for your help!
pr
I get that a lot. Always after Win10 sleeps, then resumes. And also at other pattern-yet-unidentified random times too. As I recall, running SimpleIDE at the same time can also cause this... perhaps there's a fight between the port in certain scenarios
Anyways... Closing/restarting PropellerIDE always solves it (temporarily) for me. I'm curious if a restart helps your situation too?
More generally... I don't recall seeing this behaviour prior to the last couple PropellerIDE updates. Although, a lot of other things have changed my side since then, so I can't say with any science that the issue is with the IDE. Could be a serial port driver issue, for example. Sadly I've not found time to diagnose and resolve the real cause yet, so just been livin' with it!
Try version 0.38.5. It seems to be improved.
One immediate observation I note is the change from using openspin to bstc as the background spin compiler. Given the age of bstc, it's a testament to Brad's skills I guess.
EDIT: Version confusion fix.
EDIT: Version confusion fix.
Thanks
Jim
For example this snippet of test code below from a USB host project would always trigger the problem every time and generates the follow output with weird gaps in places instead of nicely formatted text. I don't know if the QT library is buggy on the MAC or this is something in PropTerm console code. It is kind of annoying to not be able to interpret the cursor movement/positioning commands. Anyone else seeing bad cursor issues with MAC OS X and PropellerIDE serial terminal?
Non cursor based console output seems to work ok, and Newline and clear screen work OK too thankfully.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ term : "Parallax Serial Terminal" PUB start | x, y, c x := 1 y := 1 term.Start(115200) repeat c := term.CharIn term.str(@uiTemplate) DAT uiTemplate byte term#CS byte "FT232 Loopback Test" byte term#HM, term#PX, 30, "Test #" byte term#PC, 1, 2, "Settings" byte term#PC, 4, 3, "Baud Rate: [Q/A]" byte term#PC, 3, 4, "Burst Size: [W/S]" byte term#PC, 6, 5, "Pattern: [E/D]" byte term#PC, 5, 6, "HC Debug: [R/F]" byte term#PC, 30, 2, "Errors" byte term#PC, 34, 3, "Success:" byte term#PC, 38, 4, "CRC:" byte term#PC, 38, 5, "PID:" byte term#PC, 34, 6, "Timeout:" byte term#PC, 33, 7, "Bad Data:" byte term#PC, 32, 8, "Too Short:" byte term#PC, 33, 9, "Too Long:" byte term#PC, 36, 10, "Other:" byte term#PC, 1, 11, "Last bad data buffer:" byte term#PC, 1, 16, "Error rate chart:" byte 0This is the bad output pasted just like I see it on the console. Scroll down to see some more text at the end too.
Bau d Rate: [Q/A]Success: Burst Size: [W/S]CRC: Patte rn: [E/D]PID: HC Debug: [R/F] Timeout: Bad Data: Too Short: Too Long: O ther: L ast bad data buffer: Error rate chart: ttingsrorsWhat it is now doing is the following...
When you press # or . it will trigger the code completion popup as before.
But now when you press <return> or <space> or <tab> it will paste in the currently selected text as chosen by the cursor arrows or mouse click instead of mouse click alone. Pressing <escape> cancels everything including the first character you pressed. The <up> and <down> cursor keys also allow selection choice and an alpha character will select the next entry starting with that character (this is actually an automatic behaviour of the QComboBox class).
I have also made it nicer when entering constants in PASM code.
If you press # or . and then any character in this group: (, @, $, & #, %, >, 0-9
it will immediately continue on and close the dialog box but keep the two characters you entered. This lets you not be interrupted as much when entering numeric constants, and you don't need to touch the mouse. [In future it would be nice to have dynamically disabled if you are typing in a DAT section but right now it doesn't do that.]
If you just wanted to enter a single hash (#) or period (.) without any completion, you can either press the key twice, or that key followed by a tab or space or return.
As before it still has some difficulty with the positioning of the code completion pop up on screen depending on the size of the list as I've not paid so much attention to that issue which can be annoying if it ever covers over what you are typing.
I'm not a QT guy in any way and this is my first actual venture into its API and there's probably a better way to do such things, but hopefully this is an improvement at least.
Below is my diff attached below for my changes to propelleride/views/editorview.cpp
Feel free to use and improve it as you see fit.
Roger.
diff editorview.orig editorview.cpp
33a34,101 > // Attempt to filter and support useful characters within code completion dialog > class MyFilter : public QObject > { > public: > MyFilter(QComboBox *p, int *key) :QObject() > { > parent = p; > lastkey = key; > } > > protected: > bool eventFilter(QObject *obj, QEvent *event) > { > if (event->type() == QEvent::KeyPress) > { > // add special key handling here > //qDebug() << "key event" ; > QKeyEvent *ke = static_cast<QKeyEvent *>(event); > int index = parent->view()->currentIndex().row(); > //qDebug() << "key index = " << *lastkey; > *lastkey = 0; > Qt::Key key = (Qt::Key)ke->key(); > if ((key >= Qt::Key_0 && key <= Qt::Key_9) || > key == Qt::Key_Dollar || key == Qt::Key_Percent || key == Qt::Key_Ampersand || > key == Qt::Key_Greater || key == Qt::Key_Less || key == Qt::Key_At || key == Qt::Key_ParenLeft) > { > *lastkey = (int)key; > emit parent->activated(0); > return true; > } > if (key == Qt::Key_Period || key == Qt::Key_NumberSign) > { > emit parent->activated(0); > return true; > } > if (key == Qt::Key_Space || key == Qt::Key_Return || key == Qt::Key_Tab) > { > if (index < 0) // protect ourselves in case of empty list? > index = 0; > emit parent->activated(index); > return true; > } > } > return QObject::eventFilter(obj, event); > } > private: > QComboBox *parent; > int *lastkey; > }; > > class MyComboBox : public QComboBox > { > public: > MyComboBox(EditorView *editor) : QComboBox(editor) > { > codeEditor = editor; > filt = new MyFilter(this, &lastkey); > view()->installEventFilter(filt); > } > ~MyComboBox() {delete filt;} > > virtual int getLastKey() { return lastkey;} > private: > EditorView *codeEditor; > MyFilter *filt; > int lastkey; > }; > 67c135 < cbAuto = new QComboBox(this); --- > cbAuto = new MyComboBox(this); 198c266 < int row = cursor.blockNumber() + 1; // show just below line --- > int row = cursor.blockNumber() + 2; // show just below line 387a456 > qDebug() << "finishAutocomplete " << index; 388a458 > qDebug() << "finishAutocomplete text is:" << text; 396c466 < if (text.length() > 0) --- > //if (text.length() > 0) 398,399c468,469 < else < cur.insertText(s.trimmed()); --- > //else > //cur.insertText(s.trimmed()); 403c473,476 < cur.insertText(cbAuto->itemText(0)); --- > if (((MyComboBox *)cbAuto)->getLastKey()) > cur.insertText(cbAuto->itemText(0) + (char)(((MyComboBox *)cbAuto)->getLastKey())); > else > cur.insertText(cbAuto->itemText(0)); 415c488 < cbAuto->hide(); --- > cbAuto->hidePopup();// modifiedIdeally PropellerIDE would have had some additional GUI controls that would allow terminal screen size adjustments, and more flexible CR/LF option handling. Right now, the LF is ignored and CR is used to move to the new line. The PST Spin object sends CR anyway so that fixed choice is mostly okay. Another good thing would be having a way to turn PST mode on or off. It appears that the code as originally written was intended to allow for something like that but there is no GUI control to enable/disable the PST control mode, it is always on.
It's a real shame this PropellerIDE code does not appear to be maintained by anyone these days. I do find it's actually pretty nice to use for Propeller development, at least on a Mac where your choices tend to become limited anyway.
Nice job - this is something that I had wanted to look into, as I use the terminal during development a lot. I got as far as branching PropellerIDE on github...
I don't really "know" C++, and certainly not QT, but reading through the source, I find I can understand bits, and feel like with enough time digging into how each function works, I can make sense of it, but it's not SPIN!
I'd definitely be interested in the code if you're willing to share. Sometimes, "repainting" and clearing the whole terminal for every change just doesn't cut it
FWIW, I spoke to Brett over email late this past fall and he expressed interest in continuing development on it, but real life happened, which from what I gather, has consumed a lot of spare time that he'd otherwise be able to spend here. I'd bought a Lamestation kit and supported him on his Patreon (though not much, I still do a monthly donation as I use PropellerIDE almost every day) hoping that it'd all pick up steam for him, but sadly, I don't think any of that happened. It's a shame - seems every independent IDE purpose-made for the Propeller has faded (bst, pzst, now PropellerIDE...may've forgotten others) :depressed: I hope he will some day return.
Cheers,
Jesse
I can give you these changes soon. I am just playing with a couple of other possible niceties right now so my changes are a state of flux and I didn't have an early snapshot before I made additional changes. However some of this new stuff appears to be now working...
- console window now gets focus when Terminal app starts instead of the baud rate drop down, letting you start typing right away without an extra mouse click if you are happy with the 115200 default.
- added a checkbox to enable/disable PST mode, PST mode is enabled by default
- generic serial mode always shows the bottom of screen, while PST mode shows top of screen when you resize
- echo mode is now disabled by default
(Ideally the default settings would also be customizable and persist but I'm not likely to go that far right now)
Right now I am also experimenting with a dynamic console window size control by scaling the outer window. If that pans out I'll include it otherwise I'll just have to revert back to what was working before without that extra row/column adjustment stuff. It starts to get a bit tricky as you need to decide what to do with all the text already present if you resize. It's probably easiest just to clear everything out but that feels a bit brutal and won't look as nice as you do it. I'm finding there are other complexities with external events such as clear and active button presses too. Still learning stuff about QT.
I'll try get something useful out soon...
In Linux, it seems to be just a bit different - for me anyway, it's the 'Active' button that first gets the focus, so I'll hit the spacebar a couple times, and find I've reset the Prop. This'll be a nice tweak.
Sounds good!
Cheers
Summary of changes:
- Fully enabled PST mode that interprets and processes PST cursor/screen handling better
- Dynamically resizable rows and columns from 80-255 and 25-100, dimensions displayed in Title bar until overwritten by port change etc
- Can optionally send the up/down/left/right control characters to the Prop via host keyboard's cursor keys, can be useful for navigation
- Optional local echo of typed characters now including BS, for situations where the Prop doesn't return the received data
- Received DELs (127) interpreted as BS (8) character
- Non-PST (raw) mode only interprets CR (LF is ignored) and BS/DEL plus the printable ASCII characters
- focus set to console widget on window startup
- default to 80x25 size initially
- added support for text drag-and-drop and pasted data to the console window to be transmitted to the Prop (but no pacing yet, so be sure your app is fast enough to keep up!)
- can optionally append LF to CR's sent from keyboard/clipboard paste, plus LF terminated pasted data from Linux/MAC is translated to CR terminated lines (or to CR+LF if LF append option is checked)
A few other things I might mention...
There might potentially be some console screen width/scroll box issues with different platforms or font options, not really sure as it's untested on other systems. I know I had a few issues getting the text character dimensions correct during window resize and needed a couple of magic numbers. Ideally these numbers would come from the Qt API to determine these dimensions consistently if I only knew which one to use...
I'd like to add a data pacing option (i.e. to pause slightly after each line sent) so pasted data can be kept up with on the Propeller. During some testing I found a SPIN program echoing back received data at 115200 is not quite able to keep up with the transmitted rate from the host sending the bulk data. Slower rates and or faster Propeller programs probably would be okay. Ideally HW based flow control would help resolve it but PropPlugs don't support that.
I'd also like to put in a decent scroll back buffer for the non-PST mode and have the window resize operation keep all the original data available until the mouse is actually released during shrinking/expanding operations rather than lose the data if you shrink too far. The original Terminal code had 100 lines of buffer, while right now my version is just the window height. I'm still experimenting a little with that. The dynamic resize and two modes affects this sort of thing quite a bit so it needs more work to get that part going right.
There's also no support to send control characters from the console to the Propeller interactively. I think it would be nice in Raw mode to open that option up as well. PST mode probably is less likely to need it, but it would be another nice feature to put in at some point.
Enjoy! Let me know if you get it to work or have other issues etc.
Roger.
I found my change does compile and mostly work under Linux however I did notice some small differences with the focus on Linux vs MacOS. Qt on both platforms is not identical unfortunately. In Linux you can select a checkbox and the focus will change out of the console area, preventing you from typing until you click the console again. I don't like that behaviour at all and might try to resolve that somehow to keep the focus in the console after you select any checkbox. As feared the character row/columns count was slightly different too and is messed about with font size changes. To fix the cosmetics I need to figure out the true font metric calculations and will try to play with it further if I get time. My other PST related changes seem to work okay under Linux. Just a pity there are some Qt variations between platforms with respect to window layout sizes. That must really mess software developers up during testing on the different platforms and create some extra headaches.
Another difference I noticed in the original auto-completion is that it seems to work better in Linux whereas the MAC has issues and I needed to make changes to get it to behave in a useable way. Annoying.
and also merged both of those branches into a 'testing' branch.
It builds (Ubuntu 18.04 64bit), and so far, all of the changes seem to work together...
As I've noted in the modified README.md, none of this is official or endorsed by Parallax - it's just an effort to fix a few issues. As things progress, maybe a PR can be submitted for inclusion into their official repository...
Cheers
Hi there,
I'd be happy to help you to get stuff merged in. I don't have much time to work on PropellerIDE these days, but these issues bug me too, especially since I've started on a new project.
You don't need to wait and collect a lot of changes to submit a PR. Smaller changes are actually easier to review and merge, and you can make as many as you want; I don't mind! I do review PRs from people (I just haven't received any). When you make pull requests, it will trigger the build automation so I can see if your changes build for all supported platforms (Windows, OS X, Debian, Raspbian).
This goes for anyone else that wants to get changes merged into PropellerIDE: Don't be shy, send a pull request! I don't post much on here lately, but I still get notifications from GitHub, and it's the fastest way to reach me. There's also a contact form on my site at lamestation.com/contact that goes directly to my email.
Anyway, I hope to hear from more people!
Done...and *double-take* great to see you around, again!
(note this would be my first PR, so feel free to let me know if I've done it in a way that doesn't jive with the repository)
Cheers,
Jesse
I really like PropellerIDE as a tool. It mostly works okay now on my Mac. Only a couple of annoyances remain...
1) PropellerIDE always crashes when I disconnect the USB serial port to the Propeller from my machine. Not sure why but at some point I'd like to chase that down.
2) I recall I read somewhere it has issues working on the latest OS X. I use Yosemite and have held off upgrading my OS basically because of this concern. I have to be able to keep using it for Prop development.
Other that those I'm pretty happy using it at the moment. Oh and it would be really cool to support the new wifi based download method at some point, but I guess that can wait.
The other change is to add fastspin to the list of supported Spin compilers.
Thanks! I'm just happy to see people submitting changes. Looks like all my build automation stuff rotted away from disuse. I'm going to try getting the build green again and then I'll take a look at some merges.
Also, somehow I hadn't made the connection that avsa242 was the same Jesse, haha. Hi there!
In the last couple years, I've become a big fan of automated testing. Unfortunately, I worked on PropellerIDE before then, hah! With every release, random stuff would get broken that I wouldn't find out about until later. It only got more complicated with all the platforms I was trying to support. It wouldn't surprise me if the Mac version wasn't working.
Still don't have time to work on this like I used to, but if I get a I think the single biggest thing the IDE needs at this point is some automated testing. Even just dumb stuff, like a script that runs the installer and makes sure all the files end up in the right place. That would save me soooo much time.
But let's see if I can get it building again first... =P
Agree, for quality software some automation is required especially if an application needs to support cross platform. The number of platforms and testing rapidly gets too large to manage otherwise.
Unfortunately as I found, QT itself has its own quirks and can behave differently on different platforms as well, so seemingly minor changes may not always behave the same on all systems. Only testing on all platforms could really expose these differences in advance.
Thanks! Though that build/test suite (travis) seemed to reject it. I'm looking into it...
Nooo, it didn't reject *your* change. The automation is broken. I fixed the Linux stuff yesterday, but Mac and Windows is still broken. It's a case of code rot.
Have you seen any issues with the terminal and setting cursor position with your propterm code changes? Trying to set the position to either column 13 or 14 results in some unexpected behavior here. Setting the column to 13 actually prints text at column 0 and setting the column to 14 prints the first bit of text at the rightmost column of the terminal, and the rest at the beginning of the next line. I'm using this code:
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ ser : "com.serial.terminal" time : "time" VAR long _ser_cog PUB Main Setup PosTest PUB PosTest ser.Clear repeat ' ser.Position (13, 2) ser.PositionX (14) ser.Str (string("TEST")) time.MSleep (1000) PUB Setup repeat until _ser_cog := ser.Start (115_200) ser.ClearJust to rule out other possible causes, I've tried:
* Three different Prop boards to rule out hardware (FLiP, Parral, Activity)
* Parallax Serial Terminal.spin in place of com.serial.terminal, which is based on the former
* Baud rates down to 9600
and they all behave the same way.
I took a look at the code in the PropellerIDE source console.cpp for cursor movement as well as the switch block in Console::putData, but I haven't been able to figure it out... any ideas?
Cheers,
Jesse