I apologize for taking your thread off track. I am done discussing OS's + GUI's unless you have a specific question you desire to ask me, at which point I will be happy to answer your questions.
You are right we have wondered a bit from the topic and it is Dave Hein's thread after all. So unless Dave is interested in a GUI for his simulator that's it.
I may well want to pick your brains re: windows one day:)
LOL I got confused there. It was actually Dave that I had some of these discussions with. Anyhow Dave, sorry for taking your thread off track, and Heater, just ask anytime.
Your discussion on IDEs and portability was very interesting. I've been programming for 40 years, but I've never done much GUI stuff. I learned quite a bit from your discussion. For me it looks like Qt is the way to go. I'm more comfortable with the programming style used in Qt versus the method used in Microsoft's MFC. The portability of Qt is perfect for developing an app that will work on multiple platforms.
I work mostly on Windows machines, but I have used Unix/Linux at work for the past 22 years. I have to admit that I very rarely use a GUI with Unix/Linux systems. I almost always use a command line interface with those platforms.
Oh good we are back on topic:) Anyway I'm glad to here something constructive came out of all that.
I'm kind of a command line guy as well, what with having a 100% Linux at work and home. But we do need GUIs for those schematics editors, PCB layout progs etc etc. I have even softened up and become addicted to syntax highlighting editors. The Qt IDE is a wonderful thing to use. Lets face it, you are no doubt reading this in a GUI.
There is another way to cross-platform bliss. One of my favourite programs is LTSpice from Linear Technology, draw your schematic, simulate it, look at the signals or spectra produced. It's a Windows program but it works perfectly under Linux using Wine. It's as if over the years and many versions Linear has always gone out their way to ensure LTSpice never uses any Windows features that are broken in Wine and will therefore run on Linux and BSD etc.
So someone like idbruce who is happy with Windows could still widen his audience and produce useful open source apps just by ensuring that his Windows code always works under Wine.
This is not my preferred solution as I'm sure it is more limiting than using Qt and besides any Linux users with a mind to help in development will be put of by having to look at Windows code.
Proteus looks excellent. However LTSpice is free for my amateur experiments with analog circuits. I can only dream of moving up to something more professional.
IDE programs are very useful. I have one for Catalina and it has sections for xmodem transfers, downloads, multiple compile options, color highlighting and a terminal. I don't think I could code without it. But it is .net and it is Windows. So if I were to recode this it would make a lot of sense to do it in a cross platform way.
One advantage would be the ability to share code - eg the terminal part would be very useful for others and that sort of code tends to be self contained.
As things evolve, one could envisage an open source GUI with Catalina, BCX basic, Big Spin all on separate tabs.
If Qt is free, that makes it very interesting. I really need to get the BCX Basic to C project finished so I can port over some of the vb.net code.
Addit - downloading Qt now.
Second Addit: @heater, that is a very nice program. Auto complete on a lot of code, auto indents, auto color insertion. And able to write and run a "Hello World" within a couple of minutes.
Playing around more with Qt, I found a great tutorial on how to build a rich text box with syntax highlighting. That will replace pages of vb.net code, plus ought to run a lot faster too.
@heater, I'm a little stuck with writing a "hello world" in the GUI. I've got a button on a form. In vb.net, if you double click on an object like a button, it flips to the code view and writes some of the code as well. Is there an equivalent way of doing this in Qt? I can't even find the 'code' view, though I am sure it is there.
Also @heater, maybe we might need a new thread for this discussion? I'm dreaming already of an IDE for Big Spin, Big C (Catalina), Spin Simulator and Big Basic, all rolled up in one program. But I don't want to hijack this thread here.
I uploaded SpinSim version 0.24 and attached it to the first post in this thread. The main additon in this version is support for simulating external memories. I added three new system functions to allocate up to four external memories, and to transfer blocks of data between the external memory and hub RAM. I also fixed a problem where SpinSim would exit after running 2 billion loops, and I removed some extra stuff I had in the debug listing. I added memtest.spin, extmem.spin and extmempasm.to go along with the external memory changes.
I uploaded SpinSim version 0.25 to the first post in this thread. I added a -c option to enforce cycle accuracy when running PASM code. This option ensures that hub accesses happen in the correct cycle for each cog. It also accounts for the extra instruction cycle for DJNZ, TJNZ and TJZ when the jump is not taken. The listing will show a "W" character for instrutions that are waiting for the hub access window or the jump pipeline to refill.
I also modified the used of the debug flag at location $12340008 so that debug prints can be turned on for specific cogs depending on the 8 least significant bits of the flag. This way the listing can be turned on and off by the code for each cog.
I'm glad that SpinSim was able to run your FFT program OK. The run time difference is because I use the host's sytem clock to generate the value for the CNT register. So your program took about 2.4 times longer in real time. I thought about using the loop count for the CNT register when the -c option is specified, but I didn't implement that. -m32 is the default, so you didn't need to specify that. The -p option determines whether the C or PASM Spin interpreter is used, so it doesn't have any effect on PASM code.
I really need to spend some time to write some documentation. It's also about time to start working on the GUI version.
I really need to spend some time to write some documentation. It's also about time to start working on the GUI version.
You going to try Qt? BigSpin needs an IDE too and it would be nice to find a way to get plugged in
VisualC# would be a very fast development that could be used until a Qt version can be made.
Trouble I'm having with Qt right now is all the manual coding required. VC# automates most of it.
It seems like Qt is the way to go. Maybe VC# would be easier. I don't have any experience with either one. It would be good to develop common pieces of open source that could be used for various applications.
I uploaded SpinSim 0.27 to the first post in this thread. This version fixes a few minor problems and it adds a serial port. The serial port allows SpinSim to execute code that that transmits and receives serial data on pins 31 and 30. I also added the test program, echo.spin that uses FullDuplexSerial to read a character and echo it back out. The serial port is enabled by setting the baud rate with the "-b" option. The echo program can be run by typing "spinsim echo.binary -b115200".
Recently I have been using Qt, you can get GUI apps up very quickly with it. Here is hello word for Qt:
Heater - No offense or disrespect intended (honestly), but I generally hate cross-platform GUI packages like this. In my personal experience, they result in programs that run equally badly across all platforms, instead of something that runs well on each. (I haven't tried BST yet - I probably should)
To elaborate slightly, most OS's have their own set of standard controls, which affect the functionality of them. In order to work on all systems, the cross-platform GUI systems often implement their own, and they're usually not as fast, have a different look & feel, use different hot-keys for things, and so on. In so doing, they require the user to abandon their familiar conventions and learn new ones, which generally makes the user experience suffer in comparison to something written that targets their platform.
I certainly understand the value of being able to get something to run on many systems in a short period of time, I just hate that they usually result in programs that feel slightly awkward.
I don't necessarily disagree with you. If you want to get the best out of any platform it's probably better to go native.
But I might ask who cares about that?
In my day to day computer usage I might have:
1) Firefox to read the Propeller forum
2) Qt Creator to hack on pretty much any C/C++ ideas comming along.
3) BST for Propeller work.
4) Eclipse, for Android and the "chip that shall remain" nameless work.
6) LtSpice for playing around with circuit simulations.
7) Eagle for the odd PCB experiment.
Most (all?) of these work fine accross Windows, Linux and Mac. Some of them are working just fine on non-intel platforms like ARM.
Do I really care that they don't have the look and feel of their native operating systems / window managers / style of the day interface?
No, I am happy that each one of them is pretty much operable in the same way no matter which OS I run it under. So, LtSpice looks and behaves the same everywhere as does QtCreator etc etc.
I guess it's just a question of personal preference but I'd rather have that choice of platform than worry about the finer details of each one.
As a practical matter, I we really supposed to write the same app in as many different toolkits as there are platforms?
I use the Prop tool and BST under Windows, and they provide almost an identical user interface. The appearance of the folders in the directory window does look slightly different, but it doesn't feel awkward. From a user's perspective, I don't think there's much difference whether the app was developed under Microsoft VS or Qt.
I can understand that software developers may have a preference for Microsoft VS versus Qt. If the only target platform is for Windows then VS is probably a better development tool. However, it the app is intended for the Mac, Linux and Windows it seems that Qt is a better approach.
Dave Hein, or any one:
Were did you find a reference on the bytcodes of SPIN, or did you revers engineer it?
If reverse engineered, is there a reference in existence?
I have actually taken to using SPIN for some things, as it is fast enough for many things, even in MuAmi (I still prefer Pasm, though decided to think about the ability of others to modify the firmware).
david: if you take a look at my Fast Interpreter thread, there are specs in there that I put together from various sources, plus some of my own additions. See the tools link in my signature.
Been using the simulator under Linux alot lately and been getting hit by a bug in console routine: characters are being displayed twice some times.
After googling around a bit (I'm not a C expert) I found that the culrpit is in the kbhit routine used under Linux, which will sometines echo the character despite being told not to.
I originally used the code in the attached zipfile. It seems to work well. It requires calling init_keyboard() at the beginning, and close_keyboard() before exiting. If close_keyboard() is not called it will leave the console in a mode were it doesn't echo keystrokes.
The patch contained a version very similar to this and that made the echo go away. However control keys (like arrows, backspace and so on) where returned differently then under windows. Have not found a good solution for that yet (but been a bit busy lately at home). I'll try to come back with a better solution
quite a bit later, but here a patch that handles conio in a better (for me at least) way. I see no more duplicate characters echo'd (basically it moves teh non-canonical setting out of the getch/kbhit routine)
I still want conio to behave similar to the windows version, but that requires some translation of key sequences. working on that now
OK. I am going to revive an old thread because my question lies in the same area. Which, if any, of the Simulator programs in this thread have been used and actually work? I have been messing with some Arduino Simulators and want to try one for the Prop if any of them work. If I could dedicate the time to making one for all the prop boards I would but that is just not feasible at the moment.
Spinsim works, but it depends on what your requirements are whether it will fit your needs. Spinsim is a command-line program simulates the P1 and the P2 from 3 years ago. The P1 mode can execute Spin bytecodes or it can execute PASM code. The Spin mode is faster, but the PASM mode provide a more accurate count of the cycles. I believe spinsim is still distributed with PropGCC/SimpleIDE. If you can run PropGCC from the command line you should be able to run spinsim also.
I have done some additional work on spinsim beyond what is included with PropGCC. I've improved the accuracy of the timing and added some counter functions. I've also added a simple debugger interface. I could post this if there is any interest.
The other P1 simulator is called Gear. It has a graphical user interface and allows for plug-ins. I've never used it, but there has been some recent activity on the forum where people have been adding features to it. You should probably check that out as well.
Comments
I apologize for taking your thread off track. I am done discussing OS's + GUI's unless you have a specific question you desire to ask me, at which point I will be happy to answer your questions.
Bruce
You are right we have wondered a bit from the topic and it is Dave Hein's thread after all. So unless Dave is interested in a GUI for his simulator that's it.
I may well want to pick your brains re: windows one day:)
LOL I got confused there. It was actually Dave that I had some of these discussions with. Anyhow Dave, sorry for taking your thread off track, and Heater, just ask anytime.
Bruce
Your discussion on IDEs and portability was very interesting. I've been programming for 40 years, but I've never done much GUI stuff. I learned quite a bit from your discussion. For me it looks like Qt is the way to go. I'm more comfortable with the programming style used in Qt versus the method used in Microsoft's MFC. The portability of Qt is perfect for developing an app that will work on multiple platforms.
I work mostly on Windows machines, but I have used Unix/Linux at work for the past 22 years. I have to admit that I very rarely use a GUI with Unix/Linux systems. I almost always use a command line interface with those platforms.
Dave
Oh good we are back on topic:) Anyway I'm glad to here something constructive came out of all that.
I'm kind of a command line guy as well, what with having a 100% Linux at work and home. But we do need GUIs for those schematics editors, PCB layout progs etc etc. I have even softened up and become addicted to syntax highlighting editors. The Qt IDE is a wonderful thing to use. Lets face it, you are no doubt reading this in a GUI.
There is another way to cross-platform bliss. One of my favourite programs is LTSpice from Linear Technology, draw your schematic, simulate it, look at the signals or spectra produced. It's a Windows program but it works perfectly under Linux using Wine. It's as if over the years and many versions Linear has always gone out their way to ensure LTSpice never uses any Windows features that are broken in Wine and will therefore run on Linux and BSD etc.
So someone like idbruce who is happy with Windows could still widen his audience and produce useful open source apps just by ensuring that his Windows code always works under Wine.
This is not my preferred solution as I'm sure it is more limiting than using Qt and besides any Linux users with a mind to help in development will be put of by having to look at Windows code.
For that I use PROTEUS that have even Layout from that schematic's.
Ps. What I'm are missing in it are PROPELLER CPU.
Proteus looks excellent. However LTSpice is free for my amateur experiments with analog circuits. I can only dream of moving up to something more professional.
One advantage would be the ability to share code - eg the terminal part would be very useful for others and that sort of code tends to be self contained.
As things evolve, one could envisage an open source GUI with Catalina, BCX basic, Big Spin all on separate tabs.
If Qt is free, that makes it very interesting. I really need to get the BCX Basic to C project finished so I can port over some of the vb.net code.
Addit - downloading Qt now.
Second Addit: @heater, that is a very nice program. Auto complete on a lot of code, auto indents, auto color insertion. And able to write and run a "Hello World" within a couple of minutes.
Playing around more with Qt, I found a great tutorial on how to build a rich text box with syntax highlighting. That will replace pages of vb.net code, plus ought to run a lot faster too.
@heater, I'm a little stuck with writing a "hello world" in the GUI. I've got a button on a form. In vb.net, if you double click on an object like a button, it flips to the code view and writes some of the code as well. Is there an equivalent way of doing this in Qt? I can't even find the 'code' view, though I am sure it is there.
Also @heater, maybe we might need a new thread for this discussion? I'm dreaming already of an IDE for Big Spin, Big C (Catalina), Spin Simulator and Big Basic, all rolled up in one program. But I don't want to hijack this thread here.
I also modified the used of the debug flag at location $12340008 so that debug prints can be turned on for specific cogs depending on the 8 least significant bits of the flag. This way the listing can be turned on and off by the code for each cog.
I just tried SpinSim for the first time and for a test ran the PASM version of my heater_fft.
Fantastic, puts out exactly the same results as the real thing.
That is apart from the execution time calculation:
on SpinSim: "1024 point FFT plus magnitude calculation run time = 117ms"
on a real Prop: "1024 point FFT plus magnitude calculation run time = 49ms"
What an excellent piece of work.
P.S. Oh yeah, I used SpinSim like so:
# ./spinsim -p -m32 -c demo_heater_fft.binary
I'm glad that SpinSim was able to run your FFT program OK. The run time difference is because I use the host's sytem clock to generate the value for the CNT register. So your program took about 2.4 times longer in real time. I thought about using the loop count for the CNT register when the -c option is specified, but I didn't implement that. -m32 is the default, so you didn't need to specify that. The -p option determines whether the C or PASM Spin interpreter is used, so it doesn't have any effect on PASM code.
I really need to spend some time to write some documentation. It's also about time to start working on the GUI version.
Dave
VisualC# would be a very fast development that could be used until a Qt version can be made.
Trouble I'm having with Qt right now is all the manual coding required. VC# automates most of it.
Heater - No offense or disrespect intended (honestly), but I generally hate cross-platform GUI packages like this. In my personal experience, they result in programs that run equally badly across all platforms, instead of something that runs well on each. (I haven't tried BST yet - I probably should)
To elaborate slightly, most OS's have their own set of standard controls, which affect the functionality of them. In order to work on all systems, the cross-platform GUI systems often implement their own, and they're usually not as fast, have a different look & feel, use different hot-keys for things, and so on. In so doing, they require the user to abandon their familiar conventions and learn new ones, which generally makes the user experience suffer in comparison to something written that targets their platform.
I certainly understand the value of being able to get something to run on many systems in a short period of time, I just hate that they usually result in programs that feel slightly awkward.
I don't necessarily disagree with you. If you want to get the best out of any platform it's probably better to go native.
But I might ask who cares about that?
In my day to day computer usage I might have:
1) Firefox to read the Propeller forum
2) Qt Creator to hack on pretty much any C/C++ ideas comming along.
3) BST for Propeller work.
4) Eclipse, for Android and the "chip that shall remain" nameless work.
6) LtSpice for playing around with circuit simulations.
7) Eagle for the odd PCB experiment.
Most (all?) of these work fine accross Windows, Linux and Mac. Some of them are working just fine on non-intel platforms like ARM.
Do I really care that they don't have the look and feel of their native operating systems / window managers / style of the day interface?
No, I am happy that each one of them is pretty much operable in the same way no matter which OS I run it under. So, LtSpice looks and behaves the same everywhere as does QtCreator etc etc.
I guess it's just a question of personal preference but I'd rather have that choice of platform than worry about the finer details of each one.
As a practical matter, I we really supposed to write the same app in as many different toolkits as there are platforms?
I use the Prop tool and BST under Windows, and they provide almost an identical user interface. The appearance of the folders in the directory window does look slightly different, but it doesn't feel awkward. From a user's perspective, I don't think there's much difference whether the app was developed under Microsoft VS or Qt.
I can understand that software developers may have a preference for Microsoft VS versus Qt. If the only target platform is for Windows then VS is probably a better development tool. However, it the app is intended for the Mac, Linux and Windows it seems that Qt is a better approach.
Dave
http://www.fnarfbargle.com/bst.html
Were did you find a reference on the bytcodes of SPIN, or did you revers engineer it?
If reverse engineered, is there a reference in existence?
I have actually taken to using SPIN for some things, as it is fast enough for many things, even in MuAmi (I still prefer Pasm, though decided to think about the ability of others to modify the firmware).
Thank you, much.
With this it may be possible to get some better compilers for the prop (as the spin interpreter is always there).
Been using the simulator under Linux alot lately and been getting hit by a bug in console routine: characters are being displayed twice some times.
After googling around a bit (I'm not a C expert) I found that the culrpit is in the kbhit routine used under Linux, which will sometines echo the character despite being told not to.
Instead I have been using another kbhit routine (which I found here http://cboard.cprogramming.com/c-programming/63166-kbhit-linux.html#post449307 .
[Edit] The attached patch was not correct. It returned all char as 'raw' key strokes. I will come with a new patch somewhat latter.
I still want conio to behave similar to the windows version, but that requires some translation of key sequences. working on that now
I have done some additional work on spinsim beyond what is included with PropGCC. I've improved the accuracy of the timing and added some counter functions. I've also added a simple debugger interface. I could post this if there is any interest.
The other P1 simulator is called Gear. It has a graphical user interface and allows for plug-ins. I've never used it, but there has been some recent activity on the forum where people have been adding features to it. You should probably check that out as well.