Programming ACR122T-E2 in linux - nfc

I have an ACS ACR122T-E2 NFC reader. I downloaded the linux driver and the ct-api library from
http://www.acs.com.hk/en/products/109/acr122t-usb-tokens-nfc-reader/ .
I have extracted the sample C program from the header given in the ct-api library archive file. I compiled it. I also created the ctacs.ini file with this content:
[CardTerminal]
CTN1=ACR122T
[ACR122T]
ICC1=ACS ACR122 25 00
When I running the compiled executable I just get:
Error: CT_init failed with error -8
where -8 is for "CT Error" based on the documentation in the header file.
Does somebody have some experience with this ACR122T-E2 and the official C API given for it?
Does anyone have some idea on what should I check for or what should I try to do?
The only one thing I guess I might be wrong with, is the ctacs.ini file. I am not really sure if the
ICC1=ACS ACR122 25 00
line is right. I used "lsusb -t" which shows:
Bus 03.Port 1: Dev 25, If 0, Class=Chip/SmartCard, Driver=pn533, 12M
Of course I already have tried
ICC1=ACS ACR122 03 01
config line, but did not help.
Does anybody have some idea, what this configuration line should be?

A after several hour of reading different posts at different sites, studying the available NFC related packages on Ubuntu, and also got a bit of help from the maintainer/developer of the official ACS driver I managed to get this example program to work.
The solution is, to unload/remove the kernel's default drivers.
modprobe -r np533
modprobe -r nfc
Then to install and run pcscd:
apt-get install pcscd
service start pcscd
Install pcsc_scan:
apt-get install pcsc-tools
Now pcsc_scan can be used to figure out the right ICC line for the ini file:
...
Reader 0: ACS ACR122U 00 00
...
Thus the right content the ini file is:
[CardTerminal]
CTN1=ACR122T
[ACR122T]
ICC1=ACS ACR122U 00 00
Now running the compiled example C program (from the ct-api library archive file downloaded from ACS) the output is:
Response: 62 00
Not much, but at least it is working now and I can continue exploring this NFC world.

I am using Windows and was struggling with the ctacs.ini file too. The trick (for me) was retrieving and using the actual CCID name. I retrieved mine by using "Springcard pcsc quick start" which shows the CCID name when the program opens. I use an ACS ACR122U-A9 with windows 8.1. The ini file below works for me.
[CardTerminal]
CTN1=ACS-ACR122-0 ;Just a name, can be an arbitrary value
[ACS-ACR122-0] ;Must correspond to name given above
ICC1=ACS ACR122 0 ;This is the actual name of the device (CCID)

Related

VLC : which file to update VLC Lua youtube script on Mac OS X?

I am trying to read a youtube video through VLC on my mac:
/Applications/VLC.app/Contents/MacOS/VLC -v https://www.youtube.com/watch?v=afzmwAKUppU&app=desktop
Which gives errors :
VLC media player 3.0.
8 Vetinari (revision 3.0.8-0-gf350b6b5a7)
[00007faf5b5e9140] lua generic warning: Error while running script /Applications/VLC.app/Contents/MacOS/share/lua/extensions/youtube.lua, function descriptor() not found
[00007faf5b4589c0] macosx interface warning: Failed to enable media key support, likely app needs to be whitelisted in Security Settings.
[00007faf5b784950] securetransport tls client warning: Ignoring ALPN request due to lack of support in the backend. Proxy behavior potentially undefined.
[00007faf5b770200] lua stream warning: Couldn't extract video URL, falling back to alternate youtube API
[00007faf5b6b5b60] securetransport tls client warning: Ignoring ALPN request due to lack of support in the backend. Proxy behavior potentially undefined.
[00007faf5f97ce70] securetransport tls client warning: Ignoring ALPN request due to lack of support in the backend. Proxy behavior potentially undefined.
2020-10-15 13:45:28.281 VLC[65658:198319] Can't find app with identifier com.spotify.client
[00007faf5b5d8580] lua stream error: Couldn't extract youtube video URL, please check for updates to this script
[00007faf5b44b570] main playlist: playlist is empty
The youtube.lua, I got it by downloading the file from internet :
curl "http://git.videolan.org/?p=vlc.git;a=blob_plain;f=share/lua/playlist/youtube.lua;hb=HEAD" -o /Applications/VLC.app/Contents/MacOS/share/lua/extensions/youtube.lua
Which works on my ubuntu, but not in my Mac: I am wondering if this is not the correct version for Mac OS. And so, which file should be put there ?
If I look on the VLC Lua directory, I find :
/Applications/VLC.app/Contents/MacOS/share/lua/extensions$ ls -l
total 192
-rw-r--r--# 1 romain admin 72K Aug 14 2019 VLSub.luac
-rw-r--r-- 1 root admin 22K Oct 15 13:35 youtube.lua
the youtube.lua is the new script I added, but maybe it was another one to put there ?
Probably a bit late here now, but in any case:
You need to take the youtube.lua from here: https://github.com/videolan/vlc/blob/master/share/lua/playlist/youtube.lua
Then rename it to youtube.luac and place it in the directory (for MacOS) /Applications/VLC.app/Contents/MacOS/share/lua/playlist
I would recommend renaming the old one and keeping it in case something goes awry.
At least on my computer this worked and I can now open YouTube videos in VLC again.
Have you tried the 3.0.11.1 release? https://get.videolan.org/vlc/3.0.11.1/macosx/vlc-3.0.11.1.dmg
You're correct that youtube.lua would be the correct file, though the issue might come from other parts of the code depending on it. FYI, since you are running a stable VLC build, the code you should look at is https://code.videolan.org/videolan/vlc-3.0/-/blob/master/share/lua/playlist/youtube.lua.
https://code.videolan.org/videolan/vlc/-/blob/master/share/lua/playlist/youtube.lua is nightly v4 unstable builds (though for the lua script, they are identical).
Additionally, look out for a new release with an updated script soon https://mailman.videolan.org/pipermail/vlc-devel/2020-October/139076.html

Building Automotive Grade Linux for Raspberry Pi

I am currently trying to run the AGL demo platform on the RaspberryPi3.
I have proceeded according to the following instructions:
Building the AGL Demo Platform for Raspberry Pi instructions
However, the output Image tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi2.wic.xz as specified in the link is not created when building with bitbake.
Instead only one image file is created: tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.rpi-sdimg.xz
When trying to copy the image file to the SD card (with etcher and the following command line:
sudo dd if=./<file-Name.rpi-sdimg of>=<sdCard>) the demo cannot be started. When booting the RaspberryPi only a black screen appears.
But if I use the following .wic.xz from
raspberrypi3/deploy/images/raspberrypi3 - Files
and copy it to the SD card everything works fine.
Why does the image file not work and why does "Bitbake" not create a .wic.xz, although everything is done as described in the instructions from AGL?
I had also got a similar error.
I do not know the reason but this fixed the issue.
xzcat output-img.xz | sudo dd of=[sdcard] bs=4M

Class "Veins::ObstacleControl" not found

I have followed step by step the tutorial to install Veins, but when I tried running the example scenario (final step) I ended up with the above error.
The whole error was:
Error in module (cModule) RSUExampleScenario (id=1) during network
setup: Class "Veins::ObstacleControl" not found -- perhaps its code
was not linked in, or the class wasn't registered with
Register_Class(), or in the case of modules and channels, with
Define_Module()/Define_Channel().
TRAPPING on the exception above, due to a debug-on-errors=true
configuration option. Is your debugger ready?
Simulation terminated with exit code: -2147483645 Working directory:
C:/Users/user/src/veins-4.3/examples/veins Command line:
../../../omnetpp-4.6/bin/opp_run.exe -r 0 -n .;../../src/veins
--tkenv-image-path=../../images -l ../../src/veins omnetpp.ini
I don't think I have missed a step during the tutorial as I have tried it two times. I did not make any change in anything, I've just strictly followed the tutorial like a robot, so I cannot provide an MCVE with more details than the tutorial.
Here is what I'm using:
- Windows 7 Pro 64 bits
- SUMO 0.25.0 64 bits
All other steps of the tutorial successfully worked until the final step.
I assume this error occurs when running Veins via the OMNeT++ IDE. Or, if you have compiled it with GCC (The error does not happen if you use CLANG)
There are two ways to bypass this error:
Use the .run as executable from your examples directory, which calls veins/run and includes all the required libraries:
Use opp_run as executable and set dynamic libraries to the directory where libveins.so is located (usually src/veins)
PS: to answer #ChristopSommer questions: Veins::ObstacleControl appears in opp_run -l src/veins -h classes
This could be a solution too, but I never tested it: Compiler flags in Eclipse

Problems in installaing Magento in Windows Shared Server using Plesk

I don´t know how to do. I always have the same error no matter what I do to protect the files. The host (mochahost) don´t give me any support. So I will try if a good soul here could help me.
These are the errors:
Warning: include_once(Mage/Core/functions.php) [function.include-once]: failed to open stream: No such file or directory in C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\Mage.php on line 49
Warning: include_once() [function.include]: Failed opening 'Mage/Core/functions.php' for inclusion (include_path='C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\code\local;C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\code\community;C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\code\core;C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\lib;.;C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\Pear;./includes;./pear;./;') in C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\Mage.php on line 49
Warning: Varien_Autoload::include(Mage\Core\Model\App.php) [varien-autoload.include]: failed to open stream: No such file or directory in C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\lib\Varien\Autoload.php on line 93
Warning: Varien_Autoload::include() [function.include]: Failed opening 'Mage\Core\Model\App.php' for inclusion (include_path='C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\code\local;C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\code\community;C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\code\core;C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\lib;.;C:\Program Files (x86)\Parallels\Plesk\Additional\PleskPHP5\Pear;./includes;./pear;./;') in C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\lib\Varien\Autoload.php on line 93
Fatal error: Class 'Mage_Core_Model_App' not found in C:\inetpub\vhosts\e-interage.com.br\httpdocs\dinossauros\app\Mage.php on line 620
Best regards
The answer is in your question - you are 'installing Magento in Windows Shared Server using Plesk.'
You are using Windows shared hosting for an application developed for a linux box, preferably one with lots of resources.
Even if you get this working you will be spending your time adapting the software to your setup, not developing your shop.
How much do you value your time?
Is it more than your (shared) computer's time?
If so, get the right hosting, which at a minimum is virtual server, linux flavour. The installation instructions will work for you. Same with any other problems you have with your build - all the instructions and forum tips are for linux, i.e. with the path separators going '/' and not Microsoft backwards-'\'.

How does Linux Kernel know where to look for driver firmware?

I'm compiling a custom kernel under Ubuntu and I'm running into the problem that my kernel doesn't seem to know where to look for firmware. Under Ubuntu 8.04, firmware is tied to kernel version the same way driver modules are. For example, kernel 2.6.24-24-generic stores its kernel modules in:
/lib/modules/2.6.24-24-generic
and its firmware in:
/lib/firmware/2.6.24-24-generic
When I compile the 2.6.24-24-generic Ubuntu kernel according the "Alternate Build Method: The Old-Fashioned Debian Way" I get the appropriate modules directory and all my devices work except those requiring firmware such as my Intel wireless card (ipw2200 module).
The kernel log shows for example that when ipw2200 tries to load the firmware the kernel subsystem controlling the loading of firmware is unable to locate it:
ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
ipw2200: ipw2200-bss.fw request_firmware failed: Reason -2
errno-base.h defines this as:
#define ENOENT 2 /* No such file or directory */
(The function returning ENOENT puts a minus in front of it.)
I tried creating a symlink in /lib/firmware where my kernel's name pointed to the 2.6.24-24-generic directory, however this resulted in the same error. This firmware is non-GPL, provided by Intel and packed by Ubuntu. I don't believe it has any actual tie to a particular kernel version. cmp shows that the versions in the various directories are identical.
So how does the kernel know where to look for firmware?
Update
I found this solution to the exact problem I'm having, however it no longer works as Ubuntu has eliminated /etc/hotplug.d and no longer stores its firmware in /usr/lib/hotplug/firmware.
Update2
Some more research turned up some more answers. Up until version 92 of udev, the program firmware_helper was the way firmware got loaded. Starting with udev 93 this program was replaced with a script named firmware.sh providing identical functionality as far as I can tell. Both of these hardcode the firmware path to /lib/firmware. Ubuntu still seems to be using the /lib/udev/firmware_helper binary.
The name of the firmware file is passed to firmware_helper in the environment variable $FIRMWARE which is concatenated to the path /lib/firmware and used to load the firmware.
The actual request to load the firmware is made by the driver (ipw2200 in my case) via the system call:
request_firmware(..., "ipw2200-bss.fw", ...);
Now somewhere in between the driver calling request_firmware and firmware_helper looking at the $FIRMWARE environment variable, the kernel package name is getting prepended to the firmware name.
So who's doing it?
From the kernel's perspective, see /usr/src/linux/Documentation/firmware_class/README:
kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device)
userspace:
- /sys/class/firmware/xxx/{loading,data} appear.
- hotplug gets called with a firmware identifier in $FIRMWARE
and the usual hotplug environment.
- hotplug: echo 1 > /sys/class/firmware/xxx/loading
kernel: Discard any previous partial load.
userspace:
- hotplug: cat appropriate_firmware_image > \
/sys/class/firmware/xxx/data
kernel: grows a buffer in PAGE_SIZE increments to hold the image as it
comes in.
userspace:
- hotplug: echo 0 > /sys/class/firmware/xxx/loading
kernel: request_firmware() returns and the driver has the firmware
image in fw_entry->{data,size}. If something went wrong
request_firmware() returns non-zero and fw_entry is set to
NULL.
kernel(driver): Driver code calls release_firmware(fw_entry) releasing
the firmware image and any related resource.
The kernel doesn't actually load any firmware at all. It simply informs userspace, "I want a firmware by the name of xxx", and waits for userspace to pipe the firmware image back to the kernel.
Now, on Ubuntu 8.04,
$ grep firmware /etc/udev/rules.d/80-program.rules
# Load firmware on demand
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware_helper"
so as you've discovered, udev is configured to run firmware_helper when the kernel asks for firmware.
$ apt-get source udev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 312kB of source archives.
Get:1 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (dsc) [716B]
Get:2 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (tar) [245kB]
Get:3 http://us.archive.ubuntu.com hardy-security/main udev 117-8ubuntu0.2 (diff) [65.7kB]
Fetched 312kB in 1s (223kB/s)
gpg: Signature made Tue 14 Apr 2009 05:31:34 PM EDT using DSA key ID 17063E6D
gpg: Can't check signature: public key not found
dpkg-source: extracting udev in udev-117
dpkg-source: unpacking udev_117.orig.tar.gz
dpkg-source: applying ./udev_117-8ubuntu0.2.diff.gz
$ cd udev-117/
$ cat debian/patches/80-extras-firmware.patch
If you read the source, you'll find that Ubuntu wrote a firmware_helper which is hard-coded to first look for /lib/modules/$(uname -r)/$FIRMWARE, then /lib/modules/$FIRMWARE, and no other locations. Translating it to sh, it does approximately this:
echo -n 1 > /sys/$DEVPATH/loading
cat /lib/firmware/$(uname -r)/$FIRMWARE > /sys/$DEVPATH/data \
|| cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data
if [ $? = 0 ]; then
echo -n 1 > /sys/$DEVPATH/loading
echo -n -1 > /sys/$DEVPATH/loading
fi
which is exactly the format the kernel expects.
To make a long story short: Ubuntu's udev package has customizations that always look in /lib/firmware/$(uname -r) first. This policy is being handled in userspace.
Wow this is very useful information and it led me to the solution for my problem when making a custom USB kernel module for a device requiring firmware.
Basically, every Ubuntu brings a new rehash of hal,sysfs,devfs,udev,and so on...and things just change. In fact I read they stopped using hal.
So let's reverse engineer this yet again so it's pertinent to the latest [Ubuntu] systems.
On Ubuntu Lucid (the latest at time of writing), /lib/udev/rules.d/50-firmware.rules is used. This file calls the binary /lib/udev/firmware, where magic happens.
Listing: /lib/udev/rules.d/50-firmware.rules
# firmware-class requests, copies files into the kernel
SUBSYSTEM=="firmware", ACTION=="add", RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
The magic should be something along these lines (source: Linux Device Drivers, 3rd Ed., Ch. 14: The Linux Device Model):
echo 1 to loading
copy firmware to data
on failure, echo -1 to loading and halt firmware loading process
echo 0 to loading (signal the kernel)
then, a specific kernel module receives the data and pushes it to the device
If you look at Lucid's source page for udev, in udev-151/extras/firmware/firmware.c, the source for that firmware /lib/udev/firmware binary, that's exactly what goes on.
Excerpt: Lucid source, udev-151/extras/firmware/firmware.c
util_strscpyl(datapath, sizeof(datapath), udev_get_sys_path(udev), devpath, "/data", NULL);
if (!copy_firmware(udev, fwpath, datapath, statbuf.st_size)) {
err(udev, "error sending firmware '%s' to device\n", firmware);
set_loading(udev, loadpath, "-1");
rc = 4;
goto exit;
};
set_loading(udev, loadpath, "0");
Additionally, many devices use an Intel HEX format (textish files containing checksum and other stuff) (wiki it i have no reputation and no ability to link). The kernel program ihex2fw (called from Makefile in kernel_source/lib/firmware on .HEX files) converts these HEX files to an arbitrary-designed binary format that the Linux kernel then picks up with request_ihex_firmware, because they thought reading text files in the kernel was silly (it would slow things down).
On current Linux systems, this is handled via udev and the firmware.agent.
Linux 3.5.7 Gentoo, I have the same issue.
SOLVED:
emerge ipw2200-firmware
Then go to /usr/src/linux
make menucofig
on device driver, remove all wirless drivers don't needed, set Intell 2200 as module and recompile.
make
make modules_install
cp arch/x86/boot/bzImage /boot/kernel-yourdefault

Resources