Something else I've come across in OS X. If I click the Debug icon to load a program and open the debug screen, it works fine the first time. If I then click anywhere in the PropIDE window, the Debug screen disappears out of context, as expected. However, I cannot get it back. If I click the Debug icon (or select from the menu), the program loads again, but the debug screen does not reappear. To get it back, I have to exit PropIDE and restart it.
If you can attach the crash report for PropellerIDE to a tracker item ...
I did that last night. However, I do not find the LameStation facility to be a very convenient way to communicate bug reports. It's much easier to do it here.
Here's a screenshot. It's definitely not the Parallax font.
-Phil
Hmm, it's possible that your Parallax font is not being found by PropellerIDE and Mac OS X is giving you a replacement font in its place. It might be why you are seeing less-than-good font display in the Editor as well. If you run the Mac Font Book app, does it contain your Parallax & Parallax2 fonts? Might be a system error rather than an error of PropellerIDE...
The Fonts app does not show either Parallax font. Apparently the PropIDE installer did not install them. Maybe it has something to do with the error message I got from the installer:
The system extension “/System/Library/Extensions/EMUL.kext” was installed improperly and cannot be used. Please try reinstalling it, or contact the product’s vendor for an update.
The Fonts app does not show either Parallax font. Apparently the PropIDE installer did not install them. Maybe it has something to do with the error message I got from the installer:
-Phil
The app includes the font but doesn't "install" it at this point. Something for the bug tracker. As a workaround If you do download the font and double-click on it, the OS will install it!
I'm sure this will get diagnosed before final release...
I downloaded and installed the Parallax font in my MacBook. Both the editor and debug terminal screens look much better now. ('Not sure what the Parallax2 font was supposed to accomplish. I didn't bother with it, since it looked pretty bad on Windows.)
I downloaded and installed the Parallax font in my MacBook. Both the editor and debug terminal screens look much better now. ('Not sure what the Parallax2 font was supposed to accomplish. I didn't bother with it, since it looked pretty bad on Windows.)
Thanks!
-Phil
Good that the "workaround" is helping. Hopefully, a future PropellerIDE version will auto-install the font. The Parallax2 font as far as I can tell just adds a bold variant of the font so the OS does not need to create a bold version of the font on-the-fly from the regular font. Usually means you get a much cleaner bold effect as the bold font is created by a font artist rather than a computed bold.
I did that last night. However, I do not find the LameStation facility to be a very convenient way to communicate bug reports. It's much easier to do it here.
-Phil
If somebody is reading this thread and collecting bugs, otherwise you're barking in the wind.
I asked Jeff and Brett to comb this thread for issues and enter them in the issue tracker.
If somebody is reading this thread and collecting bugs, otherwise you're barking in the wind. ...
Oh, I know. Cripes! I'm sorry I'm such a curmudgeon -- a lazy one at that. But the forum is in my comfort zone; LameStation is not. I hope the powers that be can accommodate ...
On the upside, though, just posting on LameStation would never incite a broad spectrum of users to try and replicate the stuff I've had trouble with, since fewer people go there.
One thing that puzzles me about PropIDE is how it's able to load a program to EEPROM so quickly, compared with PropTool. Isn't the timing of that process determined by the ROM bootloader? The speedup is really nice, but I'm just curious about how it works.
One thing that puzzles me about PropIDE is how it's able to load a program to EEPROM so quickly, compared with PropTool. Isn't the timing of that process determined by the ROM bootloader? The speedup is really nice, but I'm just curious about how it works.
Maybe it is less gaps, or a faster baud rate ?
Most modern USB Bridge parts allow more granular Baud (typ 12MHz/N)
In another thread someone tested incremental Baud on a typical RC Osc Prop, reporting this typical value
["238,000 baud is consistent loading maxed out binaries. 250,000 is consistent for small files."]
(ROM loader Autobauds using the RC osc, & RC osc varies but will be above the corner case 115200 meets)
One thing that puzzles me about PropIDE is how it's able to load a program to EEPROM so quickly, compared with PropTool. Isn't the timing of that process determined by the ROM bootloader? The speedup is really nice, but I'm just curious about how it works.
-Phil
I'm guessing that this timing change might be the reason that PropellerIDE doesn't seem to work with any other USB devices except FTDI.
Hoping to get some scope pictures today to see what's happening.
I'm guessing that this timing change might be the reason that PropellerIDE doesn't seem to work with any other USB devices except FTDI.
Hoping to get some scope pictures today to see what's happening.
Well, as Jazzed explained up there in post #60, the CP1202 serial chip needs an RTS versus DTR for the required reset... SimpleIDE allows a configuration change to RTS or CFG for non-FTDI serial chips. PropellerIDE may need to add the ability to re-config that option, as well.
Well, as Jazzed explained up there in post #60, the CP1202 serial chip needs an RTS versus DTR for the required reset... SimpleIDE allows a configuration change to RTS or CFG for non-FTDI serial chips. PropellerIDE may need to add the ability to re-config that option, as well.
dgately
I'm using CP2102's (4D systems uUSB-MB5 modules) on a few boards with DTR as the reset. They all program fine using Propeller Tool. No RTS connected.
Well, as Jazzed explained up there in post #60, the CP1202 serial chip needs an RTS versus DTR for the required reset... SimpleIDE allows a configuration change to RTS or CFG for non-FTDI serial chips. PropellerIDE may need to add the ability to re-config that option, as well.
Certainly, any IDE should allow user selection of the control line used. (as well as full control of the Baud rate)
CP210x can support both RTS and DTR, but the problem is not all Modules give access to both pins.
To complicate this, parts like CP2105 have a default shipping state that does not enable all handshake lines.
On CP2105 RTS is always enabled, but DTR is a user-config option (and an OTP one)
.
Short answer: Just support both handshake lines.
I'm using CP2102's (4D systems uUSB-MB5 modules) on a few boards with DTR as the
reset. They all program fine using Propeller Tool. No RTS connected.
See my post above - CP2102 silicon supports both handshake lines, but not all modules bring them out, and some CP210x parts (eg CP2105) decide to ship with DTR instead optioned as GPIO (not the way I would have chosen default on a UART-Bridge device). RTS has no option, it always is enabled as RTS.
See my post above - CP2102 silicon supports both handshake lines, but not all modules bring them out, and some CP210x parts (eg CP2105) decide to ship with DTR instead optioned as GPIO (not the way I would have chosen default on a UART-Bridge device). RTS has no option, it always is enabled as RTS.
As I stated above, ALL of these modules have DTR connected as the reset with no additional configuration required.
Propeller Tool works perfectly with this module. Maybe for other variants dual handshake changes need to be added but NOT with this module.
A quick look at the timing differences between Propeller Tool and PropellerIDE shows a significant difference in DTR pulse widths. PT has a approx. pulse width of 27mS compared to 11mS of PIDE.
A quick look at the timing differences between Propeller Tool and PropellerIDE shows a significant difference in DTR pulse widths. PT has a approx. pulse width of 27mS compared to 11mS of PIDE.
How does the Baud rates, and char-char spacings, & time from DTR->Data compare ?
Any figures on the actual speedup mentioned in #71 ?
I downloaded and installed the Parallax font in my MacBook. Both the editor and debug terminal screens look much better now. ('Not sure what the Parallax2 font was supposed to accomplish. I didn't bother with it, since it looked pretty bad on Windows.)
Thanks!
-Phil
As far as I know, Parallax2 addresses some of the problems the original Parallax font had with Unicode support, among other things. However, both fonts are still buggy and behave strangely when used on various platforms.
Consequently, I am dropping support for the Parallax font as the default font, and using the platform-native monospace fonts instead in the next release.
This will break any of the special schematic characters that the Parallax font adds. However, these aren't going to work too well anyway if PropellerIDE is ever going to be used in other languages, or if Spin code itself is to be displayed correctly by different editors.
Consequently, I am dropping support for the Parallax font as the default font, and using the platform-native monospace fonts instead in the next release.
That may be going a bit too far, Brett, since it breaks compatibility with extant OBEX objects. And, yes, the schematic stuff IS important. I would rather see you default to the earlier Parallax font, warts and all, until Parallax2.ttf can be perfected. After all, we've lived with it for eight years with only mninor annoyances. Again, please consider the Propeller Tool as a minimum baselne for features and performance and build from there.
Phil,
I can't really agree that PropellerIDE should have every feature PropTool has as a baseline. I think that if you really want PropTool exactly, then just use PropTool and live with it's limitation of only being on windows.
Relying on a special font for source code comment features (i.e. schematics in the source file) is really a bad idea in the overall scheme of things. It's a neat idea, and handy to be sure, but it's not sustainable long term. It would be better to use Unicode standard glyphs only.
I'd be more in favor of a feature that provided that same end result without using a custom font. For example, have an embedded image link in a comment, that the IDE could display inline. The image file can then be included in the zip along with the source when uploading to obex or wherever. Then, even if your editor doesn't support the feature, you can just open the image file. Perhaps this isn't the best idea, but something along these lines maybe?
There are others of your "pet" features that are less likely to be done as well. Like compiling unsaved source files from an editor tab.
Anyway, Brett's the one in charge of PropellerIDE, so what I say doesn't matter. Just left like I should express my opinion here, because you are expressing yours.
Sorry, Roy, but I must respectfully disagree. If PropIDE is the designated replacement for PropTool, it has to be an upgrade, not a downgrade. I do not see how the two IDEs can co-exist in the long run, and that means that PropTool must become abandonware. What remains has to be at least as capable as what it replaces.
I do like the idea of being able to embed image files in the source code, though. In fact it's something I've considered adding to the autodocumenter in the form of an inline base64 encoding. When the autodocumented code is rendered in HTML, the images would then show up.
Well, you're just watching a motion picture. PropellerIDE will become a side-by-side official Parallax offering in time. Many features will be ported to PropellerIDE in time, but some won't.
The Parallax font has proven to be a significant issue for developers outside of our controlled Windows environment. Truthfully, it's been a bit of a struggle since the beginning. I estimate we've spent over 2,500 engineering hours designing and managing issues around this font, if not far more. For whatever reasons [which can be explained by the various IDE experts around here] this font can't display properly on non-Windows systems. There comes a point what economists call "diminishing returns" when we receive no appreciable gain for our engineering investment. When that time comes, decisions have to be made. We can complain about the loss of schematic views from OBEX, but this issue can also hold us back if it's an absolute requirement. If it's an absolute requirement for PropellerIDE then we may have no PropellerIDE for Mac or other systems, or one that has a funny-looking font as we force the Parallax font to display properly.
We're paying for PropellerIDE improvements, so you know. There are things we will pay for happily, and things we won't pay for.
I'm not about to support a Mac-pretty development of the Parallax font, just so everybody knows.
Sometimes the legacy issues feel like we're driving a car in reverse, looking in the rear-view mirror to go down the road.
Phil & Roy,
Since you are discussing PropTool vs PropellerIDE compatibility, there are 2 points mentioned here...
1. Propeller Font
I agree that it should be continued to be supported, warts and all. There a quite a number of objects where the font is used to describe schematics for the objects connection. I use this often and think it was a fantastic idea of Chips'. Perhaps there is a way to fix the warts, but please don't discard it.
2. Compiling unsaved source files
I do this all the time. After changes to the source I compile, load to ram, and test. Sometimes I just do too many changes and severely mess something up. When I do this, I revert to the old saved source. I also save versions often so I can backtrack if required, but sometimes (particularly after an interruption) I just mess the code too much between saves.
I'm not seeing a big issue here, as I read it the Parallax font is going to be available, just not the default, as it causes porting issues.Anyone that really wants it, can get at it.
We can complain about the loss of schematic views from OBEX, but this issue can also hold us back if it's an absolute requirement. If it's an absolute requirement for PropellerIDE then we may have no PropellerIDE for Mac or other systems, or one that has a funny-looking font as we force the Parallax font to display properly.
If someone really wants to convey critical info via a font, surely you can always generate a PDF (embedded font), and let Acrobat manage the rendering on differing systems ?
For more portable users, you can give them a url of an ASCII schematic pgm
Andreas Weber has AAcircuit - all this needs is a fixed font, like Courier. Done. http://www.tech-chat.de/download.html
That means the long term, niche aspect of Prop Font would simply fade away.
2. Compiling unsaved source files
I do this all the time. After changes to the source I compile, load to ram, and test. Sometimes I just do too many changes and severely mess something up. When I do this, I revert to the old saved source. I also save versions often so I can backtrack if required, but sometimes (particularly after an interruption) I just mess the code too much between saves.
That's a sightly unusual usage, as most modern compilers need a file on disk.
You can of course, name that anything you like and so insulate some original, & the Text editor I use has undo across saves, so the way I handle this is
a) for large changes, I save-as, as use a new name
b) for small changes, or the odd blind alley / interruption, I use the editor undo to recover.
Phil,
Being "as capable" doesn't mean replicates ever last feature. Especially in the case of an IDE/editor/compiler. They both will allow you to edit and compile Spin/PASM code for the Propeller. They both will provide all the normal IDE like stuff.
PropellerIDE already has several features that PropTool lacks. So just because PropellerIDE might not have some of PropTool's features that are not critical to it's primary job, you are saying that it will be inferior. I call BS. I would say that right now it's far superior PropTool in some ways, especially on non-Windows platforms.
As for dealing with the existing spin files with schematics (or whatever in them) that use the special characters in the Parallax font, perhaps someone can come up with a handy tool to render those schematics into and image to be embedded/sidecar'd or maybe even make an appropriate approximation of them from standard unicode glyphs. We don't have to force something one way, if there might be solutions that work more widely.
Also, I think PropellerIDE is going to serve and appeal to a wider audience than just the existing PropHeads that are fine with PropTool and it's oddities.
As long as the charset used is UTF-8 and not UTF-16 (or 'Little-endian UTF-16' as 'file' tells me) then I'm ok. The UTF-16 charset is not compatible with software version control systems (e.g. Git). Can't use "diff" on UTF-16, for example. Then use whatever UTF-8-compatible font you prefer.
Here's the thing: Spin, PASM, PropTool and the Prop1 architecture are all integral facets of that jewel of Chip's singular vision. The Parallax font, since it exists both in the IDE and in the Prop's ROM, is just one example of the cohesiveness of that vision. Granted, there are many departures in this system from mainstream thinking (e.g. => instead of >=). But those departures do not detract from the integrity of that beautifully self-contained whole. What I would hope for the PropIDE effort is that Chip's original vision remain intact, and that any effort to make the toolchain more mainstream not compromise the integrity of that vision by chipping at its foundations.
Comments
-Phil
-Phil
Hmm, it's possible that your Parallax font is not being found by PropellerIDE and Mac OS X is giving you a replacement font in its place. It might be why you are seeing less-than-good font display in the Editor as well. If you run the Mac Font Book app, does it contain your Parallax & Parallax2 fonts? Might be a system error rather than an error of PropellerIDE...
dgately
-Phil
The app includes the font but doesn't "install" it at this point. Something for the bug tracker. As a workaround If you do download the font and double-click on it, the OS will install it!
I'm sure this will get diagnosed before final release...
dgately
Thanks!
-Phil
Good that the "workaround" is helping. Hopefully, a future PropellerIDE version will auto-install the font. The Parallax2 font as far as I can tell just adds a bold variant of the font so the OS does not need to create a bold version of the font on-the-fly from the regular font. Usually means you get a much cleaner bold effect as the bold font is created by a font artist rather than a computed bold.
dgately
If somebody is reading this thread and collecting bugs, otherwise you're barking in the wind.
I asked Jeff and Brett to comb this thread for issues and enter them in the issue tracker.
Ken Gracey
On the upside, though, just posting on LameStation would never incite a broad spectrum of users to try and replicate the stuff I've had trouble with, since fewer people go there.
-Phil
-Phil
Most modern USB Bridge parts allow more granular Baud (typ 12MHz/N)
In another thread someone tested incremental Baud on a typical RC Osc Prop, reporting this typical value
["238,000 baud is consistent loading maxed out binaries. 250,000 is consistent for small files."]
(ROM loader Autobauds using the RC osc, & RC osc varies but will be above the corner case 115200 meets)
I'm guessing that this timing change might be the reason that PropellerIDE doesn't seem to work with any other USB devices except FTDI.
Hoping to get some scope pictures today to see what's happening.
Well, as Jazzed explained up there in post #60, the CP1202 serial chip needs an RTS versus DTR for the required reset... SimpleIDE allows a configuration change to RTS or CFG for non-FTDI serial chips. PropellerIDE may need to add the ability to re-config that option, as well.
dgately
I'm using CP2102's (4D systems uUSB-MB5 modules) on a few boards with DTR as the reset. They all program fine using Propeller Tool. No RTS connected.
Certainly, any IDE should allow user selection of the control line used. (as well as full control of the Baud rate)
CP210x can support both RTS and DTR, but the problem is not all Modules give access to both pins.
To complicate this, parts like CP2105 have a default shipping state that does not enable all handshake lines.
On CP2105 RTS is always enabled, but DTR is a user-config option (and an OTP one)
.
Short answer: Just support both handshake lines.
See my post above - CP2102 silicon supports both handshake lines, but not all modules bring them out, and some CP210x parts (eg CP2105) decide to ship with DTR instead optioned as GPIO (not the way I would have chosen default on a UART-Bridge device). RTS has no option, it always is enabled as RTS.
As I stated above, ALL of these modules have DTR connected as the reset with no additional configuration required.
Propeller Tool works perfectly with this module. Maybe for other variants dual handshake changes need to be added but NOT with this module.
How does the Baud rates, and char-char spacings, & time from DTR->Data compare ?
Any figures on the actual speedup mentioned in #71 ?
As far as I know, Parallax2 addresses some of the problems the original Parallax font had with Unicode support, among other things. However, both fonts are still buggy and behave strangely when used on various platforms.
Consequently, I am dropping support for the Parallax font as the default font, and using the platform-native monospace fonts instead in the next release.
This will break any of the special schematic characters that the Parallax font adds. However, these aren't going to work too well anyway if PropellerIDE is ever going to be used in other languages, or if Spin code itself is to be displayed correctly by different editors.
That may be going a bit too far, Brett, since it breaks compatibility with extant OBEX objects. And, yes, the schematic stuff IS important. I would rather see you default to the earlier Parallax font, warts and all, until Parallax2.ttf can be perfected. After all, we've lived with it for eight years with only mninor annoyances. Again, please consider the Propeller Tool as a minimum baselne for features and performance and build from there.
-Phil
I can't really agree that PropellerIDE should have every feature PropTool has as a baseline. I think that if you really want PropTool exactly, then just use PropTool and live with it's limitation of only being on windows.
Relying on a special font for source code comment features (i.e. schematics in the source file) is really a bad idea in the overall scheme of things. It's a neat idea, and handy to be sure, but it's not sustainable long term. It would be better to use Unicode standard glyphs only.
I'd be more in favor of a feature that provided that same end result without using a custom font. For example, have an embedded image link in a comment, that the IDE could display inline. The image file can then be included in the zip along with the source when uploading to obex or wherever. Then, even if your editor doesn't support the feature, you can just open the image file. Perhaps this isn't the best idea, but something along these lines maybe?
There are others of your "pet" features that are less likely to be done as well. Like compiling unsaved source files from an editor tab.
Anyway, Brett's the one in charge of PropellerIDE, so what I say doesn't matter. Just left like I should express my opinion here, because you are expressing yours.
Roy
I do like the idea of being able to embed image files in the source code, though. In fact it's something I've considered adding to the autodocumenter in the form of an inline base64 encoding. When the autodocumented code is rendered in HTML, the images would then show up.
-Phil
The Parallax font has proven to be a significant issue for developers outside of our controlled Windows environment. Truthfully, it's been a bit of a struggle since the beginning. I estimate we've spent over 2,500 engineering hours designing and managing issues around this font, if not far more. For whatever reasons [which can be explained by the various IDE experts around here] this font can't display properly on non-Windows systems. There comes a point what economists call "diminishing returns" when we receive no appreciable gain for our engineering investment. When that time comes, decisions have to be made. We can complain about the loss of schematic views from OBEX, but this issue can also hold us back if it's an absolute requirement. If it's an absolute requirement for PropellerIDE then we may have no PropellerIDE for Mac or other systems, or one that has a funny-looking font as we force the Parallax font to display properly.
We're paying for PropellerIDE improvements, so you know. There are things we will pay for happily, and things we won't pay for.
I'm not about to support a Mac-pretty development of the Parallax font, just so everybody knows.
Sometimes the legacy issues feel like we're driving a car in reverse, looking in the rear-view mirror to go down the road.
Ken Gracey
Since you are discussing PropTool vs PropellerIDE compatibility, there are 2 points mentioned here...
1. Propeller Font
I agree that it should be continued to be supported, warts and all. There a quite a number of objects where the font is used to describe schematics for the objects connection. I use this often and think it was a fantastic idea of Chips'. Perhaps there is a way to fix the warts, but please don't discard it.
2. Compiling unsaved source files
I do this all the time. After changes to the source I compile, load to ram, and test. Sometimes I just do too many changes and severely mess something up. When I do this, I revert to the old saved source. I also save versions often so I can backtrack if required, but sometimes (particularly after an interruption) I just mess the code too much between saves.
If someone really wants to convey critical info via a font, surely you can always generate a PDF (embedded font), and let Acrobat manage the rendering on differing systems ?
For more portable users, you can give them a url of an ASCII schematic pgm
Andreas Weber has AAcircuit - all this needs is a fixed font, like Courier. Done.
http://www.tech-chat.de/download.html
That means the long term, niche aspect of Prop Font would simply fade away.
You can of course, name that anything you like and so insulate some original, & the Text editor I use has undo across saves, so the way I handle this is
a) for large changes, I save-as, as use a new name
b) for small changes, or the odd blind alley / interruption, I use the editor undo to recover.
Being "as capable" doesn't mean replicates ever last feature. Especially in the case of an IDE/editor/compiler. They both will allow you to edit and compile Spin/PASM code for the Propeller. They both will provide all the normal IDE like stuff.
PropellerIDE already has several features that PropTool lacks. So just because PropellerIDE might not have some of PropTool's features that are not critical to it's primary job, you are saying that it will be inferior. I call BS. I would say that right now it's far superior PropTool in some ways, especially on non-Windows platforms.
As for dealing with the existing spin files with schematics (or whatever in them) that use the special characters in the Parallax font, perhaps someone can come up with a handy tool to render those schematics into and image to be embedded/sidecar'd or maybe even make an appropriate approximation of them from standard unicode glyphs. We don't have to force something one way, if there might be solutions that work more widely.
Also, I think PropellerIDE is going to serve and appeal to a wider audience than just the existing PropHeads that are fine with PropTool and it's oddities.
-Phil