Examine the silver oscillator on your board. See if it says 16Mhz or 20Mhz. Find the matching bootloader file (OLSv1-bootloader-v2-16MHz.hex or OLSv1-bootloader-v1-20MHz.hex) Use your PicKit to write the CORRECT bootloader.
-------------------
Connect the OLS to your PC. Short the PGC & PGD pins. Press the reset button. Windows should mount the OLS as a HID device.
-------------------
Start olswinloader v2.02 You should see "OLS-HID" in the port list. Select the new PIC firmware (OLSv1.firmware.v3.0.hex) Click OK to download. When finished, click Close. OLS should now appear as a COM port. Remove short on PGC & PGD pins.
-------------------
Start olswinloader 2.02 again. Select OLS COM port listed in port list. Select the FPGA image file (logic_sniffer.bit) Press and hold UPDATE button on OLS. Press and release RESET button on OLS. Now release UPDATE button. Click OK to download. When finished, click Close.
-------------------
You're OLS is now ready to use. Start the Client. Select the correct COM port. Capture data. Enjoy!
I don't think RLE is as bad as you think. It should never be worse than the original sample rate.
If every sample is different, all it stores are values. ie: <1><2><1><2><1><2> => <1><2><1><2><1><2>
If there are duplicates, only then do you get counts. ie: <1><1><2><1><1><2> => <1><count=1><2><1><count=1><2>
A 10Khz signal sampled at 100Mhz in non-rle mode would store 10000 samples per 10Khz pulse. In 16 bit or 32 bit rle-mode, it consumes only 4 samples per pulse: <1><count=4999><0><count=4999> repeat... In 8 bit mode, the same 10KHz signal burns 158 samples per pulse (counters are too small).
Assuming 32-bit mode, jbeale's one event per second sampled at 100Mhz is very doable. That is only three or four samples per second. The 31-bit rle-counter can handle over 20 seconds of nothing. A single buffer full represents hours of captures at that rate. -- IED
[quote author="rsdio"]Basically, it seems to me like the pre-trigger capture should always occur at 100 MHz or 200 MHz, unless additional logic can be used to convert the timing. [/quote] This is -exactly- how the v7 fpga works right now... and people don't like it. :-) The fpga fills the buffer at maxspeed until it's armed, at which point it observes the sample rate.
The triggers evaluate whatever comes out of the sampler (every nth sample). I'm inclined to agree with EasyRider here: If you need high resolution triggering, you should be sampling at a high rate & use rle to counter long periods of nothing happening.
Another point... once the client fully supports the advanced trigger, you'll find working in state mode very helpful. It's specially intended for applications that sample at high rate, but you need to see only specific events (not everything).
The sequencer controlled captures allow you to detect various events, capture them, go idle for while, detect something else & capture that, go idle for while, etc... all without "triggering". At some point you find the really important event & trigger, thus ending the capture. True, you lose "time" indication but the -events- of interest are all there for perusal.
The advanced trigger sequencer allows for very sophisticated captures. You can capture certain SPI transactions (out of everything), or track flash memory accesses & only record writes to a specific address range, etc...
Between sequencer captures & rle I think the bases are nicely covered.
[quote author="jawi"]If my understanding of the "state" mode is correct, the device itself should initiate when it is transitioning to another state, right? That is also different from the current device, in which the software only initiates communication...[/quote]
Edit: From the client perspective, "state" mode should be pretty easy. Nothing more than setting a flag bit, and displaying sample -counts- in the timeline (along top of waveforms) instead of time. You should also disable ability to configure the state "capture" terms. You should also be prepared to handle partial buffer dumps when using the on-demand buffer return command.
The real difference between timing & state mode is simply what gets captured. In timing mode, everything gets captured, so displaying by "time" makes sense. In state mode, only those things the trigger wants captured are stored. So displaying by "sample number" makes more sense.
I've made things confusing I'm sure (big surprise). The advanced trigger sequencer is a state-machine, which has multiple sequence levels it can move through.
However acquisition "state" mode is simply a description (matching HP's terminology). It implies the sequencer is controlling what gets captured. Thus using -time- to display samples makes no sense. In state mode, you could have a burst of captures, minutes of nothing, another burst, etc...
Referring to the advanced trigger as having sequence levels instead of states should help.
[quote author="DavidFrancis"]When RLE is used the pre capture should be based on time and not events otherwise the capture might never happen if the trigger event is the first event.[/quote] RLE will be a headache no matter what. In 32-bit RLE captures with non-changing data on a slow sample rate, it could take weeks to reach the pre-trigger threshold. I'm minded to say the user gets whatever they ask for...
In state mode, the fpga doesn't wait for the pre-trigger threshold in any case. If the trigger occurs immediately, I don't see the problem.
XP. I'm pretty sure Windows looks. There are tons of structures to sift & enumerate. The details get stored away in the depths of the registry. Perhaps it's GUI doesn't bother parsing it all though. So they have the capability, the information is all there, they just aren't bothered. -- IED
[quote author="rsdio"]That level of support for USB is different for each major version of Windows. If you're getting the "Logic Sniffer" string descriptor in your version of Windows, then it's highly likely that a dual-serial-port board would also be identified with a unique string for each port - at least if the USB Descriptors were designed with the extra information.[/quote] Windows has quite a few different text fields for each USB device. Derived I believe from the USB standard itself. Windows & Mac should be identical in that respect. Whatever GUI presents it to the user will obviously differ...
So on my machine: Location Info : "Logic Sniffer CDC-232" Device Description : "Communications Port" Friendly Name : "Communications Port (COM12)" Manufacturer : "Microchip Technology, Inc."
I'm not -certain- what would change assuming there were two "COM" ports hanging out there. However, my guess would be two devices listed, both identified as Logic Sniffers, with different "friendly" names. ie: treated like there was a USB hub with two Logic Sniffers plugged in.
So ols-winloader, which just grabs the first non-empty string (in the order shown above) would display: "COM12 - Logic Sniffer CDC-232" "COM13 - Logic Sniffer CDC-232"
The Logic Sniffer -is- identified as such. In my ols-winloader, the phase "Logic Sniffer" that appears isn't something I'm tossing in there. It comes from Windows, which presumably gets it from the OLS. Jawi's serial port library simply doesn't have the code to retrieve it from the setup-api.
A serial port connection between the fpga & PIC would be slower than the SPI connection. 115200baud (11520 bytes/sec) verses 10Mhz SPI (~1 MByte/sec max). Upload time would probably slow from a couple seconds to ~10 seconds. Depends on overhead in the PIC, which would have to use xon/xoff to throttle the fpga. -- IED
Ok... I've been reading the user reference for the HP 16555A. What we've got here is a failure to communicate. :-) I've been thinking in terms of "state" mode. You've been thinking in terms of "timing" mode. The goal was emulating the HP, and I'm sticking to that.
In state mode, data capture is controllable. Data is displayed in waveforms as "states". In automatic mode, the state trigger position is wherever it ends up based on the sequencer. The manual clearly states "This process could result in a varying portion of available memory being filled with post-trigger data". The idea of a "manual" trigger point is nothing more than a non-guaranteed goal.
In timing mode, data capture is not controllable - everything is captured always. Data is displayed in waveforms as time. Trigger controlled captures are disabled. In automatic mode, its based on delay and sec/div settings (as you mentioned). In manual mode, the percentage of pre/post capture is specified & fixed. Purely a client user interface artifact.
Clarity at last.
To date, SUMP clients currently are strictly timing mode. Fair enough. However, a state mode is immensely useful for debug more complex situations. So when Jawi gets around to supporting the advanced trigger I'll ask nicely for to support states.
----
From the fpga perspective, tweaks are needed for both modes.
In state mode, once armed the fpga captures as controlled by the trigger. When the trigger fires, the controller waits for a maximum of "delay-count" post-trigger captures. However, the controller only returns valid captures from the point when armed. If there were 8 captures, you get 8 captures. No more garbage data.
In timing mode, once armed the fpga should capture unconditionally to the pre-capture percentage. Only then are the triggers activated. Captures continue. Once the trigger fires, "delay-count" additional captures are grabbed by the controller. So pretty much what you've been asking for. However, if user hits "finish now", the user only gets that data captured to date. Supports finishing a -very- slow sample rate, yet allowing user to still see the captures thus far.
----
I still like the idea of allowing the client to poll the fpga during capture. Gives the user some feedback, letting them know if their triggers are doing anything, etc... So:
Poll Command 0x07: 1) How many captures have occurred thus far. 2) What state/level the basic and advanced triggers are in. 3) If the advanced or basic triggers have fired yet. 4) The buffer position where -last- trigger event occurred. 5) If capture is complete (triggered & delay-count captures stored).
Capture Command 0x08: Return the contents of the capture buffer now (however much that may be). Implicit "finish now".
New flag to specify "state" mode verses "timing" (default) mode: In timing mode, sequencer capture control is ignored (ie: forced always). Controller unconditionally captures to pre-trigger threshold before enabling triggers. In state mode, sequencer capture control enabled. Controller enables triggers immediately. If user hits "finish now", both modes only return whatever was captured beforehand. However, timing mode guarantees the buffer -can- fill if the user waits long enough.
New flag to control capture returns. Return on buffer full (default), or manual (via 0x08 command).
[quote author="EasyRider"]I believe this works exactly the way I preferred it would - pre-trigger data has to be collected in all circumstances before a trigger is considered (if pre-trigger is non-zero). I'd still much prefer it to work like this, in all modes, if possible... :)[/quote]
If the advanced trigger is setup to capture everything, then no problem. However, if you strictly control captures then see the trigger condition, there simply might not -ever- be enough pre-trigger captures. In addition, the advanced trigger could be configured to not capture -anything- after firing.
Must be why HP had "automatic" verses "manual" acquisition modes. In auto mode, the trigger position is computed based on the trigger sequence. What you quoted was "manual" mode. I'm remembering the auto mode.
I'm thinking the client needs more information & control. The ability to poll & see: 1) How many captures have occurred thus far. 2) What state the advanced trigger is in. 3) If the advanced or basic triggers have fired yet. 4) The buffer position where -last- trigger event occurred. 5) If capture is complete.
New commands for capture-state polling & returning of capture data: 0x07 - Poll capture state. 0x08 - Return capture data.
A new flag to control "auto" verses "manual" mode. In auto mode, everything is at the mercy of the trigger. In manual mode (default), the trigger firing is ignored until the trigger-position is reached. If the adv-trigger sequence doesn't support re-triggering so be it. If the adv-trigger never fills the buffer, so be it. If the capture -does- reach the trigger position, triggers, but doesn't continue & fill the buffer, so be it. The adv-trigger must be configured to capture often enough to reach the trigger-position, trigger, and continue capturing afterward to fill the buffer. If the user cancels capture, all bets are off. The "poll-capture-state" command shows where the last trigger was & "return-capture" returns whatever was captured.
Another new flag to control if the controller sends data back automatically (default), or under manual control to enable safe polling (ie: to avoid poll data colliding with a capture return).
Windows would be fine. Bigger problem would be confusing the client & user. Both ports show up as Logic Sniffer's. However, the fpga only responds to one of them, and you won't necessarily know which except by trial-n-error.
Seem like it'd be better to have separate serial port builds of both PIC firmware & FPGA. It'd be a -lot- slower uploading captures though. -- IED
Another possibility just occurred to me. I could do the 2.12 behavior with basic triggers. However, with the advanced trigger I'd change the controller behavior.
Instead of always returning "read-count" number of samples, only return actual captures. Even if "finish now" was requested. So the amount returned to the client would be variable. I'd need to append something to the captured data to identify the actual trigger point to the client.
Thus if your advanced-trigger setup captures 5 samples, triggers, and only captures 3 more before you hit "finish-now", you'd see 8 samples total in the client.
The "read-count" becomes an upper-limit, and the 50% ratio business sort of meaningless if the trigger fires too quickly, or you hit finish-now. I vaguely remember the 16550 working that way (been a long time since I last used one). -- IED
The "missed samples when armed" referrs to a bug that lost two samples when first arming the trigger. EasyRider's issue is because the fpga hasn't had enough time to fill 50% of the buffer before the trigger fired.
There are two values used by the controller. The "delay" count and "read" count. With a 50% trigger, the read count is 2X the delay count. ie: In 8 bit mode, delay-count = 12K samples, read-count = 24K samples
So... The analyzer gets armed & starts capturing. The trigger fires almost immediately. The controller waits for 12K samples (delay-count), then pushes out 24k samples (read-count). However, the fpga doesn't have 24k samples. Only those captured during the delay-count. The other 12k are old data, garbage, whatever, lingering in the buffer.
The 2.12 isn't entirely immune to the same problem. For example, if you change the sample rate, you'll see it.
For demon core, I wanted the advanced trigger to control captures however -- aka HP16550. So I needed to tweak things...
My initial choice was to have the fpga wipe the buffer when idle, and capture when armed. I can replicate the 2.12 behavior easily enough, although I'm not sure its desirable with trigger controlled captures.
Assuming the advanced trigger fired immediately, you'd see a capture of everything up to time zero, then only what the trigger wanted captured after. Basically the same thing you see now. My alternative wiped the buffer, and only stored actual captures.
Unfortunately I can't go both ways. The fpga doesn't know in advance of all its configuration being thrown at it when you hit capture.
If people prefer the 2.12 behavior I'll post an update. An easy tweak. -- IED
