Gui application for embedded system

On 08/07/14 04:42, Randy Yates wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> [...]
>> There's a few Python examples in which they actually *spawn threads*
>> to do socket service. Lordy.
> 
> Les,
> 
> Let's say you're waiting for a byte to come across a socket. As far as I
> know there are two alternatives to using a thread: 1) block until it's
> received, or 2) provide a callback. Blocking is usually not acceptable.
> Using a callback that executes from another thread can be a bad idea.
> 
> So we're left with spawning a thread. That actually seems like the
> *best* solution to me. Why do you (apparently) disagree? 
> 
> (Note that this really has nothing to do with Tcl specifically.)
> 

You can also use "select" to wait on a whole bunch of sockets at the
same time.  This is the usual way to handle lots of sockets without
needing the overhead of a thread (or process) for each socket
(regardless of the programming language).

However, when you are programming in Python you are often concerned with
ease of programming, rather than maximal speed - and spawning a thread
for each socket is often a very easy way to handle connections.  Python
makes multi-threading easy, as many of the key structures are already
thread-safe due to the GIL, and things like locks and queues are
convenient in the library.  It's less good for multi-threading as a way
of speeding up calculations, as only one thread does Python work at a time.

Alternatively, you can use the traditional Python approach of letting
someone else do the hard work, and use a library - if you want a
sophisticated networking application, use twisted to do the work and
then you don't have to care how it is implemented.

>I am asking this here since you have probably met the
>problem. I have developped an embedded system that has
>a serial link (RS232) as user interface. So far we used
>a terminal to communicate but I now need to develop
>a gui application for windows 7.
>
>I have tried doing that with Excel with a commercial
>active X but I get an "acces denied" error when I open
>the port.
>
>I have also tried python with serial python but there are
>installation issues.
>
>What would you suggest as a solution?
>

I have used Pyhton with Tkinter GUI on Win 7 with no problems. Pyserial is
compatible with python v2.7.6 so make sure your  version is comparible with
that. Version 3.0 onwards did not work with pyserial for me.



	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

Paul <paul@pcserviceselectronics.co.uk> writes:

> Or even the old pyserial documentation pyserial.sourceforge.net
>
> In as standard module that can be included in most distributions.

Well, Les seemed to be hung up on what's included so I brought up
asyncio since it's included now.

Anssi Saari wrote:
> Paul <paul@pcserviceselectronics.co.uk> writes:
>
>> Or even the old pyserial documentation pyserial.sourceforge.net
>>
>> In as standard module that can be included in most distributions.
>
> Well, Les seemed to be hung up on what's included so I brought up
> asyncio since it's included now.
>


Dunno about 'hung up on', but not including async I/O as a first class
... thing ( object? service? doohickey? ) in a scripting language
rather misses the classical justification for having a  scripting
language in the first place.

Scripting languages are for automating things you'd otherwise have to
type for. Since we're in an embedded newsgroup, I'm rather shocked
that this isn't the sort of thing practitioners use daily.

I used to use 'C' for this, then AWK, then Perl, then Tcl and SFAIK all
progress ended there.

SFAIK, outside of shell scripts, the original* "scripting" thing was
logic for things like establishing a SLIP/PPP connection.

*far enough back, but not that far. And yes you betcha on Winders...

There's an entire other rant :) about the politics of Tcl
which includes people like Stallman. But the principal value I find in
Tcl is the underlying ... philosophy of it as a language. It's just
had a very highly qualified team steering it all these years.

-- 
Les Cargill

On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:

> Dunno about 'hung up on', but not including async I/O as a first
> class ... thing ( object? service? doohickey? ) in a scripting
> language rather misses the classical justification for having a
> scripting language in the first place.
>
> Scripting languages are for automating things you'd otherwise have to
> type for. Since we're in an embedded newsgroup, I'm rather shocked
> that this isn't the sort of thing practitioners use daily.

Python isn't a "scripting language".  It's a general-purpose
programming language like Java, Pascal, etc.

Some people use it for scrpting stuff that they would otherwise do at
a shell prompt, but that's not what Python was intended for, nor is it
optimized for that.

-- 
Grant Edwards               grant.b.edwards        Yow! HAIR TONICS, please!!
                                  at               
                              gmail.com            

Les Cargill <lcargill99@comcast.com> writes:
> I used to use 'C' for this, then AWK, then Perl, then Tcl and SFAIK all
> progress ended there.

The current favorite for this type of thing (embedded scripting where
you want something smaller than Python) is probably Lua, www.lua.org.
There are also some small embedded Lisps and it's not that hard to write
them.

> There's an entire other rant :) about the politics of Tcl
> which includes people like Stallman. But the principal value I find in
> Tcl is the underlying ... philosophy of it as a language.

I don't think Stallman had any political objections to Tcl (i.e. in
terms of free software ideology).  His complaint was on technical
grounds:

   http://vanderburg.org/OldPages/Tcl/war/

Basically Tcl is what some of the language-design crowd calls "stringly
typed" (a pun on "strongly typed"): all values are represented as
character strings, which seems very flexible at first, but it's
difficult to manage complex programs where stuff is kept like that.
Javascript and Lua also suffer from this problem to some extent.  Python
keeps numbers, strings, etc. strictly segregated.  There's no
compile-time type checking, but any type mismatch causes a runtime
exception, so if you code in a type-aware style, then any mistakes get
caught pretty fast during development.

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> I used to use 'C' for this, then AWK, then Perl, then Tcl and SFAIK all
>> progress ended there.
>
> The current favorite for this type of thing (embedded scripting where
> you want something smaller than Python) is probably Lua, www.lua.org.
> There are also some small embedded Lisps and it's not that hard to write
> them.
>
>> There's an entire other rant :) about the politics of Tcl
>> which includes people like Stallman. But the principal value I find in
>> Tcl is the underlying ... philosophy of it as a language.
>
> I don't think Stallman had any political objections to Tcl (i.e. in
> terms of free software ideology).  His complaint was on technical
> grounds:
>
>     http://vanderburg.org/OldPages/Tcl/war/
>

It's been subsequently shown that Stallman a) didn't understand Tcl and 
b) thought Scheme was a competitor.

"Politics" is a poor word, but it's best I could do.

> Basically Tcl is what some of the language-design crowd calls "stringly
> typed" (a pun on "strongly typed"): all values are represented as
> character strings, which seems very flexible at first, but it's
> difficult to manage complex programs where stuff is kept like that.

I fundamentally disagree.

> Javascript and Lua also suffer from this problem to some extent.  Python
> keeps numbers, strings, etc. strictly segregated.  There's no
> compile-time type checking, but any type mismatch causes a runtime
> exception, so if you code in a type-aware style, then any mistakes get
> caught pretty fast during development.
>

Yep.

-- 
Les Cargill

Grant Edwards wrote:
> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
>
>> Dunno about 'hung up on', but not including async I/O as a first
>> class ... thing ( object? service? doohickey? ) in a scripting
>> language rather misses the classical justification for having a
>> scripting language in the first place.
>>
>> Scripting languages are for automating things you'd otherwise have to
>> type for. Since we're in an embedded newsgroup, I'm rather shocked
>> that this isn't the sort of thing practitioners use daily.
>
> Python isn't a "scripting language".  It's a general-purpose
> programming language like Java, Pascal, etc.
>

Interpreted language, then - I probably made the error of merging
those two out of habit over the last 20 years or so.

Pascal and Java can be used to generate native machine code. SFAIK, 
Python cannot.

> Some people use it for scrpting stuff that they would otherwise do at
> a shell prompt, but that's not what Python was intended for, nor is it
> optimized for that.
>

Fair enough. The terminology gets a bit fuzzy anyway - what I've
seen of Python in scripting, it's used in pipes under BASH or the like.

-- 
Les Cargill

On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
> Grant Edwards wrote:
>> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:
>>
>>> Dunno about 'hung up on', but not including async I/O as a first
>>> class ... thing ( object? service? doohickey? ) in a scripting
>>> language rather misses the classical justification for having a
>>> scripting language in the first place.
>>>
>>> Scripting languages are for automating things you'd otherwise have to
>>> type for. Since we're in an embedded newsgroup, I'm rather shocked
>>> that this isn't the sort of thing practitioners use daily.
>>
>> Python isn't a "scripting language".  It's a general-purpose
>> programming language like Java, Pascal, etc.
>>
>
> Interpreted language, then -

It's not interpreted either.  It's generally compiled into byte-code
that is then run on a VM Just like Java is (mostly), and like Pascal
often was back in the day.  The most commonly used Python compiler
generates byte-code for a "native" Python VM, but there also Python
compilers that generate byte-code for the Java VM and (IIRC) one or
two others.

> I probably made the error of merging those two out of habit over the
> last 20 years or so.
>
> Pascal and Java can be used to generate native machine code. SFAIK, 
> Python cannot.

You're right, the current native-code implementations of Python are
still incomplete.  Due to the dynamic typing, generating purely native
code is difficult.

>> Some people use it for scrpting stuff that they would otherwise do at
>> a shell prompt, but that's not what Python was intended for, nor is it
>> optimized for that.
>
> Fair enough. The terminology gets a bit fuzzy anyway - what I've seen
> of Python in scripting, it's used in pipes under BASH or the like.

I'm sorry, I don't know how a language is "used in pipes under BASH".
Almost all of the programs I see connected together with pipes under
bash are written in C.

Does that mean C is a "scripting language"?

-- 
Grant Edwards               grant.b.edwards        Yow! Sign my PETITION.
                                  at               
                              gmail.com            

On Fri, 11 Jul 2014 14:13:36 +0000, Grant Edwards wrote:

> On 2014-07-10, Les Cargill <lcargill99@comcast.com> wrote:

>> Fair enough. The terminology gets a bit fuzzy anyway - what I've seen
>> of Python in scripting, it's used in pipes under BASH or the like.
> 
> I'm sorry, I don't know how a language is "used in pipes under BASH".
> Almost all of the programs I see connected together with pipes under
> bash are written in C.
> 
> Does that mean C is a "scripting language"?

Nothing much to it.  The pipe works by patching the STDOUT from the first 
program into the STDIN of the second.  As long as the programs work with 
the POSIX conventions of STDIN and STDOUT it's not language-centric at 
all.

	Mel.