Again, I really appreciate that you've done this -- I just have to catch up on my knowledge of C so that I can translate the dozens of Spin objects I have, and it a way that makes sense to the C community.
Q: Would it be possible to add a tab size to the properties dialog? I find four spaces per tab a bit unwieldy for my liking. I would love to use two.
Again, I really appreciate that you've done this -- I just have to catch up on my knowledge of C so that I can translate the dozens of Spin objects I have, and it a way that makes sense to the C community.
Q: Would it be possible to add a tab size to the properties dialog? I find four spaces per tab a bit unwieldy for my liking. I would love to use two.
Hi Jon, I was thinking about adding a tabbed pane to the properties dialog for this and other things. The IDE converts all tabs to 4 spaces now. Please use the space bar for less than 4 spaces until I have time to add this. Some other issues like the terminal problem are a higher priority at the moment.
This version mainly fixes the loader hang that everyone has seen. Here is the fixed issue list.
1
Defect
IDE stalls while loader running. Performance
5
Enhanc
User requests number of bytes for image size.
6
Defect
Compiler properties dialog title wrong
8
Defect
Some syntax highlighting
12
Defect
"New" then "Save" file doesn't work.
Please verify these issues are fixed so I can close them.
I'm still having trouble with the serial port close eating CPU.
If you see the CPU usage jump just click the connect button twice.
This is a big problem, and I'm considering a different approach to fix it.
@JonnyMac, Glad to see the IDE is helpful. I'm anxious to help with any questions.
Thanks,
--Steve
Steve I tested this version 0_3_4 on my Win 7 i7 6G machine. Install went without incident. Tested hello.c on Protoboard, Spin Stamp, Quickstart board. Worked just fine showing results in terminal. Loaded very quickly. Defects 1, 6, 12 were fixed for me. Never noticed defect 8 and enhancement 5 worked as well.
Like Jon I had issues with the terminal. When I clicked OK or used the red X to close it down it didn't close all the way. By this I mean the window disappeared, but the terminal button remained in the down position and stopped tool tips from showing and when I clicked a menu item an outline of the drop down menu would show but nothing in it. If I moved the mouse to an adjacent menu item the menu would show correctly. If I moved back to the original selected menu item then it would show correctly. When I closed and restarted SIDE the menu and tooltips worked just fine, but I hadn't used the terminal. Just had an idea. Will see if the terminal close from this error state if I unplug the board.
Also if I opened a new file and saved it it didn't appear in the recently opened file area on the File menu.
Hope this helps and I will continue to learn and work with SIDE and C programing.
Just tried building the hello.c by changing Memory Mode from Cog to LMM. The program size went from 1,960 to 14,352. That's almost half of the available Hub ram correct? Am I doing something wrong? Do I have something wrong in my numbers or my understanding of how LMM works. 14,352 seems like a lot of bytes for a simple program.
Thanks for your very detailed report above. I especially appreciate your verifying bug fixes.
I'm still slogging away at the terminal close CPU hog issue. I figured out why some characters
are missing from the terminal and I could post a SimpleIDE.exe update here if that would help.
You can select the Simple Printf option in the IDE to get a smaller image from GCC.
We are using a standard C library compliant and thread safe printf by default. That takes a lot of code.
The Simple Printf option is not fully compliant and not thread safe.
The limits of Simple Printf are described here: http://propgcc.googlecode.com/hg/doc/Library.html#printf
We can always use the Spin-like functions for printing and they do save code memory to a point.
Just tried building the hello.c by changing Memory Mode from Cog to LMM. The program size went from 1,960 to 14,352. That's almost half of the available Hub ram correct? Am I doing something wrong? Do I have something wrong in my numbers or my understanding of how LMM works. 14,352 seems like a lot of bytes for a simple program.
Just tried building the hello.c by changing Memory Mode from Cog to LMM. The program size went from 1,960 to 14,352. That's almost half of the available Hub ram correct? Am I doing something wrong? Do I have something wrong in my numbers or my understanding of how LMM works. 14,352 seems like a lot of bytes for a simple program.
Tony
As Steve mentioned, compiling with Simple Printf saves a bunch of space (it should reduce the code size from about 14K to about 8K). Considering the 2.5K minimum overhead for the LMM kernel and C runtime, the extra overhead of of 5.5K for basic a printf still seems like a lot, especially if you're not using all the bells and whistles of printf.
You can get the overhead down to about 1K by using an even simpler (though still not thread-safe) printf(). Here is the trick:
The library code up on Google (at http://code.google.com/p/propgcc/source/browse/lib/cog) contains two C source files that don't seem to be included in the library: cogserial.c and miniprintf.c. Grab the code from inside these files and combine it to form two new files:
tinyprintf.h:
extern unsigned int _rxpin;
extern unsigned int _txpin;
extern unsigned int _baud;
int printf(const char *fmt, ...);
tinyprintf.c
/*
* very simple printf, adapted from one written by me
* for the MiNT OS long ago
* placed in the public domain
* - Eric Smith
*/
#include <stdarg.h>
#include <cog.h>
#include "tinyprintf.h"
#define _WaitCnt(a,b) __builtin_propeller_waitcnt(a,b)
/* globals that the loader may change; these represent the default
* pins to use
*/
unsigned int _rxpin = 31;
unsigned int _txpin = 30;
unsigned int _baud = 115200;
unsigned int _bitcycles;
int putchar(int origval)
{
int value = origval;
int i;
int txmask = (1<<_txpin);
int bitcycles;
int waitcycles;
if (origval == '\n')
putchar('\r');
_DIRA |= txmask;
_OUTA |= txmask;
if (_bitcycles == 0)
_bitcycles = _clkfreq / _baud;
bitcycles = _bitcycles;
waitcycles = _CNT + bitcycles;
value = (value | 256) << 1;
for (i = 0; i < 10; i++)
{
waitcycles = _WaitCnt(waitcycles, bitcycles);
if (value & 1)
_OUTA |= txmask;
else
_OUTA &= ~txmask;
value >>= 1;
}
return origval;
}
/*
* very simple printf -- just understands a few format features
*/
static int
PUTC(int c) {
putchar(c);
return 1;
}
static int
PUTS(const char *s) {
int r = 0;
while (*s) {
putchar(*s++);
r++;
}
return r;
}
static int
PUTL(unsigned long u, int base, int width, int fill_char)
{
int r = 0;
static char obuf[32];
char *t;
t = obuf;
do {
*t++ = "0123456789abcdef"[u % base];
u /= base;
width--;
} while (u > 0);
while (width-- > 0) {
putchar(fill_char);
r++;
}
while (t != obuf) {
putchar(*--t);
r++;
}
return r;
}
static int
_doprnt( const char *fmt, va_list args )
{
char c, fill_char;
char *s_arg;
int i_arg;
long l_arg;
int width;
int outbytes = 0;
while( (c = *fmt++) != 0 ) {
if (c != '%') {
outbytes += PUTC(c);
continue;
}
c = *fmt++;
width = 0;
fill_char = ' ';
if (c == '0') fill_char = '0';
while (c && isdigit(c)) {
width = 10*width + (c-'0');
c = *fmt++;
}
if (!c) break;
switch (c) {
case '%':
outbytes += PUTC(c);
break;
case 'c':
i_arg = va_arg(args, int);
outbytes += PUTC(i_arg);
break;
case 's':
s_arg = va_arg(args, char *);
outbytes += PUTS(s_arg);
break;
case 'd':
case 'u':
l_arg = va_arg(args, int);
if (l_arg < 0 && c == 'd') {
outbytes += PUTC('-');
width--;
l_arg = -l_arg;
}
outbytes += PUTL(l_arg, 10, width, fill_char);
break;
case 'x':
l_arg = va_arg(args, unsigned int);
outbytes += PUTL(l_arg, 16, width, fill_char);
break;
}
}
return outbytes;
}
int printf(const char *fmt, ...)
{
va_list args;
int r;
va_start(args, fmt);
r = _doprnt(fmt, args);
va_end(args);
return r;
}
Add these files to your project, and change your #include <stdio.h> to #include "tinyprintf.h". A simple "Hello World" program should now be just about 3.5K, which seems much more reasonable!
Thanks denominator for the ideas. Since I'm new to using C I was hoping there was another way to print that didn't use so much of the memory resources.
I've been testing a new SimpleIDE.exe for windows. It has several enhancements.
The biggest improvements are in compile-time and load time IDE performance.
This should fix the problem where the terminal can leave the program running on exit.
A small compromise comes though for slower machines like my netbook.
That is if you click Play and the terminal window appears and the output is very fast
it is possible that the window will stall for a moment if you try to drag it around.
I've added an Enable/Disable button to the terminal. Clicking it when it says Disable
will disconnect the terminal but it will not reset the Propeller board.
I'm not ready to upload a new package yet. It would be very useful for everyone to test
this SimpleIDE.exe by copying it to your C:\Program Files\SimpleIDE\bin folder.
The program does not include several of the other requested improvements.
This SimpleIDE.exe should solve many hang problems for people who have already
installed the 72MB package. Please test it when you can.
In general, the new version seems to be working much better. But, a couple of problems, I tried the keyboard program, in COG mode it works as expected. In LMM mode, their is no improvement, still have to press at least four keypresses before it comes up on the screen.
So, I am not sure if this is still a problem with the terminal, or something has to be changed in the keyboard program.
The other problem, my perception, when you close a file, using the X tab, and save a new file which you just started, the save part works great, but does not create an .side file. Even using F4, and Set Project has no affect, you have to close the file, and then reopen it, at which point the project gets created. It seems like a lot of extra steps to get an .side file.
Let me know if you need Linux or OS X guinea pigs.
I have Steve's IDE mostly working under Mac OS X. There are some issues with paths because the Mac OS doesn't display the /opt directory in its file browser but that's not really a SimpleIDE problem as much as a Mac installation problem. I think we'll probably have to move the GCC install to /Applications/Parallax rather than /opt on the Mac.
@Jazzed,
I just had a chance to try he new executable and it is much faster at compiling (has not stalled yet). I was finally able to build vgademo without having to use propeller-elf-gcc.exe on the command line. Also, I really appreciate it showing the bytes compiled. Thanks!
The serial window seems to work better as well. A few things that might be nice in the serial window:
Baud Rate Select
DTR/RTS options, Parity, etc.
Echo toggle (on/off)
Ability to save a log file
..those are not at all critical, considering that tools like PST (or HyperTerminal if non Win7, etc.) could be used for that sort of thing. If it is like other IDE's with a serial terminal built-in it is for quick verification (or simple serial demos).
@Jazzed,
I just had a chance to try he new executable and it is much faster at compiling (has not stalled yet). I was finally able to build vgademo without having to use propeller-elf-gcc.exe on the command line. Also, I really appreciate it showing the bytes compiled. Thanks! ....
Excellent! I'm glad this is working out better for you and everyone else so far.
"SimpleIDE" for the user should mean very few adjustments if any. It should just work "as is" out of the box.
However, I understand the compulsion to be more generic and have planned an advanced button for preferences similar to PST. Baud rate and other items will be in the dialog rather than cluttering the terminal. There will not be any concept of wait for port to be available before connecting. I'll probably change Disable/Enable to a graphic Connected/Disconnected button. Most likely I'll add a "power reset switch" graphic that toggles DTR.
Achieving stability is the most important factor right now.
However, I understand the compulsion to be more generic and have planned an advanced button for preferences similar to PST. Baud rate and other items will be in the dialog rather than cluttering the terminal. There will not be any concept of wait for port to be available before connecting. I'll probably change Disable/Enable to a graphic Connected/Disconnected button. Most likely I'll add a "power reset switch" graphic that toggles DTR.
Achieving stability is the most important factor right now.
Right on! Definately focus on stability, and your "target platform" (PropBOE ?) first. SCOPE CREEP BAD!
Provided that all of the example code matches the default baud rate and that you are using it communicate with the device you are programming (a safe assumption) you do not need to support serial port selection, or baud rate selection. Those sorts of things could easily be relegated to configuration (if they are even added at all).
If you didn't want to increase the complexity of the serial monitor in the code, you could (eventually) add the ability to launch an external serial terminal/monitor instead of the built-in terminal and save having to build/support that sort of functionality (as part of advanced settings).
I got tired of opening another editor for Find/Replace and there was a request. So, the new .exe adds a find/replace feature: see Menu->Edit->Find Replace or Ctrl-R.Currently find is case insensitive and will replace any text. Will add case and word only later.
I've also made Find Ctrl-F pick up any highlighted word and put it into the find text box.Find/Replace has more power than find.As always please point out any problems.
Thanks,
--Steve
Notes:
1. You must have previously installed a package to use the .exe. I'm cleaning up some old copies now to save bytes.
2. The COGID highlight is doctored since print-screen didn't capture it.
The other problem, my perception, when you close a file, using the X tab, and save a new file which you just started, the save part works great, but does not create an .side file. Even using F4, and Set Project has no affect, you have to close the file, and then reopen it, at which point the project gets created. It seems like a lot of extra steps to get an .side file.
Ray, I'm looking into this. I'll be adding some real project manager stuff (Project New, Open, Save, Recent, etc...), so most of these concerns will go away.
Not sure if this is already mentioned or not but I keep running into a bug where when I open and close the Serial terminal after downloading a program to the Prop, the IDE seems to go into 'super-slow-mo' and menus don't work. When I check processes then the IDE will be eating my CPU. I have to kill the process and start over. Seems to happen pretty frequently.
I'm using a Netbook with 2G Ram and Win7 32bit.
Otherwise I'm pretty elated to see my prop running C++ code!
Not sure if this is already mentioned or not but I keep running into a bug where when I open and close the Serial terminal after downloading a program to the Prop, the IDE seems to go into 'super-slow-mo' and menus don't work. When I check processes then the IDE will be eating my CPU. I have to kill the process and start over. Seems to happen pretty frequently.
I'm using a Netbook with 2G Ram and Win7 32bit.
Otherwise I'm pretty elated to see my prop running C++ code!
Hi photomankc.
Do you see this behavior with the SimpleIDE.exe posted above in message #82? The .exe in the 72MB package is less reliable.
Kyle,
Do you happen to have the exact steps to re-create this issue? I used a normal Propeller Proto Board for testing this.
I tried:
1) Open "SimpleIDE.exe"
2) Select "File...Open" and selected "hello\hello.side" from the "Open File Dialog"
3) Selected the "Run" icon. (application compiled and uploaded)
4) Selected the "Port Status" icon
5) (watched the terminal for a bit) Selected the red "X" at the top (without using "Clear," "Disable," or "OK" in the window)
...and did not have a slowness issue, even after repeating the process several times. If you have Process Explorer installed, you might try running that and see which process(es) are taking up time on your machine. If there is a specific path through the application/pattern that is triggering this, and it can be narrowed down, I am sure it will help Jazzed with the issue.
I'll try to get that for you all. I've just bumped into in putzing around with it so I was not focused on repeating it. I'll see if can make it happen again and give you the steps involved when it happens and dig a little deeper into what it's doing.
I'll try to get that for you all. I've just bumped into in putzing around with it so I was not focused on repeating it. I'll see if can make it happen again and give you the steps involved when it happens and dig a little deeper into what it's doing.
I think all one needs to do is open the hello demo (one that repeats printing hello world number), then click the blue debug button or F8. The terminal is the main issue. I had to trade the possibility of a zombie program (responsive until dead, then eating brain/CPU time) for a somewhat CPU hogging non-zombie. I'll see what I can do - this is a key problem.
I've used it on my 1.6GHz Atom, 1GB RAM, WinXP Netbook (and other machines).
It's working much, much better for me now.
Try this program first and then see how it works as you reduce the waitcnt time.
/*
* This demo uses waitcnt instead of sleep so it will fit in a COG.
* It also repeats printing every 200ms and prints the iteration.
* Some computers may not be fast enough for the terminal to catch
* the serial input after loading the Propeller, so you may not see
* "Hello World 1", but you will see something on the terminal.
*/
#include <stdio.h>
#include <propeller.h>
int main(void)
{
int n = 1;
while(1) {
waitcnt(CLKFREQ/5+CNT);
//waitcnt(CLKFREQ/50+CNT); // faster
//waitcnt(CLKFREQ/500+CNT); // murderous
printf("Hello World %d\n", n);
n++;
}
return 0;
}
Comments
Do you have google+ or yahoo messenger? It would be easier to resolve this via chat. Send me a PM.
Again, I really appreciate that you've done this -- I just have to catch up on my knowledge of C so that I can translate the dozens of Spin objects I have, and it a way that makes sense to the C community.
Q: Would it be possible to add a tab size to the properties dialog? I find four spaces per tab a bit unwieldy for my liking. I would love to use two.
Hi Jon, I was thinking about adding a tabbed pane to the properties dialog for this and other things. The IDE converts all tabs to 4 spaces now. Please use the space bar for less than 4 spaces until I have time to add this. Some other issues like the terminal problem are a higher priority at the moment.
Steve I tested this version 0_3_4 on my Win 7 i7 6G machine. Install went without incident. Tested hello.c on Protoboard, Spin Stamp, Quickstart board. Worked just fine showing results in terminal. Loaded very quickly. Defects 1, 6, 12 were fixed for me. Never noticed defect 8 and enhancement 5 worked as well.
Like Jon I had issues with the terminal. When I clicked OK or used the red X to close it down it didn't close all the way. By this I mean the window disappeared, but the terminal button remained in the down position and stopped tool tips from showing and when I clicked a menu item an outline of the drop down menu would show but nothing in it. If I moved the mouse to an adjacent menu item the menu would show correctly. If I moved back to the original selected menu item then it would show correctly. When I closed and restarted SIDE the menu and tooltips worked just fine, but I hadn't used the terminal. Just had an idea. Will see if the terminal close from this error state if I unplug the board.
Also if I opened a new file and saved it it didn't appear in the recently opened file area on the File menu.
Hope this helps and I will continue to learn and work with SIDE and C programing.
Thanks for the work!
Tony
Just tried building the hello.c by changing Memory Mode from Cog to LMM. The program size went from 1,960 to 14,352. That's almost half of the available Hub ram correct? Am I doing something wrong? Do I have something wrong in my numbers or my understanding of how LMM works. 14,352 seems like a lot of bytes for a simple program.
Tony
Thanks for your very detailed report above. I especially appreciate your verifying bug fixes.
I'm still slogging away at the terminal close CPU hog issue. I figured out why some characters
are missing from the terminal and I could post a SimpleIDE.exe update here if that would help.
You can select the Simple Printf option in the IDE to get a smaller image from GCC.
We are using a standard C library compliant and thread safe printf by default. That takes a lot of code.
The Simple Printf option is not fully compliant and not thread safe.
The limits of Simple Printf are described here: http://propgcc.googlecode.com/hg/doc/Library.html#printf
We can always use the Spin-like functions for printing and they do save code memory to a point.
Hope this helps.
--Steve
As Steve mentioned, compiling with Simple Printf saves a bunch of space (it should reduce the code size from about 14K to about 8K). Considering the 2.5K minimum overhead for the LMM kernel and C runtime, the extra overhead of of 5.5K for basic a printf still seems like a lot, especially if you're not using all the bells and whistles of printf.
You can get the overhead down to about 1K by using an even simpler (though still not thread-safe) printf(). Here is the trick:
The library code up on Google (at http://code.google.com/p/propgcc/source/browse/lib/cog) contains two C source files that don't seem to be included in the library: cogserial.c and miniprintf.c. Grab the code from inside these files and combine it to form two new files:
tinyprintf.h:
tinyprintf.c
/* * very simple printf, adapted from one written by me * for the MiNT OS long ago * placed in the public domain * - Eric Smith */ #include <stdarg.h> #include <cog.h> #include "tinyprintf.h" #define _WaitCnt(a,b) __builtin_propeller_waitcnt(a,b) /* globals that the loader may change; these represent the default * pins to use */ unsigned int _rxpin = 31; unsigned int _txpin = 30; unsigned int _baud = 115200; unsigned int _bitcycles; int putchar(int origval) { int value = origval; int i; int txmask = (1<<_txpin); int bitcycles; int waitcycles; if (origval == '\n') putchar('\r'); _DIRA |= txmask; _OUTA |= txmask; if (_bitcycles == 0) _bitcycles = _clkfreq / _baud; bitcycles = _bitcycles; waitcycles = _CNT + bitcycles; value = (value | 256) << 1; for (i = 0; i < 10; i++) { waitcycles = _WaitCnt(waitcycles, bitcycles); if (value & 1) _OUTA |= txmask; else _OUTA &= ~txmask; value >>= 1; } return origval; } /* * very simple printf -- just understands a few format features */ static int PUTC(int c) { putchar(c); return 1; } static int PUTS(const char *s) { int r = 0; while (*s) { putchar(*s++); r++; } return r; } static int PUTL(unsigned long u, int base, int width, int fill_char) { int r = 0; static char obuf[32]; char *t; t = obuf; do { *t++ = "0123456789abcdef"[u % base]; u /= base; width--; } while (u > 0); while (width-- > 0) { putchar(fill_char); r++; } while (t != obuf) { putchar(*--t); r++; } return r; } static int _doprnt( const char *fmt, va_list args ) { char c, fill_char; char *s_arg; int i_arg; long l_arg; int width; int outbytes = 0; while( (c = *fmt++) != 0 ) { if (c != '%') { outbytes += PUTC(c); continue; } c = *fmt++; width = 0; fill_char = ' '; if (c == '0') fill_char = '0'; while (c && isdigit(c)) { width = 10*width + (c-'0'); c = *fmt++; } if (!c) break; switch (c) { case '%': outbytes += PUTC(c); break; case 'c': i_arg = va_arg(args, int); outbytes += PUTC(i_arg); break; case 's': s_arg = va_arg(args, char *); outbytes += PUTS(s_arg); break; case 'd': case 'u': l_arg = va_arg(args, int); if (l_arg < 0 && c == 'd') { outbytes += PUTC('-'); width--; l_arg = -l_arg; } outbytes += PUTL(l_arg, 10, width, fill_char); break; case 'x': l_arg = va_arg(args, unsigned int); outbytes += PUTL(l_arg, 16, width, fill_char); break; } } return outbytes; } int printf(const char *fmt, ...) { va_list args; int r; va_start(args, fmt); r = _doprnt(fmt, args); va_end(args); return r; }Add these files to your project, and change your #include <stdio.h> to #include "tinyprintf.h". A simple "Hello World" program should now be just about 3.5K, which seems much more reasonable!
I've made good progress on the IDE serial troubles and compile time troubles too.
I'll make a release in the morning.
I'll post a zip on this thread for those who have Admin privileges to replace the main SimpleIDE.exe program.
That's pretty cool. :cool: I forgot about those. Thanks.
Tony
I've been testing a new SimpleIDE.exe for windows. It has several enhancements.
The biggest improvements are in compile-time and load time IDE performance.
This should fix the problem where the terminal can leave the program running on exit.
A small compromise comes though for slower machines like my netbook.
That is if you click Play and the terminal window appears and the output is very fast
it is possible that the window will stall for a moment if you try to drag it around.
I've added an Enable/Disable button to the terminal. Clicking it when it says Disable
will disconnect the terminal but it will not reset the Propeller board.
I'm not ready to upload a new package yet. It would be very useful for everyone to test
this SimpleIDE.exe by copying it to your C:\Program Files\SimpleIDE\bin folder.
The program does not include several of the other requested improvements.
This SimpleIDE.exe should solve many hang problems for people who have already
installed the 72MB package. Please test it when you can.
Thanks,
--Steve
Thanks for all the hard work, it's becoming a favorite tool.
Indeed. Those using the Arduino wanting to try the Propeller now have a tool that should work for them.
On another note (not C#!) ....
David reports his Mac was able to compile and download a toggle demo.
These are early results. Don't get too excited yet!
--Steve
Let me know if you need Linux or OS X guinea pigs.
So, I am not sure if this is still a problem with the terminal, or something has to be changed in the keyboard program.
The other problem, my perception, when you close a file, using the X tab, and save a new file which you just started, the save part works great, but does not create an .side file. Even using F4, and Set Project has no affect, you have to close the file, and then reopen it, at which point the project gets created. It seems like a lot of extra steps to get an .side file.
Ray
I just had a chance to try he new executable and it is much faster at compiling (has not stalled yet). I was finally able to build vgademo without having to use propeller-elf-gcc.exe on the command line. Also, I really appreciate it showing the bytes compiled. Thanks!
The serial window seems to work better as well. A few things that might be nice in the serial window:
Baud Rate Select
DTR/RTS options, Parity, etc.
Echo toggle (on/off)
Ability to save a log file
..those are not at all critical, considering that tools like PST (or HyperTerminal if non Win7, etc.) could be used for that sort of thing. If it is like other IDE's with a serial terminal built-in it is for quick verification (or simple serial demos).
Thanks for your hard work!
Excellent! I'm glad this is working out better for you and everyone else so far.
"SimpleIDE" for the user should mean very few adjustments if any. It should just work "as is" out of the box.
However, I understand the compulsion to be more generic and have planned an advanced button for preferences similar to PST. Baud rate and other items will be in the dialog rather than cluttering the terminal. There will not be any concept of wait for port to be available before connecting. I'll probably change Disable/Enable to a graphic Connected/Disconnected button. Most likely I'll add a "power reset switch" graphic that toggles DTR.
Achieving stability is the most important factor right now.
Thanks.
--Steve
Provided that all of the example code matches the default baud rate and that you are using it communicate with the device you are programming (a safe assumption) you do not need to support serial port selection, or baud rate selection. Those sorts of things could easily be relegated to configuration (if they are even added at all).
If you didn't want to increase the complexity of the serial monitor in the code, you could (eventually) add the ability to launch an external serial terminal/monitor instead of the built-in terminal and save having to build/support that sort of functionality (as part of advanced settings).
I got tired of opening another editor for Find/Replace and there was a request. So, the new .exe adds a find/replace feature: see Menu->Edit->Find Replace or Ctrl-R.Currently find is case insensitive and will replace any text. Will add case and word only later.
I've also made Find Ctrl-F pick up any highlighted word and put it into the find text box.Find/Replace has more power than find.As always please point out any problems.
Thanks,
--Steve
Notes:
1. You must have previously installed a package to use the .exe. I'm cleaning up some old copies now to save bytes.
2. The COGID highlight is doctored since print-screen didn't capture it.
You must have clicked on the Help->About link
Ray, I'm looking into this. I'll be adding some real project manager stuff (Project New, Open, Save, Recent, etc...), so most of these concerns will go away.
I'm using a Netbook with 2G Ram and Win7 32bit.
Otherwise I'm pretty elated to see my prop running C++ code!
Hi photomankc.
Do you see this behavior with the SimpleIDE.exe posted above in message #82? The .exe in the 72MB package is less reliable.
Thanks,
--Steve
Yes, I am using that version. I downloaded it and replaced the original EXE in the program 'bin' folder.
-Kyle
Do you happen to have the exact steps to re-create this issue? I used a normal Propeller Proto Board for testing this.
I tried:
1) Open "SimpleIDE.exe"
2) Select "File...Open" and selected "hello\hello.side" from the "Open File Dialog"
3) Selected the "Run" icon. (application compiled and uploaded)
4) Selected the "Port Status" icon
5) (watched the terminal for a bit) Selected the red "X" at the top (without using "Clear," "Disable," or "OK" in the window)
...and did not have a slowness issue, even after repeating the process several times. If you have Process Explorer installed, you might try running that and see which process(es) are taking up time on your machine. If there is a specific path through the application/pattern that is triggering this, and it can be narrowed down, I am sure it will help Jazzed with the issue.
Thanks,
--trodoss
I think all one needs to do is open the hello demo (one that repeats printing hello world number), then click the blue debug button or F8. The terminal is the main issue. I had to trade the possibility of a zombie program (responsive until dead, then eating brain/CPU time) for a somewhat CPU hogging non-zombie. I'll see what I can do - this is a key problem.
I've used it on my 1.6GHz Atom, 1GB RAM, WinXP Netbook (and other machines).
It's working much, much better for me now.
Try this program first and then see how it works as you reduce the waitcnt time.
/* * This demo uses waitcnt instead of sleep so it will fit in a COG. * It also repeats printing every 200ms and prints the iteration. * Some computers may not be fast enough for the terminal to catch * the serial input after loading the Propeller, so you may not see * "Hello World 1", but you will see something on the terminal. */ #include <stdio.h> #include <propeller.h> int main(void) { int n = 1; while(1) { waitcnt(CLKFREQ/5+CNT); //waitcnt(CLKFREQ/50+CNT); // faster //waitcnt(CLKFREQ/500+CNT); // murderous printf("Hello World %d\n", n); n++; } return 0; }Thanks,
--Steve
sometimes, murderous is hell!
Works well, now I need to try it on my Netbook.
Hi Rick! Thanks for the feedback - hope to have more before making yet another 72MB package.
I've been testing on my I7 and Netbook with waitcnt(CLKFREQ/5000+CNT); // redrum-helter-skelter
Don't move the window when it's so busy
I noticed Disable/Enable is broken and have a fix for it.