Well, I pieced together my standard serial interface that I use in Windows apps. Unfortunately, I can not get it to work in Mono/MonoDevelopment. I can make the Rx/Tx LEDs on the prop demo board light. http://www.agaverobotics.com/serialportdemo.zip
It seems like the SerialPort.DataReceived event is not firing. It's probably something I do not understand in Linux Mint.
If I send "Hello World" from the prop, what command can I use in Linux to grab the serial port data. I'm just trying to verify that the FTDI driver is working.
port = "/dev/ttyUSB0";
baud = Convert.ToInt32(115200);
com = new SerialPort(port, baud);
So there is something up with "args".
Also that loop waiting for chars to transmit slams my CPU up to 100% which then fires up all the fans on my PC which then whine like a Harrier Jump Jet trying to get into the air which then causes "her in doors" to want to pitch the PC and myself into the street.
Also that loop waiting for chars to transmit slams my CPU up to 100% which then fires up all the fans on my PC which then whine like a Harrier Jump Jet trying to get into the air which then causes "her in doors" to want to pitch the PC and myself into the street.
Otherwise it's fine:)
Ok, so this is some good info. 1) specify .net 3.0 or less in the IDE and 2) look at why args might not work.
Can't find a way to do that in monodevelop IDE. Had to hack the "TargetFrameworkVersion" in the .csprog file. Set to 2.0 seems to work.
My mono is v2.6.7.
Re Jorge P, as an example of how similar vb.net and your C# code is, this is the serial bit of code from my IDE to put all the available ports in a drop down combo box
Dim ports As String() = SerialPort.GetPortNames()
Dim port As String
ComboBox1.Items.Clear()
For Each port In ports
ComboBox1.Items.Add(port)
Next port
ComboBox1.Text = ComPort ' com port
at the beginning of the program
Imports System.IO.Ports
and then
Public Class Form1
Dim WithEvents SerialPortName As New IO.Ports.SerialPort ' generic serial port
This could be quite a fun little project.
Dr_Acula, sorry I missed your post. I am a VB Convert, I used it up untill 2001 when I was introduced to C# in the VS 2005 betas. I never turned back and forgot most VB keywords.
In some respects, VB.NET would be good for some things where it would take more coding in C#. I wish I would have not ignored VB.NET this long. As the saying goes, You snooze, you lose. It is now foreign to me.
If you have any .NET dll's you made that you think would be usefull, they can be used.
For the first time I proved that I can transmit and receive data over the serial port with C# and mono on Debian.
With Jazzed's uterm I just jammed a loop back wire into my Prop Plugs Tx and Tx pins and typed characters are indeed echoed back as advertised.
For the first time I proved that I can transmit and receive data over the serial port with C# and mono on Debian.
With Jazzed's uterm I just jammed a loop back wire into my Prop Plugs Tx and Tx pins and typed characters are indeed echoed back as advertised.
Yippie! This is great news.
Can you post a .zip back so i can start using the same source?
Just don't stay up all night again.
...as an example of how similar vb.net and your C# code is...
Seems to me that BASIC is BASIC like it was back in nineteen seventy something when I first learned it.
If it has grown up to become all sophisticated with block structure and object orientation and decent types etc etc so much so that it looks like C/C++/C#/Java/Pascal/ADA/Algol etc etc then, for me at least, there seems no point. Might as well stay with C/C++/C#/Java/Pascal/ADA/Algol etc. All of which have filled my brain to capacity anyway:) Well all right skip Algol I have not seen that in use for a few decades.
I guess BASIC has been evolving over the decades dragging all the BASIC users along with it step by step until they are where they should have been back in nineteen seventy something when they could have switched to Pascal or something. (Algol in my case:))
Heater:
Post the working code for uterm and I will add it to a seperate class for a .NET dll so it can be used in console and winforms.
1. Before I go much further, I wold like some oppinions about Localization, I think this should be done first so it will not be a headache later... http://msdn.microsoft.com/en-us/library/aa309421(v=vs.71).aspx ! I have never had the need to do this before, but I think it should be a requirement with any utility we dive into. It will give the non english speaking world an oportunity to use whatever is created as a result of our efforts.
2. Should we start up a project on sourceforge using SVN and put out a notice requesting developers? or should we use an other site like codezone, codeguru, etc...?
Can you post a .zip back so i can start using the same source?
zip? What's that? This is Unix land, we use tar balls. See attached. Not much changed really, haven't fixed the Harrier issue yet.
I didn't get what to do with "Application.DoEvents();" I mean, uterm does not have an Application to have an event loop.
Seems to me it might be better to just read com port chars directly with a little time out, check for keyboard input when it returns and then go round again. Or better still use a thread.
Just don't stay up all night again.
Ha, I tried not to. But this is Helsinki in the spring time it's already getting light at 4:30. Nothing for it but to get up and tweak on uterm. Now I have to go to work and get through the day again somehow.
I didn't get what to do with "Application.DoEvents();" I mean, uterm does not have an Application to have an event loop.
Seems to me it might be better to just read com port chars directly with a little time out, check for keyboard input when it returns and then go round again. Or better still use a thread.
Improvements are Ok If you want to add a delegate thread, that's fine. The program "uterm" is just a simple thing i put together in about 10 minutes do serve my overwhelming need to keep all my digits on the keyboard when using VIM for development. The Application class (probably a struct) is a global entity for C# programs. Application.DoEvents(); causes a thread to yield the CPU for any pending events and will put the application to sleep briefly. Think of it in terms of using select() and FD_SET.
I keep forgetting about tar balls since i'm back on Windoze. Sorry. I want to run VmWare or whatever so I can have my sweet SMP Linux back again some day. Having 12 cpus would be sweet
uterm has been a good "Hello World" program for the serial port, and for me getting familiar with C# and mondevelop. Perhaps it will grow up into a full C# Prop Loader, or has someone done that already? I'm going try it out on my ARM boards soon. If that works I'm almost sold on the C# idea. Although it bugs me that for any platform I come across it's more likely to have a C compiler than a .NET run time. And then there is the whole MS thing...
Was it you that said here somewhere they would like to the fft_bench in C#? Maybe it's coming soon.
I didn't get what to do with "Application.DoEvents();" I mean, uterm does not have an Application to have an event loop.
This is another example of the convergence of the languages. This is the same instruction in C# and VB, and it allows the operating system to go off and do other things. Practical examples are when you have a very tight loop of code (eg a download or sort) but you don't want the screen to appear frozen - so then the user can still click things like a picturebox. Sometimes you need a .doevents to update objects on the screen like progress bars and pictureboxes.
Generally I find where to put .doevents by using the program and noting parts of code where it is frozen. eg just now, in my IDE I have found that redoing all the colors in the text takes a while, so I do this when it is downloading a program as these two tasks take about the same amount of time. But so the user can see something happening, every few lines of code in the colorizing text I add a .doevents.
Yes indeed. The thing that threw me here though was that under Qt you have to create your own Application object and then run it from main. For a Qt console application you may well not have an application object if you don't want.
I have crazy ideas about writing propeller code in C#.
eg right now I'm happily coding away in Catalina C and it works very well. But the whole drop-in object concept doesn't quite work in C89. At the moment you drop in functions rather than objects, and maybe it is just a syntax thing. eg calling a function vga_out() or using an object vga.out()
But adding the . thing like in C# and vb.net means that as soon as you type that . in the IDE a drop down menu appears with all the options. It makes learning the features of an object much easier.
The great thing about Catalina C, especially XMM programs, is that they ought to be portable over to the prop II. I like XMM catalina because I've already got a taste of what you can do with unlimited memory and reloadable cogs, eg things like the GUI with text boxes and radio buttons.
Maybe a program with mainly C89 syntax but a subset of additional C# type . syntax for objects?
It's early days yet to get too serious about C#. Just now I have to deal with Spin, PASM and C on the Propeller whilst at work it's C/C++ and Pascal. Soon I might have to be working in Java for Android. Sometimes I think my brain is full already.
As for the C# on the Propeller, well it only requires that someone create a .NET run time for it. Something to interpret the byte codes. This is obviously impossible. The prop is too slow and there is not enough memory. There, I said it "impossible", I expect by next week someone will pop up having done it:) After all Jazzed has made a Java run time for the Prop already, about the same perhaps.
I'm sure there will be a Catalina for Prop II. So all your C efforts should be transferable to that. Or perhaps the GCC C compiler thing will be there for Prop II in which case things should work under that as well.
As for the lack of objects in C89, as in vga.out(). Well you should have used GCC under ZOG instead:) Then you could program using a subset of C++ features that allows one to work in exactly the same object way as you do in Spin.
I have crazy ideas about writing propeller code in C#.
.....
But adding the . thing like in C# and vb.net means that as soon as you type that . in the IDE a drop down menu appears with all the options. It makes learning the features of an object much easier.
...
There are samples on how to do this in .NET on msdn, the NET Framework SDK 1.1 has the sample Microsoft.NET\SDK\v1.1\Tool Developers Guide\Samples\clisp that shows the parsing stuff and a sample language definition file. The code isnt commented all that great. It also does not include a project or solution file, just a build.bat.
I'll include it as an attachment just so you can look over the code if you like. I have it compiled incase you can't get that far in monodevelop.
Don't be seduced by the Dark side of the Force, Dr_A!
C# on the Propeller? Just say NO!
Ross.
Although that would be sorta cool, it would realy have any purpose since a PC can do all that. But getting a C# app to spit out some spin would be alot better, especialy if you can impliment the . charactor to popup a selection of object functions, again there are samples on how to do it, just gotta find them. msdn is too huge for some searches http://msdn.microsoft.com/en-us/magazine/cc136756.aspx guess I was wrong...
[C# is] sort of Java with reliability, productivity and security deleted.
Klaus Kreft and Angelika Langer (authors of a C++ streams book):
Java and C# are almost identical programming languages. Boring repetition that lacks innovation ...Hardly anybody will claim that Java or C# are revolutionary programming languages that changed the way we write programs...
C# tries to satisfy many needs. Good, bad, or ugly, it is a credit for trying to be useful. C# has untyped variables like VB.net for ease of use in database applications. Interestingly C++ users have convinced Microsoft to adopt some obscure C++ syntax in C#. I would give some examples, but they're a little too obscure for me to remember
I'm not trying to start a language war -- we get enough of that with C programming debates.
A CIL VM on Propeller might be interesting for VB.net or C# users, but it would be super slow. C# CIL has about 230 byte-codes so there would be a ton of overlay swapping and it's not clear how much common code can stay COG resident. Also 64 bit double and integer data types support is required. What is the impact of 64 bit data on the stack? Someone might write a Propeller CIL VM as a hobby project, but the end result might not be worth-while. Propeller2 would be faster, but fast enough? Who knows.
Clearly, getting a Parallax officially sponsored C programming compiler tool-chain solution for Propeller is a higher priority than C#.
I do believe that we have proven that a C# front end can be practical though because Heater was able to get C# serial-port code working on Linux with Mono.NET. Last year it did not work at all.
Hopefully this means multi-platform tools can be easier to develop and deploy now for people who like programming for .NET and for users who don't mind having .NET on their computers. To me this is the entire point of the thread.
Now, lets get another good application running on Mono.NET. I'll post Propalyzer sources later today.
I think C# is a good compromise. Moving from C to C# is much easier than to C++. C++ is supposed to be backwards compatible with C, but I haven't had much luck that way. C# has a tremendous network of support.
Comments
http://www.agaverobotics.com/serialportdemo.zip
It seems like the SerialPort.DataReceived event is not firing. It's probably something I do not understand in Linux Mint.
If I send "Hello World" from the prop, what command can I use in Linux to grab the serial port data. I'm just trying to verify that the FTDI driver is working.
So there is something up with "args".
Also that loop waiting for chars to transmit slams my CPU up to 100% which then fires up all the fans on my PC which then whine like a Harrier Jump Jet trying to get into the air which then causes "her in doors" to want to pitch the PC and myself into the street.
Otherwise it's fine:)
I recommend GtkTerm, dead easy to use. Minicom is nice from the command line once you figured out how to stop it trying to dial a modem:)
Ok, so this is some good info. 1) specify .net 3.0 or less in the IDE and 2) look at why args might not work.
There is a method you can call "Application.DoEvents();" that can be used in the loop to make your Harrier happy.
See this page for explanation and examples.
I am very surprized you got this far. That means Propalyzer would probably work. What version of Mono.NET are you using?
Sounds like a good day
Can't find a way to do that in monodevelop IDE. Had to hack the "TargetFrameworkVersion" in the .csprog file. Set to 2.0 seems to work.
My mono is v2.6.7.
Well of course that "ToUpper" has to go on the port argument. Unix is case sensitive in file names.
Dr_Acula, sorry I missed your post. I am a VB Convert, I used it up untill 2001 when I was introduced to C# in the VS 2005 betas. I never turned back and forgot most VB keywords.
In some respects, VB.NET would be good for some things where it would take more coding in C#. I wish I would have not ignored VB.NET this long. As the saying goes, You snooze, you lose. It is now foreign to me.
If you have any .NET dll's you made that you think would be usefull, they can be used.
With Jazzed's uterm I just jammed a loop back wire into my Prop Plugs Tx and Tx pins and typed characters are indeed echoed back as advertised.
Yippie! This is great news.
Can you post a .zip back so i can start using the same source?
Just don't stay up all night again.
Cheers.
Dr_A,
Seems to me that BASIC is BASIC like it was back in nineteen seventy something when I first learned it.
If it has grown up to become all sophisticated with block structure and object orientation and decent types etc etc so much so that it looks like C/C++/C#/Java/Pascal/ADA/Algol etc etc then, for me at least, there seems no point. Might as well stay with C/C++/C#/Java/Pascal/ADA/Algol etc. All of which have filled my brain to capacity anyway:) Well all right skip Algol I have not seen that in use for a few decades.
I guess BASIC has been evolving over the decades dragging all the BASIC users along with it step by step until they are where they should have been back in nineteen seventy something when they could have switched to Pascal or something. (Algol in my case:))
Post the working code for uterm and I will add it to a seperate class for a .NET dll so it can be used in console and winforms.
1. Before I go much further, I wold like some oppinions about Localization, I think this should be done first so it will not be a headache later... http://msdn.microsoft.com/en-us/library/aa309421(v=vs.71).aspx ! I have never had the need to do this before, but I think it should be a requirement with any utility we dive into. It will give the non english speaking world an oportunity to use whatever is created as a result of our efforts.
2. Should we start up a project on sourceforge using SVN and put out a notice requesting developers? or should we use an other site like codezone, codeguru, etc...?
zip? What's that? This is Unix land, we use tar balls. See attached. Not much changed really, haven't fixed the Harrier issue yet.
I didn't get what to do with "Application.DoEvents();" I mean, uterm does not have an Application to have an event loop.
Seems to me it might be better to just read com port chars directly with a little time out, check for keyboard input when it returns and then go round again. Or better still use a thread.
Ha, I tried not to. But this is Helsinki in the spring time it's already getting light at 4:30. Nothing for it but to get up and tweak on uterm. Now I have to go to work and get through the day again somehow.
-Phil
Improvements are Ok
I keep forgetting about tar balls since i'm back on Windoze. Sorry. I want to run VmWare or whatever so I can have my sweet SMP Linux back again some day. Having 12 cpus would be sweet
I was joking about zip. Just being awkward
Jazzed,
uterm has been a good "Hello World" program for the serial port, and for me getting familiar with C# and mondevelop. Perhaps it will grow up into a full C# Prop Loader, or has someone done that already? I'm going try it out on my ARM boards soon. If that works I'm almost sold on the C# idea. Although it bugs me that for any platform I come across it's more likely to have a C compiler than a .NET run time. And then there is the whole MS thing...
Was it you that said here somewhere they would like to the fft_bench in C#? Maybe it's coming soon.
This is another example of the convergence of the languages. This is the same instruction in C# and VB, and it allows the operating system to go off and do other things. Practical examples are when you have a very tight loop of code (eg a download or sort) but you don't want the screen to appear frozen - so then the user can still click things like a picturebox. Sometimes you need a .doevents to update objects on the screen like progress bars and pictureboxes.
Generally I find where to put .doevents by using the program and noting parts of code where it is frozen. eg just now, in my IDE I have found that redoing all the colors in the text takes a while, so I do this when it is downloading a program as these two tasks take about the same amount of time. But so the user can see something happening, every few lines of code in the colorizing text I add a .doevents.
Yes indeed. The thing that threw me here though was that under Qt you have to create your own Application object and then run it from main. For a Qt console application you may well not have an application object if you don't want.
QApplication a(argc, argv); ... a.setMainWidget (bla, bla); .... return (a.exec());Whilst a.exec is running your app can get all sorts of events from keyboard, mouse, ports, network etc. So no freezing there.
Seems C# has gone to the trouble of giving you an application global automatically.
I'm not quite, but I'm getting close myself.
I have crazy ideas about writing propeller code in C#.
eg right now I'm happily coding away in Catalina C and it works very well. But the whole drop-in object concept doesn't quite work in C89. At the moment you drop in functions rather than objects, and maybe it is just a syntax thing. eg calling a function vga_out() or using an object vga.out()
But adding the . thing like in C# and vb.net means that as soon as you type that . in the IDE a drop down menu appears with all the options. It makes learning the features of an object much easier.
The great thing about Catalina C, especially XMM programs, is that they ought to be portable over to the prop II. I like XMM catalina because I've already got a taste of what you can do with unlimited memory and reloadable cogs, eg things like the GUI with text boxes and radio buttons.
Maybe a program with mainly C89 syntax but a subset of additional C# type . syntax for objects?
It's early days yet to get too serious about C#. Just now I have to deal with Spin, PASM and C on the Propeller whilst at work it's C/C++ and Pascal. Soon I might have to be working in Java for Android. Sometimes I think my brain is full already.
As for the C# on the Propeller, well it only requires that someone create a .NET run time for it. Something to interpret the byte codes. This is obviously impossible. The prop is too slow and there is not enough memory. There, I said it "impossible", I expect by next week someone will pop up having done it:) After all Jazzed has made a Java run time for the Prop already, about the same perhaps.
I'm sure there will be a Catalina for Prop II. So all your C efforts should be transferable to that. Or perhaps the GCC C compiler thing will be there for Prop II in which case things should work under that as well.
As for the lack of objects in C89, as in vga.out(). Well you should have used GCC under ZOG instead:) Then you could program using a subset of C++ features that allows one to work in exactly the same object way as you do in Spin.
There are samples on how to do this in .NET on msdn, the NET Framework SDK 1.1 has the sample Microsoft.NET\SDK\v1.1\Tool Developers Guide\Samples\clisp that shows the parsing stuff and a sample language definition file. The code isnt commented all that great. It also does not include a project or solution file, just a build.bat.
I'll include it as an attachment just so you can look over the code if you like. I have it compiled incase you can't get that far in monodevelop.
Don't be seduced by the Dark side of the Force, Dr_A!
C# on the Propeller? Just say NO!
Ross.
Although that would be sorta cool, it would realy have any purpose since a PC can do all that. But getting a C# app to spit out some spin would be alot better, especialy if you can impliment the . charactor to popup a selection of object functions, again there are samples on how to do it, just gotta find them. msdn is too huge for some searches http://msdn.microsoft.com/en-us/magazine/cc136756.aspx guess I was wrong...
Klaus Kreft and Angelika Langer (authors of a C++ streams book):
Tell me again, why are we doing all this?
C++ = "C with classes"
C# = "C with no class whatsoever"
Ross.
I'm not trying to start a language war -- we get enough of that with C programming debates.
A CIL VM on Propeller might be interesting for VB.net or C# users, but it would be super slow. C# CIL has about 230 byte-codes so there would be a ton of overlay swapping and it's not clear how much common code can stay COG resident. Also 64 bit double and integer data types support is required. What is the impact of 64 bit data on the stack? Someone might write a Propeller CIL VM as a hobby project, but the end result might not be worth-while. Propeller2 would be faster, but fast enough? Who knows.
Clearly, getting a Parallax officially sponsored C programming compiler tool-chain solution for Propeller is a higher priority than C#.
I do believe that we have proven that a C# front end can be practical though because Heater was able to get C# serial-port code working on Linux with Mono.NET. Last year it did not work at all.
Hopefully this means multi-platform tools can be easier to develop and deploy now for people who like programming for .NET and for users who don't mind having .NET on their computers. To me this is the entire point of the thread.
Now, lets get another good application running on Mono.NET. I'll post Propalyzer sources later today.
http://www.agaverobotics.com/serialportdemo.zip
The SerialPort.DataReceived event handler does not work in Mono, bummer.
Nice GUI; clean code. Looks like a port must exist before the ComPort dialog will work.