yes , i realize that . and now it works . but how i can configure pc software to run continous ??
As barbudor mentioned it doesn't run continously. There are USB logic analyzers that send the samples real-time across the USB bus and the PC uses its virtually unlimited memory to record millions of samples or whatever. Those cost real money unfortunately and don't usually come with a nice open source client either. So it is a trade off, but using SUMP on the Arduino is cheap and easy and you don't need to dedicate the Arduino full time to use as a logic analyzer if you don't want, you can always reload a different sketch.
Here is a great video someone made showing the use of the Arduino generic logic analyzer (AGLA).
It is a great demonstration of looking at the clock, data, latch and 3 outputs from a shift register driven by an Arduino.
You can setup a trigger to start capturing when you see a specific pin toggle. You can add a button and press it yourself when you need to trigger if you have to, but ideally something in the logic signal you're looking at will be the trigger. In the shift register demo video he has two Arduinos, one with AGLA and one driving the shift register. If you added a debug pin toggle somewhere in the code on the non-AGLA Arduino, you could trigger on that pin with AGLA.
That is actually the technique I use to time the sample rates. I use the OLS (Openbench Logic Sniffer) hardware to watch a debug pin on the AGLA. When I sample I toggle the debug pin a few times, then turn it on, sample, turn it off. Since I have a trigger setup on the OLS to watch the debug pin it will start capturing when I initially toggle the pin. Then I can measure the time between pin on, sample, pin off to see how long the sample took.
The maximum sample rate at 16MHz is 5.333MHz (3 clock cycles per sample) but the timing doesn't work out right with that clock rate. You can still get that rate by removing the NOP on the 4MHz rate if you want to experiment. If you run your ATmega at 20MHz you can sample at 5MHz and it should work pretty well timing wise. I haven't tried it yet, but hopefully will eventually. Note this would generally be on your own board or a breadboard setup since the Arduino is clocked at 16MHz.
I settled on 2MHz and 4MHz as being particularly useful samples rates and they appear to be as accurate as the lower rates. The code size is rather significant now do the unrolled loops. It just fits on an ATmega328. If you're using an ATmega168 you will need to comment out either the captureInline2mhz() or the captureInline4mhz() call. Then the compiler won't link that function in and you'll be fine. You can also comment out one of the other capture lines but I would say probably commenting out captureInline2mhz() is the way to go as it is the largest and leaves you with 4MHz.
Note that you should really not expect to use triggers with 2MHz & 4MHz since I can't check the trigger conditions at those speeds. You can use a trigger though, just know that the sample rate for the trigger condition is below 1MHz so if you are toggling something to trigger the logic analyzer make sure the toggle is long enough to get caught. Once the trigger fires the sampling is done at the faster clock rate.
I've tested it on an Uno and a Mega and it works as expected. If you test it and run into any problems (besides that slow upload!) let me know by filing an issue on github or posting here.
I also added some commented out code at the end of setup() to turn on timer2 at 100KHz on pin 11. The code is '#if 0', just set that to '#if 1' to include it. This is really only useful to validate your setup works with a know signal that is internally generated. Since it is internal and using the same clock the sample code is using, it should give you a nice accurate 100KHz signal to look at in the OLS client. I've submitted a pull request to get the new sample rates into the OLS client device profiles in version 0.9.7 but the github repository also has updated device profiles.
My Arduino Uno R3 arrived today and I was able to reproduce the timeout issue. Bumping the 'device.open.portdelay' to 2000 took care of it.
For some reason the Uno R3 is slower to respond after reset than my original Uno or older Duemilenove and clones. I will investigate it a bit further if I get a chance just to see what the deal is.
Anyway I updated the device profile on github and sent a pull request to get the change into the alternate client. It should make it into OLS 0.9.7 (at RC1 right now) so Uno R3 users should be good once that is out.
Meanwhile can one of you folks that had problems with the R3 try bumping up the device.open.portdelay (change from 1500 to 2000) and report back? Thanks.
Looks good. What did the measurement tool calculate? How did it compare to your Agilent? Sample at 1MHz for a bit more precision.
The ATmega328 doesn't have much RAM so 1KB is about the limit. The device profile is configured for only 1KB max, but since there is something odd with it, you're getting more options with the original SUMP device profile. Now that you know the logic analyzer is working, you might try it with the correct device profile. You could adjust some of the timeouts as well to see if you can get it to respond properly.
I merged in a patch for basic RLE support, but I haven't spent the time yet fully testing it and getting the timing correct. It might help you get longer capture times. You can use triggers as well to ensure you start capture around the interesting bits.
Really if you want larger samples you have a couple of options. I would suggest the Open Bench Logic Sniffer for $50. It is a very nice device for the price. It is not unlimited either but has 24KB worth and supports RLE and advanced triggering. Another option is a USB device like one from Saleae Logic that streams the samples so you effectively have a buffer only limited by the resources in your computer. There are trade-offs. I am biased I guess but I think the Arduino is "good enough" a lot of the time, but the OLS is well worth the $50 versus $300 for another USB model.
Ok, it looks like it worked. At least you got samples back from the Arduino. Do you have a signal you can feed to it? You need to sample at a rate that will show something based on the frequency you are generating. E.g. if you look at a 10KHz square wave signal, try a 100KHz sample rate initially so you see the transitions.
I think I will order an R3 just to see if I can reproduce some of these issues.
Make sure you're not using a resistor to disable auto-reset. It is not needed with newer versions of the client.
Here are some troubleshooting steps: 0. Make sure serial monitor is closed. 1. Reset Arduino via hardware button. ( you also unplug / replug if you want) 2. Click start capturing button in OLS client. 3. Set to correct com port, 115200bps, device type "original sump device" (do NOT click show device metadata) 4. Click triggers at the top, make sure they are not enabled. 5. Click Acquisition at the top, make sure it is Default, Internal, 500.0kHz, channel groups zero, 1.00kB no test/noise/RLE 6. click capture. 7. note what happens. if necessary click 'STOP' in OLS client. 8. switch to Arduino IDE, open serial monitor, send '1' enter
Someone else with an UNO R3 reported somewhat similar symptoms and he was able to get it working after a bit. Try adjusting these three settings: (not all at once) device.open.portdelay = 1500 device.receive.timeout = 100 device.open.portdtr = true
You could try 2000 or 3000 for the portdelay, bump the timeout to 500 and try toggling the portdtr. Exit the client, unplug / replug the UNO, restart the client between settings change.
I would be interested to find out what makes a difference. I have an original UNO (bootloader updated to the rev 0001) but it works fine for me. Since I can't reproduce these R3 problems I might just pick up an UNO R3 to test out. At least if we can't figure out an easy fix.
A couple of updates. I had broken triggers with my previous change to PORTD and I've fixed it. I also went back to PORTB as the default (with PORTD as a #define option) as it seems to work better for me.
Secondly, I've added a branch with a "toy" release of a network attached logic analyzer. If you have a Wiznet W5100 (only thing I have tested) Ethernet shield you can play around with it with Jawi's OLS client. Configure your appropriate ip in the sketch, upload it and connect to it on port 1234 from the OLS client. I'm using PORTD as most of PORTB is the SPI connection to the Ethernet shield. It is on a branch if you want to mess with it: https://github.com/gillham/logic_analyzer/tree/aglan_alpha
It isn't particularly useful, but I suppose there might be a corner case where it helps. Anyway, check it out, it is kind of fun talking to the logic analyzer via TCP/IP.
One caveat about the function generator, it is setup for a LCD Keypad shield available on eBay. Look for the "DF Robot" on the silkscreen. If there is interest I could make a version with a different UI (one button & LED, or serial, or what?) if you want to make suggestions, you can post on github. You can use the square wave generator (max of 8MHz) as an emergency clock source for an AVR if you need it.
the only critisism i can't say to your project is, because of the need to do modification on the arduino board.
That's why i just write a little piece of code for arduino and processing to have a visualisation of what appen on different wire of my board.
Thanks AKkarol7. I just wanted to find out if there were any issues I could fix to make my logic analyzer easier to use or more useful. Making your own tool that does exactly what you need is cool too and part of the fun of learning how things work.
With a recent version of the sketch and client software you do not have to disable the automatic reset feature if you are using Jawi's alternative client. I will try to improve my README so it is more clear in that area. You should be able to just upload the sketch and launch the java client to use AGLA.
Je ne parle pas français. Désolé pour les erreurs de traduction.
Je suis l'auteur de l'esquisse Arduino analyseur logique. Si vous rencontrez des problèmes avec l'AGLA ou les fonctionnalités manquantes, j'aimerais obtenir de la rétroaction et de le corriger.
S'il vous plaît comprendre les limites actuelles sont dues à des contraintes matérielles de l'Arduino lui-même, je fais ce que je peux pour rendre l'échantillon le plus rapidement (et aussi profondément) que possible.
The master branch (what shows up on the front page of http://github.com/gillham/logic_analyzer ) should work fine on 1.0 and doesn't have the Mega external SRAM support. Make sure the branch drop down says "master" and you should have the right one.
I'm working on a version for the Mega with 512kb of external SRAM (via a "QuadRAM" board). The current branch doesn't bank switch and supports 55kb. My bank switch version is in development but will support at least 443kb of samples at 500KHz.
Anyway, let me know if you have any more trouble and try the master branch if you can.
The QuadRAM is paged, but without using any paging it adds a readily addressable 55KB of space for a capture buffer. My test branch supports capturing up to 55KB if you have the '#define MEGARAM 1' uncommented.
Due to some extra cycles on the external memory interface the sampling takes a bit longer and I had to adjust the timing a little. Currently a regular (non triggered) capture at 1MHz is no longer accurate due to the increased delays with the external SRAM, but 500KHz and lower appears to be fairly accurate. Triggered captures are not accurate at 500KHz (they weren't at 1MHz already) but are semi-accurate at 200KHz and lower.
Anyway, if someone has an external SRAM setup and can test this functionality I would appreciate feedback. Rugged Circuits has the board on sale for $19.95 which isn't bad for a 512KB expansion module. I'm not affiliated with them, I've just bought one of their boards.
Also, as the external memory interface uses the pins I had previously sampled on the Mega, I switched to analog pins 0 to 7. I was avoiding using the analog pins previously so they would be available for other uses, but as I haven't added any other features to the firmware at this point, I switched pins. The main branch has not been switched to A0-A7, but I might do that in the future.
I guys I am new to arduino. I work on LCD , TV, SMPS, etc. Sometimes I have to look up an IC data sheet and see what kind of wave it should put out on a certian pin so I can confirm the suspect IC is working.
Is there a way with this logic analyzser that I can use the arduino to test an IC just to confirm it works properly.
You should be able to use a logic analyzer if the specs in the data sheet match the capabilities of an AGLA setup. With limited numbers of samples and a limited sample rate it depends on the type of chip and what its digital signal is supposed to look like. If the IC's pin transitions are in the 10s of microseconds you should be able to catch something. You might want to read this page about all of the ways you can hook stuff up wrong and damage the pins on your Arduino: http://ruggedcircuits.com/html/ancp01.html
I was kind of assuming something written in Processing would be best. That way it is cross platform and could be used in conjunction with Firmata for example.
The thing with the oscilloscope is that the sample rate would be really low. It would be better than nothing, and I'm not saying it isn't worth doing, but you won't get that many samples across the serial port. Something like 11k 8 bit samples/second @115200 baud would be best case.
About the logic shrimp.. I prefer the Open Bench Logic Sniffer. Only a few dollars more and more capable. The whole point of my code for the Arduino is "cheap & dirty" without paying $35-$50 and just using what you have. I wouldn't expect anyone to buy a Mega to run my logic analyzer code, the OLS is cheaper.