[Wulfden’s] new gadget is a 28 channel 3.3 volt digital logic analyzer. Powered by a Parallax Propeller running at 100MHz (permitting a 10 nanosecond sampling rate), using all though hole parts, and open design so it is possible to whip up your own.
Data is collected and sent to a host computer running Propalyzer which looks to be a very nice logic analyzer front end, and sports all the needed features and a HP inspired design. The design of the board allows you to plug it on to any Propeller Platform board, and this is very handy for those who have other Propeller boards, though others will have to source a regulated 3.3 volt power supply, and serial converter.
Overall this looks to be a very handy tool to have around, whether you opt for the kit to use on your Propeller Platform boards or roll your own, the features and cost are very attractive if you need a logic analyzer.
Join us after the break for a quick introduction video by [Nick] (of Gadget Gangster)
[vimeo http://vimeo.com/19542703 w=450]
Now this looks AMAZINGLY USEFUL! Thanks for sharing!
Hey, look! an ardu- … wait….
But on a side note why does everyone love through-hole parts so much? When I’m fabbing my own boards I’d much rather just etch and drill and fill a couple of vias than have to drill rows and rows of holes for all of the through-holiness.
@Squirrel – That’s just it, when you fab for yourself you make it easy for you. When you fab for others and sell as a kit, you make it easy for them.
I thought the Propeller is only designed to go to 80MHz. If it’s stable at 100MHz, that’s great news! Other than a ~25% increase in current consumption, are there any problems associated with clocking it at 100MHz?
The market must be getting saturated with these hobby-grade logic analyzers. There’s the Saleae logic and its cheap clones, the Open Bench Logic Sniffer, the Bus Pirate (sortof), and now this. I guess that’s good since it should drive prices down. It would be nice, however, if there could be one GUI frontend. All that time spent reinventing the wheel could instead be put into adding more features.
@Andy – Datasheet specs 80Mhz, but it will run at 100Mhz just by swapping the crystal. You also The PPLA comes with a custom cut 6.25Mhz xtal so you get a nice even 100Mhz.
Power consumption goes up a little. Consumption here is probably 30mA instead of 20mA.
@Nature – I normally agree, but the gui here is so simple, it took me just a few minutes to figure out.
One thing i couldn’t find out from the website or video was the maximum number of samples per capture.
I somehow doubt, that this captures 30 channels at 10ns continuosly and transfers them directly to the computer. Maybe that is where the multiple cores come in. But any logic analyser i looked at so far always included a maximum sample size in its specs.
I am very skeptical about the performance of this logic analyzer attaining the stated 10 ns sample period = 100 MHz sample rate. First of all, is it really possible to have a constant 100 MHz “read GPIO, store to memory” loop? Does it need to handle a ring buffer structure (checking limits, incrementing a pointer, etc.)? How much sample memory is available on the Propeller MCU? What is the maximum data transfer rate to the host PC? (It appears to be using a UART so I can’t imagine it is higher than 1 Mbit/s transfer rate, and more likely 100 kbit/s to 200 kbit/s.)
Even with multiple cores, I don’t see how this device could come anywhere close to the advertised performance.
Andy — See page 32 of the data sheet at http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/PropellerDatasheet-v1.2.pdf, higher frequencies don’t work at extremely high temperatures, especially at low voltages. Over a commercial temperature range, 100 MHz still works well.
NsN and ColinB — Each core, or cog has 512 32-bit registers for instructions and data. If you fill most of the core with instructions that overwrite themselves with samples, you can take over 400 32-bit samples per core, and sample with multiple cores for a few thousand samples. With some well written assembly language, you could store over 3,500 samples in the cogs alone. (You wouldn’t have any resources left to trigger, though.) If you take smaller samples, say 8 bits, some specialised assembly coding could fill the 32 Kb x 8 RAM with samples.
— David Carrier
Parallax Inc.
The 10ns sample rate cannot be accurate. The propeller does not get 1 instruction per tick. It gets 1/4. At 80 MHz it performs ~20 MIPs, so at 100 MHz it can only AT MOST perform 25 MIPs.
It should only be able to get 40ns tops.
@David Carrier:
Thanks for the insight. It still sounds incredibly difficult to get everything right and to get 1 sample per machine cycle. I guess if you only need a few hundred to a few thousand samples, it might be usable. However, if you had a bigger sample memory or a fatter pipe to the host PC, or even just compression of samples (e.g., to allow easy capture of a communication consisting of rapid digital pulses, then a long pause of 1 ms, then more digital pulses), then , it seems like it would be much easier to capture the signals in which one might be interested.
What about Mikey’s comment that one instruction takes four clock cycles? How then can a 100 MHz sample rate be achieved?
Mikey and ColinB,
The Propeller uses a Von Nuemann architecture, so the code is executing out of the same memory space as the data. It also caches the code into a cog before it is executed, so it doesn’t matter if you overwrite the code as it is being executed. If you generate several hundred instructions, where each instruction copies the input register over its own location in cog RAM, and follow it with a small loop to copy that data into the shared RAM, i.e. hub RAM, you will have a program that stores several hundred samples then loads them into hub RAM.
As Mikey mentioned, each instruction requires four clock cycles; this doesn’t pose a problem though, because the each cog can be at different stage in its pipeline. There are instructions that allow you to synchronise the cogs in such a way that each one samples the input one clock cycle after the previous cog.
If you have four cogs sampling, each cog will sample one clock cycle later than the previous cog, and they can each gather over 450 samples, for a total of over 1,800 samples. The samples would be interleaved between the cogs, but post processing is cheap, especially when you are sending the data to a PC. If you set the remaining four cogs to start sampling immediately after the first four stopped, you could gather another 1,800+ samples, contiguous with the first, for a total of over 3,600.
There is only exactly enough bandwidth to write 32 bits every clock cycle to the 32k x 8 hub ram, which doesn’t leave enough overhead for the cogs to know when to switch between sampling and writing. At a lower sample width, such as 8 or 16 and possibly 24 bits per sample, you can have the cogs take turns sampling data and copying it hub memory. This way, you could fill the hub RAM with 32,768 8-bit samples, 16,384 16-bit samples, or possibly 10,922 24-bit samples.
For streaming, sending data to the PC over an asynchronous serial connection will be the bottleneck; it is difficult to get over three megabaud. If you lowered the sample rate, you could add run-length encoding to stream data to the computer.
— David Carrier
Parallax Inc.
@Colin & Mikey – The Propeller is multicore, each core is 25MIPS, but total horespower is 200MIPS. The cores work together to sample.
Propalyzer is frame-based, although you can use other firmware (like viewport) for continuous sampling to the PC. Viewport does 2mbits / second.
@Nick & @David — NEAT.
Though, since 8 cogs — why does it need to be overlocked in the first place? — it seems to me that you could just use 5 cogs at 80MHz and achieve the same effect (or 7 of the 8 to achieve 140 MIPs…)
Mikey,
The cogs only sample when a system clock edge occurs. (I do not know off hand if it is a falling or rising edge.) So, at 80 MHz, the system clock period is 12.5ns, which is your limiting factor. If you had five cogs sampling with an 80 MHz clock, you would be sampling 100 Million times per seconds, but two of the cogs would have to sample at the same time.
We do have a work-around for outputting data faster than the system clock; there is a 32-bit shift register in each cog that can buffer four 8-bit or eight 4-bit samples and output them using them using a clock generated by a PLL. It is specified to run at 128 MHz over an extended temperature range, but we have a demo that outputs a 1600×1200 VGA signal, using 2-bits per sub-pixel plus H and V sync, for a total of an 8-bit parallel output, that is clocked at 160 MHz, double the system clock. The Propeller doesn’t have enough memory to store that big of an image, but it can draw fonts or repeating tiles, similar to the NES’s backgrounds. See http://forums.parallax.com/showthread.php?89980 for the demo.
— David Carrier
Parallax Inc.
We have no problems overclocking the prop providing proper decoupling is performed. I have pcbs that run at 104MHz. 108MHz works too, but I do not guarantee it.
5 cogs at 80MHz will not give you any better as the sampling is tied to the basic clock rate. Effectively, to sample at 10nS (100MHz) we interleave 4 cogs, each sampling at a quarter of the time.
I am not familiar with what jazzed has done with his Propalyser code, so here is what I did in my sampler code…
4 cogs can sample up to about 1700 sets. I use 1 cog to trigger. Unfortunately there is a short trigger delay of a few clocks (cannot recall now, too long ago).
However, I am fairly sure that could be overcome and in fact we could be presampling while waiting for a trigger, all by propeller software.
Another nice feature of the prop is that it could output this data to a TV or VGA quite simply (a few resistors). There is an inbuilt font that can generate timing diagrams too.
I’ve been able to pull 114.5Mhz from a 14.318 xtal pulled from an old VGA card. The Propeller will run at this speed, but I’m sure it isn’t recommended. :) 100Mhz speeds are stable and work well.
Thanks to hackaday for posting this wonderful article.
It’s interesting to see so many interesting perceptions about Propeller and the examples of fantastic support that Parallax always gives (thanks David Carrier).
PPLA was designed specifically for Propeller Platform to eliminate the need for a cable harness (a USB capable stand-alone version that allows using the cheap 9-pin grabber cables is ready to go anytime). I also use AVR, other micros and CPUs with many languages; it is wonderful to have so many devices available to fit the needs of a designer – every chip has it’s strengths and weaknesses.
Propalyzer is now 2 years old and can connect to any Propeller running the firmware. The original Propalyzer hardware concept is shown here: http://www.brouhaha.com/~sdenson/Propalyzer
If someone points me to that GUI mentioned, I’ll try to make PPLA inter-operate with it. When I designed Propalyzer I didn’t really care to look at other offerings since I have a vision of what I want and find useful. Enhancements will come for capture to trigger and larger buffer sizes.
I do not ever want Propalyzer to perform the function of an oscilloscope because I want it to do one thing for focus. If you want o-scope software, ViewPort will do that (and other things – too many other things IMHO).
Propeller is so flexible it can do practically anything; if you say it can’t be done, someone may prove you wrong. Of course, it’s just a micro-controller so there are real limits.
Join us to witness the possibilities in the thriving, vibrant, and super supportive Propeller community at http://forums.parallax.com/forum.php
Thanks.
–Steve
Just to add a bit about speed. One of the prop guys has been running for months (now probably more than a year) at 120MHz. I found it seemed to top out at 14.318MHz (~112MHz).