So sometimes, while coding you have these ideas, I was thinking how about downloading all that data from PIC scope to the PC. Then it occurred to me, 'screendump'.
The little 4 pixel horizontal on the left is the trigger level indicator, The 3 pixels more to the right is the cursor, the top left display is the time from trigger the cursor is at, the top right is the value of the signal at the cursor position, the bottom display is the full screen time (timebase setting) in us.
Hope your newsreader has a fixed font and can do > 128 characters horizontally :-) ************* ***
It looks like most of the USB oscilloscopes depend heavily on software running on the PC.
If you make it fast, have it output to standard JPEG files and use the older USB 1.0 to the PC then ANY old junk PC can be used to display the results.
The PC would need no software, and any old windows or Linux OS can display JPEG.
If the PIC could write the JPEG to the FLASH memory in a cheap digital camera through it's tiny USB connector even that could be used as a portable display.
Add the much better A/D and an LCD screen and pretty soon you've got the Rigol $550 scope.
On a sunny day (Fri, 2 Apr 2010 09:34:55 -0700 (PDT)) it happened Greegor wrote in :
Yes, sure. But this is a 3 $ single chip scope, not counting the more expensive 64 x 128 graphics LCD. It is neat that it can be controlled by, and output RS232. Also it can do games ;-) To make it stand alone all that is needed is a second PIC as keyboard controller, some push buttons, the second PIC can send RS232 commands to replace the PC as terminal. Altogether less then 30 $, with a FET input stage on top. I just added X, Y mode.
This is not for high speed, I have spartan2 and a fast flash ADC for that. No longing to buy Rigol, much more fun to write your own. You can buy anything, but try coding this, it has FFT too, single and auto trigger, 10 calibrated time base ranges, easy to add more towards the low speed. Just over half the code space used :-) PIC 18F14K22, programmed with my own programming software, copyright 99% mine. It is a fun project.
It is easy to make a jpg on the PC in Linux from the ASCII output: import scope_picture.jpg ftp://panteltje.com/pub/pic_scope.jpg And it shows the waveform much better then a jpg screenshot of the actual LCD. With this feature you need only RS232, not even an LCD :-) Ah, maybe I should add a mode where it outputs the screen continuously with a form feed in between... LOL
A 3 $ scope!!!!!!!
What do you guys think, release as open source? or what is it worth?
And learning the assembler language is easy, summary of the RISC instruction set fits on one screen. Lots of example code from Microchip, great resource for seeing an outline of what's needed for some tasks. In my case, reminders of algorithms help, as I last wrote code for uC chips in '93.
PICkit2 for ~USD50, I'm using it with the 28-pin demo board (~USD25) which has a PIC chip with built in debugger support (PIC16F886), 20MHz osc option,
32k second xtal for RTC. Lots of fun. But I'm only using a 16 char x 2 line LCD module for output. Didn't think one could run a graphics display off a PIC until Jan showed his project.
On a sunny day (Sun, 4 Apr 2010 19:53:46 -0700 (PDT)) it happened Greegor wrote in :
There are 2 issues here in my view.
1) to learn programming.
2) to use the program for something.
This requires *at least* knowledge of 2 things, so with 'at least' I mean at a minimum.
In this case about scopes and about programming. A 'beginner' will not have both.
Maybe for a 'beginner', who knows how to connect a LED and resistor, writing a program that flashes a LED is a good start,
It is extremely difficult to make a statement that is valid for all cases about this.
In my personal view, not everybody can be a programmer. Some people have the attention span of a news broadcast, and by line 5 of the program they will have forgotten what they were doing, why they were doing it, what the thing was about, where they put the tools, how to invoke the tools, ... etc etc... Some people simply do not think logically, Not that they are bad people, maybe be great people, but not good programmers.
The other thing is that you have to read dataheets, in Linux it is RTFM (Read The F*cking Manual), and for hardware it is very much the same.
The assembler *I* use is free, open source, gpasm is part of gputils. I must say that I am extremely impressed by gpasm, not only is it fast as light, I also only found the minimal amount of bugs, only line number reporting have I seen to fail, and it puts DB statements always on an even address, so if you use tables you have to write DB x, y DB a, b to make full use of the memory. If you mean 'is writing in asm economical' (relative to C), then in my view, if the intention is to stay on the PIC18 platform, yes, as it is closer to the hardware, avoids idiotic C constructs that you need to use for micros, takes less space, takes *often* less time, as in C you constantly have to check the generated asm anyways, have no decent bit flags, have to look up all the special function registers anyway, so why use C. Maybe because of printf() formatting or floating point, but I only used integer here, and I have a floating point asm lib too. C is nice for on platforms that can run a real gcc, do a lot of math, have a lot of RAM, good stack support, like x86 and maybe ARM but I am not an ARM programmer. I use C on x86, MIPS, and have even used it on Z80, with inline asm too.
What is a trainer? Microchip (the PIC makers) have MP lab, seems to be some simulator, so you can simulate the PIC code you write on the PC. Why simulate when the real thing is there? I dunno. I have not used a simulator for a micro ever, except to try one, and have not used a debugger since the 1980ties. First thing I do is reserve an I/O pin for test, and write some routines to print 8 and 16 bits numbers to the serial port, so I can put debug print statements in my code. that is all. #define DEBUG and when finished undefine it. Programing the PIC 18 F on *my* Linux PC with *my* programmer takes only a few seconds:-) You can do that thousands of times with the same PIC for less then 3 dollars (a new PIC), I never made thousands of times, and I never killed a PIC programming. Why does *ANYONE* use a simulator like MPLAB? I do not know. Maybe the same people have sex in a simulator too, over the real thing? Simulator is the sickness of this age, NASA has great simulations how stars form, galaxies collide, I have one word for it: Hollywood.
I do believe the moon landing were real, but maybe all that came after Von Braun died is simulation? LOL My programming software I used to program PIC scope:
formatting link
The assembler I used:
formatting link
Sure, there is no limit. I will add a J-FET input. There are some tricks I want to try.
Tt is a 10 bit ADC, you want faster then 100 kHz probably, use a FPGA! not a PIC for that :-) All things have their own applications. For me it is just a programming exercise for PIC18, have not used many of the instructions yet, have not use the hardware multiplier, the indexed + offset thing (if I got that right), several of the interfaces (SPI, i2c on this one), what not. It is all only limited by the imagination.
Programming is like any language, you can write a novel, a bestseller, what language is not important, I speak Dutch, English, French, German, PIC asm, C, BASIC, Pascal, Z80 ASM,
805x.asm, x86.asm, some more, it is the content not the language!
formatting link
I even wrote this newsreader... hehe fun fun fun ***** ** ****** ********** ****** ** ** ** ** *
'Second PIC' should trigger: use a real uC that can do all tasks by itself. Adding multiple PICs together always results in a kludge. I've seen it happen too many times.
Actually some controllers allow to start an ADC conversion on a timer match. You could rip de guts of an old 20MHz oscilloscope and create a digitizing oscilloscope by using the timer to delay the sampling (the sampling is started using the trigger logic).
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
I make a lot of money redesigning non-working designs based on multiple PIC controllers. Most problems are in the obfustigation due to distribution of functionality.
Like you said before: there are not many people that really know how to program. They know how to make a LED blink using a PIC so they think they are ready for the real deal. Since they only know how to use a PIC and are reluctant to widen their horizon they keep adding PICs (*) until the design appears to be ready. Unknowingly they created a device that is a hell to produce (I've seen products with
problems (see below).
(*) Like the only tool they have is a hammer to put an IKEA closet together.
The problem is that anything connecting to something else has some sort of protocol in between. Handling protocols is prone to errors, timing issues, incompatibilities, needs error handling (what if the link breaks or a message is missed?) and it takes extra time to process. Putting everything in one controller solves a lot of potential problems.
Your keyboard example is excellent regarding compatibility issues. Ever tried to make an AT keyboard simulator that is guaranteed to work on any PC?
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
On a sunny day (Mon, 05 Apr 2010 19:15:08 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :
I dunno, never came across that problem.
Possible, but this is s.e.d., and I sort of think most people here know what they are doing. Like I did say, there are 2 things needed for programming
1) know hoe to write the code
2) know about the subject that you write code for. For example if I write for financial markets, I need to know about that subject too. Things like that may put some burden on programmers, but is also a lot of fun. Implementing protocols, and making your own protocols, is a part of programming that also needs learning. Note the graphics protocol in scope_pic, it only uses 2 bytes per pixel by design, is pretty much fool proof, and is very very fast, see the youtube demo:
formatting link
I have an Ikea bench, it only took some imbus screwdriver, no hammers :-) I also have an Ikea table (2 actually) and some other of their stuff. Pretty good stuff.
Not if used in the right way, you are now connected via internet right? If you have problems with protocols, then yes, then you will need to avoid those.
I wrote a driver for my z80 system for the IBM PC keyboard. very familiar with it, in z80 asm, never a problem.
On Apr 5, 2:02 pm, Vladimir Vassilevsky wrote: VV > Does your scope have hidden 100 MHz VV > option or some other secret bonus? VV > By industry standard, it should.
THAT was funny!
On Apr 5, 2:15 pm, snipped-for-privacy@puntnl.niks (Nico Coesel) wrote: NC > Your keyboard example is excellent regarding NC > compatibility issues. Ever tried to make an NC > AT keyboard simulator that is guaranteed to NC > work on any PC?
Is there actually a problem with doing that? Is there a lack of standards for those? What ARE the variations that cause problems?
If you want it to work on any PC there is a problem.
Yes. Same like the ISA bus.
Different people having different ideas.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.