Why and for What
|
The idea was born when I was on site at a customer where I should measure and
document the abilities of a realtime system. We started with some simple logic
analyzers, but they didn't help. So we changed the equipment to higher
price ones. We ended up with a 40,000€ device and also this one was not
able to give us the results we need. Most of them are very fast, but after a
trigger they are blind for a while, because they must process the captured data.
And also the highest price device works in such manner, so its useless for
realtime measurement, because you shouldn't miss any event over the whole
measurement period. If you miss one, your measuring is only garbage.
|
| |
|
|
|
So I made Kritzel. A simple capturing device, with one stimulation output channel.
The output channel is needed for realtime measurements. Kritzel triggers an
interrupt on the target system, while it captures its response. These tests are
done with different loads in the target system, to find the worst case response.
|
|
The Kritzel device is made very simple. It only captures changes on its 8 input lines
and sends these information through the USB to the host. Any data processing occurs
on the host only. That's why Kritzel's price is low and on the other hand you can process
the data on the host in any way you like.
|
|
Due to this division into capturing and processing there is no risk to loose any event on the signal
lines. Also you can do any processing whenever you want it to do. Right now, while
capturing or later. And you can repeat the processing whenever you like, because the data
set was stored to your harddisk.
|
Documentation
|
The manual how to build Kritzel can be downloaded as a PDF only.
|
The manual how to use Kritzel can be downloaded as a PDF only.
|
Sources
|
The manual refers a project archive. It can be downloaded
here.
|
|
Update 2010-05-03:
-
In firmware up to 0.1.7 the routine to capture and send events at a 500 ns rate is completly broken.
It only seems to work. The used FTDI 245 device has an annoying timing. So, its impossible to
send an event report in less than 6 µs. The new assembler routine in revision 0.1.8 needs in
the best case 98 clocks, which means 6,125 µs. This also leaks into the 4 µs capture rate:
The reports are only useful with an external event rate of at least 8 µs.
The 500 ns capturing rate was removed in the firmware revision 0.1.8.
Update 2010-05-01:
-
All firmware revisions up to 0.1.7 containing an error that leads into a command buffer overflow
and a firmware crash. Only a power cycle (cold start) helps. A fix will comming soon.
Update 2010-04-04:
-
The hardware documentation was updated.
-
The host part of the software was extended and a bug was fixed. This bug prevents kritzel from saving
all captured events when is was terminated by CTRL-C. Most of the time this happend when also a pipe
was used to forward the captured data to a live filter like kritzel_raw.
The updated host software 'kritzel-1.1.2.tar.bz2' and the whole ptxdist based project
'OSELAS.BSP-JB-Kritzel-0.0.3.tar.bz2' can be downloaded from
here.
|
|
|
The old manual can still be downloaded from here.
|
