immediateC is a declarative, event-driven extension of the procedural language C written by John E. Wulff.
He started with this tool in 1985 and is still maintaining it. Kudos!!!
Detailed information can be found on John's immediateC website immediatec.net. The source code can be downloaded from GitHub.
To get started with immediateC, get the source files from GitHub: https://github.com/JohnWulff/immediatec.
Once you cloned the repository go to the directory ./src and run the command ./configure. This will create a Makefile that can be run later on.
Next, make sure all required Perl modules are installed.
So, first go to the section Using immediateC on Linux Mint 21
After the above is done, continue with the below.
Once the Makefile is created, run the command ./m -I. This will create a sudo user.
Then run the command ./ m -a. This will create and install all the necessary applications and libraries, such as:
immcc: the C compiler
immac: the C compiler when immedate arrays are used (see documentation of iC)
immax:
libict.so.1.3.7: dynamic library needed by immediateC
libict.so.1: a link to libict.so.1.3.7
libict.so: a link to libict.so.1.3.7
libict.a: static library needed by immediateC
Note: both libict.a as well as libict.so are candidates to be used by - in this case - immediateC. It all depends how the application is built: does it link against a .so library or against a .a library?
Note: if Tk.pm is not installed yet on your system you will get compilation errors like this:
Can't locate Tk.pm in @INC (you may need to install the Tk module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 /usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
Therefor, you need to install this Perl module first. To do this pls. read the section below called Using immediateC on Linux Mint 21, section iClive on what to do, won't repeat it here.
All should be fine now. However... See section "First application"
To get started with immediateC on a Linux Mint 21 the following preconditions must be met:
Get the source files from GitHub: https://github.com/JohnWulff/immediatec
Go inside the src directory and run the file ./iClive (pronounced iC-live). This is written in perl and will create a UI to create, build, run, debug... immediateC scripts.
When I ran the command ./iClive, I immediately got the following error thrown at me:
geertvc@mint21:~/mystuff/immediatec/src$ ./iClive
Can't locate Tk.pm in @INC (you may need to install the Tk module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0 /usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.34 /usr/share/perl/5.34 /usr/local/lib/site_perl) at ./iClive line 24.
BEGIN failed--compilation aborted at ./iClive line 24.
Since a UI is used, perl needs the Tk Perl package and in my case this was not installed by default. So, I had to do the following:
Install libx11-dev and libpng-dev first:
sudo apt install libx11-dev libpng-dev
This is needed to install Tk.pm later on.
Install flex and bison: sudo apt install flex bison
sudo cpan => This brings you in the CPAN console (CPAN = Comprehensive Perl Archive Network)
Since it was the first time I ran CPAN on this computer, the system told me that CPAN.pm required configuration but luckily most could be done automa(t)(g)ically:
CPAN.pm requires configuration, but most of it can be done automatically.
If you answer 'no' below, you will enter an interactive dialog for each
configuration option instead.
Would you like to configure as much as possible automatically? [yes]
I accepted the default stuff by simply pressing the "Enter" key.
After that, I got the following confirmation:
Autoconfiguration complete.
commit: wrote '/root/.cpan/CPAN/MyConfig.pm'
You can re-run configuration any time with 'o conf init' in the CPAN shell
I also got the following remark:
Terminal does not support AddHistory.
To fix that, maybe try> install Term::ReadLine::Perl
So, I ran this command too. See the next chapter.
I also ran the following two commands since it was proposed by the CPAN environment:
o conf init pushy_https: will ask to always use https://cpan.org to download from. Defaults to [yes], so I accepted.
To make those changes permanent you have to also run the command o config commit.
The preferences will be written into the file /root/.cpan/CPAN/MyConfig.pm.
I then ran the installation of all the Perl modules needed directly or indirectly by immediateC:
install Term::ReadKey to be able to install Term::ReadLine::Perl (it seems...)
install Term::ReadLine::Perl to add terminal history.
install Time::HiRes: this was requested by the installation instructions of immediateC. See previous section.
You also often see during the installation of Perl modules that YAML is not installed.
This can be solved by running the command install YAML on the cpan command line.
Since libx11 is installed now, exit cpan and come back to the command line. Now we're ready to install Tk.pm.
Since almost always the tests for Tk.pm fail for me, I install Tk.pm without running the tests.
To dot this, run the following on the command line: sudo cpan -T Tk.pm. This will start a quite lengthy compilation process, but without the tests.
The complete build can take up several minutes on the Linux machine.
Note: while running the installation command above I saw CPAN was also candidate to be upgraded. This was the message shown:
New CPAN.pm version (v2.34) available.
[Currently running version is v2.28]
You might want to try
install CPAN
reload cpan
to both upgrade CPAN.pm and run the new version without leaving
the current session.
So, after installation of the Tk package I also ran the command install CPAN to get the latest version of CPAN.
The command line in CPAN looked like this:
cpan[4]> install CPAN
cpan[5]> reload CPAN
Next time I ran ./iClive and I saw finally the below iClive application.
Golden advice: always carefully read the README.md file in a Git repository. It can save you a lot of time and... frustration!
Under a huge pile of dust I found an "old" HP laptop from 2012 (or was it 2013?) which I wanted to (re)use as a Linux machine (needless to say Windows was installed on that PC).
I used Ubuntu 22.04 LTS for a while but it was slow. Really slow... The specs of the laptop weren't that super (not a lot of RAM, not a super fast Intel processor, not a lot of HD size,...).
After some time, I gave up on Ubuntu 22.04 and I wanted to try out Lubuntu since that is much more suited for retired laptops and/or PC's. At least, it seems so if I read all info on the internet about what Linux distro is best for old hardware.
So, I gave it a try and I also wanted to make sure I could use it for immedateC.
After downloading the .iso file and using rufus 4.3 (as of this writing) to create a bootable USB stick with the Linux distro on it I reinstalled my laptop with this distro.
After the installation completed and I did a full upgrade it was time to start installing all necessary apps and libs to be able to compile immediateC.
Below is, in timely order, the commands to be executed:
sudo apt install git (looks like this one was already installed)
sudo apt install build-essential (to get compilers and the whole make mechanism in place)
sudo apt install libx11-dev (needed later on for immediateC)
sudo apt install libpng-dev (same reason)
sudo apt install flex
sudo apt install bison
Install rlwrap: sudo apt install rlwrap
Why? When I'm on the cpan console window then the arrow up/down keys result in awkward signs: ^[[A when pressing the arrow up key, for instance.
Starting cpan using rlwrap (readline wrapper) solves this issue.
This can be done both as a regular user or as root:
rlwrap cpan
sudo rlwrap cpan
sudo cpan (perl was also installed by default, version 5.34.0)
First see if the latest CPAN is installed:
install CPAN
reload cpan
install YAML
now quit cpan (type exit on the command line)
sudo cpan
o conf init pushy_https
answer "yes" to the question
o conf commit
install CPAN::DistnameInfo
install Term::ReadKey
install Term::ReadLine::Perl
install Term::HiRes (required by immediateC to have accurate timers)
install Tk.pm (this will take a long time and at the end, during the test phase, different UI widgets will pop up for a short time)
quit cpan
cpan (yes, this time as regular user, not as sudo)
install X11/Protocol.pm
This is necessary to give another meaning to the X of iCbox:
when clicking the X, both iCbox as well as the iCserver(s) will be destroyed
when clicking shift-X then only iCbox will be destroyed and the iCserver(s) will stay alive
Recently, I also had to install Net::MQTT::Simple on one of my RPi's since iCmqtt is using this perl module.
To install it, on the command prompt, I ran the command cpan Net::MQTT::Simple and all was fine.
Since iCmqtt will also be called from a systemd service later on, it's best to install this module also as root:
sudo span Net::MQTT::Simple
Note that I had issues installing X11::Protocol on one of my RPi's (reason still unknown).
I had the following error while installing it:
cpan[3]> install X11::Protocol
Running install for module 'X11::Protocol'
Checksum for /home/pi/.cpan/sources/authors/id/S/SM/SMCCAM/X11-Protocol-0.56.tar.gz ok
Scanning cache /home/pi/.cpan/build for sizes
............................................................................DONE
Configuring S/SM/SMCCAM/X11-Protocol-0.56.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for X11::Protocol
Writing MYMETA.yml and MYMETA.json
SMCCAM/X11-Protocol-0.56.tar.gz
/usr/bin/perl Makefile.PL -- OK
Running make for S/SM/SMCCAM/X11-Protocol-0.56.tar.gz
cp Protocol/Ext/XFree86_Misc.pm blib/lib/X11/Protocol/Ext/XFree86_Misc.pm
cp Protocol.pm blib/lib/X11/Protocol.pm
cp Protocol/Connection/Socket.pm blib/lib/X11/Protocol/Connection/Socket.pm
cp Protocol/Ext/DPMS.pm blib/lib/X11/Protocol/Ext/DPMS.pm
cp Protocol/Constants.pm blib/lib/X11/Protocol/Constants.pm
cp Protocol/Connection.pm blib/lib/X11/Protocol/Connection.pm
cp Protocol/Connection/INETSocket.pm blib/lib/X11/Protocol/Connection/INETSocket.pm
cp Protocol/Connection/UNIXFH.pm blib/lib/X11/Protocol/Connection/UNIXFH.pm
cp Protocol/Ext/RENDER.pm blib/lib/X11/Protocol/Ext/RENDER.pm
cp Protocol/Ext/XC_MISC.pm blib/lib/X11/Protocol/Ext/XC_MISC.pm
cp Protocol/Ext/SHAPE.pm blib/lib/X11/Protocol/Ext/SHAPE.pm
cp Protocol/Ext/BIG_REQUESTS.pm blib/lib/X11/Protocol/Ext/BIG_REQUESTS.pm
cp Keysyms.pm blib/lib/X11/Keysyms.pm
cp Auth.pm blib/lib/X11/Auth.pm
cp Protocol/Connection/UNIXSocket.pm blib/lib/X11/Protocol/Connection/UNIXSocket.pm
cp Protocol/Connection/INETFH.pm blib/lib/X11/Protocol/Connection/INETFH.pm
cp Protocol/Connection/FileHandle.pm blib/lib/X11/Protocol/Connection/FileHandle.pm
Manifying 16 pod documents
SMCCAM/X11-Protocol-0.56.tar.gz
/usr/bin/make -- OK
Running make test for SMCCAM/X11-Protocol-0.56.tar.gz
PERL_DL_NONLAZY=1 "/usr/bin/perl" "-Iblib/lib" "-Iblib/arch" test.pl
1..3
ok 1
ok 2
Protocol error: bad 15 (Name); Sequence Number 17
Opcode (45, 0) = OpenFont
at test.pl line 96.
make: *** [Makefile:874: test_dynamic] Error 255
Lockfile removed.
SMCCAM/X11-Protocol-0.56.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports SMCCAM/X11-Protocol-0.56.tar.gz
Failed during this command:
SMCCAM/X11-Protocol-0.56.tar.gz : make_test NO
I have no clue as to what the above means but I could resolve it by installing the module without the testing facilities (I really don't care about this feature):
cpan -T X11::Protocol
This installed the module without problems.
To be able to do Remote Desktop Connections from Windows one more package need to be installed.
sudo apt install xrdp
sudo systemctl enable --now xrdp
sudo ufw allow from any to any port 3389 proto tcp
Now open Remote Desktop Connection from Windows, give the IP address of the laptop and you should see an intro screen asking for the user name and password.
Once given, a connection between Windows and Lubuntu will be established and you can work on Windows in your Lubuntu environment.
As always, the first application is a kind of "Hello, world" when trying out a new environment. This is no different now.
To build such an application, start the immediateC editor by launching the command iClive.
Next, create a project directory and create a new file into that directory: hello.ic (must end with .ic!)
Add the following content to it:
%{ #include <stdio.h> %}
if (IX0.0) {
printf("Hello, immedateC world!\n");
} else {
printf("Goodbye, immedateC world!\n");
}
So, whenever IX0.0 is true then the first printf will be executed. Else, the second printf will be executed.
Press the Build button in the iClive IDE: the result will be a failure. The error will look like this:
$ iCmake -fsAd200 hello.ic 2>&1
hello.c
hello
/usr/bin/ld: cannot find /usr/local/lib64/libict.a: No such file or directory
collect2: error: ld returned 1 exit status
gcc compile errors in 'hello.c' - no executable 'hello' generated
ERROR: 'hello' cannot be built from 'hello.ic' (return = 1)
The problem is that the linker looks at location /usr/local/lib64 (see red above) to search for libraries to link against, since Linux Mint 21 is a 64 bit system. However, the libraries are located in /usr/local/lib instead when running the sudo make install command (see first section First things first...).
The solution to this is quite simple (don't know if this is the right way to go, but it anyhow works): make (if necessary) a lib64 directory and copy the libict* files into this directory:
cd /usr/local
sudo mkdir lib64 (only if needed!!!)
cd lib64
sudo cp ./lib/libict* .
This way, the libraries are also available in the /usr/local/lib64 directory and this time the build will be successful!
The above way of working is NOT the way to go. Normally, the autoconfig tool should know if it configures for a 32 or 64 bit system and act accordingly. But Linux Mint 21 running on a 64 bit system doesn't seem to "understand" this, since it only puts the libict* libraries in /usr/local/lib and it even doesn't create a /usr/local/lib64, let alone putting the libict* files in it.
One possible solution is the following (again, not sure if this one is the right way to go):
./configure --libdir=/usr/local/lib
When running this it looks like the system is doing its job fine. If you then run sudo make install the libict* libraries are stored in both /usr/local/lib as well as in /usr/local/lib64 (even if that last directory would not exist: it will create it for you!).
No idea why adding the --libdir parameter is also copying the libraries in to /usr/local/lib64, but it works...
Once the application hello has been created you can launch it in two different ways:
Go to the location where the hello application has been built and run it using the command ./hello
In the iClive IDE, press the Run button
In both cases the iCbox application will be opened which will show a simulator box like given to the right.
By default, the button is not pressed and you will see the output printing "Goodbye, immediateC world!" in the window where iClive is launched or where you launched hello from the command line.
If you then press the small button on the simulator (simulating contact IX0.0) it will print the text "Hello, immediateC world!".
It's getting even crazier: when you also press the Live button in the IDE you can see the variable IX0.0 changing colours: black/green when inactive, red/yellow when active. See images on the right too.
The second image shows the state where the button in the iCbox simulator is unpressed.
The third image shows the state where the button in the iCbox simulator is pressed.
You did a great job, John!
./bar -l: will start the bar executable and also the iClive environment.
iCmake -zsAf bar.ic: will compile bar.ic with extra debug information so that everything what's happening internally is seen on the terminal.
To start iClive when starting an application you can also add the -l option like so:
iCserver \
-R iCpiI2C -f -d300 \
QX140,0xFF \
QX830,0xFF \
~IX831,0xFF \
-R ff_ic -l \
-v ff_ic.vcd
Mdiff is something John made himself. The difference between diff and Mdiff is that Mdiff can do different diffs at the same time.
Example command
Mdiff kLel Test0/ORG/*.*: will show the differences between the original code and the compiled code
The below information is an excerpt from John Wulff's great immediateC application to control PLC's in a very efficient way.
IEC-1131 base names are as follows:
<io_op><size_op><address>
<io_op>
I data is input to an iC control client.
Q data is output from an iC control client.
- the following are for debugging clients only
C debug data is output from an iC control client to iClive
D debug data is input to an iC control client from iClive
- more details for C and D in section 5.
<size_op>
X signifies 8 bits of single bit data.
bit addresses are not used in the registration or
transmission of X senders and receivers. 8 bits are
always transmitted as 1 byte and the clients insert
or extract modified bits as necessary.
B signifies 8 bits or 1 byte of numerical data.
W signifies 16 bits or 2 bytes of numerical data.
L signifies 32 bits or 4 bytes of numerical data.
H signifies 64 bits or 8 bytes of numerical data.
<address>
This number is the numerical IEC-1131 address. Each
data type QX, QB, QW, QL and QH as well as IX, IB, IW,
IL and IH has its own address space, which is a sparse
array. The numbering of each of these address spaces is
independent of the others and continuous.
Some hardware I/O drivers may have a common address
space which may also enforce word, long word and long
long word baundaries. Checking for such boundaries
and overlap of I/Os with different word length has been
implemented for iC apps but is normally not switched on.
This does not affect iCserver either way.
NOTE: the syntax of correct IEC-1131 base names is only checked
by iCserver for equivalence declarations. All other IEC_1131
base names are received from clients where they should have
been checked.
Examples:
SIX0 8 single bits IX0.0 to IX0.7 sent from an external source
RIX0 8 single bits IX0.0 to IX0.7 received by an iC controller
SQX9(7) 3 single bits IX9.0 to IX9.2 sent from an iC controller
RQX9(7) 3 single bits IX9.0 to IX9.2 received by an external sink
SIB10 single 8 bit byte IB10 sent from an external source
RIB10 single 8 bit byte IB10 received by an iC controller
SQB15 single 8 bit byte QB15 sent from an iC controller
RQB15 single 8 bit byte QB15 received by an external sink
SIW10 single 16 bit word IW10 sent from an external source
RIW10 single 16 bit word IW10 received by an iC controller
SQW15 single 16 bit word QW15 sent from an iC controller
RQW15 single 16 bit word QW15 received by an external sink
SIL10 single 32 bit long IL10 sent from an external source
RIL10 single 32 bit long IL10 received by an iC controller
SQL15 single 32 bit long QL15 sent from an iC controller
RQL15 single 32 bit long QL15 received by an external sink
SIH10 single 64 bit long long IH10 sent from an external source
RIH10 single 64 bit long long IH10 received by an iC controller
SQH15 single 64 bit long long QH15 sent from an iC controller
RQH15 single 64 bit long long QH15 received by an external sink
When running iClive on the Raspberry Pi Zero I alwasy got the following warning message:
pi@rpi-zerow:~/mystuff/immediatec/src $ iClive bar.ic
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_ADDRESS = "nl_BE.UTF-8",
LC_NAME = "nl_BE.UTF-8",
LC_MONETARY = "nl_BE.UTF-8",
LC_PAPER = "nl_BE.UTF-8",
LC_IDENTIFICATION = "nl_BE.UTF-8",
LC_TELEPHONE = "nl_BE.UTF-8",
LC_MEASUREMENT = "nl_BE.UTF-8",
LC_TIME = "nl_BE.UTF-8",
LC_NUMERIC = "nl_BE.UTF-8",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_GB.UTF-8").
To solve this, add the following to the file /etc/default/locale (as sudo):
LC_CTYPE="en_GB.UTF-8"
LC_ALL="en_GB.UTF-8"
This should solve the issues.
To compile immediateC from scratch, do the following:
Get latest update from GitHub
Run a make distclean
Run ./configure from within the ./src directory: this will make sure the Makefile will be generated for Windows or Raspberry Pi (very important!!!)
Run m -I: change to root
Run m -a: this will recompile everything and also do the installation part
If only installation is needed, run m -i instead.
make distclean: remove all generated targets
configure: run/create Makefile from the Makefile.in template
m -clSi: start compilation with the following parameters:
m: compile with debug information so traces are visible in iClive (generated "assembly" also visible)
cl: build immcc and create static library libict.a with debugging support
S: create shared library libict.so but without debug support
i: install everything
m -X: build iCpiI2C and dependent components (e.g. MCP23017.c)
m -zX: same as above, but the compilation process shows all the steps taken (verbose-alike approach).
When iCserver is running there are some keys that can be typed in into the terminal to do special stuff. Below is a non-exhaustive list of characters and their meanings. Will be updated accordingly when I get new useful tips and tricks from John (Wulff).
q:
Quits the running session in a safe way. All open stuff is nicely closed, in my case all MCP's are reset to their default state and the iCserver is shut down.
T:
Shows a table overview of client names and registered senders/receivers. An example is given below for my minimalistic test setup where I have a situation where I want to address a relay on another floor with a push button from one floor:
T
iCserver: Table of ClientNames and registered Senders and Receivers
QX522
ff_ic
gf_ic_o2
iCpiI2C
iCpiI2C-o2
%Equivalences = {
QX140 => [
[ 1, { '' => QX140, } ],
[ 4, { '' => IX14, } ],
],
}
EquivBase Channels
name base primCh secCh ch
IX14 QX140 1 4 4
QX140 QX140 1 1 1
ch Sender name value Recv[0] name[0] Recv[1] name[1] ...
1 ff_ic QX140 0 iCpiI2C QX140 QX522 QX140
4 gf_ic_o2 IX14
2 ff_ic QX830 0 iCpiI2C QX830
3 iCpiI2C IX831 0 ff_ic IX831
5 ff_ic Cff_ic 2;ff_ic <no receivers> [iClive]
6 <no sender> ff_ic Dff_ic [iClive]
7 <no sender> ff_ic IX20
8 iCpiI2C-o2 IX852 0 ff_ic IX852 gf_ic_o2 IX852 QX522IX852
9 iCpiI2C-o2 IX502 0 QX522 IX502
10 iCpiI2C-o2 IX503 64 gf_ic_o2 IX503 QX522 IX503
11 gf_ic_o2 QX522 1 iCpiI2C-o2 QX522 QX522 QX522
12 gf_ic_o2 QX853 0 iCpiI2C-o2 QX853 QX522 QX853
13 gf_ic_o2 Cgf_ic_o2 2;gf_ic_o2 <no receivers> [iClive]
14 <no sender> gf_ic_o2 Dgf_ic_o2 [iClive]
15 <no sender> gf_ic_o2 IX21
Equivalence is a mechanism where you use a kind of "bridge" to share a variable defined in one app over iCserver to another app.
To define an equivalence, the option -e has to be used in the setup files.
An example:
iCserver \
-R ../../iCpiI2C -f -d300 \
QX140,0xFF \
QX830,0xFF \
~IX831,0xFF \
-R ff_ic -e IX14=QX140 \
-v ff_ic.vcd
In the above example, one app is "owning" the IEC output QX140. Here, it is ff_ic.
Note that equivalence items must be defined on byte level, not bit level.
The value of QX140, however, must also be known in another app in my particular case to activate an LED in the pushbutton of a switch since that switch is also commanding the same device: a relay (see below).
Using the "equivalence" mechanism, an internal IEC input byte IX is given the byte value of the QX IEC output byte and iCserver is "bridging" that value over the network to whom (in this case, another app) might be interested in it.
Note that bit 0 of QX140 is connected to a hardware pin in my system like so:
imm bit RBV1;
QX140.0 = RBV1;
The hardware pin itself is then controlling the state of a relay, here relay RBV1.
So, later on at the other app side the same bit of IX14 must be used! In the example given above, bit 0 of IX14 is connected to bit 0 of QX140.
In the other app, the "bridge" variable IX14 can be used like so (here, one can and must use bit level now!):
imm bit gf$switch_led$kitchen_door$b;
gf$switch_led$kitchen_door$b = IX14.0;
QX853.1 = gf$switch_led$kitchen_door$b;
The above immediate bit variable is defined in an .ih file (immediateC header file) and is linked to the "bridge" variable bit IX14.0.
When there's more than one equivalence you can specify them using two options:
-e IX14=QX140 -e IX15=QX150
-e IX14=QX140,IX15=QX150
To build immediateC on a Raspberry Pi, the following steps have to be taken assuming Perl and so on are already installed correctly: see above sections:
./configure (only if you modified the Makefile.in or you upgraded to the latest state on GitHub)
make distclean (only if you want to do a clean build)
m -I (to temporarily switch a regular user to a root user: needed to change some permissions for installation purposes)
m -a
Note that there's currently a problem during the build process with the command pod2man -u -n. For an unknown reason the build mechanism doesn't recognise the -u option in my case (on John Wulff's Raspberry Pi it seems to be no issue...).
When looking into the Makefile.in, the pod2man -u -n is executed if the following condition is true:
ifeq ($(TKGE803),true)
@pod2man -u -n immcc -c 'iC Project Documentation' -r "icc.v $(REV)" $< > $(srcdir)/immcc.1
else
@pod2man -n immcc -c 'iC Project Documentation' -r "icc.v $(REV)" $< > $(srcdir)/immcc.1
endif
@gzip -f $(srcdir)/immcc.1
The variable TKGE803 gets its value at the beginning of the Makefile.in:
TKGE803 = $(shell perl -e 'use Tk; if ($$Tk::VERSION >= 803) { print "true"; }')
For a reason still unknown to me, TKGE803 gets the value true assigned.
Solution (for the time being): change "true" into "false" into the above statement so that TKGE803 gets the value "false" assigned instead of "true".
This way, the "ifeq" conditions further down the file will fail and the -u option will not be triggered anymore, resulting in a successful build.
Note that you have to run ./configure again after this change so that the final Makefile gets updated.
You can make use of iCbox to show one or more IEC variables while an application is running. However, you don't see the state of the internal variables this way, only what is the resulting in- or output.
To also see the flow of the application you can ask the system to show iClive too when starting up the application.
To do this, add the option -l to the application that should run, like so:
iCserver \
-R iCpiI2C -f -d300 \
QX140,0xFF \
QX830,0xFF \
~IX831,0xFF \
-R ff_ic -l \
-v ff_ic.vcd
As one can see, the option -l is added to the application ff_ic. Whenever this script is run it will also start up iClive. Don't forget to activate the Live button in iClive to see the coloured status like given in the image below.
Note that the button indicated with the red arrow has already been changed from Live to Edit. It means the live session is currently already activated.
Example command:
iCmqtt -GT0 -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items
Output example:
pi@rpi3Bimmcff ~/mystuff/ff_poc$ (master) iCmqtt -GT0 -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items
home_ff_s_OHalias.ih generated with IX10 - IX18 and QX10 - QX14
home_ff_s_OHdeclare.ih generated
home_ff_s_OHtest.ic generated
-I 19 -Q 15 -T 5 # input and output IEC addresses for next -G run
To generate the code, the most important parameters are:
-G: generate the following files:
<prefix>_OHalias.ih
<prefix>_OHdeclare.ih
<prefix>_OHextern.ih
where <prefix> is the prefix used in the items file of openHab. Example: home/ff_s, home/ff_p, home/verdiep, gf_s, gf_p
-F: filter to be used:
To grab everything in one go if you're using gf_s, gf_p, ff_s, ff_p is: [gf]f_[sp] as filter
That should correspond with what has been defined in the .items file.
In the above command, the filter is home/+. This means every line starting with home/ and followed by whatever (can be ff_s/ff_p/gf_s/gf_p...) will be taken into account during generation.
Example 1:
Switch Sw_Door_CorrStudyroom_A "Studyroom - Switch_A" <switch> (FF_Corridor)
{mqtt="
>[immgeva:ff_s/Switch/Door_CorrStudyroom_A:command:ON:default],
>[immgeva:ff_s/Switch/Door_CorrStudyroom_A:command:OFF:default],
<[immgeva:ff_p/Switch/Door_CorrStudyroom_A:state:default]"
}
This would need ff_[sp] as filter.
Example 2:
Switch Sw_Door_CorrStudyroom_B "Studyroom - Switch_B" <switch> (FF_Corridor)
{mqtt="
>[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:ON:default],
>[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:OFF:default],
<[immgeva:home/ff_p/Switch/Door_CorrStudyroom_B:state:default]"
}
This would need home/ff_[sp] as filter.
Example 3:
Switch Teleruptor_3_GF "Teleruptor 3" <office> (GF_Relays,GF_Teleruptors)
{mqtt="
>[immgeva:gf_s/IX21_4:command:ON:default],
>[immgeva:gf_s/IX21_5:command:OFF:default],
<[immgeva:gf_p/QX22_1:state:default]"
}
This would need gf_[sp] as filter.
Others could be:
home/[gf]f_[sp] in the following case:
Switch Sw_Door_CorrStudyroom_A "Studyroom - Switch_A" <switch> (FF_Corridor)
{mqtt="
>[immgeva:home/gf_s/Switch/Door_CorrStudyroom_A:command:ON:default],
>[immgeva:home/gf_s/Switch/Door_CorrStudyroom_A:command:OFF:default],
<[immgeva:home/gf_p/Switch/Door_CorrStudyroom_A:state:default]"
}
Switch Sw_Door_CorrStudyroom_B "Studyroom - Switch_B" <switch> (FF_Corridor)
{mqtt="
>[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:ON:default],
>[immgeva:home/ff_s/Switch/Door_CorrStudyroom_B:command:OFF:default],
<[immgeva:home/ff_p/Switch/Door_CorrStudyroom_B:state:default]"
}
-T: Generate test code. The number given should be smaller than the -I or -Q option. In this example it is 0, which means IX0... and QX0... will be generated and visible in the iCbox application.
iCmqtt -B -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items
Each time the test .ic file is changed, a make has to be run to generate the corresponding .c and executables. So, the following command must be executed after a change:
iCmake home_ff_s_OHtest.ic
To test the iCmqtt module with openHAB, do the following:
Start the openHab application in debug mode!!! Only then you will be able to access the openHAB server via a web browser. I don't know (yet) why the non-debug version is not working fine.
On a web page in a browser, go to the following URL: http://192.168.1.40:8080/openhab.app?sitemap=homecontrol
You should see the layout defined in the homecontrol.items file, located in ~/openHAB/configuration/items directory
Run the following command to start the immediateC environment:
iCserver -R iCbox X0-X4,,400 -R iCmqtt -B -F home/+ -I10 -Q10 ~/mystuff/openHAB/configurations/items/homecontrol.items -R home_ff_s_OHtest
This will start 2 iCbox components:
One to create the groups IX0-IX4 and QX0-QX4 where groups X0 to X4 are behaving like pushbuttons with a pressed state of 400ms.
One iCbox to monitor the openHAB input and outputs defined in the start command (here: IX10 and further + QX10 and further).
Next to this, the test application generated above will start and will communicate directly with the inputs and outputs of the iCbox application given in the start command (here I10 and further and Q10 and further).
When pressing a button on the test app iCbox dialogue, the connected QX output will react. Since that output is triggered, it will send out an MQTT message that is picked up by openHAB and because of this the interface on the web page will follow the state of the relay.
See the function that is part of the generated test application
The test application has two inputs to the relay:
One from the iCbox IX0-IX4
One from the openHAB web page via MQTT
The outputs of the relay go to both iCbox QX0-QX4 and via MQTT to the openHAB web page
I recently tried the newest Raspberry Pi OS called Trixie. I quickly encountered issues when trying to set up the system for use with immediateC.
Not that immediateC gave issues. Not at all! But when I tried to run iClive I got the famous "Tk.pm not found" message.
Never mind, I thought, let's install it using CPAN.
No way, José! Since Perl has been updated to version 5.40.1 the compilation failed.
Spending quite some time on it, but to no result.
I finally found a very convenient way of installing a matching Tk.pm for Trixie: sudo apt install perl-tk. This is a precompiled version for Trixie that gives you no fuzz or headaches to compile it yourself.
After installing this package iClive went fine!
Simpel as it can be!!!