demonicpicaxeguy
Senior Member
well i can confirm that down here in oz there is no warmth to be found it's cold here tooIf you find some global warming, would you please send it my way? It snowed again in Seattle yesterday.
to Technical: SFR access on upcoming 28X2?
- Thread starter womai
- Start date
The professional user
Although the PICAXE is eminently suited to the educational and hobbyist market, another significant (though not necessarily lucrative) segment that should be considered is the professional user. By this I don’t mean software engineers (they would probably be using ‘C’ and ARM chips anyway) but professionals from other disciplines.
One of the main impacts of the original Basic Stamp was that it enabled researchers, in fields like oceanography and sports science, to quickly develop unique low cost instruments. Not only were they encouraged in this undertaking by the Stamps configurable hardware and simple software but also by the large amount of supporting material in Nuts & Volts articles, books and the Stamps in Class series etc.
Therefore, when considering features like USB and CAN, please don’t forget the many ‘professional’ users.
Although the PICAXE is eminently suited to the educational and hobbyist market, another significant (though not necessarily lucrative) segment that should be considered is the professional user. By this I don’t mean software engineers (they would probably be using ‘C’ and ARM chips anyway) but professionals from other disciplines.
One of the main impacts of the original Basic Stamp was that it enabled researchers, in fields like oceanography and sports science, to quickly develop unique low cost instruments. Not only were they encouraged in this undertaking by the Stamps configurable hardware and simple software but also by the large amount of supporting material in Nuts & Volts articles, books and the Stamps in Class series etc.
Therefore, when considering features like USB and CAN, please don’t forget the many ‘professional’ users.
demonicpicaxeguy
Senior Member
sorry all can't help myself,
why should they be using C and ARM chips? i really don't get this closed minded idea that only people doing serious development write in C what is so special about C ,it's just another ill concieved language whose compilers don't offer much more than the basic compilers in terms of efficient code and length anyway,
It's not a closed-minded idea, DPG.
For just about all microcontrollers, the first toolset available is a C package, usually provided for free or at little cost by the manufacturer. That's what their user base has come to expect, and what they demand.
For processors that gain some popularity (*cough PIC), entrepreneurs might come along and try to make a buck by developing third party tools that support C or some other language. The third party tools are of varying quality and cost, and for some processors, such tools might never appear. If one happens to be available that suits your budget, needs, and desires, you're golden. Otherwise, C is your only option for that processor family.
Tom
hippy
Ex-Staff (retired)
I wouldn't call C at all ill-conceived but its use is often misapplied or inappropriate.
It's a vicious circle; "My programmers know C, I therefore require whatever we use/do to be programmed in C", so in that respect it is a closed-minded idea, driven by trying to achieve minimum costs on the grounds that any other way would be too costly - whether that's true or not. The same sort of arguments get used by companies who will only use one type of micro because that's what they've always used and retraining means cost or delay.
From a programmer's perspective there's a similar vicious circle, "I like C because that's what I'm familiar with, and I don't want to learn anything else, so I'll choose and demand something which has C".
It all makes for a bizarre case of 'brand loyalty' where if it's not got C it's not worth even looking at; must be a toy for the drongos, not worth serious consideration, has no credibility.
IMO there are two camps - those who demand C and will consider nothing but C, and those who don't care and will adapt to whatever they need to do - and I think they have irreconcilable differences, and each has valid arguments to support their stance.
I personally believe the insistence on C is a debilitating ideology which holds back new development and limits the market for developments and alternatives. C has become seen by many as the established and only correct paradigm even though it isn't, but like many things, trying to say otherwise is swimming against the tide of 'mob rule' mentality.
C is entirely appropriate in some cases - like those it was originally designed for, and as a super-advanced macro-assembler; so often a good fit for micro development - but it's not the universal panacea it is painted as and is downright dangerous and a poor choice in other cases where its use is often insisted upon.
What does bug me is some C programmers' insistences that only they have seen the light, that only C is the true language, and anyone who says otherwise isn't a real programmer and any other option isn't a real language. Anyone who disagrees is an amateur or idiot whose opinion doesn't count. That is real closed-mindset thinking, self-serving conformity enforcement, prejudice, bigotry and demonisation all rolled into one. Unfortunately many companies actively support and promote such views.
One can either conform with that or go one's own way. With the mob running the roost though don't expect to get far if one doesn't comply with the hive mindset. At least these days they don't burn heretics who refuse to see things the way 'they' say it must be done, although, as always, dissenters will frequently be lambasted and treated dismissively.
Does a micro have to support C ? Yes, if one wants acceptance by those who refuse to see it any other way. No, if one is prepared to ignore those who insist it must.
Should a micro support C ? That depends on what one's target audience and market is.
It's a vicious circle; "My programmers know C, I therefore require whatever we use/do to be programmed in C", so in that respect it is a closed-minded idea, driven by trying to achieve minimum costs on the grounds that any other way would be too costly - whether that's true or not. The same sort of arguments get used by companies who will only use one type of micro because that's what they've always used and retraining means cost or delay.
From a programmer's perspective there's a similar vicious circle, "I like C because that's what I'm familiar with, and I don't want to learn anything else, so I'll choose and demand something which has C".
It all makes for a bizarre case of 'brand loyalty' where if it's not got C it's not worth even looking at; must be a toy for the drongos, not worth serious consideration, has no credibility.
IMO there are two camps - those who demand C and will consider nothing but C, and those who don't care and will adapt to whatever they need to do - and I think they have irreconcilable differences, and each has valid arguments to support their stance.
I personally believe the insistence on C is a debilitating ideology which holds back new development and limits the market for developments and alternatives. C has become seen by many as the established and only correct paradigm even though it isn't, but like many things, trying to say otherwise is swimming against the tide of 'mob rule' mentality.
C is entirely appropriate in some cases - like those it was originally designed for, and as a super-advanced macro-assembler; so often a good fit for micro development - but it's not the universal panacea it is painted as and is downright dangerous and a poor choice in other cases where its use is often insisted upon.
What does bug me is some C programmers' insistences that only they have seen the light, that only C is the true language, and anyone who says otherwise isn't a real programmer and any other option isn't a real language. Anyone who disagrees is an amateur or idiot whose opinion doesn't count. That is real closed-mindset thinking, self-serving conformity enforcement, prejudice, bigotry and demonisation all rolled into one. Unfortunately many companies actively support and promote such views.
One can either conform with that or go one's own way. With the mob running the roost though don't expect to get far if one doesn't comply with the hive mindset. At least these days they don't burn heretics who refuse to see things the way 'they' say it must be done, although, as always, dissenters will frequently be lambasted and treated dismissively.
Does a micro have to support C ? Yes, if one wants acceptance by those who refuse to see it any other way. No, if one is prepared to ignore those who insist it must.
Should a micro support C ? That depends on what one's target audience and market is.
Mycroft2152
Senior Member
Good point Hippy!
You could also substitute "USB" for "C" in that comment.
For the BASIC programming market, there are two revenue avenues:
First, sell a BASIC compiler (a one time sale)and let the consumer buy the raw chips from anoiter vendor.
Second, supply a "free" programmer and sell lots of hardware (chips) that will only work with that programmer.
If you are a large enough company, the second option is more profitable.
******
Note: The one area that has not been discussed is the difference between a compiled program and an interpreted one.
Myc
hippy
Ex-Staff (retired)
An interesting question, but you'd perhaps have to narrow down the question in terms of how you mean it ( speed, functionality, codeability etc ).
In terms of speed of execution ( the usual comparison ), I'd say there's often a lot less between the two than people may think. What the PICAXE does in Firmware is what a library subroutine would do in a compiled program so the time taken to do the job should be the same. The saving is in setup to do the job. For a compiled program it's a few lines of register loads, for an interpreter it means extracting the values from memory which is the slow process except when optimised. The PICAXE is perhaps the most non-optimal there can be ( it's bit aligned ) but that maximises code density.
A compiled program is intrinsically more optimised in the setup but uses considerably more code space. It's only where simple things can be done without needing a library call ( set / clear an I/O pin ) and in-lining code where the real gains are.
Forth is arguably a good language in that respect, balanced between interpreted and compiled, because it's usually a highly efficient interpreted language. But then it has a rather peculiar syntax which is hard for some to adapt to.
The advantage of interpreted over compiled comes perhaps with background tasks like running servos where one has to design that in ( the compiler and libraries won't usually save all the needed effort there ) whereas it's handed ready made on a plate once the interpreter firmware has been written.
If the PICAXE were redesigned as a simple bootloader and the Programming Editor a real compiler, I'm not sure how much real gain there'd be. Definitely some, and a lot in particular cases. Having looked at the output of Basic compilers for PICmicro I was stunned how inefficient the code was for some; little better than interpreter code in many cases only gaining from improved setup times.
That is, perhaps, the finest understatement ever written.
Forth is a write-only language.
Last edited:
Exactly on target!
Too many people at all levels fall into "The only tool I have is a hammer, thus everything I see is a nail."
I cut my programming teeth on "real" C (Bell Labs UNIX running on a DEC PDP11/70) and used C on DOS PC's and the Radio Shack Color Computer (how many people even knew there was C for the CoCo?). I even learned some assembly language along the way (patching UNIX programs that I didn't have source for, fixing an error in the C library for the CoCo, building a printer driver for a ZX80).
I found Turbo Basic for DOS produced code that was just as fast as a C compiler and TB was much easier to use. Although I have Visual C++ (and a not-yet-installed copy of Visual Studio 2005), I use VB6 for most programs: it works on all the platforms I need to support and development is quick and (relatively) easy.
I have MPLAB and a programmer, but I'm only using PICAXE's - I can have an idea running on the PICAXE faster than I can read the data sheet and figure out all the configuration settings for a "naked" PIC ;-)
Occasionally you encounter a company (or group within a company) that's open to non-traditional approaches. I was able to persuade a group in AT&T that they would be ahead to spend $3500 for a dBASE clone that ran on UNIX instead of having someone port the single PC dBASE application to Sybase or C to make it multi-user - two weeks for install and test instead of months of development...
John
Mycroft2152
Senior Member
Hippy,
I don't disagree with you, I am merely playing devil's advocate here to he majority opinion that the PICAXE BASIC is the greatest thing since "sliced bread" ( or any other phrase you would like).
There is no doubrt that BASIC has a much shorter learnig curve than C or other languages, after all it was it was designed in 1963 as as
Beginner's All-purpose Symbolic Instruction Code
Check the WIKIpedia entry for a good discussion.
Remember that the PICAXE Basic is a only minor subset of the full BASIC language. There are many useful funtions left out. This is due to the limitations of the PIC chip.
Parallax had exactly the same problem with the BASIC STAMP 1. The PICAXE was originally designed as a cheap STAMP knock off (poor man's STAMP).
Many BASIC compilers can be inefficient and lacking. IMHO, this is due to the fact the developers are small businesses trying to make money and cannot afford the development and optimiztion costs to make it more efficient; rather than major corporations or govenrment / oil company funded projects.
Personally, I think Rev-Ed has done a terrific job for its charter, to increase the technology level in British schools without straining their budgets.
The hobbyist / commercial markets are only secondary revenue streams. This is evident by the scope of the availible kits -- all classroom oriented.
As i said in the past, I happen to like the PICAXE for certain projects, as i have heard you say, "horses for courses!"
Myc
Note to DPG, in my research for this, I came across an open source BASIC that you might be interested in adding to.
http://gcbasic.sourceforge.net/index.html
Last edited:
hippy
Ex-Staff (retired)
A man after my own heart. All my command line utilities are Power Basic for DOS ( upgraded from TB ) or VB6, for precisely the reasons given.
I think for most here ( including me ) it is the best thing since sliced bread, but I know what you mean and I think we'd agree it's not necessarily the right or best tool for all jobs - I'm sometimes amazed at what people do expect from it - nor is it 100% perfect.
Judging on "can it do the job ?", I'm impressed at how many times the answer is yes. That plus low cost, ease of use is why I rank it so highly. It's advantages outweigh what short-comings there are.
I do wonder what is the best micro all round for hobbyists. When I try to critique and compare against the PICAXE I find it hard to beat except when raw speed is required and more cost can be spent. In the past few months though I have been primarily playing with something else.
That "beginner's" tag has been a huge millstone round its neck, an easy target to poke fun at and taunt its users with, even Visual Basic suffers the same ridicule which I don't believe is deserved.
krypton_john
Senior Member
Hi Myc, that may well be the case but it hasn't stopped them putting out products that are oriented to professional rather than educational use such as surface mount components and 40X pieces.
Nothing wrong with asking for advanced stuff - we can only hope....
hippy
Ex-Staff (retired)
A very good guess.
To get round the problem of initialisation, unknown baud rate use and out of spec baud rates, a long 'break' sent on the serial line will restore factory defaults, and a short 'break' followed by "@" will auto-determine the baud rate. These can be sent at any time so baud rate can be changed on the fly.
If I'd never used a PICAXE I'd have never thought of doing anything other than having a fixed baud rate at start-up.
Positioning and other control is done using 'escape codes' and designed to be easy to use from terminal emulators, PC applications and PICAXE. All input is buffered so few pauses needed. To move to a position, set a colour, write some text ...
MScomm1.output = "\"+Str$(row)+"\"+Str$(column)+"\A"
MScomm1.output = "\"+Str$(colour)+"\F"
MScomm1.output = "Wow!"
PulsOut TX_PIN, 5000
SerOut TX_PIN, TX_BAUD( "@" )
SerOut TX_PIN,TX_BAUD( "\A", row, column, "\F", colour, "Wow!" )
A work in progress but it's getting there.
To get round the problem of initialisation, unknown baud rate use and out of spec baud rates, a long 'break' sent on the serial line will restore factory defaults, and a short 'break' followed by "@" will auto-determine the baud rate. These can be sent at any time so baud rate can be changed on the fly.
If I'd never used a PICAXE I'd have never thought of doing anything other than having a fixed baud rate at start-up.
Positioning and other control is done using 'escape codes' and designed to be easy to use from terminal emulators, PC applications and PICAXE. All input is buffered so few pauses needed. To move to a position, set a colour, write some text ...
MScomm1.output = "\"+Str$(row)+"\"+Str$(column)+"\A"
MScomm1.output = "\"+Str$(colour)+"\F"
MScomm1.output = "Wow!"
PulsOut TX_PIN, 5000
SerOut TX_PIN, TX_BAUD( "@" )
SerOut TX_PIN,TX_BAUD( "\A", row, column, "\F", colour, "Wow!" )
A work in progress but it's getting there.
Mycroft2152
Senior Member
Hippy,
WOW! String commands in BASIC! What PICAXEr would know that?
Must be some jelly on that sliced bread.
Myc
I like the way this thread has turned into a discussion of programming languages and techniques. Although this is a Picaxe forum, we don't live in a vacuum.
To that end, here are some good PC resources. All this stuff is free.
The Explorer Series from CodeGear (Borland):
Turbo Delphi for Win32, Turbo Delphi .NET, Turbo C++ for Win32, Turbo C++ .NET
These are serious packages, containing everything needed for development up to the commercial level. Even though the packages are free, they include Borland's latest and greatest to support even sophisticated Internet client and server apps.
And Delphi has always been the best package for developing robust database apps. That hasn't changed in the free Turbo Explorer versions. All of their database tools from their professional packages are included.
Any of these packages would be good values at USD $300. CodeGear is giving them away for free. (Awww, they wouldn't be trying to get you hooked on their $1700 packages, would they?)
There's a fairly steep learning curve with any of these packages. But I've found a couple of good sets of Delphi/Win32 videos that ease the pain:
3DBuzz VTM series
High energy, superb videos presented by a natural teacher. Buzz and his assistants start from the very beginning and move up to a level where you'll be comfortable doing actual work on your own.
There are presently 9 videos on their site, each lasting up to two hours. I hope there will be many more.
Nick Hodges "30 Videos in 30 Days".
Nick is CodeGear's Delphi product manager. He knows the package inside and out. Starting from the beginning, Nick takes you through the installation of Delphi/Win32 right up through the development of a complete application.
His course takes you farther than that presented by 3DBuzz, but in less depth. Each is about 15 minutes in length. I hope that 3DBuzz will, eventually, cover as much ground as Nick does.
A couple of videos in Nick's series were corrupt for me, even after repeating the download.
The beginning videos in either series will be enough to get you up and running, and help to get you comfortable with Delphi/Win32.
(By the way... Delphi is Borland's term for the development environment, libraries, and components that greatly ease the pain of Windows development. The actual language used in Delphi is Object Pascal.)
If anyone is contemplating a career as a programmer, either Delphi or C++ experience (or both) would look good on a resume.
(Back in 2000, I was contacted by the Federal Aviation Agency, simply because I'd published some freeware written in Delphi. They were hot and hungry for Delphi people back then, and looking for contract programmers. Didn't work out for me -- they wanted database heavies -- but it proves my point. If you get good at Delphi, jobs might come looking for you.)
LCC-Win 32 C-language Development System
I've installed this one, but haven't played with it much. The Win32 API is supported, but there aren't any wrappers to insulate you from low-level Windows calls. Naked Windows programming has always been a scary undertaking, and has only gotten worse since the Win 3.1 days when naked programming was your only option if you wanted to write Windows apps.
(Uhhh... I didn't phrase that very well. Just for the record, I've always worn at least jeans and a t-shirt while programming. )
LCC-Win 32 is good for small DOS-type console apps that run in Windows' Command Prompt box as you explore fundamental concepts and test algorithms. The package is great for learning basic C programming.
The language supports some, if not all, the features of C++. Extensive documentation is available for download on the LCC-Win site.
Stanford University's "Essential C"
I've mentioned this before, and I'm sure I will again. I can't say enough good about this excellent tutorial.
You can spend a lot of money buying books that won't teach you as much or as well as you'll get from this tutorial.
I've heard that Microsoft is giving stuff away, too. I'm sort of a non-Microsoft guy, though, so I haven't looked into their offers. (I was terrified at a young age by Microsoft C, way back in the early DOS days, and it stuck.)
Perhaps someone on here, who is familiar with the free Microsoft offerings, could put together a list of the available Microsoft resources.
Good luck!
Tom
Edited to add:
I just realized that I had a pretty good Delphi example sitting right here on my drive. I was fooling with the program below, just this morning, experimenting with Delphi's media playing capabilities.
This program implements a media player that will play, at least, .mp3 audio and .avi video files. It should work with .wmv video, .wav audio, and just about any other format natively supported by Windows.
There's not much of a user interface, but it certainly plays media.
To that end, here are some good PC resources. All this stuff is free.
The Explorer Series from CodeGear (Borland):
Turbo Delphi for Win32, Turbo Delphi .NET, Turbo C++ for Win32, Turbo C++ .NET
These are serious packages, containing everything needed for development up to the commercial level. Even though the packages are free, they include Borland's latest and greatest to support even sophisticated Internet client and server apps.
And Delphi has always been the best package for developing robust database apps. That hasn't changed in the free Turbo Explorer versions. All of their database tools from their professional packages are included.
Any of these packages would be good values at USD $300. CodeGear is giving them away for free. (Awww, they wouldn't be trying to get you hooked on their $1700 packages, would they?)
There's a fairly steep learning curve with any of these packages. But I've found a couple of good sets of Delphi/Win32 videos that ease the pain:
3DBuzz VTM series
High energy, superb videos presented by a natural teacher. Buzz and his assistants start from the very beginning and move up to a level where you'll be comfortable doing actual work on your own.
There are presently 9 videos on their site, each lasting up to two hours. I hope there will be many more.
Nick Hodges "30 Videos in 30 Days".
Nick is CodeGear's Delphi product manager. He knows the package inside and out. Starting from the beginning, Nick takes you through the installation of Delphi/Win32 right up through the development of a complete application.
His course takes you farther than that presented by 3DBuzz, but in less depth. Each is about 15 minutes in length. I hope that 3DBuzz will, eventually, cover as much ground as Nick does.
A couple of videos in Nick's series were corrupt for me, even after repeating the download.
The beginning videos in either series will be enough to get you up and running, and help to get you comfortable with Delphi/Win32.
(By the way... Delphi is Borland's term for the development environment, libraries, and components that greatly ease the pain of Windows development. The actual language used in Delphi is Object Pascal.)
If anyone is contemplating a career as a programmer, either Delphi or C++ experience (or both) would look good on a resume.
(Back in 2000, I was contacted by the Federal Aviation Agency, simply because I'd published some freeware written in Delphi. They were hot and hungry for Delphi people back then, and looking for contract programmers. Didn't work out for me -- they wanted database heavies -- but it proves my point. If you get good at Delphi, jobs might come looking for you.)
LCC-Win 32 C-language Development System
I've installed this one, but haven't played with it much. The Win32 API is supported, but there aren't any wrappers to insulate you from low-level Windows calls. Naked Windows programming has always been a scary undertaking, and has only gotten worse since the Win 3.1 days when naked programming was your only option if you wanted to write Windows apps.
(Uhhh... I didn't phrase that very well. Just for the record, I've always worn at least jeans and a t-shirt while programming.
)LCC-Win 32 is good for small DOS-type console apps that run in Windows' Command Prompt box as you explore fundamental concepts and test algorithms. The package is great for learning basic C programming.
The language supports some, if not all, the features of C++. Extensive documentation is available for download on the LCC-Win site.
Stanford University's "Essential C"
I've mentioned this before, and I'm sure I will again. I can't say enough good about this excellent tutorial.
You can spend a lot of money buying books that won't teach you as much or as well as you'll get from this tutorial.
I've heard that Microsoft is giving stuff away, too. I'm sort of a non-Microsoft guy, though, so I haven't looked into their offers. (I was terrified at a young age by Microsoft C, way back in the early DOS days, and it stuck.)
Perhaps someone on here, who is familiar with the free Microsoft offerings, could put together a list of the available Microsoft resources.
Good luck!
Tom
Edited to add:
I just realized that I had a pretty good Delphi example sitting right here on my drive. I was fooling with the program below, just this morning, experimenting with Delphi's media playing capabilities.
This program implements a media player that will play, at least, .mp3 audio and .avi video files. It should work with .wmv video, .wav audio, and just about any other format natively supported by Windows.
There's not much of a user interface, but it certainly plays media.
Code:
{
TMediaPlayer and DirectX Media Player experiment
This program uses TMediaPlayer generically, so it can play
many types of media files. Tested, so far, on MP3 audio and
AVI video.
}
unit frmMain;
// ListBox1.Items.Assign(OpenDialog1.Files);
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics,
Controls, Forms, Dialogs, StdCtrls, ComCtrls, ExtCtrls,
MPlayer, Buttons;
type
TMain = class(TForm)
txtFolder: TStaticText;
btnOpenFolder: TBitBtn;
tmrProgress: TTimer;
OpenDialog1: TOpenDialog;
lbNames: TListBox;
lbPaths: TListBox;
ScrollBar1: TScrollBar;
mpPlayer: TMediaPlayer;
procedure lbNamesClick(Sender: TObject);
procedure btnOpenFolderClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Main: TMain;
implementation
{$R *.dfm}
procedure TMain.btnOpenFolderClick(Sender: TObject);
// Illustrates the use of multiple file select with TOpenDialog
var
i : integer;
begin
if OpenDialog1.Execute = True then begin
lbNames.Clear;
lbPaths.Clear;
if OpenDialog1.Files.Count > 0 then
for i := 0 to OpenDialog1.Files.Count - 1 do begin
lbPaths.Items.Strings[i] := OpenDialog1.Files.Strings[i]; // Paths
lbNames.Items.Strings[i] :=
ExtractFileName(OpenDialog1.Files.Strings[i]); // just File names
end;
end;
end;
procedure TMain.lbNamesClick(Sender: TObject);
// Play the media file from dblclick-selected file
var
MediaFile : string;
begin
// if the list is empty don't do anything
if lbPaths.Items.Count = 0 then
exit;
MediaFile := lbPaths.Items.Strings[lbNames.ItemIndex];
// Chechk again if it exists
if not FileExists(MediaFile) then begin
ShowMessage('Media file does not exist.');
exit;
end;
mpPlayer.Close;
mpPlayer.FileName := MediaFile;
mpPlayer.Open;
end;
end.
Last edited:
That's correct. But it's easy to write a serial port driver for it. You just can't install it as a component. You just include it with the rest of your program's procedures.
Tom
Hippy, I think I made a liar out of myself. I'm sure I've seen stuff on serial comm in Turbo Delphi in the past, but suddenly I can't lay my hands on it. (I use Delphi 2005 Professional, so I use a component.)
Oh, and I've been away from Delphi for a long, long time. I've just started working with it again recently, so I'm very rusty. That's not helping much.
The best I was able to find after a quick search was this which describes a polled serial comm method using Turbo C++. The same technique (and, for all I know, the same code, when translated) should work for Turbo Delphi. When I get some spare time, I'll take a look at the C++ stuff and see if I can make hide or hair of it.
In the meantime, I'll keep beating the bushes.
Frustrated...
Tom
PS - I found a post on Usenet asking a pretty good question on serial comm in Turbo Delphi. Unfortunately, the poster got no good answers. I laughed my tail off, though, when I looked at the poster's name and found it was you! My, you do get around!
hippy
Ex-Staff (retired)
I was excitedly looking forward to the Delphi Explorers, got them all on day one, jumped through all the hoops of early registration and install issues, and then found they didn't deliver what was needed.
If they want to shoot themselves in the foot that's fine by me, and presumably this will be sanctioned by them - "If you want free and easy to use serial port access, forget Delphi Explorer, use Microsoft Express or some other product which supports serial port access simply and effectively. Delphi Explorer is entirely useless for what you want to do".
If anyone does find a way to easily use serial ports in Delphi Explorer ( and can deliver a simple terminal emulator example ) I'll look at it again, but it seems Borland isn't interested in hobbyists who want to do serial comms, so consequently I'm no longer interested in Delphi; my advice is to head towards Microsoft who do.
What I was really surprised by was that no so-called 'Delphi Expert' could even give any working example of using serial ports with Delphi Explorer. It makes for a nice CD Coaster though
If they want to shoot themselves in the foot that's fine by me, and presumably this will be sanctioned by them - "If you want free and easy to use serial port access, forget Delphi Explorer, use Microsoft Express or some other product which supports serial port access simply and effectively. Delphi Explorer is entirely useless for what you want to do".
If anyone does find a way to easily use serial ports in Delphi Explorer ( and can deliver a simple terminal emulator example ) I'll look at it again, but it seems Borland isn't interested in hobbyists who want to do serial comms, so consequently I'm no longer interested in Delphi; my advice is to head towards Microsoft who do.
What I was really surprised by was that no so-called 'Delphi Expert' could even give any working example of using serial ports with Delphi Explorer. It makes for a nice CD Coaster though
Unfortunately, it's not only Explorer. I ran into the same problem, and with pretty much your reaction, when I first started working with Delphi V back in '98 or so. And I wasn't much happier when I transitioned to Delphi 2005, since the com port component I'd been using for Delphi V didn't work (yet) with 2005. (It's since been updated, and works OK now.)
In the meantime, I hear that serial comms are simple to implement in VB, and work well. Sigh...
I'll keep pluggin'
Tom
z
Hippy, since you didn't respond to my PM, I'm posting this here.
To my utter surprise, both the Delphi serial comm method and the simple terminal program work (Although that terminal is begging for some dress-up. As written, it's really bare-bones.)
So now you can write serial apps in Turbo Delphi. You also have the simple terminal you requested.
And, if you have any interest, I can also point you to the source code for Comport, which you can easily add to your own apps for fully-featured serial communication. (Having worked with Comport, I think it's vast overkill for the sort of stuff you do. I think the polled method will be just as effective, and be a whole lot easier to include in your own software.)
Tom
To my utter surprise, both the Delphi serial comm method and the simple terminal program work (Although that terminal is begging for some dress-up. As written, it's really bare-bones.)
So now you can write serial apps in Turbo Delphi. You also have the simple terminal you requested.
And, if you have any interest, I can also point you to the source code for Comport, which you can easily add to your own apps for fully-featured serial communication. (Having worked with Comport, I think it's vast overkill for the sort of stuff you do. I think the polled method will be just as effective, and be a whole lot easier to include in your own software.)
Tom
hippy
Ex-Staff (retired)
@ Tom : Sorry, I've been tied up with other things. I've got to re-install Delphi but I'll see how it goes.
I've tended to steer clear of polled serial when I can. There's not much choice in MS-DOS but Windows is event driven so using that is generally more efficient and I've found simplifies things in my apps, but it's not necessarily something for the novice and .Net throws traps in the way for the unwary which VB6 simply 'just handled'.
I've tended to steer clear of polled serial when I can. There's not much choice in MS-DOS but Windows is event driven so using that is generally more efficient and I've found simplifies things in my apps, but it's not necessarily something for the novice and .Net throws traps in the way for the unwary which VB6 simply 'just handled'.
Yeah, I understand. XP and beyond are weird beasts.
You can find the "OS friendly" Comport source at http://www.arrl.org/qexfiles/ . Run down the page, or search, until you find the file 9x07_Gradijan.zip.
After you unzip it, you'll find the TComport source hiding in the catsimple folder.
Good luck!
Tom
hippy
Ex-Staff (retired)
Finally got round to installing Turbo Delphi and jumping through its hoops again, but I have to admit you did it with your SimpleSerial application. Well done and thanks.
I cannot say hand on heart I'm now a Delphi convert because there's a long way to go to make it as easily usable as a 'drop-on-form component" and event driven and it's a steep learning curve to take on but it definitely proves it can work which takes Delphi Explorer out of the "don't use this" category.
I cannot say hand on heart I'm now a Delphi convert because there's a long way to go to make it as easily usable as a 'drop-on-form component" and event driven and it's a steep learning curve to take on but it definitely proves it can work which takes Delphi Explorer out of the "don't use this" category.
Good news, Hippy. Thanks for the feedback.
And good luck with Delphi. I hope that you'll come to enjoy it as much as I do.
You have a lot to learn, though. Delphi can have a very steep learning curve. As someone who's climbed that cliff once, and is well on his way to climbing it again, I'm sure I can help you around a few pitfalls.
Feel free to ask any questions that might arise.
However, I don't want to clutter the forum with discussions of specific Delphi techniques, so I'd prefer it if you'd ask via PM or email.
Have fun!
Tom
PS... I just caught a hint -- just a hint, mind you, nothing specific -- that it might be possible to incorporate components simply by declaring and using them as dynamically-created objects, just as I do in my VU Meter class.
Off the top of my head, it doesn't make sense that such a simple, generic method would work for the wide variety of components available on the net, but I could be wrong.
I plan to experiment with this to see if it's true or not. If so, it would solve lots of problems for you, and open up lots of options.
And good luck with Delphi. I hope that you'll come to enjoy it as much as I do.
You have a lot to learn, though. Delphi can have a very steep learning curve. As someone who's climbed that cliff once, and is well on his way to climbing it again, I'm sure I can help you around a few pitfalls.
Feel free to ask any questions that might arise.
However, I don't want to clutter the forum with discussions of specific Delphi techniques, so I'd prefer it if you'd ask via PM or email.
Have fun!
Tom
PS... I just caught a hint -- just a hint, mind you, nothing specific -- that it might be possible to incorporate components simply by declaring and using them as dynamically-created objects, just as I do in my VU Meter class.
Off the top of my head, it doesn't make sense that such a simple, generic method would work for the wide variety of components available on the net, but I could be wrong.
I plan to experiment with this to see if it's true or not. If so, it would solve lots of problems for you, and open up lots of options.
Last edited: