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

16
Client software / Re: Repeated capture
Do you have a use case for this??

On a scope it obviously makes sense to have a live update of the analog signal, but I can't really think of any situation where I would want the logic channels to be updated every second or so.

Eberhard
17
Client software / Re: Jawi's Logic Sniffer client software - releases
[quote author="jawi"]@wayoda: that only 8 channels are shown is probably due to the fact that the 2nd, 3rd and 4th channel group are disabled. See the diagram settings to enable those...[/quote]

You are right, but since I (almost) never use more than the first channelgroup ...
Why do I have to enable the channelsgroups in two different places : the capture dialog and in the diagramm settings?
Any secret logic behind this?

Apart from the GUI stuff , I don't have any problems with signals being mirrored on different channels (with or without RLE /Java6 and Java7).
Test signal is the pwm-output of a BusPirate connected with 5cm long patchcables.

Eberhard
18
Client software / Re: Jawi's Logic Sniffer client software - releases
B.B. is right!
I'm so used to working with a maximum of 8 channels, that I didn't even notice that only 8 channels are shown no matter how many capturegroups have been selected.

[quote author="wayoda"]Capturing data on channels 0-15 at all speeds simply works.[/quote]
Not true, I spoke too soon, only the first 8 channels work for here (including RLE, Simple and 4 stage triggers), other channelgroups are not even shown on the screen.

Eberhard
P.S. I was just too exited about getting rid of RXTX which has given me headaches for a couple of years now!
19
Client software / Re: Jawi's Logic Sniffer client software - releases
Hi, Jawi
I tested the new version on latest Ubuntu with JRE 1.6 and JRE 1.7 and found no obvious errors. Capturing data on channels 0-15 at all speeds simply works. I never use more than 16 channels, actually I never used more than 7 channels in the last year, so I can't tell if there are problems with channels 16-31.

There are some minor issues with the GUI which are probably not to hard to fix for a new release:

I did have a problem with one of the panels in the capture settings dialog
[attachment=0]
The Before/After ratio slider could use a little bit more space in its layout. The slider is given no room to expand even if the user makes the dialog-window wider.

The application should remember the setting for last capture device.
When I start up the client  I always have to go through
[tt:]Menu->Capture->Device->OpenLogicSniffer[/tt:]
before I can start collecting data.
It would be nice if the client could remember my setting from a previous run, especially since it perfectly remembers my analyzer port name [tt:]/dev/OpenLogicSniffer[/tt:].


Eberhard
21
Open Bench Logic Sniffer / Re: PIC firmware v3.0 for Demon core v3
[quote author="ian"]The latest should be in the gadget factory git hub:
http://gadgetfactory.net/logicsniffer/
[/quote]

Hi Ian,

lately I searched for the PIC-Firmware source code on GitHub
https://github.com/GadgetFactory/OpenBe ... ic-Sniffer
but all I found where the already compiled HEX-Files in this location
https://github.com/GadgetFactory/OpenBe ... C_firmware

In the end I pulled the files from the old gadgetforge svn.

[quote author="ian"]
I attached my latest copy, though it may not be synced. You'll also need to get the Microchip USB stuff on your own.
[/quote]
Would be nice if the source code could be merged into the github project files, maybe into a  dedicated directory "PIC-Firmware/src".

Adding a README with a link to this article
http://dangerousprototypes.com/docs/Com ... C_projects
should get people started.

Eberhard
22
Open Bench Logic Sniffer / Re: Why should I buy?
Hi,
I'm lucky I  have the Salae and the OLS too. (But can't say any hing about the USBee)

The right tool for your SPI-problem depends on:
  • The clockspeed on the bus
  • The amount of data you need to see

If the SPI-clockspeed is greater 4-5MHz, the Salea is too slow at 24 MHz maximum samplerate, The OLS can cope with 20MHz at least.
But the OLS has even less onboard-memory than you wrote: It can capture only 24k of data on 8 channels.
If you have to record and analyze large amounts of data  you need the Salea because  it does not use any onboard memory, it streams the data to the host-computer over a fast USB2.0 port.

Eberhard
23
Client software / Re: Android client
[quote author="Tarloth"]Regarding the bluetooth connection, keep in mind that the PC is not as standard management as one might expect and that can bring many complications to the client.

In wich task can I help?[/quote]
I think the difficult part is on the OLS hardware side: connecting the bluetooth hardware and making the OLS talk over the bluetooth connection instead of using the USB.
(Making the Client aware of the Bluetooth-connection to the OLS doesn't seem to be a major problem to me.)

I also read what Ian wrote about this ....
[quote author="Ian"]pppd has already done this. It rolls over to serial if there is no USB I think. There were some minor changes to the firmware, mostly to setup the UART and do UART instead of USB buffers. It may even be in the latest release already (?)[/quote]
... but I don't understand it.
There is support for this in the PIC-firmware of the OLS already???
I think I followed every release, an also read release notes when available, so this would be a big surprise!

Can anybody shed some light on this?

Eberhard
24
Client software / Re: Android client
[quote author="ian"]
....
pppd has already done this. It rolls over to serial if there is no USB I think. There were some minor changes to the firmware, mostly to setup the UART and do UART instead of USB buffers. It may even be in the latest release already (?)[/quote]

Is there a place where to look for more information on this?
Bluetooth connectivity would be useful for my Desktop Machine as well, one less USB-cable on the workbench!

Eberhard
25
Client software / Re: Android client
Hi,
I would really like to see the OLS going wireless!

When I read through this thread I remembered that the OLS breaks out the Pins [tt:]RX1,TX1[/tt:] on header [tt:]JP1[/tt:].

AFAIK in the beginning the PIC used to communicate with the FPGA over this serial line. That was changed to SPI later on. Now it looks like these pins [tt:]RX1,TX1[/tt:] are not used for anything.
Is there a chance to control a Serial2Bluetooth and/or Serial2WiFi board over these two pins? That would make it very easy to connect any kind of communication hardware(BlueTooth,WiFi,Ethernet) to the OLS.
Are there major problems to be expected with the PIC-(FPGA?-)Firmware changes to make this work?

Eberhard
26
Bus Pirate Support / Re: Yet another GUI
[quote author="MickM"]I have it running fine with Fedora  15 x64.
I have never used QT-Creator before.
Where does it put the executable?
[/quote]
The location of the executable is shown in IDE when you start up the application with the run button.
A small console window pops up below the editor and prints something like
[tt:]Starting /home/wayoda/lab/buspirate/code/all-build-desktop-Desktop_Qt_4_7_4_for_GCC__Qt_SDK__Release/BuccaneersDen/BuccaneersDen...[/tt:]

The build directory is configurable via the "Projects" Button.

Eberhard
27
Bus Pirate Support / Re: Yet another GUI
Hi,
[quote author="Vincent"]Since the Bus Pirate v3 use generic vid/pid, auto-detection is impossible without talking to the device but if we talk to every FT232 and some are not Bus Pirate, who knows how they will react.  [/quote]

Every FT232 has a unique serial string.
My Buspirate can be easily be deteted by looking for the FT232-Device with
[tt:]idVendor==0x0403 idProduct==0x6001 iSerial==A6005lHV[/tt:]

On Linux you simply create a udev-rule like this one:
[tt:]/etc/udev/rules.d/bp.rules[/tt:]
Code: [Select]
#Create a nice link for the bus-pirate 
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A6005lHV", MODE="0666", SYMLINK+="BusPirate"
and the BusPirate can simply be autodetected by checking if [tt:]/dev/BusPirate[/tt:] exists.

At least on Linux it very simple to autodetect one (or more) BusPirate device(s)

Eberhard
28
Bus Pirate Support / Re: Any way to do partial writes on SPI?
Hi suravi,
I had a quick look at the datasheet of the 93c66 and  found this on page 5
Quote
Microwire Interface
A typical communication on the Microwire bus is made through the
CS, SK, DI and DO signals. To facilitate various operations on the
Memory array, a set of 7 instructions are implemented on FM93C66.
The format of each instruction is listed under Table 1.
Instruction
Each of the 7 instructions is explained under individual instruction
descriptions.
Start bit
This is a 1-bit field and is the first bit that is clocked into the device
when a Microwire cycle starts. This bit has to be “1” for a valid cycle
to begin. Any number of preceding “0” can be clocked into the
device before clocking a “1”.
This sounds like you can simply fill up the 3 bits of the device opcode with 5 extra zero-bits before the startbit. So you end up with 8 bits (for the opcode+startbit) which the BP can handle easily.

Eberhard
29
Open Bench Logic Sniffer / Re: Command 'ID' needs retries ?
Solved!

I didn't read all the bytes that where captured by the OLS and somehow the PySerial implementation on Linux doesn't seem to like that.
Flushing the pyserial input buffers before closing/after opening doesn't seem to help.
But maybe its the pydev plugin for eclipse that messes things up?

Anyway,  reading what you ask for in the capture setup solves the issue.

Eberhard
30
Open Bench Logic Sniffer / [Solved] Command 'ID' needs retries ?
Hi,
I'm trying to talk to the OLS through a bit of Python code. This most works fine but I have a litte trouble with the ID command from the Sump protocol.

What I'm doing is
  • Open the serial port
  • Reset the device (5 bytes of 0x00)
  • Send the ID command
  • Read back 4 bytes and check if they match '1ALS'
  • Capture some data
  • Close the device

But the String '1ALS' is returned without failure only when the device is opened for the first time after it is plugged in or if I hit the reset-button on the OLS between runs.

If the device had been used before, it takes several (4-6) retries until the ID is read back sucessfully. At first I thought I was doing something wrong and started to fill in some extra timeouts, but then I looked at Jawis Code and  he also takes up to 15 stabs at reading the ID.

Now I'm doing the ID part in a loop like the one in Jawis Code and it works
  • for i in range(15):
    • Reset the device (5 bytes of 0x00)
    • Send the ID command
    • Read back 4 bytes and check if they match '1ALS'

But I wonder why doesn't the OLS get that right in the first place?

Eberhard

( ! ) Fatal error: Uncaught exception 'Elk_Exception' with message 'Please try again. If you come back to this error screen, report the error to an administrator.' in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
( ! ) Elk_Exception: Please try again. If you come back to this error screen, report the error to an administrator. in /var/www/dangerousprototypes/forum/sources/database/Db-mysql.class.php on line 696
Call Stack
#TimeMemoryFunctionLocation
10.02362452472session_write_close ( )...(null):0
20.02392584088ElkArte\sources\subs\SessionHandler\DatabaseHandler->write( )...(null):0
30.02392584864Database_MySQL->query( ).../DatabaseHandler.php:119
40.06862723616Database_MySQL->error( ).../Db-mysql.class.php:273