Skip to main content

Messages

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 - mabl

3
Client software / Re: Jawi's Logic Sniffer client software - support and bug reports
[quote author="robots"]
1/(x+1) is a hyperbolic function, not a linear function. So you probably cannot set any sampling rate.
[/quote]
True, the highest possible sampling rates are quiet far away - but at 1kHz there should be no limitation. Between 10kHz to 1kHz there are 90000 possible settings.

Actually, not even the first 20 sampling rates are exposed:

> 100*1/(seq(0,20)+1)
 [1] 100.000000  50.000000  33.333333  25.000000  20.000000  16.666667
 [7]  14.285714  12.500000  11.111111  10.000000   9.090909   8.333333
[13]   7.692308   7.142857   6.666667   6.250000   5.882353   5.555556
[19]   5.263158   5.000000   4.761905

Where only 100, 50, 20, 10 and 5 MHz are available in software.
7
Client software / Re: Jawi's Logic Sniffer client software - releases and requests
[quote author="arhi"]
[quote author="mabl"]
When I checked, it was not in the right format to be loaded by the logic sniffer client.
[/quote]
I have not found the format description so I did what any proper dev would of done :D I just dumped object (array of bytes in this case) on to disk :D
[/quote]
Yeah, I did a quick look into a saved project of the java sniffer. The format is straight forward, should be no problem.


[quote author="arhi"]
of course, I didn't say python is "bad lang" just that it is sooooooooooo ugly to me that it makes me vomit .. and that it is only language that induces this feelings out of many ..
[/quote]
Never mind, it's the same for me with C++. For example I just don't get why any modern language should not have "Named parameter". (Yes, I know the technical reasons but it is still so ugly). Ah, and don't tell me x86 asm gives you this warm fuzzy feeling :D


[quote author="arhi"]
the "triggering on the remote server side" ... I assume you want the capturing app to handle triggering and then to transmit the file to the client ... I'm really not sure it all makes much sense as actually we need a client that is aware of all the stuff that needs to be done so maybe it is simpler if client can do the sampling directly
[/quote]
I guess it's a design decision. I like to be able to run things separated. - Just my two cents..

[quote author="arhi"]
Quote
The same purpose why X11 is socket based.
don't get me started on that too ... if we managed to convince the community in '93-'95 to move the r5 on the dri platform and forget the backward compatibility with sockets now windows would not rule the desktop market and we would have decent desktop already for over 10 years ... but everyone is a general after the battle :( ...
[/quote]
HA! I knew this would convince you ^^
8
Client software / Re: Jawi's Logic Sniffer client software - releases and requests
[quote author="arhi"]
Quote
1. We might first export captured data to a file and load it with the logic sniffer client. I had a quick look into the file format and it seems simple enough.

if you look at the ftdiCLI I wrote - it does just that, it samples as many bytes as you request and stores in file .. then you can do with it whatever you like
[/quote]
When I checked, it was not in the right format to be loaded by the logic sniffer client.

[quote author="arhi"]
Quote
2. Decide on software architecture:
  a) Directly integrate into the java client
  b) Use an external client over TCP/IP.

  I guess the second choice sounds reasonable. We could use some nice XML/RPC calls. My personal favorite language is Python - not sure if it can handle the 60MB/s stream of data, though...
I mentioned many times in many places, I use more then 60 programming languages and python is the only one that I find disgusting. Also 60MHz is 60 megabytes per second of data, most HDD's cannot write this fast for long period of time (until you fill the buffers), writing triggers to handle 60megabytes per second stream in python :D :D :D :D :D :D yeah right ... also, tcp/ip - overhead is too high for something like this, we could push udp stream but since in 99.9% cases the 2232h and desktop gui app will be on the same machine - what would be actually the point of encapsulating the stream in the tcp/ip, then decoding it in java ... I know today's cpu's are fast but .. cmon ..  
[/quote]
Well, it's always a matter of taste. And as I mentioned, I have never used Python for such high bitrates. But I think you misunderstood me, I don't want to transfer the data in realtime over Ethernet. It would be far more easy to handle the triggering at the remote server side and do all the trigger/sampling configuration over XML/RPC. Once it has been captured, you can easily compress it and transmit it via TCP. Of cause we won't have a real time display that way. But as you mentioned, that wont be possible anyway.

[quote author="arhi"]
Quote
3. In the long run, the OSL interface could also be migrated to TCP.
for what purpose?
[/quote]
The same purpose why X11 is socket based.
9
Client software / Re: Jawi's Logic Sniffer client software - releases and requests
Hey arhi, thx for the explanation! I guess it's best to stick with the current hardware, therefore ignoring lost samples (there is no way in software to determine lost samples? wth..)

1. We might first export captured data to a file and load it with the logic sniffer client. I had a quick look into the file format and it seems simple enough.

2. Decide on software architecture:
  a) Directly integrate into the java client
  b) Use an external client over TCP/IP.

  I guess the second choice sounds reasonable. We could use some nice XML/RPC calls. My personal favorite language is Python - not sure if it can handle the 60MB/s stream of data, though...

3. In the long run, the OSL interface could also be migrated to TCP.
4. Design specialized hardware. The software side should be quiet straight forward by then.
10
Client software / TCP sockets, continous analyzer mode
True, it's a great idea to use tcp sockets for communication. Eventually this could also be useful for the OSL. Imagine running the OLS remotely on an arm board (like Dockstar) but displaying the result on your local computer.