Searching \ for '[EE] Host interface software programming language' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Host interface software programming language'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Host interface software programming language '
2005\07\07@221105 by Chen Xiao Fan

face
flavicon
face

After joining the list for a while I see a more urgent need
for me to learn at least a bit of programming on the host PC
side. I know everyone has his or her own preferred language
so hopefully this will not lead to a language war.

I have not been well trained in the university regarding
programming (learned Fortran and 8086 assembly only). Later
I learned some basic C but I have never written any PC
software using it even though I have written three production
firmwares using Hitech PICC (quite simple programs using
16C72A and 16F872).

My main goal here is to interface the MCU to the PC using
either RS232 or USB. I will mainly using Windows XP but
Linux is on my potential list of OS as well. So I have list
the following choice based on the order of my preference.

1) Plain C / GCC with some open source library, any good
recommendations?
2) Python with pyserial and Libusb, any good USB examples?
3) Visual Basic ( lots of examples)
4) Visual C++ (the C part): a bit daunting for me so it is
my last choice

I will not consider things like Java or Perl since I think
they are not well suited to the tasks or is too difficult
for me to learn.

What is your recommendation and suggestion?

Regards,
Xiaofan

2005\07\07@224140 by Vitaliy

flavicon
face
[snip]
> My main goal here is to interface the MCU to the PC using
> either RS232 or USB. I will mainly using Windows XP but
> Linux is on my potential list of OS as well. So I have list
> the following choice based on the order of my preference.
>
> 1) Plain C / GCC with some open source library, any good
> recommendations?
> 2) Python with pyserial and Libusb, any good USB examples?
> 3) Visual Basic ( lots of examples)
> 4) Visual C++ (the C part): a bit daunting for me so it is
> my last choice
>
> I will not consider things like Java or Perl since I think
> they are not well suited to the tasks or is too difficult
> for me to learn.
>
> What is your recommendation and suggestion?

I found Delphi to be intuitive and relatively easy to learn (much more so
than VC++/MFC). It is more powerful than VB, and there's a lot less overhead
(at least at the beginning) than in VC++.  You can still find free
personal/student use versions (v6 or v7) on the internet if you want to give
it a try.

Starting with version 8, you can write apps that will run under both Windows
and Linux.

Unless you have a very good reason, I would stay away from GCC - you will
end up reinventing a lot of wheels.

Best regards,

Vitaliy

2005\07\07@230807 by Bob Blick

face picon face
On 8 Jul 2005 at 10:11, Chen Xiao Fan wrote:
> After joining the list for a while I see a more urgent need
> for me to learn at least a bit of programming on the host PC
> side.

Since you are using Linux, you might give Kylix or Gambas a shot.

Cheers,

Bob

2005\07\07@230918 by Mark Rages

face picon face
On 7/7/05, Chen Xiao Fan <spam_OUTxiaofanTakeThisOuTspamsg.pepperl-fuchs.com> wrote:
>
> My main goal here is to interface the MCU to the PC using
> either RS232 or USB. I will mainly using Windows XP but
> Linux is on my potential list of OS as well. So I have list
> the following choice based on the order of my preference.
>
> 1) Plain C / GCC with some open source library, any good
> recommendations?
> 2) Python with pyserial and Libusb, any good USB examples?
> 3) Visual Basic ( lots of examples)
> 4) Visual C++ (the C part): a bit daunting for me so it is
> my last choice

Here's what I use.

For quick and dirty prototyping on Linux, you don't need a language:
echo "command" > /dev/ttyS0

(defaults to 9600 baud, 1 stop bit, no parity.  Use 'setserial' to change.)

For writing host software, Python is great.  It's quick to learn and
does what you want, unless you want blazing speed.  The above example
in Python:

import serial
serial.Serial(0).write('command\n')

If you need a USB example, I've ported the Pickit 1 programming
software to Python. I can put that up for you.  It also includes a
library for manipulation of Intel hex files.

I've got another library that speaks a variant of the Sony 9-pin VCR
control protocol.  I'm not sure how helpful that would be for you, if
you're using a different protocol.

Recently I integrated host control functions into a large monolithic
C++ program.  Instead of integrating directly, I linked it against the
Python library and made it call methods of my Python control class.
This was a great idea. It sped development immensely and added a lot
of flexibility to a program.  I just used the embedding instructions
on python.org.  As a bonus, I can use the same host control library in
Python scripts for testing and calibration.

Regards,
Mark
markrages@gmail


--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\07\07@231008 by John J. McDonough

flavicon
face
I hate to say this, because deep down I'm a C bigot, but for your
application, I think VB is the ticket (yeah I know, yuck).

Talking to the outside from Windoze is a major PITA.   With VB, there are
loads of examples, DLL's, etc. so that you only have to do the application
part ... you can grab the grody talk to the hardware part from the net.

Java, which you already don't like, is possibly the worst choice.  Even on a
friendly operating system, Java wants to be self contained.  It is really
hard to interface to anything.  On Windoze, you have not only XP trying to
wall you off from the port, but also the JVM.  Neither hurdle is trivial.

My second choice would be VC++.  C is good <g>  There are some drivers you
can use to get by the XP wall, they're not the best in the world, but you
can make them work.  And the interface isn't really unmanageable.

Problem is, good old gcc is a huge pain to get set up on Windoze compared to
VB or VC++.  It's basically an alien thing to WIndows.  Same with Python or
Perl, although those aren't quite as intimidating as gcc.  Pity, too,
because gcc is a really nice compiler.

Development on Windoze is getting to be a real pain.  The Visual series of
products has gotten really good, but the price is breathtaking.  The
alternatives, though, mean you will spend more time installing the
development environment than writing your application.  Not pretty.

OK, if you are willing to toss Windoze, then the serial port on Linux is a
pretty simple thing to do with gcc.  I understand it's not so bad with
Python, either, but I have no experience there.

But to be really honest, as much as I dislike VB, it will be the shortest
path.

--McD


{Original Message removed}

2005\07\07@233415 by Chen Xiao Fan

face
flavicon
face
On Windows it seems that VB is the nature choice. However to me
anything with "Visual" is a bit difficult (VB is less so than
VC) for me. Is it really true that GCC/Python are a pain on
Windows? I have Cygwin and Python installed flawlessly on
the Windows XP machine. XWisp (wisp628) is also running on
Windows using Python. I also see a lot of the Linux software
ported to Windows using Cygwin or Mingw.

To be honest, I am quite new to Linux as well so I will not
toss Windows yet. I am exploring Linux and like it more and
more since the installation of Ubuntu though.

Regards,
Xiaofan

{Original Message removed}

2005\07\07@234528 by Chen Xiao Fan

face
flavicon
face
Thanks for the suggestions but Delphi/Kylix/Gambas are not in my list.
The problem is that I am not willing to learn another language (object
pascal) and to me they are in the same league of Visual C/C++ which
I feel more difficult than plain C or Python or VB.

I do not really need a very powerful IDE and GUI framework. My goal
is quite modest as well (but already a big step for me if I can
write something like PICkit 1 host software).

Regards,
Xiaofan

{Original Message removed}

2005\07\07@234614 by Robert Young

picon face
Subject: [EE] Host interface software programming language

Vitaliy is right on the money recommending Delphi especially since with V8
you can move between Windows and Linux (with some minor fiddling).  I never
upgraded past V5 so my opinions are based on 2nd hand information.  I did
some serial communication stuff using the Win32 API with Delphi and it
worked OK.

A good backup for you would be Visual Basic.  If you get your hands on VB6
(buying somebody's old copy from Ebay or finding one gathering dust at
CompUSA or Microcenter) you will need to get the service packs.  I think you
can just get SP5 and be caught up.  Otherwise get the .NET version and if
you can afford it get C#.NET too.  This does lock you into Windows a bit but
you will be well off with lots of examples on the web.  Using the COMM
object to do serial communications is pretty simple but you have to think a
bit, it isn't 100% automatic.  You can also use the Win32 API.

If you go the Visual Basic route get a copy of Jan Axelson's "Serial Port
Complete" as she covers LOT of ground and most if not all examples are in
Visual Basic (V5 or V6 will work, .NET might need some adjusting of the
code).

Both VB and Delphi can make calls to DLLs very easily.  When I need a PC
application I typically write the front end and user interface with Visual
Basic because I can have it done in very short order and then write DLLs
with Visual C to handle any serious data processing.  Also lots of vendors
sell add-on DLLs or COM objects to do just about everything else you could
want.

Rob

2005\07\08@000238 by Jose Da Silva

flavicon
face
On July 7, 2005 08:34 pm, Chen Xiao Fan wrote:
> To be honest, I am quite new to Linux as well so I will not
> toss Windows yet. I am exploring Linux and like it more and
> more since the installation of Ubuntu though.

You are trying Linux the "correct way", which is to try a bit more each
time.
You don't quit Windows cold-turkey, because if you were to simply wipe
your disk clean, install linux, you would find yourself running into a
brick wall because you would not be able to run "must-have" application
X, or "must-have" application Y. The result of such a a drastic action
would be, linux-no-good, file-n-forget.
For myself, it's the route I took. I still got OS/2, and Win98 for the
must-have apps, but linux is slowly increasing in use while the others
are becoming less used.
Sounds like you may become a penguin lover eventually.


> Regards,
> Xiaofan
>
> {Original Message removed}

2005\07\08@000853 by Mark Rages

face picon face
On 7/7/05, Chen Xiao Fan <.....xiaofanKILLspamspam@spam@sg.pepperl-fuchs.com> wrote:
> On Windows it seems that VB is the nature choice. However to me
> anything with "Visual" is a bit difficult (VB is less so than
> VC) for me. Is it really true that GCC/Python are a pain on
> Windows?

Python is easier on Linux, but *everything* is easier on Linux (for
me!).  If you've got Cygwin going already, then Python is no problem
-- until you want to distribute your program.

I develop on Python under Linux, then I use distutils to make a
Windows .exe out of the Python files.  It's not a compiler, it's more
like a zip program that unzips the scripts and the Python .dll in a
temporary directory, then runs the Python script from there.  Pretty
smooth.  I can just distribute the exe file and the guy I give it to
doesn't know or care what language it's written in.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\07\08@013526 by Vitaliy

flavicon
face
> Thanks for the suggestions but Delphi/Kylix/Gambas are not in my list.
> The problem is that I am not willing to learn another language (object
> pascal) and to me they are in the same league of Visual C/C++ which
> I feel more difficult than plain C or Python or VB.
>
> I do not really need a very powerful IDE and GUI framework. My goal
> is quite modest as well (but already a big step for me if I can
> write something like PICkit 1 host software).

I find that writing applications in Delphi is often easier than writing
console-based C programs. It took me exactly two weeks (most of that time
spent reading the User's Guide) to go from almost zero to a very good
understanding of Object Pascal/Delphi. Like John, I too used to be a C
bigot, since I used it for years before I had to have a serious look at
Delphi (out of necessity - I inherited a program written in OP). What I
found was, Object Pascal is not that different from C or C++. Once you learn
one of the high-level languages, it is easy to learn another one - the core
concepts are the same, only the way in which they're expressed are
different. Pascal uses ':=' instead of '=', and '=' instead of '=='.  So
what? :)

Coincidentally, my first serious Delphi app also had to do with serial
communication. There's a freeware component that can be set up from within
the visual environment, so basically all you need to do is send(), wait for
an event (think interrupt) from the serial port, and read() out the bytes.

IMHO, Delphi is the best tool for developing visual applications of low to
medium complexity under Windows. However, my advice would be to go with
whatever you feel most comfortable with (after you do the research).

Best regards,

Vitaliy

2005\07\08@023821 by Wouter van Ooijen

face picon face
> Problem is, good old gcc is a huge pain to get set up on
> Windoze compared to VB or VC++.

A have used djgpp al long time, and found it reasonably easy to set up
and use.

For 1y student classes we often used devcpp. I just say to the student:
download, install, use. Most of them have not seen and IDE before but
can use it immediately.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\08@023821 by Wouter van Ooijen

face picon face

> If you need a USB example, I've ported the Pickit 1 programming
> software to Python. I can put that up for you.  It also includes a
> library for manipulation of Intel hex files.

If the OP is not interested I am. Can it run on both Windoze an Linux?


Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\08@023821 by Wouter van Ooijen

face picon face
> My main goal here is to interface the MCU to the PC using
> either RS232 or USB. I will mainly using Windows XP but
> Linux is on my potential list of OS as well. So I have list
> the following choice based on the order of my preference.

If you don't need real USB stick to serial and USB-to-serial. That way
you have only one interface to program for, but serial-port-deprived
computers can still use the usb-to-serial option.

> 1) Plain C / GCC with some open source library, any good
> recommendations?
> 2) Python with pyserial and Libusb, any good USB examples?
> 3) Visual Basic ( lots of examples)
> 4) Visual C++ (the C part): a bit daunting for me so it is
> my last choice

My choice would be Python + pyserial, unless speed is realy important.
My XWisp PC software for the Wips628 is known to take roughly twice the
time to program al large PIC than the C rewrite (by Rob Hamerling). I
know where the problem is, so I can probably take care of it when I
rewrite the program, but it is easy to write a Python program that is
less than optimal in the speed aspect. But it is so damn easy to write
in the first place!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\08@025822 by Chen Xiao Fan

face
flavicon
face
I am really very interested and I have emailed Mark off-list.
PICkit 1 is one of my favorite and now it can be a good learning
tools for me as well. After Mark's email I am now leaning towards
Python already. Still GCC and VB are also possible. Maybe I will
start with Python first and later see if I can learn VB and
better my C skills.

Regards,
Xiaofan

-----Original Message-----
From: Wouter van Ooijen [wouterspamKILLspamvoti.nl]
Sent: Friday, July 08, 2005 2:38 PM
To: 'Microcontroller discussion list - Public.'
Subject: RE: [EE] Host interface software programming language

> If you need a USB example, I've ported the Pickit 1 programming
> software to Python. I can put that up for you.  It also includes a
> library for manipulation of Intel hex files.

If the OP is not interested I am. Can it run on both Windoze an Linux?

2005\07\08@051847 by Shawn Tan Ser Ngiap

flavicon
face
On Friday 08 July 2005 04:07, Bob Blick wrote:
> On 8 Jul 2005 at 10:11, Chen Xiao Fan wrote:
> > After joining the list for a while I see a more urgent need
> > for me to learn at least a bit of programming on the host PC
> > side.
>
> Since you are using Linux, you might give Kylix or Gambas a shot.

I would recommend using FreePascal if you're planning to use pascal... Borland
seems to have put Kylix on a back burner... FreePascal + Lazarus is pretty
much similar (as an IDE).. and of course, you have the power of the Pascal
programming language (which IMHO, is the best...) Freepascal also cross
compiles to other platforms and processor architectures... I regularly use it
and I think it's pretty good...

http://www.freepascal.org

cheers..

--
with metta,
Shawn Tan

2005\07\08@052704 by Chen Xiao Fan

face
flavicon
face
Thanks for the comments. Actually I have used Linux since 1998
(Slackware 3.5 on a US$60 486) and I am quite okay with the basic
operation and installation (they become very easy now). However I
was not using Linux since late year 2001 because at the time Linux
was really slow (much slower than 98SE/XP) on my old computer
(Celeron 400, 256MB SDRAM with lousy SIS620 integrated graphics
built in 1999) with Redhat Linux or similar.

On the other hand with Ubuntu and faster computer (AMD64 desktop
and Dell 600M Pentium notebook), I can now do a lot of things
in Linux which I was not able to do before. So it is getting better
and better. Still I do not yet have anything important which I can
only do in Linux but not in Windows. To me both OS are nice platforms
to work with. I also see that a lot of the people in the open source
world do not exclude Windows and a lot of the good open source programs
are now running in Windows. For example, GCC/Python/AVR-GCC/GPUtils/...
are all working on both platforms. I even managed to get most of the
PIC developement tools (MPASM, MPSIM, MPASM30, MPSIM30, MPLAB C18,
MPLAB C30) work under Linux with Wine.

Anyway this is not the topic of the thread.

Regards,
Xiaofan

{Original Message removed}

2005\07\08@075818 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Chen Xiao Fan" <.....xiaofanKILLspamspam.....sg.pepperl-fuchs.com>
Subject: RE: [EE] Host interface software programming language


> On Windows it seems that VB is the nature choice. However to me
> anything with "Visual" is a bit difficult (VB is less so than
> VC) for me. Is it really true that GCC/Python are a pain on
> Windows?

If you're a Linux guy at heart, it really isn't that bad.  But even then,
it's about 100 times more difficult than VB.  I assumed your objective was
to do the project not play with development environments <g>

> I have Cygwin and Python installed flawlessly on
> the Windows XP machine. XWisp (wisp628) is also running on
> Windows using Python. I also see a lot of the Linux software
> ported to Windows using Cygwin or Mingw.

I have Cygwin on all my Windoze boxes, and love it.  But it's not so much
fun if you want to get out of the Cygwin box.  But then, I came up through
the old "time sharing" days, and the whole unix thing feels more like a
"real computer" to me than Windows.

> To be honest, I am quite new to Linux as well so I will not
> toss Windows yet. I am exploring Linux and like it more and
> more since the installation of Ubuntu though.

mmmm ... well again, ask whether the objective is to play or to get the
project done.  Some people will jump through all sorts of hoops to make
their project work on Linux.  Other people are stymied if they can't do it
on Windows.  I use either Windows, Cygwin or Linux depending on what will be
easier for the particular project.  Sometimes I wish I had a VMS box around
because once in a while I run across something that would be easier on VMS,
or maybe MVS, or maybe RSX <g>.  I don't feel that I need to be "true" to
some operating system or another.  I will exploit whatever works best for
the job.

I also wouldn't be too shy about different languages.  Once you've gotten
past the first 3 or 4 they're pretty much all the same.  Generally some
language has an advantage in some situation, so it probably isn't good to
limit yourself.  I happen to like the portability of C - some of the code I
still use has been ported from OS to OS since the mid 80's, but I will use
what works best for the situation.  I have current, relatively recently
written code in bash, Perl, C, C++, Java, VB, Fortran, Lisp, even Ada.  I
keep my XPL books around because even though I haven't had a need recently,
I see a potential in the future.  I really don't like VB and C# because of
the portability thing.  Pascal/Delphi falls into the same category (sorry
Olin).  I've been around a long time and operating systems evolve with
surprising speed when you look back over time.  I often have the same
problems to solve over and over again, though, so I would like to solve them
once, and then reuse the code.  That's why I generally choose C, all other
things being equal.

Once upon a time I swore I would write everything in Fortran-60.  This was
after porting a bunch of stuff from Cal (an awful language -- predecessor to
Focal).  Nowadays I really hate Fortran, but there are certain things it is
very good at.  Once it was the only language that was reasonably portable.
It no longer is as portable as it used to be, and it is pretty bad at things
that don't involve punch cards <g>  So things change, and it's worth having
enough tools on your belt that you can respond.

But if you want a short path to your serial port problem, grab a DLL from
the net, write your app in VB and be done with it.  You are not going to get
portability writing to the serial port anyway.

--McD

2005\07\08@100059 by peiserma

flavicon
face
piclist-bounces@mit.edu wrote:
> After Mark's email I am now leaning towards
> Python already. Still GCC and VB are also possible.

When I have to write windows apps, I invariably do it with
VC. Just because I am a C-bigot like some others <g>, I have
the compiler, existing code, etc.

Having said that, I can tell you interfacing with the serial
port is not trivial under anything after Win98. While it's
not difficult for someone reasonably comfortable with the C
language, to do it correctly takes a fair bit of programming.

I have a book called 'Serial Communcations Developer's Guide'
which is 822 pages without the appendix. I ended up stripping
down a C++ class from that book, and its still over 500 lines
of source code that involves creating multiple threads.

Of course, you only have to do it once, then you can re-use.

> Maybe I will
> start with Python first and later see if I can learn VB and
> better my C skills.

I think that's a good course of action. Maybe it's time for
me to look into Python. Sounds like a good alternative for
quickly  developing certain apps.

2005\07\08@101707 by Wouter van Ooijen

face picon face
> I also wouldn't be too shy about different languages.  Once
> you've gotten
> past the first 3 or 4 they're pretty much all the same.

>From your list I guess you have never programmed in a lazy-functional
language. You should try that just for fun - it is realy different from
the imperative crowd! But alas, the world does not seem to fit
functional languages very well.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\08@102149 by Wouter van Ooijen

face picon face
> I have a book called 'Serial Communcations Developer's Guide'
> which is 822 pages without the appendix. I ended up stripping
> down a C++ class from that book, and its still over 500 lines
> of source code that involves creating multiple threads.
>
> Of course, you only have to do it once, then you can re-use.

Better yet, you can re-use what someone else has written! I use the
Python serial library without knowing much about DLLs, windows calls,
Linux prort-configure calls and other tidbits. That's of course only an
example, but a good set of libraries can be a stronger argument to use a
particular language than the language itself. Of course that language
itself has caused the other developers to create such libraries.

> I think that's a good course of action. Maybe it's time for
> me to look into Python. Sounds like a good alternative for
> quickly  developing certain apps.

So far I think Python is definitely weak for writing large applications,
but large in this sense might well be over 5k lines. It is also weak in
run-time speed, but in most cases writing-time speed is much more
important.

If I ever write a Jal2 I will be very much tempted to use
indendation-based block structure :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\08@104511 by peiserma

flavicon
face
piclist-bounces@mit.edu wrote:
> So far I think Python is definitely weak for writing large
> applications, but large in this sense might well be over 5k lines. It
> is also weak in run-time speed, but in most cases writing-time speed
> is much more important.

Agreed, that's very much an issue. And I don't consider having to
re-learn how to access the serial port everytime Gates & Co rewrites
the OS a productive use of my time. Of course, with the gradual fading
of the serial port it's about time to learn how to interface to USB.
I like to know how the underlying hardware and software works, but
let's face it, there isn't always the luxury of time.

Just how weak is it in run-time speed? And why is it weak for
large apps? Is that due to runtime speed or some other factor?

2005\07\08@111843 by olin piclist

face picon face
peiserma@ridgid.com wrote:
> Having said that, I can tell you interfacing with the serial
> port is not trivial under anything after Win98.

True, so you do it only once.  I've got all hidden below my portable OS
interface.  All my apps call FILE_OPEN_SIO, FILE_READ_SIO_REC,
FILE_WRITE_SIO_REC, etc.  The Windows specific implementation of those
routines takes care of the rather complicated Windows interface, but I only
had to write that once.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\08@113322 by Wouter van Ooijen

face picon face
> Agreed, that's very much an issue. And I don't consider having to
> re-learn how to access the serial port everytime Gates & Co rewrites
> the OS a productive use of my time. Of course, with the gradual fading
> of the serial port it's about time to learn how to interface to USB.

For the moment the co-existence of USB-lacking PCs with serial ports,
and serial-port-lacking PCs with USB I think the best way is to write
for a (possibly emulated) serial port.

> Just how weak is it in run-time speed? And why is it weak for
> large apps? Is that due to runtime speed or some other factor?

Runtime speed can be an issue, but it has not much relation with
application size.

Python is an interpreted language, with all the associated strengths and
weaknesses. Let's say you have an object X, and you use a property Name,
like
  print( X.Name )
In a compiled language the compiler would assure that object X is of a
type that indeed has a Name property, and that it is of an appropriate
type to pass to print(). When any of these conditions are not satisfied
you will be flogged by the compiler, that is: before you can run the
program. With an interpreted program like Python the compiler will
simply tokenise your program, and the mentioned checks take place when
the statement is executed. Note: only when it is executed! So your
program can have errors of a type that are simply not possible in a
compiled program. But on the other hand you have language features that
can not exist in a compiled program, like the ability to decide at
run-time which properties a certain object will have.

This run-time freedom has advantages and disadvantages. Roughly the
advantages are dominant when you write small, frequently changing,
use-once programs, the disadvantages are dominant when you write very
large, relatively static, industrial-strength programs. The interesting
point is of course where the small/large boundary is. I think this will
vary a lot depending on personal coding style and experience.

But all that does not matter much when the difference is using a library
or writing it all yourself. I just changed my website-generating code a
bit, so thumbnails are included for certain products. I had to add lots
of bookkeeping code, but the prodedure for the actual generation of the
thumbnail from the original image is just (note that this includes error
handling!):

def CopyImage( Source, Dest, Height ):
  import os
  try:
     Im = Image.open( Source )
     Im.thumbnail( ( 1000, Height ), Image.ANTIALIAS )
     Im.save( Dest, "JPEG")
  except:
     File_Error( Source )  

Note that is not an argument for the Python language, it is an argument
for using an existing library (and Python just happens to have a *lot*
of usefull libraries).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\08@123805 by Bob Blick

face picon face
Vitaliy writes:
> I find that writing applications in Delphi is often easier than writing
> console-based C programs.
...
> What I
> found was, Object Pascal is not that different from C or C++.

I agree completely.

> Coincidentally, my first serious Delphi app also had to do with serial
> communication. There's a freeware component that can be set up from within
> the visual environment

Yes, drop in this and you're good to go:
http://sourceforge.net/projects/tpapro/

Best regards,

Bob



2005\07\08@133051 by Jose Da Silva
flavicon
face
On July 8, 2005 09:38 am, Bob Blick wrote:
> Yes, drop in this and you're good to go:
> http://sourceforge.net/projects/tpapro/

Egads! that has a nasty number of errors on the buglist  hehehe.


If you are used to Borland C++ this appears to work across the line from
Win95 all the way up.

char portStr[16] = "COM1:9600,n,8,1"; //note, may just be ..5] = "COM1";
portStr[3] = portNum + '0';
ComH = CreateFile(portStr,GENERIC_READ|GENERIC_WRITE,0,
           &securL, OPEN_EXISTING,FILE_FLAG_OVERLAPPED,NULL);
etc...

You will also want to work with BuildCommDCB(), GetCommState() and
SetCommState() which should show some examples on usage if you read the
help for those commands.

If you want a linux comm port interface, this shows a great example,
especially if the project gets you pulling out your hair, hehehe.
slashdot.org/articles/03/01/10/1343224.shtml?tid=133

2005\07\08@134826 by Bob Blick

face picon face
Jose writes:

> On July 8, 2005 09:38 am, Bob Blick wrote:
>> Yes, drop in this and you're good to go:
>> http://sourceforge.net/projects/tpapro/
>
> Egads! that has a nasty number of errors on the buglist  hehehe.

I have not noticed any, it works great for me. The Kylix version,
tpaproclx, does have an error if you don't close it, but otherwise is
amazingly easy to use.

Cheers,

Bob


2005\07\08@151020 by William Chops Westfield

face picon face
On Jul 8, 2005, at 7:00 AM, EraseMEpeisermaspam_OUTspamTakeThisOuTridgid.com wrote:

> I can tell you interfacing with the serial
> port is not trivial under anything after Win98. While it's
> not difficult for someone reasonably comfortable with the C
> language, to do it correctly takes a fair bit of programming.

Really?  I thought that treating the serial port "normally" would
be pretty easy; just open com1: as a file and do your reads and
writes.  It's when you need to do NON-standard things like bit-bang
the modem control lines that things become difficult.

If I'm right, that implies something about designing the PIC-side
serial interface as well - keeping it simple enough to operate with
WXP through "normal" channels will probably also allow it to work
through more complex comm paths...

BillW

2005\07\08@152714 by olin piclist

face picon face
William Chops Westfield wrote:
> Really?  I thought that treating the serial port "normally" would
> be pretty easy; just open com1: as a file and do your reads and
> writes.  It's when you need to do NON-standard things like bit-bang
> the modem control lines that things become difficult.

The extra complexity is because a serial port I/O is not just reading or
writing bytes from/to a file.  There are issues of baud rate, stop bits,
parity bits, various types of hardware flow control, modem handshaking,
handling of "end of records", NULL bytes, control codes, etc, etc, etc.  The
Windows interface is quite flexible in that it lets the application control
just about everything independently, but that comes at a cost of complexity.

So you deal with all the complexity once and set up your own simple
interface for the normal 8N1 raw byte protocol.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\08@155938 by William Chops Westfield

face picon face

On Jul 8, 2005, at 12:27 PM, Olin Lathrop wrote:

> The Windows interface is quite flexible in that it lets the
>  application control just about everything independently, but that
>  comes at a cost of complexity.

Oh.  When people talked about things beyond W98 being difficult to
use, I assumed they were complaining about "no direct IO instructions
to the uart from user programs" issue...

Complexity in the application doesn't bother me much; as several
people have said, it's something you deal with once...  Having to
have a user install special device drivers that explictly defeat
windows 'security' is a more serious "problem."

BillW

2005\07\08@155948 by Harold Hallikainen

face picon face
How does Windoze deal with who "owns" the port? Can any user just open it,
read/write, then close it? Is it "first come - first served" with any
other user/application locked out? Are there "permissions" or similar on a
port so some user can access it and others can't?

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\07\08@160526 by Wouter van Ooijen

face picon face
> > I can tell you interfacing with the serial
> > port is not trivial under anything after Win98. While it's
> > not difficult for someone reasonably comfortable with the C
> > language, to do it correctly takes a fair bit of programming.
>
> Really?  I thought that treating the serial port "normally" would
> be pretty easy; just open com1: as a file and do your reads and
> writes.  It's when you need to do NON-standard things like bit-bang
> the modem control lines that things become difficult.

How do you set the baudrate, or do you consider that a non-standard
operation?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\08@191256 by Vitaliy

flavicon
face
>> Problem is, good old gcc is a huge pain to get set up on
>> Windoze compared to VB or VC++.
>
> A have used djgpp al long time, and found it reasonably easy to set up
> and use.
>
> For 1y student classes we often used devcpp. I just say to the student:
> download, install, use. Most of them have not seen and IDE before but
> can use it immediately.
>
> Wouter van Ooijen

Last time I checked, DJGPP (http://www.delorie.com/djgpp/) created DOS
executables only. For "true" Windows applications, you can use MinGW
(http://www.mingw.org/).

DevC++ (http://www.bloodshed.net/devcpp.html) works equally well with both
compilers.

Wouter is right - if you just follow the steps, installation is painless.

Best regards,

Vitaliy

2005\07\08@195230 by Vitaliy

flavicon
face
From: "Bob Blick"
>>[snip] There's a freeware component that can be set up from within
>> the visual environment
>
> Yes, drop in this and you're good to go:
> http://sourceforge.net/projects/tpapro/

Actually, I was referring to http://sourceforge.net/projects/comport/.
However, it appears to have a few minor, but annoying bugs - so thank you
for the link, I'll give it a try!

Best regards,

Vitaliy

2005\07\08@212342 by William Chops Westfield

face picon face
On Jul 8, 2005, at 4:12 PM, Vitaliy wrote:

> if you just follow the steps, installation is painless.
>

Hmmph.  Trying to get all the pieces to compile the sources for a
particular GUI open source project can be quite a challenge, though.
I guess it's now largely automatic and relatively incomprehensible,
via the package managers that automatically get the dependencies for
each "thing."  Otherwise you'd be forever lost trying to understand
the differences between gtk+, gtk-gnutella, gtk-+2, and so on.

There's probably an existing open source library to do whatever you
might wish.  But FINDING it based on a vague idea of what you want to
accomplish is next to impossible...

BillW

2005\07\08@235900 by Vitaliy

flavicon
face
> There's probably an existing open source library to do whatever you
> might wish.  But FINDING it based on a vague idea of what you want to
> accomplish is next to impossible...
>
> BillW

I think that for anything but the simplest programs, you should have the
design on paper before you start coding. If you don't know exactly what it
is that you want to accomplish, what do you think you're going to end up
with?

Best regards,

Vitaliy

2005\07\09@001944 by Mark Rages

face picon face
On 7/8/05, Vitaliy <vitaliyspamspam_OUTmaksimov.org> wrote:
> > There's probably an existing open source library to do whatever you
> > might wish.  But FINDING it based on a vague idea of what you want to
> > accomplish is next to impossible...
> >
> > BillW
>
> I think that for anything but the simplest programs, you should have the
> design on paper before you start coding. If you don't know exactly what it
> is that you want to accomplish, what do you think you're going to end up
> with?
>

I think he was talking about the difficulty of finding open source libraries.

I haven't had much difficulty.  I look to see what libraries are used
by popular applications in a similar application domain.  If a library
is packaged by my distribution, so much the better.  If I come up
blank, I ask on my LUG (linux user group) mailing list and look
through the projects at freshmeat.net.

Maybe BillW was talking from a Windows perspective.   On Linux there
are already gobs of great open-source libraries installed by the
distribution.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2005\07\09@012310 by William Chops Westfield

face picon face

On Jul 8, 2005, at 8:58 PM, Vitaliy wrote:

>> There's probably an existing open source library to do whatever you
>> might wish.  But FINDING it based on a vague idea of what you want
>> to accomplish is next to impossible...
>
> for anything but the simplest programs, you should have the design
> on paper before you start coding. If you don't know exactly what it is
> you want to accomplish, what do you think you're going to end up with?

You're misunderstanding.  Suppose, for example, that I start out with a
task like "I want to drive my pickit1 from my linux box, using a GUI
that
looks very much like microchip's windows pickit1 software."  That's a
pretty specific target.  Assume that I understand the "hard" parts like
talking over USB, the pickit1 "protocol", and so on.   Now, I know there
are toolkits for doing windows-like interfaces under linux/X.  But how
to I find out which ones are most appropriate for my task?  Which ones
will work at all?  Which ones require a particular environment already
installed?  Grr.

BillW

2005\07\09@035334 by Rob Hamerling

flavicon
face


Wouter van Ooijen wrote:
>>>I can tell you interfacing with the serial
>>>port is not trivial under anything after Win98. While it's
>>>not difficult for someone reasonably comfortable with the C
>>>language, to do it correctly takes a fair bit of programming.
>>
>>Really?  I thought that treating the serial port "normally" would
>>be pretty easy; just open com1: as a file and do your reads and
>>writes.  It's when you need to do NON-standard things like bit-bang
>>the modem control lines that things become difficult.
>
>
> How do you set the baudrate, or do you consider that a non-standard
> operation?

Those who want an example of this may have a look at the source of my
XWisp2 program, in particular the OS-dependent module. It contains the
platform dependent code (the other modules work for all platforms).  In
this module you'll find a number of functions to set baudrate, generate
a 'break', manipulate the control lines, etc. Currently these functions
contain code for both OS/2 and Windows (W32), all with documented system
API calls, no 'direct' I/O or other tricks.
From the same source an OS/2 or W32 executable can be generated (with
the same compiler - Open Watcom C/C++ - but also with other compilers).

I'm still waiting for a volunteer to insert the equivalent code for
Linux....

Regards, Rob.

--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

2005\07\09@050214 by Peter Onion

flavicon
face
On Fri, 2005-07-08 at 22:23 -0700, William Chops Westfield wrote:
> Now, I know there
> are toolkits for doing windows-like interfaces under linux/X.  But how
> to I find out which ones are most appropriate for my task?

I suggest that you spend some time trying the ones you can find, looking
at the quality and quantity of documentation, looking for related news
groups and mailing lists.  My advice is don't try and mix learning about
a GUI environment with learning how to drive USB or how to implement a
protocol.  Put those things in libraries which you develop or use
existing libs and learn their APIs without worrying about the GUI.

You seem to have your "Microsoft blinkers" on.  In the M$ view there is
only one M$ tool for each task. The fact that there may be several tools
in the Open Source is NOT (as you seem to think) a bad thing.  
You just have to make a decision as to which tool to use (something
Windows users don't have the freedom to do).

> Which ones
> will work at all?  Which ones require a particular environment already
> installed?  Grr.

You seem to be frustrated  which makes me think you are trying to do too
much in one step.   "Divide and Conquer" is the key to learning about
new stuff.  As I said learn about the GUI in isolation.  Write some
simple "blink a led" type programs before you try to tackle complex
things like dealing with serial or USB i/o via the event loop etc.

FYI I have user Tcl/Tk & X11 + Athena Widget & now I use Gtk+ with glade
for GUI design.

Peter



2005\07\09@050558 by William Chops Westfield

face picon face

On Jul 9, 2005, at 12:53 AM, Rob Hamerling wrote:

>>> I thought that treating the serial port "normally" would
>>> be pretty easy; just open com1: as a file and do your reads and
>>> writes.  It's when you need to do NON-standard things like bit-bang
>>> the modem control lines that things become difficult.

>> How do you set the baudrate, or do you consider that a non-standard
>> operation?
>>
Typically it's an ioctl operation, isn't it?  yeah, that gets
complicated.

For the first effort, I'd require that the user set them correctly.
For a second effort, I'd be tempted to do something like
    exec("mode com1:9600,n,8,1 > nul:");

that still works, doesn't it?  It did back in the DOS days, and it looks
like XP still has "mode" as a command line utility...

BillW

2005\07\09@140533 by Gerhard Fiedler

picon face
Chen Xiao Fan wrote:

> The problem is that I am not willing to learn another language (object
> pascal) and to me they are in the same league of Visual C/C++ which I
> feel more difficult than plain C or Python or VB.

You may want to have a second look at it. It doesn't seem to me that the
Object Pascal/Delphi dialects are more difficult to learn than Python. (I
don't use them since I moved on from Turbo-Pascal

You didn't say whether you wanted GUI access or whether command line is
good enough. Programming Windows GUI applications in C is definitely more
complex than any of the other choices. The issue with this is not so much
the language. This is something you usually can learn rather quickly, at
least the basics that get you going, for any of the suggested languages.
But some of the GUI development environments shield you quite well from the
complexity that any GUI includes, whereas with others you have to get into
the ugly innards of whatever GUI library you are using. The best example is
the VB6 IDE: the language sucks, but you can write a reasonably nice GUI
that does something trivial in 10 minutes, without even knowing the first
thing about VB. That applies also to other similar IDE-based development
systems. I've never worked with Delphi, but I know the ones who use it
claim a similar ease. Using one of these, you don't have to worry about
system APIs and how things work; you drag and drop a button to where you
want it, set its properties, and write a function that does what you want
to happen when it gets pressed. That's about as simple as it gets. In the
time it takes you to learn how to achieve the same result with C in
Windows, you have written your complete application in Delphi or any of the
others with a decent IDE :)

Gerhard

2005\07\09@142352 by Peter

picon face

On Fri, 8 Jul 2005, Vitaliy wrote:

>> There's probably an existing open source library to do whatever you
>> might wish.  But FINDING it based on a vague idea of what you want to
>> accomplish is next to impossible...
>>
>> BillW
>
> I think that for anything but the simplest programs, you should have the
> design on paper before you start coding. If you don't know exactly what it is
> that you want to accomplish, what do you think you're going to end up with?

Imho for medium size projects it is better NOT to have it on paper.
Unless one likes to write on 850mm wide scrolls that is. Some system to
represent strongly structured data and interaction models, preferrably
in an editable and searchable way, is essential. I usually work alone
and I found out the hard way what my limits are and how small I have to
slice up something so I can manage the bugs. Besides small notes and
sketches there is no good reason for using paper. Statistics are your
best friend. If you handle *anything* with more than about 100 items
(pins, holes, wires, program steps - any or all of these things), you
better put aside serious reserves for finding and squashing bugs. It
simply does not work otherwise.

Peter

2005\07\09@142938 by Peter

picon face

On Sat, 9 Jul 2005, William Chops Westfield wrote:

> For the first effort, I'd require that the user set them correctly.
> For a second effort, I'd be tempted to do something like
>    exec("mode com1:9600,n,8,1 > nul:");

You actually mean system("...");

> that still works, doesn't it?  It did back in the DOS days, and it looks
> like XP still has "mode" as a command line utility...

If it helps any on *BSD you have to use stty or equivalent ioctls after
opening the port to set parameters or nothing will work ... deja vu

Peter

2005\07\09@162150 by Timothy J. Weber

face
flavicon
face
Gerhard Fiedler wrote:
> I've never worked with Delphi, but I know the ones who use it
> claim a similar ease. Using one of these, you don't have to worry about
> system APIs and how things work; you drag and drop a button to where you
> want it, set its properties, and write a function that does what you want
> to happen when it gets pressed. That's about as simple as it gets. In the
> time it takes you to learn how to achieve the same result with C in
> Windows, you have written your complete application in Delphi or any of the
> others with a decent IDE :)

Yes - I did my first Windows app to interface with a PIC using Delphi.
It took me about half an hour to find and decide on an open-source
serial component.  Installed it, dropped it on a form, and a few minutes
later I had it up and running.

Later I decided it would be good to add a full-blown binary file editor
- you know, view the hex digits on the left and ASCII on the right -
with File Open, Save, Save As, automatically reload most-recently-used
file, edit in-place, and send the result down the serial line on a
button press.  Another twenty minutes to pick an open-source control and
ten or twenty minutes max to get it integrated, most of which was no
more complicated than using a web form.

Delphi, VB, and C++Builder all have this in common.  Delphi and
C++Builder have the advantage that what you get when you're done is a
single statically-linked EXE (no big DLLs), it's a fully compiled
language (i.e., if you have to do something fast, you can), and it's
reasonably possible to get the same code running Linux.  Delphi has the
further advantage that its code is more legible than C++ (IMHO) and it
compiles much faster.

As a former command-line and C++ snob who has used (and still uses) many
languages, I find it much faster to develop a GUI with Delphi than it is
to develop a command-line tool, especially when the features start to
accumulate.  And, the resulting program is easier to use and maintain.

I'm skeptical of silver bullets.  Delphi isn't one.  But it's darn good
at quick, solid interfaces.
--
Timothy J. Weber                 http://www.lightlink.com/tjweber
@spam@tjweberKILLspamspamlightlink.com

2005\07\10@193512 by Vitaliy

flavicon
face
----- Original Message -----
From: "William Chops Westfield"
>>> There's probably an existing open source library to do whatever you
>>> might wish.  But FINDING it based on a vague idea of what you want
>>> to accomplish is next to impossible...
>>
>> for anything but the simplest programs, you should have the design
>> on paper before you start coding. If you don't know exactly what it is
>> you want to accomplish, what do you think you're going to end up with?
>
> You're misunderstanding.

Rather, you've misspoken. :) There are not many ways to misinterpret "a
vague idea of what you want to accomplish."

> Suppose, for example, that I start out with a
> task like "I want to drive my pickit1 from my linux box, using a GUI that
> looks very much like microchip's windows pickit1 software."  That's a
> pretty specific target.

I would go even further, and *list* the functionality that must be present
in the final product. The "must-haves" and the
"nice-to-haves-but-can-do-withouts".

> Assume that I understand the "hard" parts like
> talking over USB, the pickit1 "protocol", and so on.   Now, I know there
> are toolkits for doing windows-like interfaces under linux/X.  But how
> to I find out which ones are most appropriate for my task?  Which ones
> will work at all?  Which ones require a particular environment already
> installed?  Grr.

That's why you need to have a reasonably good understanding of what it is
that you want to accomplish. I bet by the time you're done listing the
requirements, you will be left with only a handful of libraries that fit
those requirements. The next step would be to compare these remaining
libraries to see which one would work best for your particular project.

As Peter suggested, "Divide and Conquer."

Best regards,

Vitaliy

2005\07\10@195300 by Vitaliy

flavicon
face
----- Original Message -----
From: "Peter" <KILLspamplpKILLspamspamactcom.co.il>
>> I think that for anything but the simplest programs, you should have the
>> design on paper before you start coding. If you don't know exactly what
>> it is that you want to accomplish, what do you think you're going to end
>> up with?
>
> Imho for medium size projects it is better NOT to have it on paper. Unless
> one likes to write on 850mm wide scrolls that is.

It should be possible to draw a "bird's view" representation of any project
on a single sheet of paper. But what I really meant was - you should at
least have a reasonably detailed description of what you're trying to
accomplish, before you start coding or start looking for libraries.

> Some system to represent strongly structured data and interaction models,
> preferrably in an editable and searchable way, is essential.

May I ask what system you use for your projects?

Best regards,

Vitaliy

2005\07\10@200919 by Chen Xiao Fan

face
flavicon
face
Thanks for all the replies. Actually my goal is really modest.
Something like Mark Rages' command line PICKit 1 utility or
Wouter's XWisp is my "ultimate" goal. Maybe my goal is much
lower than that depending on my progress.

I know almost nothing about host programming. I also do not
want to deal with GUI. I say Visual C/C++ is difficult because
I was overwhelmed by MFC. VB looks easier and I have lots of
examples written in VB. But still I consider it not so easy.
Delphi may be no more difficult than VB but there are less
examples and people around me only uses VB/VC/Java. So I think
Delphi is not an option for me. Maybe I will look into it later
as well as VC. For now I will stick with Python/GCC/VB.

Now the next question is the examples of serial/USB communication
for Python and plain GCC on Windows and Linux. Any good
introductory web sites?

Regards,
Xiaofan

{Original Message removed}

2005\07\10@230340 by WH Tan

flavicon
face
Maybe it's just me... the one that never work with other 'platform'. Anyway
if you consider DOS is one, then I did somehow...

Well I think to work with USB, perhaps MS dev tools is the best!?

Best regards,
WH Tan

PS: I'm still waiting the official release of VS.net 2005. But I think I
will talk to my boss soon... Meanwhile I'm downloading VC++ 2005 beta
Express edition... 398MB out of 516MB, still 45mins to go...



{Original Message removed}

2005\07\11@013123 by Chen Xiao Fan

face
flavicon
face
Guess that they are the best. It is just they are too difficult for
me right now.

You are not alone. My two brothers are professional software
developers. One of them is using VC++ 6 and only works on Windows.
They used to have Linux driver development teams but now they
are relying on open source drivers which does not have all the
advance features on the Linux side. The other is developing using
C++/Java now for SUN Solaris /Redhat Linux (telecom applications)
but he is normally using the Windows platform as the main
development machine.

For me I have used many platforms: Apple II / DPS-8 / Micro VAX /
VAX VMS /Sun OS and Solaris /DOS/Windows 9x/2k/XP /Linux during my
many years in schools. Yet I never learned how to program. :(
Therefore the platform is not an important issue.

Once I had access to VS.net in a lab. The lab was doing some project
for Intel regarding VRM for next generation processors. Intel donated
a fast US$3000 PC with 1GB of RAM and ORCAD donated the PSpice software.
Then somehow Microsoft knew this and donated a whole set of Windows
XP + VS.net 2002 + others and quite some books on programming even
though the research project had nothing to do with software. Anyway,
we installed it since it was free. However we looked at it and found
that it was better to use VS6 for simple programming so it was
uninstalled.

Regards,
Xiaofan


{Original Message removed}

2005\07\11@013723 by Chen Xiao Fan

face
flavicon
face
Maybe we should forward this to the GNUPIC mailing list.
Anyway the leading members in the GNUPIC list are also
monitoring the PICList. Hopefully they will look into
this. XWisp2 is really very nice!

Regards,
Xiaofan

{Original Message removed}

2005\07\13@195314 by Chen Xiao Fan

face
flavicon
face
What is the difference between VC++ 2005 Express edition and the
regular version? It is said to be not able to produce standalone
applications.  How long will Beta II remain functioning
after register it? I know that one needs to register it in
30 days.

Regards,
Xiaofan

-----Original Message-----
From: WH Tan
Sent: Monday, July 11, 2005 11:00 AM

Maybe it's just me... the one that never work with other 'platform'. Anyway
if you consider DOS is one, then I did somehow...

Well I think to work with USB, perhaps MS dev tools is the best!?

Best regards,
WH Tan

PS: I'm still waiting the official release of VS.net 2005. But I think I
will talk to my boss soon... Meanwhile I'm downloading VC++ 2005 beta
Express edition... 398MB out of 516MB, still 45mins to go...

2005\07\13@235005 by WH Tan

flavicon
face
It's a strip down version of the full version and it's available for public
download. Microsoft recent public realase not including an IDE. Hoever this
time around, it includes an IDE! I think the major difference is it has no
MFC library support. Apart some optimizations are not available in express
edition.

Where did you hear about that? It can't produce a standalone application?
Well I think you have to register (or Microcost sometime refers it as
activate) it. If not it will only work for 30 days. I think there is no time
limit after you register it. I also believe there will be an official
express edition for public download once it is really!

>From Microsoft web site:

Top 10 Cool Things about Visual C++ 2005 Express Edition
Here are the Top 10 cool things about Visual C++ 2005 Express Edition.

- Superior compatibility with language standards allow you to compile almost
any C/C++ source code
- Build powerful, high-performance 32-bit native code applications using the
Microsoft Platform SDK
- Quickly create .NET Framework applications with advanced features such as
data access, networking, built-in printing support, and Web Services
- Add professional quality video, 2D/3D graphics, and sound to your
applications using the DirectX SDK
- Build applications that interact with website such as eBay.com,
Amazon.com, and MapPoint.com
- Visual designers enable drag-and-drop creation of user interface code when
building .NET Framework applications
- Import additional controls and components for rapidly building powerful
applications
- Automatic statement completion helps you code quickly and correctly
- Quickly find and eliminate programming errors using an intuitive graphical
debugger
- Small download makes it easy to get started

I'm doubt over the last comment anyway. 516MB is considered small download?
Never mind it's free anyway ;)

Best regards,
WH Tan


{Original Message removed}

2005\07\14@000328 by WH Tan

flavicon
face

>I also believe there will be an official
>express edition for public download once it is really!

I think sometime I am really 'out of control' when typing in speed. I should
has type: "I also believe there will be an official express edition for
public download once it is ready!"

WH Tan

2005\07\14@002414 by Chen Xiao Fan

face
flavicon
face
Thanks for the reply. I downloaded the VB and VC version yesterday
evening over my newly installed 2Mbps cable broadband (so expensive here
in Singapore compared to Hong Kong, Korea and Japan?). It is not that
bad : 1 hours and 40 minutes for VB and VC. Therefore it is not
that big for broadband users. :)

I installed the VB express beta II version and in a glance I do not see a
compile to exe option like in VB 6. Maybe I need to look harder. I will
check out the VC express version.

I can remember where I come across the cost of the express edition
but I remember something like US$49. Maybe I am wrong here.

Regards,
Xiaofan

{Original Message removed}

2005\07\14@014725 by WH Tan

flavicon
face
Hi,

I downloaded VB day after I have done the VC. Anyway never did the
installation until now. OK it's installed. I think it's there. After you
have set up a project, from the menu, choose Build>Build [your project
name].

Best regards,
WH Tan

{Original Message removed}

2005\07\14@202236 by Chen Xiao Fan

face
flavicon
face
I find from the FAQ section of the Microsoft Visual Studio Express
Edition website that each will indeed be sold at US$49 once
formally released.

Still I did not see any mentioning of the beta testing period so
hopefully there are no time limit. It is meant for the beginners,
students, hobbyists. Perfect for me. For professionals who need
MFC/ATL/ActiveX then the full version is necessary.

As a test drive, I downloaded some VB.NET and C# USB codes from Lakeview
Research and they are actually working.

Another thing is that Microsoft is really correct to say that they
are small (<50MB) since the 516MB has the .NET 2 Beta, MSDN
Express (big) and SQL Express. The VB/VC/C#/J# portion are less than
50MB.

Regards,
Xiaofan

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...