Gui application for embedded system

[Lanarcam]

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?

[Don Y]

On 6/26/2014 1:18 PM, Lanarcam wrote:
> 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.

Why? Are you planning on doing some additional (pre- or
post-) *processing* on the Windows 7 side? Or, to layout
the information in a more visible "structure" (e.g., like
a "form" instead of "streaming text")? Or, just to make
it pretty-pretty?

What will you do in the *absence* of a Windows 7 "client"?
Will your device be usable? Or, is the W7 machine to be
considered *the* user interface?

I've had some success using curses-based presentations.
This can provide dialogs, menus, etc. -- many of the
same "controls" (widgets) that you would typically
find in a GUI "form" -- but without all the overhead
*nor* the "external Windows computer" requirement.

[i.e., you could continue to use your device with a
dumb terminal, an ANSI terminal, a terminal emulator,
"Hyperterm", etc. and have a consistent appearance]

[Rob Gaddi]

Fighting through the installation issues. Python, PySerial, and PySide
are exactly how I attack similar problems when I have to do such things
here.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

[Lanarcam]

Le 26/06/2014 22:44, Don Y a �crit :

> On 6/26/2014 1:18 PM, Lanarcam wrote:
>> 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.
>
> Why? Are you planning on doing some additional (pre- or
> post-) *processing* on the Windows 7 side? Or, to layout
> the information in a more visible "structure" (e.g., like
> a "form" instead of "streaming text")? Or, just to make
> it pretty-pretty?

We need a more user friendly access, for instance, there is
a time setting command that requires the user to enter the time
in a given format such as: "TIME XX YY ZZ". A gui user interface
would control the numbers ( 0 < XX < 24) format the string and
send it on the serial link.

There is also the possibility of postprocessing the data
to form tables or graphs. (The data are mainly time stamped
digital and analog inputs.

>
> What will you do in the *absence* of a Windows 7 "client"?
> Will your device be usable?

Yes, it stores the data on a SD card which can be later transferred
on a PC. (we use the FAT32 format).

However, there is also a "programming" interface that can be used
to trigger actions or recordings.

> Or, is the W7 machine to be
> considered *the* user interface?

Yes.

>
> I've had some success using curses-based presentations.
> This can provide dialogs, menus, etc. -- many of the
> same "controls" (widgets) that you would typically
> find in a GUI "form" -- but without all the overhead
> *nor* the "external Windows computer" requirement.

I will have a look. We need however to run the user
application on Windows 7, that is a requisite.

[Lanarcam]

Le 26/06/2014 22:54, Rob Gaddi a �crit :

> On Thu, 26 Jun 2014 22:18:38 +0200
> Lanarcam <lana...@yahoo.fr> wrote:
>
>> 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?
>
> Fighting through the installation issues. Python, PySerial, and PySide
> are exactly how I attack similar problems when I have to do such things
> here.
>

Thanks for that, I will fight through ;)

[Tim Wescott]

On Thu, 26 Jun 2014 13:54:06 -0700, Rob Gaddi wrote:

> On Thu, 26 Jun 2014 22:18:38 +0200 Lanarcam <lana...@yahoo.fr> wrote:
>
>> 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?
>
> Fighting through the installation issues. Python, PySerial, and PySide
> are exactly how I attack similar problems when I have to do such things
> here.

Whatever you do, if it's with Windows (or Linux for that matter) you'll
be fighting the installation issues.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[Robert Wessel]

On Thu, 26 Jun 2014 22:18:38 +0200, Lanarcam <lana...@yahoo.fr>
wrote:

Why on earth would you want to use Excel as a base?

If you want to use Windows to run the management application, just
download one of the Visual Studio Express versions from MS (free), and
use VB.NET (I'm thinking you might be familiar with VBA, which is why
you're thinking Excel, and VB.NET would be most similar), or use C#,
which is definitely a better language. And there are a million
articles on accessing the serial post from C# (probably VB.NET too),
but just starting with the System.IO.Ports.SerialPort documentation
from MS isn't that hard.

Of course you may want to consider if you really want to tie yourself
to Windows to manage your device, but that's a different issue, and if
you've already decided that, it's moot.

[Reinhardt Behm]

Have a look at Qt <https://qt-project.org/>.

You can write your program and compile it for Windows or Linux without any
changes. It comes with an IDE (QtCreator). For Windows you can use MingGW as
a compiler.
It is (L)GPL. That means you can keep your source secret and deploy the
relevant libs.
Installation on customers Windows PC consists of copying the relevant EXE
and DLLs into one directory.

Beware, it's huge and the learning curve is steep. The documentation is
excellent. But it's worth the effort if you will use it for more projects.

--
Reinhardt

[Mikko OH2HVJ]

Robert Wessel <robert...@yahoo.com> writes:
> On Thu, 26 Jun 2014 22:18:38 +0200, Lanarcam <lana...@yahoo.fr>

>>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.

...

>>What would you suggest as a solution?

> If you want to use Windows to run the management application, just
> download one of the Visual Studio Express versions from MS (free), and
> use VB.NET (I'm thinking you might be familiar with VBA, which is why
> you're thinking Excel, and VB.NET would be most similar), or use C#,
> which is definitely a better language. And there are a million
> articles on accessing the serial post from C# (probably VB.NET too),
> but just starting with the System.IO.Ports.SerialPort documentation
> from MS isn't that hard.

I warmly recommend following this suggestion. I did one gas analyzer
calibration system with Excel and VBA, which was a bad idea.

It took some time to get used to the VS (I mostly code in bare metal/Linux/web
world), but after that VS has served me well for developing small GUI apps
whenever native Windows has been the requirement.

And if you use just the MS supplied class libraries, VSE will create
an installation package and everything for you.

--
Mikko OH2HVJ

[Jack]

For things like this I usually create a GUI using Java and RXTX.

Bye Jack
--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

[Sp...@controlq.com]

On Thu, 26 Jun 2014, Lanarcam wrote:

> Date: Thu, 26 Jun 2014 22:18:38 +0200
> From: Lanarcam <lana...@yahoo.fr>
> Newsgroups: comp.arch.embedded
> Subject: Gui application for embedded system

I would suggest tcl/tk for a very rapid solution, with GUI and a flexible
serial interface. While not the latest and greatest scripting language,
(sic Python/Kivy), the learning curve is simple, the widgets are built in,
and it runs on Windows, Linux, Unix and various.

HTH,
Cheers,
Rob.

[Dombo]

Op 27-Jun-14 2:55, Reinhardt Behm schreef:

And it comes with support for serial ports (QSerialPort class) out of
the box, so you won't have to deal with the native API calls. A
potential downside is that you have to program in C++, which has its own
rather steep learning curve.

[Tim Wescott]

OTOH, if you already know C++ it's a nice environment.

I didn't know it had the serial port class -- I'll be able to use that
within the next month, if it has the features I need.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

[Olaf Kaluza]

Tim Wescott <t...@seemywebsite.please> wrote:

>I didn't know it had the serial port class -- I'll be able to use that
>within the next month, if it has the features I need.

It did not have the feature to ask how many bytes in the
send-buffer. Only in case you like to switch the direction of
RS485. .-)

Olaf

[Randy Yates]

Reinhardt Behm <rb...@hushmail.com> writes:

> Lanarcam wrote:
>
>> 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?
>
> Have a look at Qt <https://qt-project.org/>.

I also second this recommendation. Been using it for a couple of months
and I just love it! VERY powerful!

If you know C++, I wouldn't say it's difficult to learn how to use -
just perhaps a little time-consuming. And the documentation IS
excellent.
--
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

[Lanarcam]

Le 29/06/2014 22:31, Randy Yates a �crit :

I would like to thank all of those who have answered and
provided good advice. I am still undecided, but I think
I will try the C# way since it appears rather easy and
since I don't need a multi platform solution and I won't
spend too much time on it, hopefully.

Qt seems interessant also, I know C++ and I will look
into that, as a second choice.

[Anssi Saari]

Dombo <do...@disposable.invalid> writes:

> And it comes with support for serial ports (QSerialPort class) out of
> the box, so you won't have to deal with the native API calls.

Thanks! It's good to know there's serial port support built in now. I
remember we had to find a separate serial qclass for a small Qt project back in
2011.

[Randy Yates]

Lanarcam <lana...@yahoo.fr> writes:
> [...]
> I will try the C# way ...

<facepalms>

[Rob Gaddi]

On Fri, 27 Jun 2014 14:38:04 -0400
Sp...@ControlQ.com wrote:

>
> I would suggest tcl/tk for a very rapid solution, with GUI and a flexible
> serial interface. While not the latest and greatest scripting language,
> (sic Python/Kivy), the learning curve is simple, the widgets are built in,
> and it runs on Windows, Linux, Unix and various.
>
> HTH,
> Cheers,
> Rob.

Tk's not a terrible graphics toolkit, but what manner of sadist are you
that you would suggest Tcl as the language of choice for anyone without
a gun to their head? I've written assembly for a half dozen
processors, C, C++, C#, Python, Perl, VHDL, Verilog, three flavors of
BASIC, Java, Javascript, and Awk, and in all that have NEVER
encountered a language so unlikely to give you the results you want
without extensive debugging as when my EDA tools force me to write Tcl.

[Grant Edwards]

On 2014-06-30, Rob Gaddi <rga...@technologyhighland.invalid> wrote:
> On Fri, 27 Jun 2014 14:38:04 -0400
> Sp...@ControlQ.com wrote:
>
>>
>> I would suggest tcl/tk for a very rapid solution, with GUI and a flexible
>> serial interface. While not the latest and greatest scripting language,
>> (sic Python/Kivy), the learning curve is simple, the widgets are built in,
>> and it runs on Windows, Linux, Unix and various.
>>
>> HTH,
>> Cheers,
>> Rob.
>
> Tk's not a terrible graphics toolkit, but what manner of sadist are you
> that you would suggest Tcl as the language of choice for anyone without
> a gun to their head? I've written assembly for a half dozen
> processors, C, C++, C#, Python, Perl, VHDL, Verilog, three flavors of
> BASIC, Java, Javascript, and Awk, and in all that have NEVER
> encountered a language so unlikely to give you the results you want
> without extensive debugging as when my EDA tools force me to write Tcl.

Seconded. If you want to use Tk, use Python, or Scheme, or sticks and
rocks. _Anything_ but TCL.

--
Grant Edwards grant.b.edwards Yow! ... I have read the
at INSTRUCTIONS ...
gmail.com

[Lanarcam]

Le 30/06/2014 17:12, Randy Yates a �crit :

> Lanarcam <lana...@yahoo.fr> writes:
>> [...]
>> I will try the C# way ...
>
> <facepalms>
>

Well... ;)

I have been able today to install the dev environment
which is free and develop a first interface with a
text window to display the messages exchanged and
two combo boxes for the selection of the ports and
the speed. I could also make a test with a loopback
serial interface (two virtual ports).

It is rather easy, you find a lot of information on the
web. I am not a fan of windows but I must admit that
that environment looks professional, you can even deploy
an installation in one click.

I will see if it works, I can't test it here, I must
send it to another person, not the best conditions but
that's how it is.

[hamilton]

On 6/30/2014 10:35 AM, Rob Gaddi wrote:
> On Fri, 27 Jun 2014 14:38:04 -0400
> Sp...@ControlQ.com wrote:
>
>>
>> I would suggest tcl/tk for a very rapid solution, with GUI and a flexible
>> serial interface. While not the latest and greatest scripting language,
>> (sic Python/Kivy), the learning curve is simple, the widgets are built in,
>> and it runs on Windows, Linux, Unix and various.
>>
>> HTH,
>> Cheers,
>> Rob.
>
> Tk's not a terrible graphics toolkit, but what manner of sadist are you
> that you would suggest Tcl as the language of choice for anyone without
> a gun to their head? I've written assembly for a half dozen
> processors, C, C++, C#, Python, Perl, VHDL, Verilog, three flavors of
> BASIC, Java, Javascript, and Awk, and in all that have NEVER
> encountered a language so unlikely to give you the results you want
> without extensive debugging as when my EDA tools force me to write Tcl.
>
>

You have never wrote in Forth !

Forth, the write only language.

h

[Dombo]

Op 30-Jun-14 20:26, hamilton schreef:

I thought that was PERL...and LISP...

[Randy Yates]

Lanarcam <lana...@yahoo.fr> writes:

Well I guess I can't argue with results.

[Reinhardt Behm]

In that category APL is the winner.

--
Reinhardt

[Grant Edwards]

On 2014-07-01, Reinhardt Behm <rb...@hushmail.com> wrote:
> hamilton wrote:

[...]

>> Forth, the write only language.
>
> In that category APL is the winner.

When I learned APL, it was on VAX/VMS using Lear Sieglar ADM3 ASCII
terminals. Not only didn't they the APL character set, most of them
didn't even have lower case. With the proper character set, I thought
APL was pretty readable (with a little practice).

--
Grant

[Allan Herriman]

On Mon, 30 Jun 2014 09:35:43 -0700, Rob Gaddi wrote:

> On Fri, 27 Jun 2014 14:38:04 -0400 Sp...@ControlQ.com wrote:
>
>
>> I would suggest tcl/tk for a very rapid solution, with GUI and a
>> flexible serial interface. While not the latest and greatest scripting
>> language, (sic Python/Kivy), the learning curve is simple, the widgets
>> are built in,
>> and it runs on Windows, Linux, Unix and various.
>>
>> HTH,
>> Cheers,
>> Rob.
>
> Tk's not a terrible graphics toolkit, but what manner of sadist are you
> that you would suggest Tcl as the language of choice for anyone without
> a gun to their head? I've written assembly for a half dozen processors,
> C, C++, C#, Python, Perl, VHDL, Verilog, three flavors of BASIC, Java,
> Javascript, and Awk, and in all that have NEVER encountered a language
> so unlikely to give you the results you want without extensive debugging
> as when my EDA tools force me to write Tcl.

[somewhat OT]

I have similar experiences, and have similar feelings for TCL. Yet if I
were to create a tool that needed an embeddable scripting language, I
would consider TCL, simply because all other other tools (of the sort I
believe you're thinking of (e.g. logic simulation and synthesis)) already
use TCL and the users already programs in TCL and will want to reuse
those scripts.

What other options are there if we restrict ourselves to lightweight
shells that are designed to be embedded into other programs?

TCL, Lua and Squirrel come to mind. I wouldn't describe any as wildly
popular.
Any others?

Allan

[Mel Wilson]

On Tue, 01 Jul 2014 02:21:31 +0000, Allan Herriman wrote:

> On Mon, 30 Jun 2014 09:35:43 -0700, Rob Gaddi wrote:
>
>> On Fri, 27 Jun 2014 14:38:04 -0400 Sp...@ControlQ.com wrote:
>>
>>
>>> I would suggest tcl/tk for a very rapid solution, with GUI and a
>>> flexible serial interface. While not the latest and greatest
>>> scripting language, (sic Python/Kivy), the learning curve is simple,
>>> the widgets are built in,
>>> and it runs on Windows, Linux, Unix and various.
>>>
>>> HTH,

> I have similar experiences, and have similar feelings for TCL. Yet if I
> were to create a tool that needed an embeddable scripting language, I
> would consider TCL, simply because all other other tools (of the sort I
> believe you're thinking of (e.g. logic simulation and synthesis))
> already use TCL and the users already programs in TCL and will want to
> reuse those scripts.
>
> What other options are there if we restrict ourselves to lightweight
> shells that are designed to be embedded into other programs?
>
> TCL, Lua and Squirrel come to mind. I wouldn't describe any as wildly
> popular.
> Any others?

From my experience, I decided that if I ever had to implement a project
using only *one* language -- application code, user interface, scripting,
anything else -- the language would be Forth. For a while after I got an
Atari 512, Forth was the only good language on the machine so I got kind
of familiar. Still glad that I've never hit a requirement for using only
one language. (Used Tcl/Tk in one application specifically to provide a
GUI to an embedded system. It was -- OK. Quite lightweight, which was
the point.)

>
> Allan

[Gerhard Mesenich]

On 26/06/14 22:18, Lanarcam wrote:

> 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.

Use Lazarus (or fpgui). You might not have heard about it yet :).

Lazarus is a cross platform open source Object Pascal RAD-IDE modeled
after Delphi. It is the simplest and by far the easiest method I know to
generate good looking stable Guis mainly by simple drag and drop and
afterwards setting the properties of the gui elements with the property
editor. This generates the basic pascal framework in which you later
fill in the specific details of the application.

Afterwards you can compile for all mayor operating systems from the same
source with only minimally changed specific settings. RS232
communication is certainly available, it may even be in the main
distribution right away. It should not present any mayor problems. I
have used a FTDI-USB chip about 10 years ago, for which a Delphi driver
was/is available from FTDI, which hopefully should work with Lazarus
too. This is most likely the easiest way to get USB running with minimal
effort.

Lazarus uses the same graphical elements of the operating system for
which it is compiled, so you get a native system look and feel. After
over 10 years of very active development it is now finally in a very
stable and usable state.


http://sourceforge.net/projects/lazarus/

http://en.wikipedia.org/wiki/Lazarus_%28IDE%29

Fully installed on Windows with all source and examples Lazarus takes
about 700Mb.

---

A very good similar lightweight alternative to Lazarus especially for
guis for embedded systems is fpgui. It uses the same pascal compiler as
Lazarus (FPC), but the gui is almost completely programmed in pascal
sitting directly on the api, using fpgui native elements. With this you
get a very fast lightweight gui with consistent look and feel on the
different operating systems. For technical stuff I think this is an
advantage, even if it looks slightly different than the native
applications (fpgui look).

http://fpgui.sourceforge.net/

http://en.wikipedia.org/wiki/Fpgui

Simple installation (recommended):

http://www.turbocontrol.com/easyfpgui.htm


All in all the above are by far the simplest and fastest ways for making
good looking stable and professional GUI interfaces on any common
operating system for embedded systems. Pascal is pretty close to C, so
getting familiar should be quite easy for a C programmer. Pascal is well
suited even for safety critical applications; I have seen some very
heavy and dangerous mining equipment controlled with Pascal interfaces
(Delphi), of cause bypassed with emergency shutdowns.

Regards,
Gerhard

[Anssi Saari]

Allan Herriman <allanh...@hotmail.com> writes:

> What other options are there if we restrict ourselves to lightweight
> shells that are designed to be embedded into other programs?
>
> TCL, Lua and Squirrel come to mind. I wouldn't describe any as wildly
> popular.
> Any others?

Python is embeddable. I'd really love to have EDA tools with Python
scripting instead of TCL! But as you say, it's doubtful TCL's reign is
in any way threatened. It's there and it works. I can't see a business
case in it and I doubt many customers have interest.

[Tom Gardner]

On 01/07/14 03:21, Allan Herriman wrote:
> I have similar experiences, and have similar feelings for TCL. Yet if I
> were to create a tool that needed an embeddable scripting language, I
> would consider TCL, simply because all other other tools (of the sort I
> believe you're thinking of (e.g. logic simulation and synthesis)) already
> use TCL and the users already programs in TCL and will want to reuse
> those scripts.

I note that the new Xilinx FPGA tool is based around TCL.
I haven't, yet, experimented with it sufficiently to see
whether I "approve" of the TCL!

[Les Cargill]

Grant Edwards wrote:
> On 2014-06-30, Rob Gaddi <rga...@technologyhighland.invalid> wrote:
>> On Fri, 27 Jun 2014 14:38:04 -0400
>> Sp...@ControlQ.com wrote:
>>
>>>
>>> I would suggest tcl/tk for a very rapid solution, with GUI and a flexible
>>> serial interface. While not the latest and greatest scripting language,
>>> (sic Python/Kivy), the learning curve is simple, the widgets are built in,
>>> and it runs on Windows, Linux, Unix and various.
>>>
>>> HTH,
>>> Cheers,
>>> Rob.
>>
>> Tk's not a terrible graphics toolkit, but what manner of sadist are you
>> that you would suggest Tcl as the language of choice for anyone without
>> a gun to their head? I've written assembly for a half dozen
>> processors, C, C++, C#, Python, Perl, VHDL, Verilog, three flavors of
>> BASIC, Java, Javascript, and Awk, and in all that have NEVER
>> encountered a language so unlikely to give you the results you want
>> without extensive debugging as when my EDA tools force me to write Tcl.

My comment below is predicated on having learned the handful of ...
unexpected things about Tcl that generally confuse people long ago
in a galaxy far away...

I also don't see LISP on your list ( ha! ) So that's probably why Tcl
seems so odd. It was also that or (shudder) Perl at the time, back in
the 20th Century...

If this comes up again, please consider buying and working through the
Brent Welch book. I think it'll raise your pain level.

>
> Seconded. If you want to use Tk, use Python, or Scheme, or sticks and
> rocks. _Anything_ but TCL.
>

Phfbbt! Slander! :)

Writing Tcl from scratch is , I would think, different from having to
back Tcl into an EDA kit. I also have to wonder if EDA kits froze to
ancient versions of Tcl that miss critical features { namespaces for one }.

I dunno, really - never had to do that with an EDA kit.

I don't even think you can do actual asynchronous I/O in Python without
a "framework" (Twisted) . It's five lines of Tcl plus the read handler,
built-into the main language.

There's a few Python examples in which they actually *spawn threads* to
do socket service. Lordy.

Granted, you have to learn three or four patterns before you get Tcl
singing, but it's worth it. Figure a couple or four weeks of evenings to
go through the Brent Welch book.


Every time I try to do something in Python, I end up giving up because
it's missing something.


Just sayin... I write full-featured testers for embedded stuff I've
written in Tcl in two hours or less. But I've been using Tcl for 20
years. IMO, it makes for better programming habits in other
languages once you get the rhythm of it.

The Welch book is absolutely critical here...

--
Les Cargill

[Les Cargill]

If you find Tcl painful, and will have to suffer with it again, please
consider buying the Brent Welch book and skipping around in it enough to
be able to defend yourself.

It's available for very cheap on Abebooks.

--
Les Cargill

[Randy Yates]

Les Cargill <lcarg...@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.)

[Robert Wessel]

Well, you can also poll for the event (or block on it if the OS will
post a semaphore for you), or use a queue that the OS can post the
event to, and that you can poll or block on. Even in environments
where a callback is what the OS most conveniently provides, doing
nothing in the callback but posting the event to a work queue is often
the best approach.

The approach with a queue also easily allows multiple service threads,
without having to create a thread for each socket or whatnot.

[Randy Yates]

Agreed. Queues are a smart way to work.

[Les Cargill]

Randy Yates wrote:
> Les Cargill <lcarg...@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.

This is done in Tcl essentially using a callback. But it's all
first-class furniture in the language itself, not a bolt-on.

> Blocking is usually not acceptable.
> Using a callback that executes from another thread can be a bad idea.
>

Very much so. But Tcl is specifically designed to be callback-friendly.
It's *all* callbacks; there is just an invisible, default callback in
the text it runs in the (implicit) "main" block.

> So we're left with spawning a thread. That actually seems like the
> *best* solution to me. Why do you (apparently) disagree?
>

It's not better because it's one more part that's not necessary. Not
having to have a thread also means you never have to (sempahore) lock
things.

The magic to Tcl is - it is completely and irrevocably event driven.

I am a raving advocate for event driven. YMMV.

There's a built-in event loop that defaults to a "do nothing" when
there are no events and you have blocked. I'll leave "blocked' for now
- it's easy to do.

It's nearly trivial to use event-driven I/O.

So we can have three lines of code:
set s [socket $IP $PORT ]
fconfigure $s -blocking 0 -buffering none -translation binary
fileevent $s readable ::aProc

and then once you fill out ::aProc ( :: is just the top namespace
for Tcl ; we're being VERY EXPLICIT about the name ) you're done.

proc aProc { } {
variable s
if {[eof $s]} { exit } # or something...
set ib [ read $s ]
doSomethingWith $ib
}

That's an entire TCP client.

This does not run in a spawned thread and it's completely serialized for
you.

"blocked" is easy :

vwait ::forever

Want a timered background loop?

proc BGloop { } {
after 500 ::BGloop // 500 msec ; more namsepacery
...
}

after 10 BGloop # the after 10 is unnecessary
vwait ::forever

> (Note that this really has nothing to do with Tcl specifically.)
>

It rather does, really. To my eye, it's congruent with using
(p)select() in a non-blocking fashion in 'C' on nonblocking channels
(yes, you have to be careful of both ) rather than spawning a thread to
block or poll on sockets/file handles pipes/what have you.

--
Les Cargill

[Les Cargill]

Please "man select" when you get a chance. You can certainly spawn a
thread for a (p)select() loop in 'C' but you have to attend to locking
that way - fortunately, pthreads.h has semaphores.

--
Les Cargill

[Anssi Saari]

Les Cargill <lcarg...@comcast.com> writes:

> I don't even think you can do actual asynchronous I/O in Python
> without a "framework" (Twisted) . It's five lines of Tcl plus the read
> handler,
> built-into the main language.

I think the new asyncio module might do that. There's a little client
server example at
https://code.google.com/p/tulip/source/browse/examples/tcp_echo.py

But I don't really know TCL or Python or networking well enough to make
the comparison.

[Paul]

In article <vg37g3m...@coffee.modeemi.fi>, a...@sci.fi says...

Or even the old pyserial documentation pyserial.sourceforge.net

In as standard module that can be included in most distributions.

There are hundreds of modules for adding functionality to Python

There are many ways to crack the same nut generally I would prefer
Python over Tcl, and anything over Basic or Perl or Lisp....

Most languages have lots of libraries/modules, all depends on
a lot of requirements even what core skill set in a place is
as to what is best. Some though I would not consider.

--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.badweb.org.uk/> For those web sites you hate

[David Brown]

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.

[Cryptoman]

>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

[Anssi Saari]

Paul <pa...@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.

[Les Cargill]

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

[Grant Edwards]

On 2014-07-10, Les Cargill <lcarg...@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

[Paul Rubin]

Les Cargill <lcarg...@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.

[Les Cargill]

Paul Rubin wrote:
> Les Cargill <lcarg...@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

[Les Cargill]

Grant Edwards wrote:
> On 2014-07-10, Les Cargill <lcarg...@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

[Grant Edwards]

On 2014-07-10, Les Cargill <lcarg...@comcast.com> wrote:
> Grant Edwards wrote:
>> On 2014-07-10, Les Cargill <lcarg...@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

[Mel Wilson]

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.

[Grant Edwards]

Yep, I know what a pipe is. I've been writing shell scripts for 30+
years. What I didn't understand was when you described Python as a
programming language that is "used in pipes under BASH".

--
Grant Edwards grant.b.edwards Yow! I think I am an
at overnight sensation right
gmail.com now!!

[Les Cargill]

Grant Edwards wrote:
> On 2014-07-10, Les Cargill <lcarg...@comcast.com> wrote:
>> Grant Edwards wrote:
>>> On 2014-07-10, Les Cargill <lcarg...@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.

True enough, although I'd still call that an implementation detail of
"interpreted".

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.
>

NO doubt, and VM are frequently good enough these days.

>>> 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".

cat file | python myScript.py > zee

> Almost all of the programs I see connected together with pipes under
> bash are written in C.
>

That's because an awful lot of software was written in 'C'.

> Does that mean C is a "scripting language"?
>

No. My point is that it's not the shell, like bash.

--
Les Cargill

[Les Cargill]

My meaning was that when Python is apparently used in scripting, it's
not the scripting language; filters are written with it and then a shell
is used to pipe things together.

--
Les Cargill

[David Brown]

There is a saying - when you are in a hole, stop digging.

Python is used for an enormous range of tasks. That includes websites
and web frameworks, general applications, scientific applications,
games, test systems, embedded development tools, systems software,
utilities, scripts, gui programs, cli programs, and pretty much anything
else you can think of except small embedded systems (there are limited
versions of python available for pretty small processors, but these are
mostly experimental projects).

Python is a byte-compiled language, not an interpreted language (though
the byte-compiler is built into the standard virtual machine). There
are byte-compilers for Python to VM's other than the standard one
(cpython), such as for .net or java VM's. There are JIT compilers such
as pypy, which can result in speeds comparable to typical C code for
some types of tasks (though usually Python code on a standard VM is
significantly slower than compiled C).

Of the roughly 2500 non-link files in my /usr/bin directory, 200 are
python files. These are not "filters" - in fact, I don't know of any
that are filters. They cover a variety of tasks - one of which is the
"yum" package manager for Fedora/Red Hat.

I know (from your many posts over the years) you are experienced and
knowledgeable in many things in the programming world, but Python is
apparently not something you are familiar with. You would be better off
listening to experienced Python users like Grant than continuing to
demonstrate your lack of experience here. Even better, you might like
to try to learn Python yourself.

[Les Cargill]

David Brown wrote:
<snip>

>
> I know (from your many posts over the years) you are experienced and
> knowledgeable in many things in the programming world, but Python is
> apparently not something you are familiar with.

Of course - I believe I stipulated that up front.

> You would be better off
> listening to experienced Python users like Grant than continuing to
> demonstrate your lack of experience here. Even better, you might like
> to try to learn Python yourself.
>

I've tried it. Meh. All I can say is that it is better than Perl. I'm
not trying to give Grant or anyone a rash here; at best I could hope
somebody would provide a nice reason to consider investing more in the
language other than "everybody's using it."

To clarify:
- Tcl provides an event system by default. Python
doesn't. There is a package.
- Tcl provides event-driven I/O by default. Python doesn't.
There is a package.
- Freewrap/Teapot provide mechanisms for wrapping or packaging
code for distribution without installing Tcl. Python
doesn't.


--
Les Cargill

[Paul Rubin]

Les Cargill <lcarg...@comcast.com> writes:
> - Tcl provides an event system by default. Python
> doesn't. There is a package.
> - Tcl provides event-driven I/O by default. Python doesn't.

I'm not sure what you mean by this, but Python (at least on Linux)
supports select and epoll, and there are some event driven i/o modules
like asyncore or the fancier Twisted that have been around for a while.
I haven't tried the new coroutine-based asyncio module but it looks
interesting. I've always just use threads, whose dangers are overhyped
if you know what you're doing and program conservatively.

> - Freewrap/Teapot provide mechanisms for wrapping or packaging
> code for distribution without installing Tcl. Python
> doesn't.

For Windows there is py2exe.org, and InnoSetup if you want a fancy
InstalShield-like experience. Most Linux systems have Python already
available so there's less need for something like that, and people just
use standard Linux packaging tools.

[Les Cargill]

Paul Rubin wrote:
> Les Cargill <lcarg...@comcast.com> writes:
>> - Tcl provides an event system by default. Python
>> doesn't. There is a package.
>> - Tcl provides event-driven I/O by default. Python doesn't.
>
> I'm not sure what you mean by this, but Python (at least on Linux)
> supports select and epoll, and there are some event driven i/o modules
> like asyncore or the fancier Twisted that have been around for a while.

Agreed. Since Ptyhon is doubtless built on 'C', I'd
be surprised that select() and epoll() aren't supported for Windows.

> I haven't tried the new coroutine-based asyncio module but it looks
> interesting. I've always just use threads, whose dangers are overhyped
> if you know what you're doing and program conservatively.
>

Sure. I appear to be having some difficulty in explaining why I prefer
that the interpreter itself be built around event-driven-ness but
that's okay. It's always possible to use the dispatch
pattern but I've gotten used to it being the default state
of things.

I've been repetitive about this because I sometimes get to evangelize
in real life about testing frameworks for embedded stuff. When the
accusations of failure get to flying :) it's darned handy to
have a test framework that demonstrates that the embedded side works,
or one that exposes the defects that are there.

Threads are absolutely no problem but it's nicer to have options.

>> - Freewrap/Teapot provide mechanisms for wrapping or packaging
>> code for distribution without installing Tcl. Python
>> doesn't.
>
> For Windows there is py2exe.org, and InnoSetup if you want a fancy
> InstalShield-like experience. Most Linux systems have Python already
> available so there's less need for something like that, and people just
> use standard Linux packaging tools.
>

Yep; Windows is a pain with this issue.

One thing I've clarified with this thread ( thanks, guys ) is that
Python is closer to a replacement for 'C' than other roles I was
trying to hammer it into.

--
Les Cargill

[Paul Rubin]

Les Cargill <lcarg...@comcast.com> writes:
> Threads are absolutely no problem but it's nicer to have options.

The Python community seems to mostly hate threads and prefer Twisted, so
I'm in a bit of a minority. I found Twisted confusing and too Java-like
the one time I tried to use it. It has better performance than threads
so I've figured I'd have to get familiar with it someday, but have
avoided it so far and now I have hopes that the new asyncio library may
make it unnecessary. There are also alternative languages like Erlang,
Haskell, and Go, that have high-performance concurrency that looks like
threads/processes to the user but are implement as async under the hood.

> I've been repetitive about this because I sometimes get to evangelize
> in real life about testing frameworks for embedded stuff.

I'm pretty interested in this and would be happy to hear about any
recommendations you might have.

> One thing I've clarified with this thread ( thanks, guys ) is that
> Python is closer to a replacement for 'C' than other roles I was
> trying to hammer it into.

Yeah, most of my stuff in the past decade or so has been in Python.
When I write anything in C these days, as I've written elsewhere it
feels like a "back to nature" experience.

[Les Cargill]

Paul Rubin wrote:
> Les Cargill <lcarg...@comcast.com> writes:
>> Threads are absolutely no problem but it's nicer to have options.
>
> The Python community seems to mostly hate threads and prefer Twisted, so
> I'm in a bit of a minority. I found Twisted confusing and too Java-like
> the one time I tried to use it. It has better performance than threads
> so I've figured I'd have to get familiar with it someday, but have
> avoided it so far and now I have hopes that the new asyncio library may
> make it unnecessary.

Huh. Well, I'd expect them to catch up. Thread aren't *bad*; thy're
better when the system is run-to-completion, which isn't common these
days.

> There are also alternative languages like Erlang,
> Haskell, and Go, that have high-performance concurrency that looks like
> threads/processes to the user but are implement as async under the hood.
>

Those are on the list too, but it's a real Tower of Babel out there :)

>> I've been repetitive about this because I sometimes get to evangelize
>> in real life about testing frameworks for embedded stuff.
>
> I'm pretty interested in this and would be happy to hear about any
> recommendations you might have.
>

It's all good, really. The main thing will be what you're comfortable
with and you won't know that until you try.

I've glommed onto Tcl because you just open a serial port or a socket
and whale away. If you have, say, a USB device, I'll write 'C' to
operate it and load up a pipe in Tcl to drive it.

This goes back 20 years to a hard-to-find bug on a relatively simple
system where we actually built an exhaustive test jig that got run
continuously for days every release. Put in instrumentation at every
branch point and worked on the jig until we proved we executed every
path. We generated all the permutations of events and made that into a
"script" that would run repeatedly.

There are prepared frameworks but they can be tricky and they're
targeted at bespoke test as a job function, but at developer testing.

This is harder for things that implement, say, layer 1 comms stuff. But
those are often tractable by connecting to both ends and writing pattern
generators, or setting up and tearing down cross connects. If you can
buy COTS testers it's arguably better, but sometimes you can't.

>> One thing I've clarified with this thread ( thanks, guys ) is that
>> Python is closer to a replacement for 'C' than other roles I was
>> trying to hammer it into.
>
> Yeah, most of my stuff in the past decade or so has been in Python.
> When I write anything in C these days, as I've written elsewhere it
> feels like a "back to nature" experience.
>

For anything complicated, I end up writing C++ wrappers for freely
available 'C' libraries, generally. This is domain-dependent, of course.
This is purely to make the programs shorter; it's
not very "OO". I did this for the leverage, not the methodology.

FFTW and libsndfile both got this treatment.

Since my day job is embedded, I don't use a whole lot of Python. Perhaps
that will change.


--
Les Cargill

[Paul Rubin]

Les Cargill <lcarg...@comcast.com> writes:
> Since my day job is embedded, I don't use a whole lot of
> Python. Perhaps that will change.

Python is great on the ARM/Linux class of embedded system. It's not
usable for small MCU's and probably not so great for bare metal even
with larger processors. I've heard it works ok with around 2 meg of
ram, though I haven't personally run it in anything that small.

I see someone has uploaded Hedgehog Lisp to github:

https://github.com/sbp/hedgehog

This is an embedded, functional Lisp dialect with offline compilation,
whose runtime is around 20 kbytes and which (given a C compiler) should
be able to run in bare metal and is supposedly ok with around 256K of
ram. It uses a semispace GC and maybe the footprint could be decreased
further by switching to mark-sweep. I've spent a while studying it and
playing with it, though I never used it for anything "real".

[Andrea D'Amore]

On 2014-07-12 23:07:42 +0000, Paul Rubin said:

> Python is great on the ARM/Linux class of embedded system. It's not
> usable for small MCU's and probably not so great for bare metal even
> with larger processors. I've heard it works ok with around 2 meg of
> ram, though I haven't personally run it in anything that small.

On that matter MicroPython [1] has been recently presented on
comp.lang.python, it's a Python3 implementation aimed at
microcontroller with main (only?) big difference from being the lack of
Unicode string (a main point in Python 2/3 difference in strings
handling).

I have no experience with it, I just read around about it and from what
I can see it requires a 32bit MCU so the MSP430 is not suited for it.
AFAICT the minimum memory requirement is as low as ~64 kB. Not sure how
big the full standard library is.

It also works on regular desktop OSes as well so you can use the same
environment on your regular computer and it's said it offers
equal-or-better performance than CPython.

Just FYI, it may come in handy to someone.


[1] http://micropython.org

--
Andrea

[Anssi Saari]

Paul Rubin <no.e...@nospam.invalid> writes:

> Python is great on the ARM/Linux class of embedded system. It's not
> usable for small MCU's and probably not so great for bare metal even
> with larger processors. I've heard it works ok with around 2 meg of
> ram, though I haven't personally run it in anything that small.

I guess that was true pre-micropython but the reference design for
micropython runs an STM32F405RGT6 with 192 kB RAM which seems pretty
interesting.

[Grant Edwards]

On 2014-07-12, Paul Rubin <no.e...@nospam.invalid> wrote:
> Les Cargill <lcarg...@comcast.com> writes:
>> Threads are absolutely no problem but it's nicer to have options.
>
> The Python community seems to mostly hate threads and prefer Twisted,
> so I'm in a bit of a minority.

I wouldn't say they "hate" threads, but there is a surprising amount
fear surrounding threads and a lot of warning/moaning about how hard
it is to get programs using threads to work right. I honestly don't
understand where that comes from. I use Python's native threading
features a lot, and I never have any problems. I _think_ the problem
is that a lot of Python users come from a Windows/web-hacker
background and have absolutely zero training on or experience with
multi-tasking (or any other aspect of computer science or software
engineering for that matter).

IMO, for anybody who has ever used multiple threads in an embedded
system (and that includes interrupts) or with Posix threads, Python's
threads are dead simple and nearly fool-proof.

> Yeah, most of my stuff in the past decade or so has been in Python.
> When I write anything in C these days, as I've written elsewhere it
> feels like a "back to nature" experience.

I still write Linux kernel code in C and embedded stuff in C.
User-space application code for Linux/Windows has been almost
exclusively Python for 15+ years.

--
Grant Edwards grant.b.edwards Yow! UH-OH!! We're out
at of AUTOMOBILE PARTS and
gmail.com RUBBER GOODS!

[Les Cargill]

Grant Edwards wrote:
> On 2014-07-12, Paul Rubin <no.e...@nospam.invalid> wrote:
>> Les Cargill <lcarg...@comcast.com> writes:
>>> Threads are absolutely no problem but it's nicer to have options.
>>
>> The Python community seems to mostly hate threads and prefer Twisted,
>> so I'm in a bit of a minority.
>
> I wouldn't say they "hate" threads, but there is a surprising amount
> fear surrounding threads and a lot of warning/moaning about how hard
> it is to get programs using threads to work right. I honestly don't
> understand where that comes from.

(guessing here)
It probably comes from issues related to serialization and locking.

Does the Python toolkit have "run to completion" in threads ( relative
to other threads in the bytecode interpreter ) or do you have to do
locking?

I agree; it's not difficult, but if Python is positioned as a "popular"
language "they" may not have gotten to the part in the Dragon book about
P and V operations.

> I use Python's native threading
> features a lot, and I never have any problems. I _think_ the problem
> is that a lot of Python users come from a Windows/web-hacker
> background and have absolutely zero training on or experience with
> multi-tasking (or any other aspect of computer science or software
> engineering for that matter).
>

That's extremely likely, I think.

> IMO, for anybody who has ever used multiple threads in an embedded
> system (and that includes interrupts) or with Posix threads, Python's
> threads are dead simple and nearly fool-proof.
>

They should be; I'm glad to hear that.

>> Yeah, most of my stuff in the past decade or so has been in Python.
>> When I write anything in C these days, as I've written elsewhere it
>> feels like a "back to nature" experience.
>
> I still write Linux kernel code in C and embedded stuff in C.
> User-space application code for Linux/Windows has been almost
> exclusively Python for 15+ years.
>

--

Les Cargill

[Grant Edwards]

On 2014-07-15, Les Cargill <lcarg...@comcast.com> wrote:
> Grant Edwards wrote:
>> On 2014-07-12, Paul Rubin <no.e...@nospam.invalid> wrote:
>>> Les Cargill <lcarg...@comcast.com> writes:
>>>> Threads are absolutely no problem but it's nicer to have options.
>>>
>>> The Python community seems to mostly hate threads and prefer Twisted,
>>> so I'm in a bit of a minority.
>>
>> I wouldn't say they "hate" threads, but there is a surprising amount
>> fear surrounding threads and a lot of warning/moaning about how hard
>> it is to get programs using threads to work right. I honestly don't
>> understand where that comes from.
>
> (guessing here)
> It probably comes from issues related to serialization and locking.
>
> Does the Python toolkit have "run to completion" in threads (
> relative to other threads in the bytecode interpreter ) or do you
> have to do locking?

AFIK, it doesn't have "run to completion". Accesses to basic Python
types are guaranteed to be thread safe. If you're doing a series of
manipulations on an object that you want to be atomic, then you have
to do locking/serialization (Ptyhon provides a lock object type). All
of the usual suspects (read/write/send/receive) block as you would
expect and allow other threads to run.

There is one gotcha regarding the standard "CPython" implementation.
There is a global lock in the VM that only allows one thread to run at
a time. For what I generally use threads (manage contexts when
dealing with multiple overlapping I/O operations), that works fine.

If you want to try to do things like parallelize floating point
computations to take advantage of multi-core CPU, that global lock is
a problem _unless_ you're doing your computations using numerical
library calls that release the global lock while they're busy. In that
case theres a "multiprocessing" module that uses multiple instances of
the VM to allow parallel computation.

--
Grant Edwards grant.b.edwards Yow! Somewhere in DOWNTOWN
at BURBANK a prostitute is
gmail.com OVERCOOKING a LAMB CHOP!!

[George Neuner]

On Mon, 14 Jul 2014 14:59:12 +0000 (UTC), Grant Edwards
<inv...@invalid.invalid> wrote:


>I wouldn't say they "hate" threads, but there is a surprising amount
>fear surrounding threads and a lot of warning/moaning about how hard
>it is to get programs using threads to work right. I honestly don't
>understand where that comes from.

As Les suggested already, it mostly is about serialization and
locking. Studies have shown repeatedly that the majority of
programmers will make a horrible mess of coordinating access to shared
resources and, in particular, of algorithms which require multiple
locks or which lock/unlock recursively.

Studies also show that, in the absence of GC, too many programmers
can't keep track of who is responsible for deallocating objects that
are shared or passed around.

This is the reason for the rise of "managed" environments which handle
automatically deallocation and, at least, simple cases of object
locking.

>I _think_ the problem is that a lot of Python users come from a
>Windows/web-hacker background and have absolutely zero training on
>or experience with multi-tasking (or any other aspect of computer
>science or software engineering for that matter).

It's a wide-spread problem that has little to do with what language or
operating system is in use. The skill level of the average
desktop/server software "developer" now is only slightly better than
"script kiddie". They are able to plug together library functions and
routines scavenged from other sources, but largely are incapable
themselves of coding those things in the first place.

I'm not referring to actually difficult things that require expert
knowledge, but rather to really basic things like, e.g., writing code
to search/modify a string or to manipulate a binary tree.


The fact is that the vast majority of "developers" now have neither
formal education nor any training in the domain for which they are
writing applications. Not infrequently, I see questions that really
scare me. I think we've all seen things for which we've thought - and
sometimes said publicly - "Hey! this task is way above your skill
level."

>IMO, for anybody who has ever used multiple threads in an embedded
>system (and that includes interrupts) or with Posix threads, Python's
>threads are dead simple and nearly fool-proof.

And thread safety makes everything slower in the simple cases where it
is not needed. 8-)

Understand that I'm not in any way opposed to leveraging a helpful
programming environment ... but neither would I be helpless if that
environment suddenly were taken away. Far too many programmers are
completely dependent on a helpful environment and cannot function
without it.

YMMV,
George

[Dimiter_Popoff]

On 15.7.2014 г. 21:50, George Neuner wrote:
> ....

> Far too many programmers are
> completely dependent on a helpful environment and cannot function
> without it.

I believe this is key, perhaps understated.
It is not only about people becoming dependent on having a few things
to click on and expect a result; having to do more yourself and
go deep down to the lowest level is important to keep the head
of the programmer in shape. Not all the time, one does need
the efficiency provided by level change, once a day or at least
once every few days would be OK I guess.
If I have been doing hardware and not programming for a few months
it may take me weeks (typically 2) to become again the programmer
I am used to think I am.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[Randy Yates]

George Neuner <gneu...@comcast.net> writes:

...<a lot of stuff about synchronization>...

Can someone PLEASE explain to me, REALLY, the difference between a mutex
and a binary semaphore? In the FreeRTOS implementation, the only
difference I can see is the potential "priority elevation" thingie.

Also, the difference is in how it is used. A semaphore starts out
unposted and blocks until a post event occurs. A mutex starts out
"available," then some task takes the token (making it unavailable),
does its thing, and then returns the token (making it available again).

So usage of a semaphore requires one access per event, while usage of a
mutex requires two accesses per <protected resource usage>.

Is this right?

So is that it??!?
--
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

[Paul Rubin]

Randy Yates <ya...@digitalsignallabs.com> writes:
> Can someone PLEASE explain to me, REALLY, the difference between a mutex
> and a binary semaphore? In the FreeRTOS implementation, the only
> difference I can see is the potential "priority elevation" thingie.

Usually a mutex is in one of two states: either owned by some process
(therefore locked), or else unlocked (so any proces can acquire it). In
other words it's a one-bit value indicating whether you have ownership
of a resource.

A semaphore on the other hand contains an integer rather than a bit, so
it can keep track of how many of some replicated resource are in use:

http://en.wikipedia.org/wiki/Semaphore_%28programming%29

Semaphores (aka Dijkstra's P and V primitives) are among the oldest
concurrency primitives. These days I usually think it's best to use
asynchronous queues protected by locks (your system probably has a
library offering those), then don't share any mutable data at all
between processes/threads. You can take an efficiency hit from doing
this, but you avoid a whole lot of traditional concurrency hazards.

[Tom Gardner]

I've been using "message passing" via asynchronous mailboxes/queues
since 1981. I always found it far easier to understand and debug and
measure/manage than semaphores/mutexes.

I wouldn't worry about any reduced efficiency. Besides, as Dijkstra
or Hoare once said after a programming competition's results were
announced "If I had known that I didn't need to get the right
answer, I could have made my code much faster".

[David Brown]

On 23/07/14 05:40, Randy Yates wrote:
> George Neuner <gneu...@comcast.net> writes:
>
> ...<a lot of stuff about synchronization>...
>
> Can someone PLEASE explain to me, REALLY, the difference between a mutex
> and a binary semaphore? In the FreeRTOS implementation, the only
> difference I can see is the potential "priority elevation" thingie.
>

The key issue is that a mutex has an owner, while a semaphore is just a
counter (usually with a limit - binary semaphores have a limit of 1).

Having an owner means more overhead and higher costs, but also more
flexibility - such as for priority elevation, and ensuring that only the
owner can release the mutex. Semaphores are simpler, and can often be
implemented by single atomic operations or by a short section with
disabled interrupts (depending on the hardware). It is common to use
semaphores to implement higher-level structures such as mutexes or queues.

[Richard Damon]

A mutex is very much a specialized kind of semaphore, and due to that
specialization works a bit different. This specialization is for
protecting something from access by two tasks.

A Mutex's state is either it is owned by a particular task (which then
has the right to access the thing being protected), or is free. A mutex
will generally start in the "free" state, will be acquired by a task
needing to access the resource, and then when the access is done, will
be released by the task going back into the free state. Due to the fact
that Mutex can know who "owns" it, it is possible that when a higher
priority task tries to get a Mutex that is currently owned by a lower
priority task, that the system can take action (like raise the priority
of the owning task) to get the Mutex to the higher priority task
quicker. Note also that only the task that "owns" the Mutex is supposed
to give it back, and sometimes this will be enforced.

A Semaphore on the other hand is a more general type of primitive. In
general, it it counts how many times it has been "Given", and allows
that many "Takes" to occur. Sometimes blocking if too many gives have
been done, and generally blocking if you try to take when there hasn't
been a matching give already. A Binary Semaphore, is basically just a
special case of the "Counting" Semaphore with an upper limit of 1. Note
that for a semaphore, the giver and taker do not need to be the same
task, and in fact generally aren't. The givers being the "Producer" of
something and the takers being the "Consumers", and the semaphore being
a control over the availability of the thing.

A Semaphore CAN act mostly like a Mutex if used in a similar way, the
semaphore initialized to say there is a single resource available, and a
task wanting exclusive access will "consume" that resource, work with
it, then "produce" it back to the semaphore so someone else can use it.
(this is why binary semaphores are sometimes initialized as "full",
while more generic counting semaphores tend to start "empty"). The major
limitation of this over a Mutex is that since semaphores aren't "owned"
by their consumer, you don't get the ability to do something special
like priority inheritance if a higher priority task tries to take the
semaphore when it is already empty.

[Grant Edwards]

On 2014-07-23, Paul Rubin <no.e...@nospam.invalid> wrote:
> Randy Yates <ya...@digitalsignallabs.com> writes:
>> Can someone PLEASE explain to me, REALLY, the difference between a mutex
>> and a binary semaphore? In the FreeRTOS implementation, the only
>> difference I can see is the potential "priority elevation" thingie.
>
> Usually a mutex is in one of two states: either owned by some process
> (therefore locked), or else unlocked (so any proces can acquire it). In
> other words it's a one-bit value indicating whether you have ownership
> of a resource.
>
> A semaphore on the other hand contains an integer rather than a bit,

If it's a counting semaphore (the kind Dijkstra talked about). There
are also binary semaphores.

--
Grant Edwards grant.b.edwards Yow! ... bleakness
at ... desolation ... plastic
gmail.com forks ...

[Randy Yates]

Thank you all for your input - very educational! Richard, I especially
appreciately your response.

[Randy Yates]

Randy Yates <ya...@digitalsignallabs.com> writes:
> [...]
> Richard, I especially appreciately ...

??? _appreciated_

[Stefan Reuther]

Randy Yates wrote:
> Can someone PLEASE explain to me, REALLY, the difference between a mutex
> and a binary semaphore? In the FreeRTOS implementation, the only
> difference I can see is the potential "priority elevation" thingie.
>
> Also, the difference is in how it is used. A semaphore starts out
> unposted and blocks until a post event occurs. A mutex starts out
> "available," then some task takes the token (making it unavailable),
> does its thing, and then returns the token (making it available again).

There isn't necessarily a difference between a mutex and a binary
semaphore. In INTEGRITY, the binary semaphore *is* what everyone calls a
mutex.

To me, key properties of a mutex are:
- it starts "available"
- someone can take it, and later bring it back.
- you cannot bring back a mutex you do not own.
- bonus points for being recursive (i.e. if I already have it, I can
take it again, and must the bring it back twice).
- bonus points for priority inheritance.
- ideal for implementing critical sections.

Key properties of a semaphore are:
- it's a counter starting at an arbitrary value.
- anyone can count it up, anyone can count it down. Counting below
zero makes you block.
- ideal for managing queues.

Some people (namely the INTEGRITY guys) define a binary semaphore as a
recursive, priority-inheriting mutex.

Some other people define a binary semaphore as a simple semaphore that
just cannot count farther up than one. Such a semaphore can be used to
build a non-recursive, non-priority-inheriting mutex, or it can be used
to implement a wakeup event (where multiple signals should result in
only one actual wakeup).


Stefan

[Les Cargill]

Randy Yates wrote:
> George Neuner <gneu...@comcast.net> writes:
>
> ...<a lot of stuff about synchronization>...
>
> Can someone PLEASE explain to me, REALLY, the difference between a mutex
> and a binary semaphore? In the FreeRTOS implementation, the only
> difference I can see is the potential "priority elevation" thingie.
>

It'll vary. The canonical { P(),V() } as per Knuth is the mutex/binary
semaphore.

There are several heresies on this theme.

> Also, the difference is in how it is used. A semaphore starts out
> unposted and blocks until a post event occurs. A mutex starts out
> "available," then some task takes the token (making it unavailable),
> does its thing, and then returns the token (making it available again).
>

I would not be surprised if you could initialize either either way.
VxWorks has a sempahore object that you can initialize to a value
so that <n> threads can do their initialization, then block on it.

> So usage of a semaphore requires one access per event, while usage of a
> mutex requires two accesses per <protected resource usage>.
>
> Is this right?
>

It is whatever the implementers say is right.

> So is that it??!?
>

--

Les Cargill

[Les Cargill]

Les Cargill wrote:
<snip>

> It'll vary. The canonical { P(),V() } as per Knuth is the mutex/binary
> semaphore.

Edit: It was Djikstra and the default was counting semaphores.

--
Les Cargill

[George Neuner]

Hi Randy,

On Tue, 22 Jul 2014 23:40:07 -0400, Randy Yates
<ya...@digitalsignallabs.com> wrote:

>Can someone PLEASE explain to me, REALLY, the difference between a mutex
>and a binary semaphore?

When you are speaking strictly about _binary_ semaphores, the
difference essentially is the use case.

A general semaphore *conceptually* is simply a pairing of a binary
semaphore with a counter.


The "environment awareness" properties that people often associate
with synchronization primitives really are tangential to their basic
function of resource locking.

E.g., the notion that a "mutex" has an owner fell out of early
algorithmic locking schemes which had to work without the aid of
atomic RMW instructions [e.g., compare/swap, test/set, interlocked
inc/dec, etc.] that commonly are found on modern CPUs.
See:
https://en.wikipedia.org/wiki/Dekker%27s_algorithm
https://en.wikipedia.org/wiki/Peterson%27s_algorithm
https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm

In use, it isn't necessary for a mutex to have an explicit owner: the
owner is implicit in the states of the competing tasks. If you look
at the algorithms above, you'll see that, at least as written, the
identity of the current "owner" is known only implicitly by the
participants.
[Obviously, an external observer or a participant in busy-wait could,
in principle, examine the shared state and identify the owner, but
that is extraneous to the algorithm(s).]

However, external identification of the owner enables other useful
concepts such as priority awareness, deadlock detection, etc. to be
layered on top of the basic synchronization.


It has been proven that all so-far discovered synchronization
"primitives" are equivalent and that they all can be implemented in
terms of one other.

Hope this helps,
George

[Les Cargill]

George Neuner wrote:
> Hi Randy,
<snip>

>
> It has been proven that all so-far discovered synchronization
> "primitives" are equivalent and that they all can be implemented in
> terms of one other.
>

Well said - which is one reason I don't even try to remember the fine
points of them any more. Next time is always different.

> Hope this helps,
> George
>

--
Les Cargill