Logic Analyzer advice
TC
Posts: 1,019
Hello all,
I have put my oven on hold for a little bit (getting overwhelmed). So for now I am going to see if can get my Data I/O 60 working.
All I have done with it so far, is fixed the fuse I blew, and tested the keypad matrix with a meter. All the buttons act like they should work. But the unit still does not notice the buttons being pressed. So now I am going to see if there is a chip (EPROM, logic gate, etc..) that is not working the way it should. I found code, and a program that turns a prop into a Logic Analyzer. I was thinking of using it to see if things are working the way they should.
My question is..... Does anyone have any advice that could make this process quick and easy? Anything I should do to protect both the prop and the Data I/O? And, What should I look (or look out) for?
Thank you for any advice you give.
Thanks
TC
PS. I wrote this just before I have to leave to visit family, and I did not want to forget. I will try to respond when I can through out the day.
I have put my oven on hold for a little bit (getting overwhelmed). So for now I am going to see if can get my Data I/O 60 working.
All I have done with it so far, is fixed the fuse I blew, and tested the keypad matrix with a meter. All the buttons act like they should work. But the unit still does not notice the buttons being pressed. So now I am going to see if there is a chip (EPROM, logic gate, etc..) that is not working the way it should. I found code, and a program that turns a prop into a Logic Analyzer. I was thinking of using it to see if things are working the way they should.
My question is..... Does anyone have any advice that could make this process quick and easy? Anything I should do to protect both the prop and the Data I/O? And, What should I look (or look out) for?
Thank you for any advice you give.
Thanks
TC
PS. I wrote this just before I have to leave to visit family, and I did not want to forget. I will try to respond when I can through out the day.
Comments
There is another prop logic analyzer you might consider. WARNING: May contain FORTH!!! It is in the propforth download archive. You don't have to program in forth, just load it and use it. One three cogs are used depending on sample rate and sample size. The state of all the prop I/O pins is stored as a snapshot in memory. It is then dispalyed on the PC via the terminal program (tera term, etc). I usually use the standard sampling, this stores to unused hub memory.
The module is in the extensions subdirectory of the archive. I think it "la.f". Load any of the included kernels (usually try the dev kernel first) and load "la.f" and you are good to go. Instructions are in the propforth.htm manual, included in the download.
If you use the logic analyzer on a separate prop chip, the other chip can run spin etc. Just trigger off whatever pin. If you run the logic analyze on the same prop chip as the program being monitored (in another cog), its easiest if the other cog are running forth programs and not spin. Propforth is not designed to run in the same prop alongside spin code.
As I said, you don't have to leaarn or use forth to use the logic analyzer. You just download, unzip, load the devkernel.spin like any other spin program, and load the la.f throught the terminal. Ok, you do have to learn how to click n the terminal program icon. The actual paste is the same old copy - paste you are familliar with.
You should really give it a try, its too easy.
I think I will. Thank you.
http://onerobot.org/products/viewport/
Anyone can try.
It is up to each individual to decide whether or not it is a waste of one's time.
Most certainly it is easier for forthers, cults, and criminals to take advantage of beginners.
Jazzed,
Shame on you. Don't you know Forth is the solution to all problems? It slices, it dices, it shakes, it vacs, it takes you out for a good time on a Friday night, cures your hangover the next morning, it does all your worrying for the future and feeling guilty for your past, and makes every known problem in computer science and electronics trivially easy to solve.
Sadly it is not for us mere mortals.
Ah well. We just have to do stuff the hard way.
My suggestion is a very specific solution that exactly meets a specific request. While implemented in forth, it does not require the user to learn or program in forth. What the hell else do you want?
I mean this in the best possible way, but sometimes you guys are just @$$4013$.
"It is better to remain silent and be thought a fool, than to open your mouth and remove all doubt"
Your petty tirades against forth are getting very tiresome.Put a cork in it.
These days, so often we no longer care what is under the hood. If it works the way we want, and the price is right, then its a good choice.
How many really know how a PC works these days? We just use it as a black box.
Until a couple of weeks ago, none of us really knew the P1 guts. It didn't stop us using it, did it? ANd now we can appreciate how it works, and we can even mod it.
Same goes for profs solution. Use it as a black box. Later, if one wants to, you can delve into forth and modify it - but only if you want to.
I LOL-ed over this one.
If you can get the results you need from a prop, more power to you. At some point, you may find yourself wishing for a real logic analyzer though. I can't give enough praise to Saleae. I have a Logic 8 and it's already saved me countless weeks of debugging. It's infinitely more expensive than free... but if you've found yourself often wishing for a logic analyzer, go for it.
https://www.saleae.com/
Or buy it direct from Parallax:
http://www.parallax.com/product/32314
I've said it before.... I can remember when a logic analyzer with the capability of a Saleae would have cost a year's wages. Mine has made the difference between a successful project and abject failure.
Indeed.
While it won't capture 32 channels of 100MHz samples like the software linked in the original post, it does have device protocol templates for I2C, SPI, UART, etc... that are very useful. It's also a neatly enclosed package that you can stuff in your pocket.
It is very easy to use. Extra loading not required.
This doesn't sound plausible. I could see how up to 32 channels can be detected with 100 MHz precision for a single edge - but after each edge there would be a large delay before the next edge can be detected. Utilizing all 8 cogs, we can do a bit better but still not 32 channels @ 100 MHz. Am I missing something or are the specs a bit misleading?
Many impossible or implausible things have been done with propeller ;-)
With a 6.25MHz crystal 5 cogs working together (1 to manage 4 others running PASM) can capture about 450 samples at 100MHz into HUB RAM, then transmit back to the user's application. It is not plausible without PASM.
You seen to be leaning towards the dedicated hardware options, but for those following along:
With software only, on a stock (5Mhz crystal) pop board 4 cogs can capture every transition on every clock, and can run until cog memory is filled. A fifth cog is consumed for the user interface. This method only captures events for a brief period until the meory is filled. But it you know when to trigger, it can usually get the job done. It can be handy (for those of us that can't justify a logic analyzer purchase) to turn any quickstart in to a logic analyzer with no additional wires (if on the same chip) or just a few wires (if on a separate chip).
Right. I never said anything about approximating an Oscope ;-)
The delay could be minimized however by using another cog. That is, change the role of the current main program from serial IO + capture management. A new cog would simply interact with the PC program which would be responsible for accepting commands, controlling the capture manager, and sending back data. The capture manager cog could then be free to point to a queue of capture buffers and do capture as required when the buffer queues are available. With more cogs, the whole system could be duplicated for better capture with smaller gap ping-ponging the cog set being used. A fully continuous stream would be much harder of course if not impossible since the capture instructions have to be rewritten every time for each capture.
The new scheme would require recoding some things, but the basic PASM would be the same and looks like this.
{{ DataLoggerX4_050_jsd2.spin Copyright (c) 2009 Steve Denson See end of file for terms of use. This program builds on work done in or by the following: Data Logger Demo v0.050 Author: Ray Rodrick Copyright (c) 2008 Ray Rodrick See end of file for terms of use. Ray's Acknowledgement: to Paul Baker's Logic Analyzer (dscope.spin) for the inspiration and naming conventions. }} { CON _CLKMODE = XTAL1 + PLL16X 'Set to ext low-speed xtal, 16x PLL _XINFREQ = 5_000_000 'Xtal 5MHz BUFSZ = 512*4 VAR ' '\\ THE FOLLOWING MUST BE KEPT TOGETHER & IN THIS ORDER long trigmask '|| trigger pin mask (trigger immediately if =0) long trigarm '|| trigger pin arm state long trigstate '|| trigger pin capture state long speriod '|| sample period long delay '|| delay from trigger event to snap long slot '|| number of cpu slots long syn '|| startup sync cogs word long bufsize[BUFNO]'|| dataset buffer size (set by cog when done) long buffer[BUFSZ] '|| dataset buffer (max 512*slot, but not all used) ' '// Note: This is not the same as dscope.spin !!! pub main repeat trigmask~ ' test only trigstate := trigstate & trigmask 'enforce we don't look for masked pins (if error above 2 lines!) speriod := 1 slot := 1 longfill(@buffer, 0, BUFSZ) 'clear the buffer syn~~ 'sync wait command start(@trigmask,0) syn~ 'sync go ... get started repeat until bufsize repeat '} CON BUFNO = 4 VAR long cog[BUFNO] PUB Start(bufptr,num) '' Start DataLogger - starts a cog '' returns 0 if no Cog available or cog "id" '' bufptr = pointer to DL parameters '' num is cog number result := cog[num] := cognew(@entry, bufptr) + 1 PUB stop(num) '' Stop DataLogger - frees a cog '' normally stops after sample completed and copied to buffer '' num is cog number if cog[num] cogstop(cog[num]~ - 1) DAT '_______________________________________________________________________________ ' entry org 0 '_______________________________________________________________________________ ' jmp #init 'go and setup the variables '_______________________________________________________________________________ ' bufferfull { buffer slots 0, 0, 0, 0 1 cog add hptr, #4 0, 0, 0, 0 2 cogs add hptr, #8 0, 0, 0, 0 3 cogs add hptr, #12 0, 0, 0, 0 4 cogs add hptr, #16 } mov i,CogBufSz 'get actual buffer size writeloop wrlong bufstart,hptr 'write long to main memory (buffer) add writeloop,d_inc 'increment buffer pointer add hptr,#16 'increment hub pointer by 4 long ... always use 4 cogs djnz i,#writeloop 'repeat for entire buffer wrlong CogBufSz,bsize 'store size of dataset in bufsize (signals buffer written) cogid i 'get this Cog ID cogstop i 'stop this Cog '_______________________________________________________________________________ ' prototype1 mov bufstart-0,ina 'prototype "read all 32 pins" ... change to cnt for clkfreq sample proof mov i,CogBufSz 'get actual buffer size setuploop mov bufstart-0,prototype1 'save the modified prototype instr add setuploop,d_inc 'increment destination in instruction above add prototype1,d_inc 'increment destination in prototype instruction djnz i,#setuploop '_______________________________________________________________________________ ' cmp del, #0 wz if_nz mov jmpNoDelay, #0 'set nop ... no jump if delay if_nz mov trig, #0 'set nop ... no 2nd wait trigger if no delay tjz tmask,#nowait 'don't wait if =0 cmp tarm, tmask wz if_nz waitpeq tarm,tmask 'wait for arm if arm != mask jmpNoDelay jmp #noDelay 'will be nop if delay is used waitpeq tstate,tmask 'wait for start condition add del, #$4 add del, cnt waitcnt del, del 'wait for delay*12.5ns to pass noDelay trig waitpeq tstate,tmask 'wait for start condition nowait '_______________________________________________________________________________ ' bufstart 'long 0 '\\ instr overwritten by the data '_______________________________________________________________________________ ' init mov hptr,par 'save hub memory pointer (initially set to trigmask) rdlong tmask,hptr 'get triggermask parameter add hptr,#4 'increment hub memory pointer to trigarm rdlong tarm,hptr 'get triggerarm parameter add hptr,#4 'increment hub memory pointer to trigstate rdlong tstate,hptr 'get triggerstate parameter add hptr,#4 'increment hub memory pointer to period rdlong sper,hptr 'get period parameter add hptr,#4 'increment hub memory pointer to delay rdlong del,hptr 'get delay parameter add hptr,#4 'increment hub memory pointer to slt rdlong slt,hptr 'get slt parameter add hptr,#4 'increment hub memory pointer to sync mov sync,hptr 'save pointer to bufsize add hptr,#4 'increment hub memory pointer to buffer size mov bsize,hptr 'save pointer to bufsize mov i,#BUFNO incbsz add hptr,#4 'increment hub memory pointer to buffer and stay until hub update djnz i, #incbsz cogid i sub i, slt mov slt, i 'get our slot number shl i, #2 add hptr,i 'get my hub write slot add bsize,i 'assign update slots add bsize,slt syncup ' wait for user to say go rdlong i,sync wz if_nz jmp #syncup mov i, cnt 'assign sample position add i, #$1ff 'add waitcnt margin andn i, #$7f 'start with 0 every time add i, slt 'add our sample position slot number waitcnt i, #0 nr 'wait for our count for sample movd d_inc,#1 'set d_inc to $0000_0200 (nop = $0) mov i,CogBufSz 'get actual buffer size jmp #setuploop 'do setup '_______________________________________________________________________________ ' bufpad long 0 [418] bufend jmp #bufferfull 'prototype "jump to bufferfull" hptr nop 'save hub memory pointer (initially set to trigmask) tmask nop 'get triggermask parameter tarm nop 'get triggerarm parameter tstate nop 'get triggerstate parameter sper nop 'get period parameter del nop 'get delay parameter slt nop 'get slot parameter sync nop 'startup sync word bsize nop 'save pointer to bufsize d_inc nop 'must be nop 'value to increment destination reg by 1 (will be $0000_0200) i nop CogBufSz long (@bufend-@bufstart)>>2 fit $1f0 {{ TERMS OF USE MIT License _______________________________________________________________________________ Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. _______________________________________________________________________________ }}This is just one of several Spin files in the Propalyzer package.
I'll add my second. It's one of the more indispensable devices on my bench. My scope can do 2ch decodes too but is far more cumbersome to setup. Saleae has made a great product at a very affordable price. Bonus for me is that it works on Mac natively.
I knew there was something out there for the prop. But I could not remember what it was. I did a google search on "Propeller Logic Analyzer" and I could not find ViewPort.
I agree Cluso, Thank you for your input braino. I have been intrigued about forth, but could not spent the time to understand it.
I want to know what is going on under the hood of a lot of things. That is why I like the prop as a Logic Analyzer. With having up to 32 channels (28 usable), I can hook up all the address, control, and data pins to see what is going on.
At this point, this is the first time I have needed a logic analyzer. If I need better options, stability, etc.. then I will get a mass produced device like the Saleae. But for know, I don't think I need something that powerful.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Everyone has been giving great advice on what I could use to monitor the prop. But no one has provided any hardware advice. I know the prop can tolerate 5V inputs. But should I add a resistor to each pin? Maybe a 150 ohm resistor? I do not want to take the chance of frying my QuickStart board, or my rare Data I/O 60.
Thank you
TC
I apologize, it was early and my coffee did not kick in. I was thinking the prop was outputting, not inputting when I wrote that.
Thank you for setting me straight.
Ahh, I see. Yeah, I like to add maybe 160 ohms or so between GPIO connections on differing controllers connected together. Cheap protection from a programming boo-boo and a dead short when two outputs meet and disagree.