I have some new boards on the way and so this is highly relevant. 512k ram chip with a single latch and 4k blocks so any read or write of a single value will need to check if the latch needs changing. And any page reads might need checking if they cross the boundary of a 4k block. The pasm code is working for the video driver so should be possible to port to catalina.
Thinking ahead, I've been pondering the steps for a GUI on the propeller. It is a bit of a challenge to write in C89 as there are some fundamental differences between C89 and languages like C#. First off, there need be no "main" function in a GUI language.
There is much hidden code, eg at startup the program would go through and draw all the buttons and objects on the screen based on text files which are stored separately. Or maybe as part of the code. This is hidden from the user in a C# program - the objects just appear on startup, but it is going on behind the scenes.
And then there is the main loop. In C89 that might be doing all sorts of things, but in a GUI there is another hidden function running where the mouse is being tested, keyboard input is being tested and send to the object with the focus, and if the mouse cursor is on an object like a button, then that gets clicked. Plus there might be timers running (and running timers in a GUI is a perfect application for the propeller with a cog running a timer as the timing can be very precise).
I have already written a lot of GUI primitives in C but it isn't quite fast enough for moving pixels around for putting text on a screen (esp fonts with variable width letters) so I'm thinking this might be moved over to pasm in some dedicated code to move blocks from screen to external ram. Probably in a separate propeller and then use the new 8megabit comms link that got posted recently. And so there might need to be a catalina object for that link.
Overall, I think catalina is going to be the best option for a prop GUI as the program is going to be too big for spin. One crazy idea I think could be possible is to take C# and take the descriptors files and put them on an sd card and then have a C89 program that interprets them and draws the objects as needed. button, x, y, sizex, sizey, font etc etc. Then a huge skeleton program that handles the GUI side and in that you put your own code as well. Keep the 'main' loop tight so that mouse events are polled regularly. buttons, checkboxes, radio boxes are all pretty easy. The complicated ones are textboxes and pictureboxes. Not impossible though. Just a lot of coding.
My task at the moment is moving blocks of the screen in and out of external memory. I'm hoping that will be fast enough to fill a textbox with text in less than a second.
So I don't need anything from catalina quite yet. But one question I'd like to ask - are there other GUI languages like C#. In particular, ones that are i) free, ii) run on multiplatforms and iii) let you get inside the descriptor files for where all the buttons are. C# does fulfill all these but I know some people don't like .net.
I have some new boards on the way and so this is highly relevant. 512k ram chip with a single latch and 4k blocks so any read or write of a single value will need to check if the latch needs changing. And any page reads might need checking if they cross the boundary of a 4k block. The pasm code is working for the video driver so should be possible to port to catalina.
If you have working PASM code, it should be easy enough to wrap the necessary function definitions around it.
...
C# does fulfill all these but I know some people don't like .net.
Possibly the understatement of the decade! - .NET is a bloated monstrosity that should never have been allowed to escape the secret dungeons of Microsoft. Even though they're now busy running after it with torches and wooden stakes, they simply can't kill it off fast enough.
Just a quick update. Catalina 3.3 is nearly ready. I decided that since I was messing about with the XMM API, I should also tidy up and refactor some of the plugins and utilities - many of them were sprinkled with platform dependent chunks of code enabled by detecting specific platform names (e.g. HYDRA or TRIBLADEPROP). This not only made the logic hard to follow, it complicated adding a new platform, since doing so often required a code change even if the new platform was functionally identical to an existing one. This was just pure laziness on my part, I'm afraid.
Well, the same code is still there in most cases, but I now use a set of global configuration options with more descriptive functional names to configure it. For example, the code enabling programs to be loaded from one CPU to another in a multi-CPU system is now enabled by setting a global option called MULTI_CPU_LOADER (previously this code was duplicated in various #ifdef TRIBLADEPROP <code> #elseifdef MORPHEUS <same code again> #endif type constructs).
Now for each platform there is only one file you need to edit to configure all the plugins. If you are adding a new board that is similar to another supported board (which is often the case) then you will probably not need to make any code changes to make all the existing plugins work.
The downside of this is that I have had to do more testing than I had anticipated for this release. However, if I don't finish everything this weekend, I will release a beta version of 3.3. anyway - so that anyone with a RamPage or a SuperQuad board can start using them with Catalina.
The downside of this is that I have had to do more testing than I had anticipated for this release. However, if I don't finish everything this weekend, I will release a beta version of 3.3. anyway - so that anyone with a RamPage or a SuperQuad board can start using them with Catalina.
.NET is a bloated monstrosity that should never have been allowed to escape the secret dungeons of Microsoft. Even though they're now busy running after it with torches and wooden stakes, they simply can't kill it off fast enough.
So I gather you don't like it then?
They seem to me keen on pushing it into into the micro controller arena with the .NET Micro Framework.
The CLR is an interpreter rather than a just-in-time compiler, and uses a simpler mark-and-sweep garbage collector rather than a generational approach.
Interpreted language? Garbage collection? On a microcontroller? For real-time applications?
Windows .NET Micro will suffer the same fate as all Microsoft's other forays into the embedded space - ignominously!
Keep up the good work Ross- these updates are most appreciated.
Re .NET, it isn't whether it is disliked by some but rather what other options are out there as a model for a GUI language.
Talking about this from a practical perspective, I have buttons and textboxes and things on a prop screen now and it is getting time to think about the code that makes them work. Of course, there is always the option of inventing new protocols, or you can recycle those from someone else.
All standard C89 code, but take the descriptor for a button for instance. Its location, size, font etc. That is a text file and that text file can exist as an array declaration in C89 or it can exist as a file on an SD card that you read in.
But what order are the parameters? And do you include parameters that you don't think you will need but might later on? Or do you copy the entire parameter list from something like .NET, because it is likely that over the years all the things have been added to that list that others have thought of? (bloatware, here we come?!)
Or - is there a protocol used by another language that is better/smaller/has crossover to linux?
eg, this is a c# program with one button on a form. Nothing happens yet when you click the button but the code is ready to be inserted. This is the equivalent of a standard C89 program - ie the program you write.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
}
}
}
But there is more to your program than that. There are hidden pieces which are files. For instance form1.designer.cs which contains the location of that button
namespace WindowsFormsApplication1
{
partial class Form1
{
/// <summary>
/// Required designer variable.
/// </summary>
private System.ComponentModel.IContainer components = null;
/// <summary>
/// Clean up any resources being used.
/// </summary>
/// <param name="disposing">true if managed resources should be disposed; otherwise, false.</param>
protected override void Dispose(bool disposing)
{
if (disposing && (components != null))
{
components.Dispose();
}
base.Dispose(disposing);
}
#region Windows Form Designer generated code
/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
this.button1 = new System.Windows.Forms.Button();
this.SuspendLayout();
//
// button1
//
this.button1.Location = new System.Drawing.Point(167, 89);
this.button1.Name = "button1";
this.button1.Size = new System.Drawing.Size(108, 37);
this.button1.TabIndex = 0;
this.button1.Text = "button1";
this.button1.UseVisualStyleBackColor = true;
//
// Form1
//
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.ClientSize = new System.Drawing.Size(452, 266);
this.Controls.Add(this.button1);
this.Name = "Form1";
this.Text = "Form1";
this.ResumeLayout(false);
}
#endregion
private System.Windows.Forms.Button button1;
}
}
So the program is now in two parts and to write that as a C89 program you would need to glue these back together. Or build a translator for that code above.
The reason this could be useful is you could design and debug some of your GUI within an existing framework and then read the text files into a C89 program and if the C89 program found " this.button1.Location = new System.Drawing.Point(167, 89);" then it could draw the button in the correct place.
Or - is there a protocol used by another language that is better/smaller/has crossover to linux?
Dr_A,
The language you seem to be searching for is probably Java. For example, here is a Java program to do what you did in C# and C (example taken from this page):
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class Frame2 extends JFrame
{
JPanel pane = new JPanel();
JButton pressme = new JButton("Press Me");
Frame2() // the frame constructor
{
super("JPrompt Demo"); setBounds(100,100,300,200);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Container con = this.getContentPane(); // inherit main frame
con.add(pane); // JPanel containers default to FlowLayout
pressme.setMnemonic('P'); // associate hotkey to button
pane.add(pressme); pressme.requestFocus();
setVisible(true); // make frame visible
}
public static void main(String args[]) {new Frame2();}
}
None of the hidden files and all the other stuff C# loves to "manage" for you (various class libraries required, of course - but that's true of all the examples).
The main difference between C# and Java is that there is some chance you could eventually see Java running on the Propeller (especially the Prop II).
I don't care about .NET at all, but C# isn't too bad. Its main problem is that it's tied to .NET as an interpreted language. There are one or two compilers out there which sends a nod to C#, one is Vala which is an object oriented language which makes it simple to write GTK GUI applications. It generates C code and that code can be copied and built on systems that don't support Vala natively. http://live.gnome.org/Vala
Well, Microsoft ceased being anything to do with "micro" shortly after they moved from 4K BASIC to operating systems. Of course I always considered the the 4K BASIC to be essentially useless. I mean what real time control in an embedded system can you do with that?
However MCU's and embedded systems are getting bigger and faster all the time so MS can get away with piling on the bloat as usual.
C# as a language is quite OK. Or at least as OK as Java or Python or whatever. It's just that I can't see a language depending on an interpreter with garbage collection etc is much help in building deterministic. time critical, real-time embedded systems.
Dr_A,
You might be surprised to learn that C# used on Linux allows one to create all kinds of GUI's and graphical apps using the GTK gui tool kit. Which is itself entirely written in C. Languages like C#, Java and co are not required to create GUI's. Although I suspect it's much easier to work with if you have an object oriented language.
As for hidden files etc. Even in the C++ world the Qt GUI library allows you to create GUIs in a drag and drop manner. The GUI designer program than creates an XML file representing the elements and layout of you GUI. That XML file is then processed into C++ classes that you can use in your app. Nothing stopping you writing those classes manually if you want to. Same applies to C# and Java probably.
Comments
I have some new boards on the way and so this is highly relevant. 512k ram chip with a single latch and 4k blocks so any read or write of a single value will need to check if the latch needs changing. And any page reads might need checking if they cross the boundary of a 4k block. The pasm code is working for the video driver so should be possible to port to catalina.
Thinking ahead, I've been pondering the steps for a GUI on the propeller. It is a bit of a challenge to write in C89 as there are some fundamental differences between C89 and languages like C#. First off, there need be no "main" function in a GUI language.
There is much hidden code, eg at startup the program would go through and draw all the buttons and objects on the screen based on text files which are stored separately. Or maybe as part of the code. This is hidden from the user in a C# program - the objects just appear on startup, but it is going on behind the scenes.
And then there is the main loop. In C89 that might be doing all sorts of things, but in a GUI there is another hidden function running where the mouse is being tested, keyboard input is being tested and send to the object with the focus, and if the mouse cursor is on an object like a button, then that gets clicked. Plus there might be timers running (and running timers in a GUI is a perfect application for the propeller with a cog running a timer as the timing can be very precise).
I have already written a lot of GUI primitives in C but it isn't quite fast enough for moving pixels around for putting text on a screen (esp fonts with variable width letters) so I'm thinking this might be moved over to pasm in some dedicated code to move blocks from screen to external ram. Probably in a separate propeller and then use the new 8megabit comms link that got posted recently. And so there might need to be a catalina object for that link.
Overall, I think catalina is going to be the best option for a prop GUI as the program is going to be too big for spin. One crazy idea I think could be possible is to take C# and take the descriptors files and put them on an sd card and then have a C89 program that interprets them and draws the objects as needed. button, x, y, sizex, sizey, font etc etc. Then a huge skeleton program that handles the GUI side and in that you put your own code as well. Keep the 'main' loop tight so that mouse events are polled regularly. buttons, checkboxes, radio boxes are all pretty easy. The complicated ones are textboxes and pictureboxes. Not impossible though. Just a lot of coding.
My task at the moment is moving blocks of the screen in and out of external memory. I'm hoping that will be fast enough to fill a textbox with text in less than a second.
So I don't need anything from catalina quite yet. But one question I'd like to ask - are there other GUI languages like C#. In particular, ones that are i) free, ii) run on multiplatforms and iii) let you get inside the descriptor files for where all the buttons are. C# does fulfill all these but I know some people don't like .net.
Ross.
Just a quick update. Catalina 3.3 is nearly ready. I decided that since I was messing about with the XMM API, I should also tidy up and refactor some of the plugins and utilities - many of them were sprinkled with platform dependent chunks of code enabled by detecting specific platform names (e.g. HYDRA or TRIBLADEPROP). This not only made the logic hard to follow, it complicated adding a new platform, since doing so often required a code change even if the new platform was functionally identical to an existing one. This was just pure laziness on my part, I'm afraid.
Well, the same code is still there in most cases, but I now use a set of global configuration options with more descriptive functional names to configure it. For example, the code enabling programs to be loaded from one CPU to another in a multi-CPU system is now enabled by setting a global option called MULTI_CPU_LOADER (previously this code was duplicated in various #ifdef TRIBLADEPROP <code> #elseifdef MORPHEUS <same code again> #endif type constructs).
Now for each platform there is only one file you need to edit to configure all the plugins. If you are adding a new board that is similar to another supported board (which is often the case) then you will probably not need to make any code changes to make all the existing plugins work.
The downside of this is that I have had to do more testing than I had anticipated for this release. However, if I don't finish everything this weekend, I will release a beta version of 3.3. anyway - so that anyone with a RamPage or a SuperQuad board can start using them with Catalina.
Ross.
Will You even have support for --- Bill's --- PropCade
So I gather you don't like it then?
They seem to me keen on pushing it into into the micro controller arena with the .NET Micro Framework.
Hi Sapieha,
I don't know the PropCade (I'm so out of touch these days!).
However, I just had a quick look and since it supports VMCOG it should be easy enough to support in Catalina.
Ross.
Microsoft must have a different definition of "micro controller" than you do. Just looking on Wikipedia, the first "feature" you see is:
But that's just the start. When you read a little deeper, it gets worse ...
Interpreted language? Garbage collection? On a microcontroller? For real-time applications?
Windows .NET Micro will suffer the same fate as all Microsoft's other forays into the embedded space - ignominously!
Ross.
Re .NET, it isn't whether it is disliked by some but rather what other options are out there as a model for a GUI language.
Talking about this from a practical perspective, I have buttons and textboxes and things on a prop screen now and it is getting time to think about the code that makes them work. Of course, there is always the option of inventing new protocols, or you can recycle those from someone else.
All standard C89 code, but take the descriptor for a button for instance. Its location, size, font etc. That is a text file and that text file can exist as an array declaration in C89 or it can exist as a file on an SD card that you read in.
But what order are the parameters? And do you include parameters that you don't think you will need but might later on? Or do you copy the entire parameter list from something like .NET, because it is likely that over the years all the things have been added to that list that others have thought of? (bloatware, here we come?!)
Or - is there a protocol used by another language that is better/smaller/has crossover to linux?
eg, this is a c# program with one button on a form. Nothing happens yet when you click the button but the code is ready to be inserted. This is the equivalent of a standard C89 program - ie the program you write.
using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; namespace WindowsFormsApplication1 { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void button1_Click(object sender, EventArgs e) { } } }But there is more to your program than that. There are hidden pieces which are files. For instance form1.designer.cs which contains the location of that button
namespace WindowsFormsApplication1 { partial class Form1 { /// <summary> /// Required designer variable. /// </summary> private System.ComponentModel.IContainer components = null; /// <summary> /// Clean up any resources being used. /// </summary> /// <param name="disposing">true if managed resources should be disposed; otherwise, false.</param> protected override void Dispose(bool disposing) { if (disposing && (components != null)) { components.Dispose(); } base.Dispose(disposing); } #region Windows Form Designer generated code /// <summary> /// Required method for Designer support - do not modify /// the contents of this method with the code editor. /// </summary> private void InitializeComponent() { this.button1 = new System.Windows.Forms.Button(); this.SuspendLayout(); // // button1 // this.button1.Location = new System.Drawing.Point(167, 89); this.button1.Name = "button1"; this.button1.Size = new System.Drawing.Size(108, 37); this.button1.TabIndex = 0; this.button1.Text = "button1"; this.button1.UseVisualStyleBackColor = true; // // Form1 // this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F); this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font; this.ClientSize = new System.Drawing.Size(452, 266); this.Controls.Add(this.button1); this.Name = "Form1"; this.Text = "Form1"; this.ResumeLayout(false); } #endregion private System.Windows.Forms.Button button1; } }So the program is now in two parts and to write that as a C89 program you would need to glue these back together. Or build a translator for that code above.
The reason this could be useful is you could design and debug some of your GUI within an existing framework and then read the text files into a C89 program and if the C89 program found " this.button1.Location = new System.Drawing.Point(167, 89);" then it could draw the button in the correct place.
This would explain why it is constantly telling me to turn left/right at the next intersection - AFTER I HAVE PASSED THE GODDAM INTERSECTION!!!
I've nearly thrown the damn thing out the car window several times!
AARRGGHH!!!
Thanks!
Sapieha pointed me at this thread... I've been meaning to send you a PropCade for a while; I've just been too busy to build one for you!
As soon as I can breathe a bit I'll send you a care package
PropCade uses P9-P11 as a 3 bit SPI address, to select one of 8 SPI devices
P0-P3 are the normal SPI signals
P0=/CS
P1=CLK
P2=MISO
P3=MOSI
Device 0-3 = SPI RAM normally 32kx8
Device 4-5 = SPI Flash, normally 1MB or 2MB
Device 6 = MCP23S017
Device 7 = uSD
I designed it to support Obex objects; just choose the device by
movd outa,#0..7
Then bit-bang SPI on pins 0..3 as defined above.
Dr_A,
The language you seem to be searching for is probably Java. For example, here is a Java program to do what you did in C# and C (example taken from this page):
import java.awt.*; import java.awt.event.*; import javax.swing.*; public class Frame2 extends JFrame { JPanel pane = new JPanel(); JButton pressme = new JButton("Press Me"); Frame2() // the frame constructor { super("JPrompt Demo"); setBounds(100,100,300,200); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); Container con = this.getContentPane(); // inherit main frame con.add(pane); // JPanel containers default to FlowLayout pressme.setMnemonic('P'); // associate hotkey to button pane.add(pressme); pressme.requestFocus(); setVisible(true); // make frame visible } public static void main(String args[]) {new Frame2();} }None of the hidden files and all the other stuff C# loves to "manage" for you (various class libraries required, of course - but that's true of all the examples).The main difference between C# and Java is that there is some chance you could eventually see Java running on the Propeller (especially the Prop II).
Ross.
Thanks - but please don't hurry! I'm snowed under these days as it is
Ross.
-Tor
However MCU's and embedded systems are getting bigger and faster all the time so MS can get away with piling on the bloat as usual.
C# as a language is quite OK. Or at least as OK as Java or Python or whatever. It's just that I can't see a language depending on an interpreter with garbage collection etc is much help in building deterministic. time critical, real-time embedded systems.
Dr_A,
You might be surprised to learn that C# used on Linux allows one to create all kinds of GUI's and graphical apps using the GTK gui tool kit. Which is itself entirely written in C. Languages like C#, Java and co are not required to create GUI's. Although I suspect it's much easier to work with if you have an object oriented language.
As for hidden files etc. Even in the C++ world the Qt GUI library allows you to create GUIs in a drag and drop manner. The GUI designer program than creates an XML file representing the elements and layout of you GUI. That XML file is then processed into C++ classes that you can use in your app. Nothing stopping you writing those classes manually if you want to. Same applies to C# and Java probably.
Yes, I know - that's why I said it!
All we need is a JVM that can run from XMM, and then Java becomes a real option.
This would probably be a bit slow on the Prop I - but it should be okay on the Prop II.
Ross.
Catalina 3.3 has been released. See here.
If you have installed the beta version, I recommend you delete it and install the "official" release instead.
There are no functional changes since the 3.3. beta - just some very minor bug fixes and documentation changes.
Ross.