Prev: load tk85.dll fail
Next: How to transfer "trusted" environment into a safe slave interpreter?
From: Kirill Frolov on 15 Jan 2010 06:28
I'm writing simple testing framework for embedded application. The
application is written on C language and runs on microchip PIC
microcontroller normally. To test application I made the following:

* hardware depended code was picked out from main source and written
to separate source files (module_hal.c for example);

* two build mode for program: for microchip PIC, using *_hal.c files
dealing with real hardware, or for PC, where *_hal.c files contain
hardware simulation code and bindings to TCL-commands.

Then program was build for PC, I can using TCL commands change input
signal states for simulated hardware, for example, or view output
signal states.
But I need some method to call tcl callback procedure when output
signal changes state.
I see two methods to achieve this:

* map signal state to variable, and then use 'trace' command to bind
tcl-scripts to state change events;

* add new events to tcl event queue, as described here: http://wiki.tcl.tk/17195

Which method can be more preferable and why? In case if signal state
changes too fast, and if I use variable trace, my callback will be
called on every state change -- I think it is serious drawback of
first method. With second method I can add only one event to queue,
and add second only if first event is processed. But as I see, second
method requires more complex code in C (now I wrote this code and see
it as serious drawback too).

May be exists some other methods to call tcl-callbacks on events
generated in C program? Something like Tk events.

From: Harald Oehlmann on 15 Jan 2010 07:40
Hi Kirill,

On 15 Jan., 12:28, Kirill Frolov <kfro...(a)gmail.com> wrote:
> I see two methods to achieve this:
>
>   * map signal state to variable, and then use 'trace' command to bind
> tcl-scripts to state change events;
>
>   * add new events to tcl event queue, as described here:http://wiki.tcl.tk/17195
>
> Which method can be more preferable and why?   In case if signal state
> changes too fast, and if I use variable trace, my callback will be
> called on every state change -- I think it is serious drawback of
> first method. With second method I can add only one event to queue,
> and add second only if first event is processed. But as I see, second
> method requires more complex code in C (now I wrote this code and see
> it as serious drawback too).

the advantage of Method two is that you are called by tcl and it is a
save moment to manipulate the current interpreter.
I was not aware, that it is not possible to post multiple events
before processing.

I don't know how Method 1 would work.
Maybee, something like that could be found in the framework of
threadding and thread syncronisation.

A thierd and very stupid method would be to implement a poll command
in TCL which is called in a regular manner (timer event).
Or the poll moment may be combined with Method 2.

Hope this helps,
Harald
From: Alexandre Ferrieux on 15 Jan 2010 10:42
On Jan 15, 12:28 pm, Kirill Frolov <kfro...(a)gmail.com> wrote:
> I'm writing simple testing framework for embedded application. The
> application is written on C language and runs on microchip PIC
> microcontroller normally. To test application I made the following:
>
>   * hardware depended code was picked out from main source and written
> to separate source files (module_hal.c for example);
>
>   * two build mode for program: for microchip PIC, using *_hal.c files
> dealing with real hardware, or for PC, where *_hal.c files contain
> hardware simulation code and bindings to TCL-commands.
>
> Then program was build for PC, I can using TCL commands change input
> signal states for simulated hardware, for example, or view output
> signal states.
> But I need some method to call tcl callback procedure when output
> signal changes state.
> I see two methods to achieve this:
>
>   * map signal state to variable, and then use 'trace' command to bind
> tcl-scripts to state change events;
>
>   * add new events to tcl event queue, as described here:http://wiki.tcl.tk/17195
>
> Which method can be more preferable and why?   In case if signal state
> changes too fast, and if I use variable trace, my callback will be
> called on every state change -- I think it is serious drawback of
> first method. With second method I can add only one event to queue,
> and add second only if first event is processed. But as I see, second
> method requires more complex code in C (now I wrote this code and see
> it as serious drawback too).
>
> May be exists some other methods to call tcl-callbacks on events
> generated in C program?  Something like Tk events.

Given your context, I'd build a completely different architecture.
Instead of tying the Tcl interp to the running program, I'd just use
interprocess communication.
Just establish a socket or a pair of pipes between your C process and
a Tcl process (with or without GUI).
You can define a very simple protocol, based on text. For example from
C to Tcl, you'd be sending text lines, each one conveying the states
of all outputs. From Tcl to C, the same for the states of inputs. If
you're more comfortable with binary protocols, and/or you have a fixed
number of input/outputs, just exchange fixed-size blocks of bytes.

In all cases, the Tcl side will be event-driven, using [fileevent].
Ask again if you need extra guidance.

-Alex



 | 
Pages: 1
Prev: load tk85.dll fail
Next: How to transfer "trusted" environment into a safe slave interpreter?