Hi,
I found an Arduino Logic Analyzer at http://letsmakerobots.com/node/31422.
It runs with http://www.lxtreme.nl/ols/ Logic Analyzer application.
Does anyone know of a similar Maple option?
Can (How?) that Arduino be ported to Maple R5 (or other)?
Thanks
gbulmer
Moderator
samtal - "Does anyone know of a similar Maple option?"
No. I haven't searched actively recently, but I have wanted a Maple-based logic analyser for a while.
I did find SUMP:
http://www.sump.org/projects/analyzer/
but it is FPGA based, and skipped it until (if) LeafLabs release Oak.
I'd also looked at GadgetFactory FPGA boards, but I don't think I'd spotted the "Open Bench Logic Sniffer", so thanks for that link.
I assume the goal is to use http://www.lxtreme.nl/ols/
and so implement the SUMP protocol.
I've had a quick skim of the code at https://github.com/gillham/logic_analyzer/blob/master/logic_analyzer.ino
There are lots of in-line asm statements, but AFAICT, they are all 'no ops', to soak-up CPU cycles, and get the timing right. You'd have to futz around with the equivalent for ARM, however I think that is practical to convert the code; the time consuming part will be getting the delays just right (unless you have access to reasonably good frequency measuring test equipment). I might be able to get access to that sort of equipment, so please ask if you'd like some help.
Other ATmega specific parts are direct access to digital I/O pins and timers.
The direct timer stuff doesn't look too difficult. Direct timer access seems to be in their for debugging, so that could be made to work. It seems to generate a 100KHz 'tick' which should be okay for Maple's STM32F103 if its okay for an ATmega.
Using individual digital I/O pins shouldn't be too awful to port, especially if you use the faster_write/faster_read stuff.
However there is (at least) one major area which looks slightly sneaky. The code reads a port-worth of pins (8 pins on the ATmega), with a single direct access. So it looks like it has packed the logic-data samples into one byte. Then the code both uses the 'packed data' (read from the entire 8-bit port) for triggering, and data storage.
If all of the signals being sampled came into one STM32F port, you could use the same technique. You'd likely have to change the size of some variables as int is different for gcc targeted at ATmega vs gcc targeted at ARM.
To make it easier, you'd probably have to use the upper or lower 8bits from one of the STM32F's 16-bit ports.
So if that restriction is okay, then I'd WAG that it is practical to do the translation. Otherwise you are probably going to retain the code which talks to the host PC's logic analyser user interface, and re-engineer the code that does the triggering, sampling and storage.
Edit: I've skimmed over the SUMp protocol at http://www.sump.org/projects/analyzer/protocol/
It looks like the protocol would handle 32 channels, so you could use an entire 16bit port. It would be possible to use two ports-worth of pins, but the trigger function would get a bit more complex, and all the capture code would need a rewrite.
There are a bunch of 'captureXXXX' functions, each engineered to work within different constraints of the ATmega and Arduino software. With a bit of care, you might get enough functionality from translating one of them to make the entire exercise worthwhile. That might not be good enough for general use, as the logic analyser UI might be set to ask for an un-translated function. However as a starting point, one working capture function may be BRILLIANT!-)
If you do decide to try to do the port, please keep us 'in the loop', and I'm sure we'll try to help you; it would be a lovely project.
If you decide not to do it, please tell us too. I am very busy 'till January, but I might be able to make some time then to have a crack at it.
Thanks gbulmer for superb, overwhelming yet prompt reply.
I do agree it could be nice project, and I also believe that if the Arduino got it, the Maple should as well.
It can be the basis for a more advanced tool like a combined scope-Logic-analyzer that is very common nowadays also in FPGA.
Unfortunately, to me this is more of a current need for monitoring another project than a general-purpose project, I can not see myself diving into such uncertain project that may take months to accomplish.
I have an Arduino Mega board on which I will try to run the Arduino supplied program (there is no additional hardware needed).
and yes, I do have the tools and the knowledge to measure and evaluate the outcome of such.
If it will work for me - I'll use it and let you know.
If it does not - I can get a full working solution for less that $100, so why bother?
In any case - Why not encourage one of the Maple lovers to do the work? As you wrote, it is a nice project, suitable for a software student or graduate.
Thanks again
samtal
gbulmer
Moderator
samtal - sorry for being a bit overwhelming - I got enthusiastic :-)
I understand your position.
I am expecting a port to take significantly less than a week, but that is still a lot of effort when you already have the means to use it with an Arduino.
When I looked at the SUMP protocol, it didn't look like it had provision for mixed scope and analyser.
However, anything working is much better than 'perfect' :-)
mlundinse
Member
It 'works' by just making the minimal changes from arduino to Maple:
Change Serial -> SerialUSB
#define CHANPIN GPIOC->regs->IDR
#define CHAN0 10
#define CHAN1 11
#define CHAN2 12
#define CHAN3 13
#define CHAN4 14
#define CHAN5 15
Change cli() -> asm volatile ("cpsid i");
Change sei() -> asm volatile ("cpsie i");
Comment away the 2 and 4 MHz sampling.
Remove most of the Arduina and Atmega board variant stuff for now.
This will capture from the analog pins that are loctated at port C[0:5]
Timing loops will be off, and this can be a bit tricky to get right since the Cortex M3 pipeline and STM32 flash preload will make timing very hard to predict. Still, with some work its possible to get the timing correct to within 2 clock cycles, not great but useful in many situations.
The timing can probably be improved by using a timer to trigger DMA transfers from the port input register to the buffer.
I have only made some preliminary tests, and not at all looked at the triggering code.
gbulmer
Moderator
mlundinse - it depends what 'works' means.
I agree the code translation isn't a lot of work.
I certainly agree, if all the optimisation needed to sample quickly is deleted, then it is much easier to do the translation.
This is the core 'capture' function:
void captureMilli() {
unsigned int i = 0;
/*
* very basic trigger, just like in captureMicros() above.
*/
if (trigger) {
while ((trigger_values ^ CHANPIN) & trigger);
}
for (i = 0 ; i < readCount; i++) {
logicdata[i] = CHANPIN;
delay(delayTime);
}
for (i = 0 ; i < readCount; i++) {
Serial.write(logicdata[i]);
}
}It loops, looking for a condition on some of the pins, samples data at a reasonably consistent rate, then write the data to the host.
Exactly this code could 'work', but it wouldn't have a stable sampling rate unless:
- it were sampling so slowly interrupts don't matter, or
- it is only sampling for a fraction of a millisecond, so interrupts can safely be switched off.
An effort-consuming part of the port is getting the timing correct. That is where I'd expect the time to go in my effort SWAG.
"... this can be a bit tricky to get right since the Cortex M3 pipeline and STM32 flash preload will make timing very hard to predict."
I agree it is tricky.
However, if, instead of trying to predict it, one has access to good test gear, it can be measured.
When we look at disassembled code for a for loop like
for (i = 0 ; i < readCount; i++) { logicdata[i] = CHANPIN; }
the first iteration can be different, but the middle iterations are usually consistent (without interrupts or DMA), and would show that on good test equipment.
Of course, DMA could be better. Replacing:
// ...
for (i = 0 ; i < readCount; i++) {
logicdata[i] = CHANPIN;
delay(delayTime);
}with DMA would reduce the sampling overhead, and offer the potential for a more stable sampling rate. That is certainly the direction I'd want to go.
However, DMA introduces contention for RAM, and potentially the buses, between DMA and the Cortex CPU. That may be an issue at high speed, or with 'bursty' activity from the CPU (for example servicing the USB interrupt). That would cause sampling to have 'jitter'. So even DMA needs some care.
Summary
I agree, getting something to sample is straightforward.
However, I think users would expect a logic analyser, which writes times on the UI, to be reasonably accurate, with low jitter.
mlundinse
Member
The contention for DMA should be minimal since other activities can be silienced, we are thinking of a Maple devted to this task.
I have measured the timing loop delays and I cannot make them more precise than 2 clocks, even when a adding single cycle asm instructions, and I get a single cycle error per sample at best even with code running from SRAM, this corresponds to an error of 1/72 = 1.4% for 1MHz sampling rate, useable for logic analysis, but not for precise timing analysis.
"work" means I can sample a 1 kHz signal from a precise source and get a fairly good representation. The error is always a mixture of quantization errors proportional to the sampling time and accumulated sampling time errors that can be proportional to a multiple of the number of samples taken to measure a signal, thus being proportional to sampling rate and inversely proportional to sampling time.
So what sampling rates, and precision as a function of the sampling rate is needed to make the Maple soft logic analyzer an interesting project as a simple but usable tool ???
gbulmer
Moderator
mlundinse - "The contention for DMA should be minimal since other activities can be silienced, we are thinking of a Maple devted to this task."
Good comment. I agree; it is very reasonable to assume a Maple is devoted to the task.
The goal is to use the already-written "Logic Sniffer" host UI (identified by samtal) 'as is'.
AFAICT "Logic Sniffer" doesn't currently offer any features which would affect that assumption.
(It would be even better to, for example, be able to use the Maple to generate test signals, e.g. SPI, I2C, etc. That might make the Maple software even more interesting and useful than the Arduino starting point. The "Logic Sniffer features" lists the ability to add plugins, but there is no point expanding scope to include additions before the basics work.)
As I wrote, USB will be running on the CPU. That will be 'bursty', which would be worse than random jitter.
(The Arduino software switches off all interrupts for some sampling rates, but does nothing about them at other sample rates, so it's going to suffer non-random jitter too.)
"So what sampling rates, and precision as a function of the sampling rate is needed to make the Maple soft logic analyzer an interesting project as a simple but usable tool ???"
I think that is a different question. Let me try to be clear where I started.
I wrote "I am expecting a port to take significantly less than a week"
I was unclear about what I'd expect as the result.
You wrote "It 'works' by just making the minimal changes from arduino to Maple"
You posted a small set of changes which got the software running in a Maple, and sampling. That is great work, and very helpful.
I wrote "it depends what 'works' means"
My definition for what 'works' means is relatively simple:
"Comparable to the Arduino version, across the range of sampling rates the original software supported."
Better would be excellent, but worse would be disappointing.
I am delighted and impressed with your progress. I have no issues if you're goal is different.
mlundinse
Member
I will clean up my work and post it soon, but I would like to worka bit on the triggering code first. Without a trigger I can reliably, with no noticable jitter when sampling a 1kHz signal, sample from DMA at 6MHz, this is 1/12 of 72MHz, 8MHz sampling at 1/9 of 72MHz cannot quite keep up.
(each DMA request makes one peripherial register access, one memory access, decrements the DMA counter and increments the memory access pointer and AFAIK the processor is guaranteed 50% of bus bandwith leaving less than 50% to DMA)
I am not shure it is meaningful to try and push this much further, but it is an interesting programming task and a way to learn the precice performance of the 103 chip.
For a quick and cheap logic analyzer its not bad, also a starting point for more developed solution.
/Magnus
gbulmer
Moderator
Magnus - Great work!
"I can reliably, with no noticable jitter when sampling a 1kHz signal, sample from DMA at 6MHz, this is 1/12 of 72MHz, 8MHz sampling at 1/9 of 72MHz cannot quite keep up."
That is a very interesting result. The STM32F103 documentation is vague about throughput, so I'd assumed there'd be a way to get DMA to do about 1/8th of clock (as you say, about 4 (visible) operations, and a 50:50 share of the buses and memory with the CPU), but never measured. So thanks for the work, and thanks for sharing results.
You must log in to post.