One pin, one component oscillator with GA144

Yes, the controversy is because this has limited utility. He states, "A resonator has a lower Q than a crystal and is much easier to start oscillating." which says to me that using a crystal doesn't work. He also gives no performance specs on the resulting circuit or even info on how this was tested. So even with a resonator I can't verify that this is a "working" circuit in a practical sense. Does it drift with temperature, does it start at temperature extremes? Does it work reliably when you build 100's or even 1000's of them? Another quote from the page, "The number of unexts in a us may need to be adjusted for different chips or temperatures." I think that says it all!

For now I am still planning to use an oscillator.

Rick

Why so negative? Why not admit that this chip is an interesting and curious experiment?

This is plain dishonest. Let me site another line: " Neither us or ms is used here. I leave the code in clock as a reference copy that I may be able to find. " So he jotted down a delay routine, so what?

Of course! It will take forever before we see application notes from GreenArrays. Maybe you'll see those from us (Dutch Forth users) first.

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

Saying the comment is dishonest is way too strong. Had I read the website before I saw your comment, I would paired "oscillator" with "way huge variance in constants for timing" and come up with "crappy" myself.

And, if the oscillator isn't crappy for needing such adjustments, the code sure is for being misleading.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

m/e=3D

I am expressing a negative opinion of the "one pin oscillator" because I find it has little or no use in most designs. Yes, I agree that it is an interesting experiment, but this feature has no value in a commercial product, which is how GA is currently promoting the GA144.

The resonator has to be started with timed kicks. He backed off from using a crystal because he couldn't get that to work over Process, Voltage and Temperature (PVT, but not the Boyle's Law PVT). There isn't enough timing resolution using a 1.5 ns instruction cycle to reliably and consistently start a crystal. I don't know that even a resonator will start reliably. Currently Chuck is "experimenting", not designing or writing app notes for a commercial product.

Actually, I'm glad you posted your comment here. It gave me a chance to take a fresh look at what Chuck is doing. I have been looking for a product to sell and have been short on ideas for some time now. A couple of weeks ago it occurred to me that the GA144 might be the basis of a low end, very low cost oscilloscope. I'm having a little trouble figuring out how to design around the memory size and speed limitations of the device as well as the clocking problems. At some point I started to think about adding a dedicated display possibly through a VGA port and realized that might be pretty easy for moderate resolutions. I did some timing analysis and found it should work at up to 1024x768 resolution with the overall pixel, line and frame clocks being easy to generate. But then it started to fall apart. For a full graphic application, the memory access rate was higher than what the memory used on eval board is capable of much less the 5x slower implementation the GA design uses. I quickly realized that I would only be able to support a text display which has a much lower memory access speed.

Your post lead me back to Chuck's pages which I think I read some months ago and mostly forgot. I found the part where he discusses his video design and realized that he is truly experimenting to see what he can do with "real time" video processing. He is not trying to design a practical video display. He has generated the timing strobes and put up a blue background and has yet to begin confronting the real limitations of this device in producing a video display.

I haven't given up on using the device as the core of a very low cost oscilloscope, but it will clearly need supporting devices. Most notably a high speed USB interface which may be hard to interface to the GA144 chip since it has no high speed interfaces for non-GA144 devices. That was part of the motivation for using the GA144 for a video display, give up on a high speed USB. Even using two GA144s may not do the job (one of oscope front end and one for video display) since the video is not suited for graphics that I can tell. I'm going to look at the now obsolete video DRAMs. They could stream an entire page of memory with one setup delay. Or maybe DDR. This thing has to have faster memory.

Rick

USB... I was distressed at seeing dedicated USB chips on the development board. The GA144 should be able to do its own USB, or all the hype is, well, just hype. If I where at Green Arrays the GA144 would already have been registered as a USB device, awaiting the software. (the slowest should be doable, heck the Arduino is doing bit banged USB of sorts.)

Lately I was thinking of a typically Dutch application: a fiets (bike) computer on solar. There is a market for a bike computer without batteries, because it could be hermetically sealed and very sturdy and sport a deft prevention device. Once you're established in the high end of this market, you may become even profitable! People are sinking money into their hobby and the properties of the device may be hard to replicate. (Most competition would face memory loss.)

I have looked into vintage DDR ram for laptops. I got those for cents/Mbyte. This is available in plenty and the CAS/RAS interfacing could be left to the chip doubling the address lines as it where. Experimenting costs time, not money.

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

to

There are two reasons why USB will not be native in the GA144 any time soon. One is that to be really useful it needs to be High Speed at

480 Mbps and that ain't happenin' in software. I thought they might find a way to use the SERDES, but I think that is a VERY remote chance since it seems to be timed by the chip and not a clock. The other and truly limiting feature is the software. I can't imagine partitioning a USB stack into the tiny pieces that can be implemented on the GA144.

Am I wrong about either of these?

They may someday implement a very limited Full Speed USB slave, but I doubt you will ever see a master implementation without support chips.

Yes, that could be a useful product, but why would it need a GA144 at $12 each? There are lots of good MCU devices with very low power features that should be able to easily implement such a device. Energy Micro has a very low power ARM and I often hear about how low power an MSP430 can be. They are currently much lower power than the one GA used in their energy comparison that is now two years old.

BTW, check out the thread here on "Open source writswatch ?". That device with very few mods (like a lower power focus) could be device you are describing.

Time IS money!!!

I don't know if DDR is needed, I did a survey and tossed the DDR chips I found, possibly because of the dual phase clock required. But SDRAM should be easy to interface to the GA144, but to what end? It is still slow for single accesses (~70 ns with 100 MHz clock which may not be realistic).

I was just researching using SDRAM and I found references in the documents saying the ROM for nodes 007, 008 and 009 supports SDRAM! So why do they use async ram on the eval board? WTF?

I'm actually very frustrated trying to learn the tools and device. A lot of the documentation includes features that aren't implemented or don't work and much of it assumes you have mastered other stuff first. The order of precedence is not at all clear to me and I am having a hard time getting to the point where I know enough to determine if the SDRAM interface is practical at 100 MHz. If you have to slow down the interface much the cycle time gets too slow to be worth doing.

If I can rant a little more, reading Chuck's pages doesn't help much. His approach is so far from mainstream that I don't get much "education" from it. For example he is trying to implement a video interface that doesn't use a pixel clock and has no video memory! So far he has generated the sync pulses and put up a solid blue screen. Yep, that's the sum total of some six months or more of work. At least that is all he has documented.

The GA page is not much better. I looked at the arrayForth Institute page and signed up for PROG100. It has two parts, one is available and the other will not be ready until later in March 2012. I think that says it all. Also, I can't seem to get the first lesson to work. Oh well...

Rick