Dangerous Prototypes Open Source Hardware

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

• Messages
• Topics
• Attachments

Messages - rasmus

16

Open Bench Logic Sniffer / Re: Status of RLE

January 23, 2011, 02:45:02 pm

Sure. Literally a one line fix. :-)

Code: [Select]

if timerSeconds = x"00000000" or cmd(7 downto 0) = x"91" then

In other words send 91h to set off the timer instantly.

17

Open Bench Logic Sniffer / Re: Status of RLE

January 23, 2011, 02:23:00 pm

[quote author="jgovers"]
I've got a question/suggestion.. Why do we need a timer inside the FPGA? We can configure everything we need from the client software, which has all the information at hand. A timer implemented in the FPGA will need to collect the necessary information to calculate from clock pulses to seconds. Why not let the software do that? This would remove the need for a 'second' counter.[/quote]

That is a good question. The answer is that we don't, it doesn't matter where the timer runs, but I don't code Java.

I'm going to add a "finish now" command. That command could be used to implement a "finish now" button in the client which would let you finish the recording right away instead of waiting for the timer. The command could also be used to implement a software timer in the client.

[quote author="jgovers"]And about the need for 'ringing': implementing a done signal should not be that hard. All we need to known is from which memory address actual data is stored. If the memory reaches the memory spot before that address it is full with good data.
[/quote]

The ringing is just there as a hack that I used to fix a problem I had when I tested the module. I'm not sure if it's needed the way it works now. It's only a couple of lines of VHDL anyway.

Edit: Just to clarify what I mean by "the way it works now", the client sends a reset every time you start a new capture. So assuming the client always does that then it's fine to let a state machine in the FPGA get stuck in a final inescapable state, because as soon as you start a new capture the state machine will reset.

18

Open Bench Logic Sniffer / Re: Status of RLE

January 22, 2011, 11:34:19 pm

I've set the timer to receive its time by the command 90h followed by four bytes of time expressed in seconds. Feel free to change this if you want, but I've set it to that for now.

So for example to set the timer to 32 seconds you (or rather the software client) would send 90h 00h 00h 00h 20h.

If you don't send a 90h command the timer will default to 20 seconds. Also, please note that the set timer command will not work until there is a PIC firmware (and a client) that supports it.

Bitstream and source below.

19

Open Bench Logic Sniffer / Re: Status of RLE

January 22, 2011, 05:05:06 pm

If it's just a matter of adding a new command to an existing structure in the VHDL then that would probably be easy. I'll have to take a look at it.

Edit: I took a quick peek at the VHDL and liked what I saw. This should be easy.

Edit2: I've added the feature. Haven't tested it yet, but it should work.

20

Open Bench Logic Sniffer / Re: Status of RLE

January 22, 2011, 03:01:51 pm

I'm not sure I follow. I don't know much about how it works, but I imagine that the software client sends command over the serial port to the PIC. The PIC then sends that to the FPGA. Is that anywhere near how it works? If so, which of the PIC and the FPGA is the SPI master?

21

Open Bench Logic Sniffer / Re: Status of RLE

January 22, 2011, 01:41:11 pm

Thanks for the feedback. The code is still in progress, with some fixes being made to the RLE module.

A configurable timer would be extremely easy to add inside the RLE module, but I don't know enough about how SUMP protocol and the Client -->  PIC --> Spartan chain works and I don't have time to look into it at the moment.

22

Open Bench Logic Sniffer / Re: Status of RLE

January 20, 2011, 03:32:47 pm

I'm releasing my code as it is now, version 0.0.4 of the RLE module. Beware that it's not fully optimized or beautified for easy reading...

It lacks a couple of features which would be nice to have, namely a user-configurable timeout and a better solution for how to reset the timer (get a signal when the memory is full).

23

Open Bench Logic Sniffer / Re: Device not found! error

January 20, 2011, 08:24:11 am

Take a look at the COM port in the Device manager in Windows. What driver do you have and what are the COM port settings?

24

Open Bench Logic Sniffer / Re: UART communication with OLS

January 18, 2011, 12:04:37 pm

FPGA --> SPI --> WiFi module could be pretty fast and reliable. The WiFi wing might potentially provide faster data rates than USB 1.1. That would be nice for a continuous mode.

Other nice perks would be that your OLS is never grounded and that you can access it from several meters away, although those obviously apply to bluetooth as well.

25

Open Bench Logic Sniffer / Re: Status of RLE

January 17, 2011, 06:55:03 pm

Thanks for the feedback David Francis. Did I say 60 seconds? The timer is actually set to 100 seconds, so that's normal behaviour. I must have confused it with 64 hex. :-)

About it not working on subsequent captures; it sounds like something doesn't go back to it's original state properly. Going to look into that.

jack.gassett: Sounds promising. 16-bit mode would be really useful for parallel bus captures if it was 16-channel and counted run-lengths all the way up to 65k.

26

Open Bench Logic Sniffer / Re: Status of RLE

January 17, 2011, 12:53:35 pm

Is there any harm done if the recording finishes before the timer? It could be useful to have a timeout when you're using sample rates in the sub-MHz range. (Why you would want to do that is a different question.)

I think it overflows correctly, but I have not spent a lot of time at testing the overflow behavior. How did you spot the overflow bug in 2.12?

I have a new version for you to test. Changes:
Timer is now set to 100 seconds.
Timer no longer interferes with triggered recordings.

27

Open Bench Logic Sniffer / Re: (Near) realtime cq. continuous mode acquisition

January 17, 2011, 10:19:08 am

I guess a lot of the user cases would involve 4-channel, 3-channel, 2-channel or even 1-channel communication data from unknown devices. Stuff that the Bus pirate is too slow to do. Sample rates and reliability would be important.

One obvious and simple solution would be to have 4-channel, 2-channel and 1-channel modes where the data ends up being packaged in 8-bit words. The 4-channel mode would allow sample rates to be twice as fast as the 8-channel mode. The 2-channel mode would be four times as fast and the 1-channel mode would be eight times as fast.

28

Client software / Re: Jawi's Logic Sniffer client software - releases and requests

January 17, 2011, 09:25:33 am

Yeah, that would be nice. I don't know much about how Java works and even less about where the relevant stuff is in the client. Otherwise I would have tried to modify it myself.

29

Open Bench Logic Sniffer / Re: (Near) realtime cq. continuous mode acquisition

January 17, 2011, 08:05:25 am

With regards to the RLE: it's not using anything that isn't used by the normal mode. The data path in the FPGA is 32 bits wide and the RLE module sits on that data path.

The 32-bit RLE module in firmware 2.12 throws away anything that comes in on channel 31 and replaces that with the RLE flag when RLE is enabled.

30

Open Bench Logic Sniffer / Re: "Capture Aborted! Device Not Found!" after update

January 17, 2011, 05:14:52 am

Is RLE on or off? Try turning it off. RLE on the 2.12 version doesn't really work.