[fprint] fprint for embedded
Jono Woodhouse
justcool_fprint at capesoft.com
Thu Jan 17 15:41:29 GMT 2008
Hi Daniel, Davidlohr and Andrei
This is a very interesting thread...
I too have been working on using the libfprint library on an embedded
(cris) architecture, and as of last night now have a working model,
where a fingerprint is read on an embedded cris Linux machine and send
it to a Linux i386 machine which performs the identification, the
results are then sent back to the cris Linux machine.
The cris machine is too slow to perform the identification process by
itself - partly because it runs at 100MHz and even more so because it
has no Floating Point Unit - (doubles are used heavily by the bozorth3
and mindtct algorithms in the nbis code).
At the moment I've hacked the libfprint library with a series of #ifndef
that control which part of the project is built. But as Davidlohr
suggested a set of smaller libraries, may well be a lot cleaner and
easier to use. Specifically in the embedded world.
In our case the cris machine only has 4MB of flash disk space - so using
glib and ImageMagick is totally out of the question.
The big question, that's running around my head at the moment is what to
do with these changes.
Since this is primarily Daniel's project, it makes sense to see if all
the changes that embedded developers are making could be folded back
into either the main source line, or branched sources for each version
that Daniel releases.
Daniel, is this option, or would you prefer a new separate embedded
project altogether (although this seems a pity)?
List of tasks (done)
----------------------------
In v0.03 only - customised for the cris embedded device, that only
captures the fingerprint
1. #ifndef out all the bits that use ImageMagick
2. A small subset of glib function (g_free g_malloc g_malloc0 g_realloc
g_memmove) written using stdlib c library functions
3. include a small subset of glib types
4. #ifndef out all the bits that use all other glib functions (e.g.
GSList linked lists etc).
5. Expose some of the internal functions through fprint.h
e.g. dev_to_img_dev
6. Only include the one driver we are using (uru4000)
7. Hand copy config.h and Makefile - since I can't ./configure for my
embedded architecture (you can in theory - but in practise it doesn't
work well enough always)
8. #ifndef out all nbis code - since I don't need that code
9. I've then written some wrapper code (in my project - but I'm half
tempted to put this back into the libfprint library code), that hacks
together all the devices, drivers, usb_ids, discover devices, image
drivers & images so that one can capture fingerprints without having to
run fp_discover_devs() (which has glib dependencies).
List of tasks (done)
----------------------------
In v0.05 only - customised for i386 device, that needs to reconstruct an
image (which it didn't capture on this machine and then perform
identification)
1. #ifndef out all the bits that use the Crypto Library since I don't
use AES_encrypt etc.
2. Expose some of the internal functions through fprint.h, as in my
project I need to be able to construct an image from raw data that's
sent to the function via TCP/IP, and I then need to identify the image
without a fingerprint being captured.
As, you probably guessed, it's all been a bit of hack up till now -
which is fine as this was to prove the concept works (which I can now
happily say it does). And so I am wanting to formalise these changes
now, in a way that's clean, and also useful to other people doing
similar projects.
List of tasks (to do)
----------------------------
- update the embedded version to v0.05
- expose the necessary internal structs and functions through fprint.h
- possible add my wrapper functions (??)
- as well as exposing direct access to the nbis functions (and possibly
also some of their settings too)
- look into seeing if you can have a sig_atomic_t that is checked in the
fingerprint capture loop code, so that it's possible to abort a
fingerprint capture even while you are say await_finger_on().
- investigate the interrupt of Death - which I still sometimes get using
the uru4000
- investigate profiling of the nbis code - although I am guessing the
coders at NIST have done this.
Your thoughts and comments would be appreciated.
Daniel, thanks again for a fantastic project. Well done. I hope your
lectures give you top marks.
Cheers
Jono
Davidlohr Bueso wrote:
> Currently I am doing major fprint modifications. Removing
> glib/imagemagick, fixing leaks, separating the project into different
> little independent modules. I will have get this proyect working on a
> little ARM machine. Hopefully I will have something ready to show soon.
>
> The basic idea is that a rather heavy monolithic fprint library is
> separated into smaller, lighter, simpler (usually) independent modules
> (libraries actually) that can be used in a wide range of devices and
> architectures (like ARM, microblaze, etc). So, for example, if I
> wanted to implement a matching server, I can use that specific lib,
> and not care about enrolling, capturing, etc.
>
> 2008/1/11, Gustavo Chain <g at 0xff.cl <mailto:g at 0xff.cl>>:
>
> El Tue, 8 Jan 2008 16:01:03 -0800
> "Jeff White" <jdwhite08 at gmail.com <mailto:jdwhite08 at gmail.com>>
> escribió:
>
> > I am trying to get fprint to work on an embedded system,
> specifically
> > a microblaze processor.
> > I am running uclinux and using a secugen hamster III reader. Is
> there
> > any way to strip down the libraries and code needed to the bare
> > minimum. I don't need any graphical interface, just the capture and
> > verification.
> >
> > I have been havening difficulties with getting libiconv and gettext
> > that are needed for glib to compile. Are they really needed, if not
> > is there a way around them.
> >
> > Thanks,
> >
> > Jeff White
>
> You will have to rewrite a big chunk of code, removeing routines
> (Imagemagick, etc).
>
> By the way, lots of fingerprint aplication/solution are installed on
> embedded system, libfprint should try to minimize dependencies (glib?)
> and be designed modular (optional builds)
>
>
>
> --
> Gustavo Chaín Dumit
> http://0xff.cl
> _______________________________________________
> fprint mailing list
> fprint at reactivated.net <mailto:fprint at reactivated.net>
> http://lists.reactivated.net/mailman/listinfo/fprint
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fprint mailing list
> fprint at reactivated.net
> http://lists.reactivated.net/mailman/listinfo/fprint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.reactivated.net/pipermail/fprint/attachments/20080117/09337146/attachment-0001.html
More information about the fprint
mailing list