After a very long time, I finally made some time to start finalising the upcoming 0.9.7 release. Before going actually making a final release, I'd like to hear some feedback about its current state. So, I'd like to ask you guys to give the latest RC1 snapshot a spin on your machines. Bugs, issues and so on can be reported in this thread, or on GitHub.
While working on the support for the Demon Core triggers (see viewtopic.php?f=57&t=4628), I've noticed something strange about the ACT and TRIG LEDs:
The ACT LED goes on right after a reset, which its doing for as long as I remember (I'm running the DemonCore FW for a long time now), but after reading the documentation, it should only be lit when actively waiting for a trigger, i.e., once the "arm basic trigger" or "arm advanced trigger" command is send;
The TRIG LED goed on once a trigger is activated, and deactivated probably when all data is pushed out to the client. For the basic triggers this works as expected, but in the advanced trigger mode, this LED remains lit until a new capture is started. Issuing reset commands does not make a difference in this.
I've not tested this on the "original" bitstreams, so I cannot verify the "old" behaviour, but I think this behaviour is somewhat confusing, not?
I'm currently busy developing on the long awaited support for the Demon Core triggers in my client. So far, I've got a small DSL that can be interpreted and translated to the necessary LUT configurations.
Today, I was feeling bold and decided to give the current code a test ride. So, I coded a small test rig to write the LUT configurations to a real OBLS running DemonCore v3.07, and it worked! A simple one-stage trigger that looks for a simple bit-pattern was correctly triggered by external input and caused the capture to finish.
There's still tons of stuff that needs to be done prior to getting the current code ready for prime-time, but its a start...
The OLS client supports the annotating of data to present additional information along with the signal data. For example, many of the decoding tools use annotations to represent the decoded data. For the new signal display component, I'd like to implement a new style of annotation rendering that is both useable regarding its presentation of data, as well looks good.
I'd like to invite as many people as possible to cast their vote on which annotation style rendering they prefer. Screenshots are added below to give you an idea on how the current styles look.
If you've got new ideas on how to represent annotations, please post them in this topic! All ideas are welcome!
I'm shouting it across several topics already for quite some time, but the new OLS signal display component is becoming more and more mature. To inform all those interested, and to get valuable feedback from you guys, I decided to post a new working mock of it.
the need for speed; the drawing routines are optimized in such extent that the component can handle large data sets quite easily (up to 10M samples tested);
look and feel; I got assistance from Marius in the design of the look and feel. He helped me greatly in improving the default look and provided two new ways of showing annotations (more on this later);
keyboard navigation; the zooming can be controlled from the keyboard now (+/=, -/_, 0 and 1). Additional navigation features can be added easily (moving left/right with cursor keys and such);
cursors can be added from the timeline as well as the signal view; right clicking a cursor now provides a real context-sensitive popup menu;
cursors can now be placed in 'snapped' to a signal edge.
CTRL/CMD + mouse click allows you to easily jump to a future signal edge
renaming of channel labels can be done by right clicking it;
channels can be reordered by drag-and-drop. Channels can also be moved to another channel group with this;
channels can be "disabled", meaning that they are drawn as if they were continuously low;
cursor, measurement and acquisition information is now presented in separate windows that can be docked/undocked/moved at will.
Any thoughts, ideas and/or improvements? Post them!
I'm playing a bit with the binary mode of the BusPirate, and was suprised by its completeness of functionality: almost everything can be accessed through this mode as well! One thing I did not find back (nor in the Wiki, nor in the source) was the frequency measurement functionality. Is this on purpose, or simply never implemented?
I've some mail contact with a OBLS user (Emil) that is testing the OBLS in a very simple setup: a 74LS161 (= sync. 4-bit counter) which is clocked by a 4MHz (canned) oscillator. The 4-bit output of the 161 is captured, along with the "carry" and input clock signal on channels 0..5 of the OBLS, while channels 6 & 7 are tied to ground:
[list type=0] [li]Original clock;[/li] [li]Q0 of 161;[/li] [li]Q1 of 161;[/li] [li]Q2 of 161;[/li] [li]Q3 of 161;[/li] [li]TC/carry of 161;[/li] [li]Ground;[/li] [li]Ground.[/li][/list]
Upon capturing (@100MHz), glitches appear in the captured results, even on the grounded channels! Enabling the noise filter option somewhat reduces the level of glitches, but not 100%. See the following screenshot: [attachment=0]
After building the same circuit myself, I was able to reduce the glitches a bit more by tying channel 6 to +5V instead of ground. This results in spurious glitches in channel 5 only, as far as I tested.
I only got a 74LS161 myself, but Emil has tested it with a 74F161 as well, and sees similar results. One thing I did notice was that visualizing the output of the LS161 on my scope revealed quite a lot of overshoot. While it might be a clue, it could also be either my crappy local oscillator or the limited bandwidth of the LS161...
Anyways, we're a bit baffled by this result, and cannot explain why this happens. Can anybody shed a light on this?
I've been working on an improved component for the display of captured signal data from the LogicSniffer for some time now, and wanted to share the current results with you guys. Reasons for rewriting the component can be found on this Wiki page.
Anyway, I've made some screenshots, and a runnable JAR file, for people to play with. Its still very early alpha code, but good enough for demo purposes.
Attached you find some screenshots with some highlights of the new component, along with a runnable demo application.
Let me know what you think of it, such as improvements, ideas, suggestions, and so on...
For some reason my OLS's bootloader got mangled, causing me to perform a OLS-rescue operation. After several disappointing tries with the .NET application, I compiled the PiratePICprog and it worked instantaneously! It rescued my beloved OLS, which is now happily capturing again...!
I'm thinking about writing a new rescue-howto for the OLS. Maybe in a couple of days, as I'm now busy with other stuff (the OLS client).
I've been playing around with the continuous mode firmware to see how I can integrate this into my client. I've got a proof of concept, which works fairly good. But, I'm wondering about the following, mostly use case related. So, do you:
want to simply see the last X samples on screen until the trigger(s) is/are matched and see the set (predefined size?) of samples (or until you're fed up with it and abort the capture);
be able to make really long captures without worrying about memory issues. How usable would this be, having hours of sample material without some sort of post-processing.
I guess the first point aids to the "wow"-factor, while the second point would be more practical. But then again, I've used LAs only a few times, so maybe I'm missing use cases...
For a while now, I've been working on my own Java client for the OLS. While the original SUMP client certainly works, it has its drawbacks and limitations. For example, the fiddling around with the RXTX library on various OSs and the lack of (dynamic) runtime extensions without recompiling the clients to name a few. So, I took the original SUMP sources, and "hacked" away...
While it is certainly not ready or complete, it is already quite usable, so hereby I want to make a first public release.
A highlight of the changes:
Make use of Felix OSGi framework as plugin mechanism/runtime environment;
Integrated the RXTX library for Mac OSX (64-bit, SL), Linux (32/64 bit) and Windows (32/64 bit). The RXTX library no longer needs to be installed separately;
Improved the UI "snappiness" by profiling the various drawing routines (signal drawing improved with approx. 200%) and making (better) use of the Java threading model (SwingWorker) to improve the analysis tools (done for I2C & state analyser);
Support more than 2 cursors.
Ideas and future improvements:
Make the sources publicly available through some public hosting site (Github, ...);
Create some sort of home page/documentation;
Add UI for performing some basic measurements between (sets of) cursors;
Add tools for 1-wire, and other protocols (USB?);
Improve the look&feel on other OSs (Linux and Windows);
...any other ideas?...
You can download my OLS client from: [s:]http://lxtreme.xs4all.nl/~jawi/ols/ols-0.5b3.tgz[/s:]. Basically, it is gunzipping/untarring the archive and running the "[tt:]run.sh[/tt:]" script in the felix folder, or invoking [tt:]java -jar bin/felix.jar[/tt:] from a commandline.