sorry I'm confused (again?) by the PIC Firmware release number scheme.
I have Version 2.1 on my OLS. That came as part of the 2.12 Test-Release. Now I'm following this thread viewtopic.php?f=23&t=1711 and there is talk of a version 2.3 (what happend to 2.2?).
I'm wondering, where exactly is the source code for the PIC Firmware? On Gadget Forge's trunk/Firmware path I see different versions (V2.1 V2.2, no V2.3) which are all 2 month old (Revision 294). Is there a different repository where the active developers commit their changes?
Also when you are looking for (binary) Updates starting from the OLS-Wiki "Update" section, you get send all over the place to look for the files, but never to a fixed download page for the files. Somtimes you end up on an entry on the DG-Blog, other links send you to a topic on this forum.
I start to envy the people who are working in the BusPirate code. The GoogleCode repos for this project seem to be much better organized, with all downloads (binary and soure) in one place. Google Code also has the "issues" list which I find quite conveniant to use for bug tracking.
Is there a chance to sort this out a bit more logically? I don't care where the code is hosted, but having it in one place (with a way of RSS/Mail notification on changes) would be nice.
Thanks for all the work you have put into this Eberhard
P.S. Ian will be happy to hear that I ordered the BP anyway
Sorry about that, I didn't mean to push unneeded hardware. Did you get a probe cable? I can send you a free one. [/quote] Nothing to be sorry about Ian, I ordered after repairing the OLS. I have good use for the BP. Thanks for the probe cable offer, but I'm using breadboard patchcables most of the time.
Hi, robots [quote author="robots"] You have not killed your bootloader !, just use jumper to enter bootloader and upload the firmware again. using correct format.
I have made HEX default format, but the changes didn't make it to github. Sorry about that!.
Edit: Precompiled versions have default type set to HEX [/quote] Right, it's alive again. It was a bit of surprise to me (but obvious when you think about it), that the OLS disappeared completely from the USB.
Eberhard
P.S. Ian will be happy to hear that I ordered the BP anyway
[quote author="ian"] You can get a Bus Pirate from Watterot or ehajo in .de if you don't have one. The 18F24J50 on the OLS does NOT require the HVP adapter, you can program it directly. [/quote] Thanks Ian, great news! I'd rather support DG then.
wayoda@rebooter:~/lab/ols/code/ols-fwloader$ ./ols-fwloader -f BOOT -n -P /dev/OpenLogicSniffer -V -W -w ../../downloads/updates/OLSv1-FW2.1-final-1/OLSv1-firmware-v2.1.hex Found OLS HW: 1, FW: 0.6, Boot: 1 Found flash: ATMEL AT45DB041D OLS switched to bootloader mode Bootloader version 0.2.2 Bootloader version 0.2.2 Erasing flash ... Reading file '../../downloads/updates/OLSv1-FW2.1-final-1/OLSv1-firmware-v2.1.hex' file won't fit into buffer :( Writing flash ... (0x0800 - 0x0000) Protecting bootloader - skip @0x3be0 Checking flash ... file won't fit into buffer :( Verify failed :(
The OLS is not even enumerated on the USB any more, so I guess the bootloader was erased/overwritten?? I did not set the [tt:]-t HEX[/tt:] flag. Could that be the reason for failure? Wouldn't it make sense to check the file-format (using the extension and/or the well defined IntelHex Format) in future releases?
But having a combined tool for both update procdures is definatly the right way.
I do have a second board, so I'm not really worried, but how do I restore my broken board now? I guess I need a PIC programmer? Here in Germany the currently offer the "PICkit 3 Debug Express it 3" at a discount price, any advice on buying this one? (I would go for a BusPirate and the Programmer-Adapter, but I'd have to order the Programmer-Adapter from China. When I ordered the 2 OLS boards last year, they where hostages of the German Customs for 2 weeks. So much for globalization when its NOT about exporting stuff from Germany.)
Hi Ian, [quote author="ian"] Haha, 24 hours later and nobody dared download it Here's an updated firmware with fixed self-test for the new connections. [/quote]
The updated firmware seems to work (ran a few basic tests).
But I wonder
Quote
The PIC and FPGA now communicate over the same SPI connection shared with the ROM. This requires an updated firmware and bitstream with pin assignment updates. The reason is to reduce the number of pins needed to interface the system. Previously we used 3 AUX pins for the SPI connection between the PIC and FPGA, and the PIC, FPGA, and ROM shared three other SPI pins.
does all communication now happens over the DataFlash SPI-breakout pins on the pcb? That would make it quite easy to control the OLS from some custom SPI-Master hardware. (OLS run on batteries, with wireless network access? You can't buy that anywhere on this planet I think!)
Hi, I'm using Linux (Kubuntu 10.10 to be exact) for everything but video-editing, and decided to rewrite the ols-loader and the fw_update utility in Python. There is a Linux utilities discussion. A Python version should be much easier to package for different Linux distributions, since the code for the hardware-stuff is already available. There are python-serial and python-usb packages at least for Ubuntu.
Now I checked out the ols-loader code from svn (trunk/ols-loader) and I'm already confused about the set of parameters the ols-loader is expecting.
The wiki http://dangerousprototypes.com/docs/Logic_Sniffer:_OLS-loader_utility#Options lists a set of parameters ... [tt:]--port PORT - port of Logic Sniffer, needs to be specified. Same as -p Port[/tt:] [tt:]--speed SPEED - sets speed of the serial port. Same as -s Speed[/tt:] which is implemented in the [tt:]trunk/ols-loader/new-command-parser-version[/tt:] directory. It prints a version of [tt:]Logic Sniffer ROM loader v0.3 (September 30, 2010)[/tt:]
The code in the [tt:]trunk/ols-loader[/tt:] directory itself, uses the old-school parameters like [tt:]-p:PORT - port of Logic Sniffer, needs to be specified -t:SPEED - sets speed of the serial port[/tt:] but claims to be the more recent version [tt:]Logic Sniffer ROM loader v0.3 (November 9, 2010)[/tt:]
So which set of parameter-names is the right one to implement?
[quote author="jmcgill"] Would anyone with an OLBS be kind enough to verify that this works? Mine is in the post (to Australia, curse you seas!) [/quote] I can confirm this works with Jawi's client http://dangerousprototypes.com/forum/index.php?topic=716.0
[quote author="jawi"] While I'm at it: I'm already thinking quite some time about altering the color scheme; I think the current white/blue scheme is somewhat straining for the eyes, so I tried to make a scheme which is darker and provides different colors for each channel so its easier to distinguish which data is what channel. Would this be a good improvement or not? I've attached a screenie of how this would look like. [/quote]
The best solution to the problem I have seen so far is the Salea software. http://www.saleae.com/logic/gallery/ The signal traces are white on some darkish background, which provides for a lot of contrast. The probe colors are shown along with the label which makes it easy to identify the probe that recorded the signal. With this simple solution you are also free to use any other color for markup like Triggers or I2C analysis markers.
It is probably not nice to steal the idea from Saleae, but I bought one of their LA's so I feel less guilty.
[quote author="rsdio"] [quote author="honken"]But then I have to go back and figure out what the iSerialNumber is for...[/quote]All products have a Serial Number. [/quote] Sadly, Not! For instance the OLS does not have this USB String Descriptor, which has consequences when you have more than one board.
Windows and Linux (probably MacOs too?) use the combination VID/PID/SerialNumber to tell two devices with the same VID/PID apart. On linux you can write a very simple script that allows you to identify a device and give it a descriptive name by stating the VID/PID/SerialNumber unique to the device.
Here is for instance the script that identifies one of my Arduino boards that drives a LedMatrix.
#Rules for Arduino Board driving the LedMatrix ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="01234567", MODE="0666", SYMLINK+="LedController"
When the board is plugged in the script creates a new link to the device and my driver software calls open("/dev/LedController") to talk to the device. This works fine since the USB2SerialChip on the board has the SerialNumber String. The great thing about this feature is that your software can issue a detailed errormessage: If the device "/dev/LedController" cannot be opened it is either not plugged or there is a serious hardware problem.
The OLS does not have a serial. If you have only a single board you get by with the unique VID/PID combination:
#Rules for Openbench Logix Snifferslogic. Creates a link to the OLS ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fc92", MODE="0666", SYMLINK+="OpenLogicSniffer"
This will create a link "/dev/OpenLogicSniffer" which you can use to talk to te device.
But if you want to use more than one OLS you are stuck. The first one plugged in will appear as "/dev/OpenLogicSniffer", but as soon as you plug in the second board the link to the first device is removed, and a new link is created ow pointing to the second device.
There are some tricks to create unique names for the links , but they do not solve the problem to physically identify a OLS. Let's say you have one OLS with the latest Firmware upgrade and one withn the latest stable release. There currently is not way to tell this two devices apart. With a serial you could say the one with Serial==003 is "/dev/OpenLogicSniffer-Stable" and the one with Serial==016 is "/dev/OpenLogicSniffer-Latest"
Quote
The USB String Descriptor for Serial Number is just a way to make the serial number accessible through automated software, rather than having to manually read it off the original product box or a sticker on the product itself.
Its a bit more than this: Windows uses it for instance to always connect devices to the same Com-Ports. If you have more than one Arduino boards they will appear on different ComPorts and the OS will remember the board-specific port next time it is plugged in. This does not work with the OLS. The first time you plug it in a ComPort is assigned. But if you have a second board it will appear on the same ComPort because only VID/PID is available to identify the device.
About the original Topic "PIC firmware version as USB Device Version Number" Very good idea, will not break any existing code, do it.
About the Serial Number issue I think the SerialNumber String is necessary. Here are some ideas
The best solution was already mentioned by rsdio : If possible read the Atmel DataFlash-ID value on startup and put this value in the USB SerialNumber String. Atmel guarantees that this value is globally unique so the problem would be solved.
Another solution would be to set a default USB SerialNumber in the source code of the firmware, and write a short tutorial how users can change this value and recompile the Firmware on their own.
*grin* the code is set up in such way that they are (very) loosly coupled, in the form of separate projects. The idea is to have small pieces of functionality each in their own project with well-defined interfaces. ... I should be able to work the I2C tool while you work on the UART tool knowing that my changes cannot influence your code (unless I change the interface of course)
Ok, maybe trying to prove my point on the tools-tree was a bad choice. Current (and future) tools should definatly come in their own jar-file, with the client loading them into the application on request only. But splitting up the Gui , API and the Device it self so that they live in different source trees is a bit too much for me. For instance I'm currently playing around with capturing the data through ser2net since I have a spare first generation netbook which handles the serialIO that is initiated from my desktop machine (with the big screen) over WLAN. So my code would have to impelment stuff from the API project, but I would need to fiddle round with the Gui too, because I obviously need a Panel where the user sets the hostname and port where the OLS is sniffing.
Quote
The OSGi container solves the loading of the correct RXTX library for the correct host platform without having to mingle with JVM startup parameters, or fiddle with the JVM installation.
Yes, that is a good reason for Operating Systems that don't have a package manager. If I had to name one good reason why someone wants to switch to Linux its the package manager!
Quote
The problem you face in Eclipse is that (probably) you've not enabled the Maven support of the projects. This way, Eclipse doesn't recognize the Maven dependencies and does not add them to its compilation classpath. Maybe, I should add some lines in the README on which Eclipse plugins are minimally needed...
I installed maven support but still no luck. I really not up to spending my time making Eclispe work or digging into maven and OSGI sorry.
Eberhard
Quote
Let me know if you're problems with maven persist.
FYI : Looks good up to bundle when running mvn package then
Try downloading the file manually from the project website.
Then, install it using the command: mvn install:install-file -DgroupId=nl.lxtreme.ols -DartifactId=api -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=nl.lxtreme.ols -DartifactId=api -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency: 1) nl.lxtreme.ols:client:bundle:1.0.0-SNAPSHOT 2) nl.lxtreme.ols:api:jar:1.0.0-SNAPSHOT
2) nl.lxtreme.ols:util:jar:1.0.4-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command: mvn install:install-file -DgroupId=nl.lxtreme.ols -DartifactId=util -Dversion=1.0.4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=nl.lxtreme.ols -DartifactId=util -Dversion=1.0.4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency: 1) nl.lxtreme.ols:client:bundle:1.0.0-SNAPSHOT 2) nl.lxtreme.ols:util:jar:1.0.4-SNAPSHOT
---------- 2 required artifacts are missing.
for artifact: nl.lxtreme.ols:client:bundle:1.0.0-SNAPSHOT
from the specified remote repositories: central (http://repo1.maven.org/maven2)
Hi Jawi, I have checked out you sources from the github repo, but I have not found a way to create an eclipse project from the files in the repo. I have only marginal knowledge about eclipse, since I do most of my work with "emacs+ant+commandline".
When I looked at the code in the repo it looked like it was run over by a car because all the source-files from the packages somehow end up in in different directory trees, and not in a subtree of a common src-dir. For instance the java-code from the nl.lxtreme.tools.base and nl.lxtreme.tools.i2c packages in my opinion should not look like this:
Eclipse seems to take care of this huge structure for you. But if you are not into IDE's that much, you don't really want to move through 18 directrories (9 up 9 down) to get from BaseData.java to I2CData.java.
The other problem I have with your code is the use of the OSGI framework. I was not able to find out how to install the framework into eclipse so I could compile the project. This is where I stopped. Do you really need the OSGI framework, or could you live without it? What exactly is it good for in this specific project?
I'd really like to help with the code, if you could consider reorganizing the sources and (if possible) drop the OSGI dependency.
Besides not knowing much about Eclipse, I also know near to nothing about Git :-) I always seem to be one step behind (just managed to see mercurial as my friend not my enemy).
But I can promise to write a working ant build-file so you don't need maven to build the project (which also did not really work on my Ubuntu machine). I'm really looking forward to a stable and convenient Client now that most of the hardware issues have been solved I think.
Here's an updated firmware with fixed self-test for the new connections.