Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Killer App for the GA144
205 views
Skip to first unread message
rickman
May 24, 2012, 6:39:44 PM5/24/12
to
Well, maybe this is not really a "killer" app, but it is good enough
to get me to build something for this chip. I was looking at a site
about o'scopes and I realized that the GA144 would make a decent low
end o'scope with very little additional hardware.
With five analog inputs, one can be used as the trigger and the other
four can provide separate input channels. Heck, it can be a five
input scope if that is useful. The input may or may not need an
amplifier depending on your needs. The useful range of the ADC inputs
are only around a half volt centered at about 1 volt. As long as the
input can be AC coupled, this can be done with a passive circuit given
that the impedance of the ADC inputs are so high.
The ADC can provide more than 8 bit resolution at a sample rate of 5
MSPS which is enough for a number of applications. The resolution
increases with lower sample rates giving greater than 15 bits at 48
kSPS.
There are a number of small displays available that can be interfaced
to provide a self contained display or it can be connected to a PC
through a USB cable for control and display.
With 144 nodes there is a lot of opportunity to add real time signal
processing features.
Rick
to get me to build something for this chip. I was looking at a site
about o'scopes and I realized that the GA144 would make a decent low
end o'scope with very little additional hardware.
With five analog inputs, one can be used as the trigger and the other
four can provide separate input channels. Heck, it can be a five
input scope if that is useful. The input may or may not need an
amplifier depending on your needs. The useful range of the ADC inputs
are only around a half volt centered at about 1 volt. As long as the
input can be AC coupled, this can be done with a passive circuit given
that the impedance of the ADC inputs are so high.
The ADC can provide more than 8 bit resolution at a sample rate of 5
MSPS which is enough for a number of applications. The resolution
increases with lower sample rates giving greater than 15 bits at 48
kSPS.
There are a number of small displays available that can be interfaced
to provide a self contained display or it can be connected to a PC
through a USB cable for control and display.
With 144 nodes there is a lot of opportunity to add real time signal
processing features.
Rick
Paul Rubin
May 24, 2012, 6:59:57 PM5/24/12
to
> ... and I realized that the GA144 would make a decent low
compares to a dedicated A/D converter and a USB chip, plus some PC
software.
> The ADC can provide more than 8 bit resolution at a sample rate of 5
> MSPS which is enough for a number of applications.
That's 40 megabits/sec per channel -- how do you plan to get that off
the chip into a PC?
> The resolution increases with lower sample rates giving greater than
> 15 bits at 48 kSPS.
I thought per earlier discussion, it's not realistic to expect 15 bit
precision from those a/d's at any reasonable speed. In particular I
thought one really couldn't do CD-quality audio this way.
> There are a number of small displays available that can be interfaced
> to provide a self contained display or it can be connected to a PC
> through a USB cable for control and display.
Dedicated display => higher cost gadget => might as well use a real
scope. Using a PC or tablet interface makes much more sense.
Hmm. How will you keep the clock rate accurate, and the channels
synchronized? I guess these are doable, but I remember earlier threads
about crystal oscillators, and propagating signals between nodes is a
bit painful if the nodes are concurrently doing other things.
> With 144 nodes there is a lot of opportunity to add real time signal
> processing features.
I keep having a hard time thinking of uses for 144 nodes. The 32 node
version (if smaller and less expensive) might have been more attractive.
> end o'scope with very little additional hardware.
That does sound like a plausible GA application. I wonder how it
compares to a dedicated A/D converter and a USB chip, plus some PC
software.
> The ADC can provide more than 8 bit resolution at a sample rate of 5
> MSPS which is enough for a number of applications.
the chip into a PC?
> The resolution increases with lower sample rates giving greater than
> 15 bits at 48 kSPS.
precision from those a/d's at any reasonable speed. In particular I
thought one really couldn't do CD-quality audio this way.
> There are a number of small displays available that can be interfaced
> to provide a self contained display or it can be connected to a PC
> through a USB cable for control and display.
scope. Using a PC or tablet interface makes much more sense.
Hmm. How will you keep the clock rate accurate, and the channels
synchronized? I guess these are doable, but I remember earlier threads
about crystal oscillators, and propagating signals between nodes is a
bit painful if the nodes are concurrently doing other things.
> With 144 nodes there is a lot of opportunity to add real time signal
> processing features.
version (if smaller and less expensive) might have been more attractive.
lynx
May 24, 2012, 10:46:29 PM5/24/12
to
With no offense intended to many people who have thoughtfully considered
the many applications of the Green Arrays microprocessor, is it too much
for me to ask that people stop publicly dreaming about writing code and
simply get down to actually writing it? As far as I know, GA is
basically running on fumes, and is still a ways away from turning a
profit. Your support, even if it's only just publishing your simple
experiments for others to read, laugh at, or play with, would go a long
way towards supporting this platform.
If you really have an interesting idea (e.g., a simple oscilloscope) but
are seriously short on cash, you might want to contact Green Arrays to
see if you they'd supply you an Evaluation Board so you could contribute
an App Note. (See their website for some examples.) I recall that
Chuck Bailey made a standing offer to those serious about this prospect
at the last Forth Day.
the many applications of the Green Arrays microprocessor, is it too much
for me to ask that people stop publicly dreaming about writing code and
simply get down to actually writing it? As far as I know, GA is
basically running on fumes, and is still a ways away from turning a
profit. Your support, even if it's only just publishing your simple
experiments for others to read, laugh at, or play with, would go a long
way towards supporting this platform.
If you really have an interesting idea (e.g., a simple oscilloscope) but
are seriously short on cash, you might want to contact Green Arrays to
see if you they'd supply you an Evaluation Board so you could contribute
an App Note. (See their website for some examples.) I recall that
Chuck Bailey made a standing offer to those serious about this prospect
at the last Forth Day.
lynx
May 24, 2012, 10:49:32 PM5/24/12
to
In <jpmrq5$ga1$1...@reader1.panix.com> lynx <rin...@kaze.void.null> writes:
>I recall that Chuck Bailey made a standing offer to those serious about
>this prospect at the last Forth Day.
Err, Greg Bailey. Talk about saying one name and thinking another . . .
>I recall that Chuck Bailey made a standing offer to those serious about
>this prospect at the last Forth Day.
Paul Rubin
May 24, 2012, 11:17:52 PM5/24/12
to
lynx <rin...@kaze.void.null> writes:
> is it too much for me to ask that people stop publicly dreaming about
> writing code and simply get down to actually writing it?
That turns out to be rather difficult to do. Have you written any
> is it too much for me to ask that people stop publicly dreaming about
> writing code and simply get down to actually writing it?
yourself? I've made some attempts that were pretty painful.
> As far as I know, GA is basically running on fumes, and is still a
> ways away from turning a profit. Your support, even if it's only just
> publishing your simple experiments for others to read, laugh at, or
> play with, would go a long way towards supporting this platform.
"ArrayForth Institute" on their regular web site instead of behind a
registration wall. I think fundamentally though, the first generation
chip is less flexible than it might sound at first, so it's hard to find
viable ideas. I hope they have enough customers to finance follow-on
chips. I don't know what kinds of deals they're pursuing but one
possible area is custom chip designs involving GA cores and other
circuitry. That's probably beyond the means of most individual
experimenters.
> If you really have an interesting idea (e.g., a simple oscilloscope)
> but are seriously short on cash, you might want to contact Green
> Arrays to see if you they'd supply you an Evaluation Board so you
> could contribute an App Note. (See their website for some examples.)
> those serious about this prospect at the last Forth Day.
Greg's proposal was for folks to go up and visit GA and work on an
application there. That sounds like a neat opportunity that could be
fun to follow up on, for those with the schedule flexibility to do
something like that. I've had too many commitments to do it myself,
unfortunately, plus involvement in too many other interesting projects
competing for attention.
lynx
May 25, 2012, 12:15:51 AM5/25/12
to
In <7x8vghn...@ruckus.brouhaha.com> Paul Rubin <no.e...@nospam.invalid> writes:
>That turns out to be rather difficult to do. Have you written any
>yourself? I've made some attempts that were pretty painful.
No. I have done nothing. But I also haven't said anything until now.
>That turns out to be rather difficult to do. Have you written any
>yourself? I've made some attempts that were pretty painful.
My message wasn't meant to single anyone out, and I apologize if it came
across that way. I've just seen WAY too many messages on c.l.f lately
that expound on the possibilities or the limitations of the GA144 from
too many people who aren't even doing anything with it yet (and don't
have one, and in all likelihood, won't get around to even getting one).
It began to bother me . . . sorry! If anything, I humbly salute your
efforts, however preliminary you make them out to be.
>It would be nice if GA put the instructional materials of the
>"ArrayForth Institute" on their regular web site instead of behind a
>registration wall.
only to allow users to track their progress as they go through the
coursework. I don't think it was intended as a barrier.
>I think fundamentally though, the first generation chip is less
>flexible than it might sound at first, so it's hard to find viable
>ideas. I hope they have enough customers to finance follow-on chips.
>I don't know what kinds of deals they're pursuing but one possible area
>is custom chip designs involving GA cores and other circuitry. That's
>probably beyond the means of most individual experimenters.
take some time for people to get a grip on. Even if should be a
failed experiment, I think it's still much too soon to know.
>Greg's proposal was for folks to go up and visit GA and work on an
>application there. That sounds like a neat opportunity that could be
>fun to follow up on, for those with the schedule flexibility to do
>something like that. I've had too many commitments to do it myself,
>unfortunately, plus involvement in too many other interesting projects
>competing for attention.
that anyone coming at them with an idea and the right commitment might
be indulged anyway. Perhaps. Perhaps not. *shrug*
Paul Rubin
May 25, 2012, 12:51:16 AM5/25/12
to
lynx <rin...@kaze.void.null> writes:
> I've just seen WAY too many messages on c.l.f lately
> that expound on the possibilities or the limitations of the GA144 from
> too many people who aren't even doing anything with it yet
I suspect the people posting messages like that have studied the GA144
> I've just seen WAY too many messages on c.l.f lately
> that expound on the possibilities or the limitations of the GA144 from
> too many people who aren't even doing anything with it yet
and tried to figure out how to run their app on it, and hit some sort of
limitation that they then posted about.
> I think the technique of factoring programs across cores is going to
> take some time for people to get a grip on. Even if should be a
> failed experiment, I think it's still much too soon to know.
finished product. Bernd P. has said similar things, and he's actually
made processors very similar to the F18 and done practical things with
them. I believe his versions have tended to have a lot more code space
than the F18. The GA144 would probably be much more attractive if they
used the same die area for 1/4 as many nodes with 4x the memory per
node.
In fact the basic notion of a lot of rather weak parallel processors has
been tried many times since at least the 1960's. The lesson always
seems to be that it's best make the individual nodes powerful in their
own right. So GA may be repeating a very old error.
> You are right, and I appreciate the clarification. I suspect, however,
> that anyone coming at them with an idea and the right commitment might
> be indulged anyway. Perhaps. Perhaps not. *shrug*
if I had one. If I had an idea to pursue I think it would make more
sense to implement it in a software simulator before touching actual
boards with wires sticking out. So I've made a few attempts at coding
stuff, that quickly gets painful. But, the stuff I've looked into is
rather far from the analog electronics realm where the GA is aimed,
i.e. something with signals coming in the A/D and going through some
signal processing functions spread across many nodes. Rickman is doing
stuff like that, so maybe he'll have better luck than me.
Albert van der Horst
May 25, 2012, 7:35:25 AM5/25/12
to
In article <b4c89c90-22d2-4e85...@ec4g2000vbb.googlegroups.com>,
Clever.
>
>With 144 nodes there is a lot of opportunity to add real time signal
>processing features.
And an upgrade path. I like it!
>
>Rick
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
>
>With 144 nodes there is a lot of opportunity to add real time signal
>processing features.
>
>Rick
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
Albert van der Horst
May 25, 2012, 9:49:58 AM5/25/12
to
In article <7x4nr49...@ruckus.brouhaha.com>,
only attractive for hobbyist to tinker with.
So what should be done to the chips:
- make them solderable (at least 1 mm pitch)
- cheap them down to the point that I can afford to smoke up a dozen
chips. Say a unit price of one Euro.
- more explanation of how to bit toggle a program into a chip
- the number of processors per chip may go down by an order of magnitude,
say 10 on a chip would be sufficient, without affecting usability.
(And yes I have actually programmed the chip and its preprocessor,
look up parpi. parpi has run on the then Patriot board. It runs on the
colorforth emulator. It runs in the new Factor based development system
of Leon Konings. Still trying to run it on the GA's development board
intimidates enough that we haven't tried it yet.)
The price of a single GA144 plus breakout board buys you a linux
computer at olimex.
Regards the cheap scope: Chuck has demonstrated generating VGA signals.
So the price of the video is two precision resistors. Discarded VGA monitors
are to be found at the way side.
Paul Rubin <no.e...@nospam.invalid> wrote:
>lynx <rin...@kaze.void.null> writes:
>> I've just seen WAY too many messages on c.l.f lately
>> that expound on the possibilities or the limitations of the GA144 from
>> too many people who aren't even doing anything with it yet
>
>I suspect the people posting messages like that have studied the GA144
>and tried to figure out how to run their app on it, and hit some sort of
>limitation that they then posted about.
>
>> I think the technique of factoring programs across cores is going to
>> take some time for people to get a grip on. Even if should be a
>> failed experiment, I think it's still much too soon to know.
>
>That says: the GA144 is an interesting research project, as opposed to a
>finished product. Bernd P. has said similar things, and he's actually
>made processors very similar to the F18 and done practical things with
>them. I believe his versions have tended to have a lot more code space
>than the F18. The GA144 would probably be much more attractive if they
>used the same die area for 1/4 as many nodes with 4x the memory per
>node.
The single most important thing would be to recognize that it is
>lynx <rin...@kaze.void.null> writes:
>> I've just seen WAY too many messages on c.l.f lately
>> that expound on the possibilities or the limitations of the GA144 from
>> too many people who aren't even doing anything with it yet
>
>I suspect the people posting messages like that have studied the GA144
>and tried to figure out how to run their app on it, and hit some sort of
>limitation that they then posted about.
>
>> I think the technique of factoring programs across cores is going to
>> take some time for people to get a grip on. Even if should be a
>> failed experiment, I think it's still much too soon to know.
>
>That says: the GA144 is an interesting research project, as opposed to a
>finished product. Bernd P. has said similar things, and he's actually
>made processors very similar to the F18 and done practical things with
>them. I believe his versions have tended to have a lot more code space
>than the F18. The GA144 would probably be much more attractive if they
>used the same die area for 1/4 as many nodes with 4x the memory per
>node.
only attractive for hobbyist to tinker with.
So what should be done to the chips:
- make them solderable (at least 1 mm pitch)
- cheap them down to the point that I can afford to smoke up a dozen
chips. Say a unit price of one Euro.
- more explanation of how to bit toggle a program into a chip
- the number of processors per chip may go down by an order of magnitude,
say 10 on a chip would be sufficient, without affecting usability.
(And yes I have actually programmed the chip and its preprocessor,
look up parpi. parpi has run on the then Patriot board. It runs on the
colorforth emulator. It runs in the new Factor based development system
of Leon Konings. Still trying to run it on the GA's development board
intimidates enough that we haven't tried it yet.)
The price of a single GA144 plus breakout board buys you a linux
computer at olimex.
Regards the cheap scope: Chuck has demonstrated generating VGA signals.
So the price of the video is two precision resistors. Discarded VGA monitors
are to be found at the way side.
rickman
May 26, 2012, 8:02:53 PM5/26/12
to
Thanks for your comments.
On May 24, 6:59 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> > ... and I realized that the GA144 would make a decent low
> > end o'scope with very little additional hardware.
>
> That does sound like a plausible GA application. I wonder how it
> compares to a dedicated A/D converter and a USB chip, plus some PC
> software.
>
> > The ADC can provide more than 8 bit resolution at a sample rate of 5
> > MSPS which is enough for a number of applications.
>
> That's 40 megabits/sec per channel -- how do you plan to get that off
> the chip into a PC?
Who said anything about a PC? I'm thinking a dedicated screen, but
adding a USB2.0 chip might do a decent job of connecting to a PC, not
sure I've never worked with USB before and I don't know what rates are
realistic. Of course it doesn't really need to be real time, just
fast enough to give a real time feel to a screen update.
The "no extra chip" solution would only be 12 Mbps, but that might
still be an option for display rate data.
> > The resolution increases with lower sample rates giving greater than
> > 15 bits at 48 kSPS.
>
> I thought per earlier discussion, it's not realistic to expect 15 bit
> precision from those a/d's at any reasonable speed. In particular I
> thought one really couldn't do CD-quality audio this way.
I was not party to that discussion that I recall. CD quality implies
both resolution and rate, so no, I don't think that is feasible, I see
just less than 16 bits at 48 kSPS.
> > There are a number of small displays available that can be interfaced
> > to provide a self contained display or it can be connected to a PC
> > through a USB cable for control and display.
>
> Dedicated display => higher cost gadget => might as well use a real
> scope. Using a PC or tablet interface makes much more sense.
I think you way overestimate the cost of a display. There is a 7 inch
display for the BeagleBone that is under $150. Not many scopes come
close to that figure, but then this is apples and oranges.
> Hmm. How will you keep the clock rate accurate, and the channels
> synchronized? I guess these are doable, but I remember earlier threads
> about crystal oscillators, and propagating signals between nodes is a
> bit painful if the nodes are concurrently doing other things.
That is all just something you work out with your design plan. If
needed wires on the board can be used to connect sync signals, but I
doubt that is required.
> > With 144 nodes there is a lot of opportunity to add real time signal
> > processing features.
>
> I keep having a hard time thinking of uses for 144 nodes. The 32 node
> version (if smaller and less expensive) might have been more attractive.
32 nodes is the same package because it has the same I/O. The chip
cost is not currently a result of the chip size I doubt, it is mostly
a function of the other costs of running a small company. I'm not
looking at doing this for a marketable product.
Rick
On May 24, 6:59 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> > ... and I realized that the GA144 would make a decent low
> > end o'scope with very little additional hardware.
>
> That does sound like a plausible GA application. I wonder how it
> compares to a dedicated A/D converter and a USB chip, plus some PC
> software.
>
> > The ADC can provide more than 8 bit resolution at a sample rate of 5
> > MSPS which is enough for a number of applications.
>
> That's 40 megabits/sec per channel -- how do you plan to get that off
> the chip into a PC?
adding a USB2.0 chip might do a decent job of connecting to a PC, not
sure I've never worked with USB before and I don't know what rates are
realistic. Of course it doesn't really need to be real time, just
fast enough to give a real time feel to a screen update.
The "no extra chip" solution would only be 12 Mbps, but that might
still be an option for display rate data.
> > The resolution increases with lower sample rates giving greater than
> > 15 bits at 48 kSPS.
>
> I thought per earlier discussion, it's not realistic to expect 15 bit
> precision from those a/d's at any reasonable speed. In particular I
> thought one really couldn't do CD-quality audio this way.
both resolution and rate, so no, I don't think that is feasible, I see
just less than 16 bits at 48 kSPS.
> > There are a number of small displays available that can be interfaced
> > to provide a self contained display or it can be connected to a PC
> > through a USB cable for control and display.
>
> Dedicated display => higher cost gadget => might as well use a real
> scope. Using a PC or tablet interface makes much more sense.
display for the BeagleBone that is under $150. Not many scopes come
close to that figure, but then this is apples and oranges.
> Hmm. How will you keep the clock rate accurate, and the channels
> synchronized? I guess these are doable, but I remember earlier threads
> about crystal oscillators, and propagating signals between nodes is a
> bit painful if the nodes are concurrently doing other things.
needed wires on the board can be used to connect sync signals, but I
doubt that is required.
> > With 144 nodes there is a lot of opportunity to add real time signal
> > processing features.
>
> I keep having a hard time thinking of uses for 144 nodes. The 32 node
> version (if smaller and less expensive) might have been more attractive.
cost is not currently a result of the chip size I doubt, it is mostly
a function of the other costs of running a small company. I'm not
looking at doing this for a marketable product.
Rick
rickman
May 26, 2012, 8:05:52 PM5/26/12
to
On May 24, 10:46 pm, lynx <rink...@kaze.void.null> wrote:
> With no offense intended to many people who have thoughtfully considered
> the many applications of the Green Arrays microprocessor, is it too much
> for me to ask that people stop publicly dreaming about writing code and
> simply get down to actually writing it?
Yes, it is too much to ask. I posted this here to get people to help
> With no offense intended to many people who have thoughtfully considered
> the many applications of the Green Arrays microprocessor, is it too much
> for me to ask that people stop publicly dreaming about writing code and
> simply get down to actually writing it?
me think about it. There are a lot of good thinkers and even those
who aren't so good <grin> might have a useful observation.
> As far as I know, GA is
> basically running on fumes, and is still a ways away from turning a
> profit. Your support, even if it's only just publishing your simple
> experiments for others to read, laugh at, or play with, would go a long
> way towards supporting this platform.
>
> If you really have an interesting idea (e.g., a simple oscilloscope) but
> are seriously short on cash, you might want to contact Green Arrays to
> see if you they'd supply you an Evaluation Board so you could contribute
> an App Note. (See their website for some examples.) I recall that
> Chuck Bailey made a standing offer to those serious about this prospect
> at the last Forth Day.
In fact, I think they asked you to chip in for meals. Do I remember
that incorrectly?
Rick
Paul Rubin
May 26, 2012, 10:16:42 PM5/26/12
to
rickman <gnu...@gmail.com> writes:
>> That's 40 megabits/sec per channel -- how do you plan to get that off
>> the chip into a PC?
>
> Who said anything about a PC? I'm thinking a dedicated screen,
It would be really nice to be able to store the samples in a memory
>> That's 40 megabits/sec per channel -- how do you plan to get that off
>> the chip into a PC?
>
> Who said anything about a PC? I'm thinking a dedicated screen,
buffer to scroll around in them, and the GA has no internal memory to
speak of. I guess you could use their SRAM control nodes which
currently can write 16 bit samples to sram at 4 mhz or so (some
optimization might be possible), and upload to the PC from that.
> The "no extra chip" solution would only be 12 Mbps, but that might
> still be an option for display rate data.
> I think you way overestimate the cost of a display. There is a 7 inch
> display for the BeagleBone that is under $150.
that. So it would make more sense for this scope to be an add-on gadget
for a PC or tablet. There are already various products like that, of
course. Here is a circuit with some code:
http://projectproto.blogspot.com/2010/09/android-bluetooth-oscilloscope.html
>> I keep having a hard time thinking of uses for 144 nodes. The 32 node
>> version (if smaller and less expensive) might have been more attractive.
>
> 32 nodes is the same package because it has the same I/O. The chip
> cost is not currently a result of the chip size I doubt, it is mostly
> a function of the other costs of running a small company.
chip the same size and cost and die area as the GA144, but with 32 nodes
with 4x the memory per node, and if possible more connectivity between
nodes. Or 32 nodes and some SRAM blocks, or 32 nodes and some FPGA
LUT's, or you get the idea.
rickman
May 27, 2012, 5:33:24 PM5/27/12
to
On May 26, 10:16 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
> rickman <gnu...@gmail.com> writes:
> >> That's 40 megabits/sec per channel -- how do you plan to get that off
> >> the chip into a PC?
>
> > Who said anything about a PC? I'm thinking a dedicated screen,
>
> It would be really nice to be able to store the samples in a memory
> buffer to scroll around in them, and the GA has no internal memory to
> speak of. I guess you could use their SRAM control nodes which
> currently can write 16 bit samples to sram at 4 mhz or so (some
> optimization might be possible), and upload to the PC from that.
I'm not ruling out the use of a PC, but that requires the USB
> rickman <gnu...@gmail.com> writes:
> >> That's 40 megabits/sec per channel -- how do you plan to get that off
> >> the chip into a PC?
>
> > Who said anything about a PC? I'm thinking a dedicated screen,
>
> It would be really nice to be able to store the samples in a memory
> buffer to scroll around in them, and the GA has no internal memory to
> speak of. I guess you could use their SRAM control nodes which
> currently can write 16 bit samples to sram at 4 mhz or so (some
> optimization might be possible), and upload to the PC from that.
interface and I would want to start with a self contained unit. As to
the memory, yes, I am thinking of writing samples to memory and
displaying based on what is in the memory.
> > The "no extra chip" solution would only be 12 Mbps, but that might
> > still be an option for display rate data.
>
> I guess that is reasonable with external sram.
all the processing on chip and just uses the USB port to send display
data to the PC. That only requires that you send one screen worth of
data say, 60 times a second. If you are just displaying a waveform
that is only 2k samples or 120 kBps or 1 Mbps. I think that is doable
with a 12 Mbps USB link, no? Of course there are some types of
displays that can't be sent as a set of values to be graphed. There
are DPO type display modes that require a huge pipe to memory.
> > I think you way overestimate the cost of a display. There is a 7 inch
> > display for the BeagleBone that is under $150.
>
> $150? Are you kidding? I can get a retail 7" Android tablet for half
> that. So it would make more sense for this scope to be an add-on gadget
> for a PC or tablet. There are already various products like that, of
> course. Here is a circuit with some code:
>
It might cost less, but with a directly connected display there are no
"software" issues other than the ones I create. $150 is the 1-off
cost. My goal is not to sell this as a practical device really, it is
to see what I can do with the GA144. I suppose I could consider a
tablet app, but if I'm doing that why not make it a PC app and then
the hardware is free...
> >> I keep having a hard time thinking of uses for 144 nodes. The 32 node
> >> version (if smaller and less expensive) might have been more attractive.
>
> > 32 nodes is the same package because it has the same I/O. The chip
> > cost is not currently a result of the chip size I doubt, it is mostly
> > a function of the other costs of running a small company.
>
> OK, that makes sense. But then, I think I'd still find more use for a
> chip the same size and cost and die area as the GA144, but with 32 nodes
> with 4x the memory per node, and if possible more connectivity between
> nodes. Or 32 nodes and some SRAM blocks, or 32 nodes and some FPGA
> LUT's, or you get the idea.
is. If I were playing that game, one of the first things I would
change is the I/Os, I would give them programmable I/O voltage and
type like found on FPGAs. There currently is no way to receive a
differential signal like LVDS without external chips. But then that
is actually a common theme with the GA144. There are lots of things
it can do, but there are lots of things it can't do without other
chips.
I appreciate your thoughts.
Rick
rickman
May 27, 2012, 5:46:01 PM5/27/12
to
I thought of another application today. I was looking at the Analog
Devices video series on thermocouples and realized that you could do
an entire t-couple interface in software using a single ADC input on a
GA144. T-couples are typically monitored with a very low duty cycle
so there could be lots of time for averaging out the noise using the
methods GA describes. There would still need to be some sort of cold
junction temperature sensing but the rest is all software!
I'm not certain that common mode rejection is not needed, but that
could be done using two ADC inputs. If 50 or 60 Hz is the concern,
that can be eliminated by sampling synchronously... as long as the
common mode signal is still within the input range of the ADC.
Rick
Devices video series on thermocouples and realized that you could do
an entire t-couple interface in software using a single ADC input on a
GA144. T-couples are typically monitored with a very low duty cycle
so there could be lots of time for averaging out the noise using the
methods GA describes. There would still need to be some sort of cold
junction temperature sensing but the rest is all software!
I'm not certain that common mode rejection is not needed, but that
could be done using two ADC inputs. If 50 or 60 Hz is the concern,
that can be eliminated by sampling synchronously... as long as the
common mode signal is still within the input range of the ADC.
Rick
Paul Rubin
May 27, 2012, 6:00:25 PM5/27/12
to
rickman <gnu...@gmail.com> writes:
> I was looking at the Analog Devices video series on thermocouples and
> realized that you could do an entire t-couple interface in software
> using a single ADC input on a GA144.
That might be doable but doesn't seem to call for any of the GA144's
> I was looking at the Analog Devices video series on thermocouples and
> realized that you could do an entire t-couple interface in software
> using a single ADC input on a GA144.
special capabilities. Couldn't you do it with a 50 cent AVR or MSP430
that's a lot easier to program? The oscilloscope idea seems much
more suited to the GA144 because of the high speed sampling needed.
The challenge of finding suitable GA apps isn't just "think up things
that a GA144 can do", but "think up things where a GA144 is superior
to conventional approaches". Maybe I misunderstand the requirements and
the thermocouple is like that, but in this case I'd be interested in
more explanation.
rickman
May 27, 2012, 6:08:47 PM5/27/12
to
seen a poor man's o'scope built using one. The thermocouple idea came
to me as I had been trying to design a general purpose input/output
board for the BeagleBone which would also have t-couple
capabilities.
I don't think you can really do t-couple sensing with other MCUs
without adding precision amplifiers. By taking advantage of the
unique sampling method of the GA144, very low level signals can be
measured with high resolution. I'm just not sure how to best deal
with the noise issues which seem to be common with t-couple apps.
This may take some real world testing.
Rick
Paul Rubin
May 27, 2012, 6:34:46 PM5/27/12
to
rickman <gnu...@gmail.com> writes:
> I don't think you can really do t-couple sensing with other MCUs
> without adding precision amplifiers. By taking advantage of the
> unique sampling method of the GA144, very low level signals can be
> measured with high resolution.
Oh that's interesting, I wasn't aware of this issue at all. I'll try to
> I don't think you can really do t-couple sensing with other MCUs
> without adding precision amplifiers. By taking advantage of the
> unique sampling method of the GA144, very low level signals can be
> measured with high resolution.
read about it.
Paul Rubin
May 27, 2012, 6:39:22 PM5/27/12
to
rickman <gnu...@gmail.com> writes:
> Here I am thinking of a real time display on the PC. The GA144 can do
> all the processing on chip and just uses the USB port to send display
> data to the PC. That only requires that you send one screen worth of
> data say, 60 times a second. If you are just displaying a waveform
> that is only 2k samples or 120 kBps or 1 Mbps. I think that is doable
> with a 12 Mbps USB link, no?
Can you do 12 MBps USB in GA software? Maybe 1 mbit is enough, if the
> Here I am thinking of a real time display on the PC. The GA144 can do
> all the processing on chip and just uses the USB port to send display
> data to the PC. That only requires that you send one screen worth of
> data say, 60 times a second. If you are just displaying a waveform
> that is only 2k samples or 120 kBps or 1 Mbps. I think that is doable
> with a 12 Mbps USB link, no?
PC is doing some of the work and the GA is just sending updates.
> I suppose I could consider a tablet app, but if I'm doing that why not
> make it a PC app and then the hardware is free...
fancier tablets, are almost as portable, and do a lot more.
rickman
May 28, 2012, 10:52:03 AM5/28/12
to
one is about 2:30 minutes and covers one key concept, I think there
are eight total. You can even download them. Matt Duff is the
speaker IIRC.
The main issue is that the "signal" is only 40 uV/°C. This is below
one bit with most ADCs and so requires a very low offset opamp or
instrumentation amp. I don't know that the GA144 ADC can measure this
directly, but I bet it can. You just integrate the signal over a long
enough period which also reduces the noise greatly. It depends on the
various sources of error which we will need to figure out for
ourselves since GA isn't talking... I would be mostly worried about
thermal drift with changes in the die temperature.
Oddly enough the limiting factor in accuracy when using a t-couple is
measuring the temperature of the reference junction. Most methods are
only accurate to ±1°C which is really not all that good even for a
common household thermostat. I'd like to be able to get accuracy to
0.25°C. That will be the fifth ADC...
Rick
Dennis Ruffer
May 28, 2012, 1:27:48 PM5/28/12
to
If you hardware types are looking for a project that will allow the rest of us software types to help come up with the next killer app, then why not do the seemingly trivial job of finishing what GA started at:
http://www.greenarraychips.com/home/documents/budget.html
I've got that setup, of a GA144, a SchmartBoard|ez and a Sparkfun FTDI board, but I realized yesterday that there's quite a bit of the details missing from that page. Getting it all setup is going to take someone with hardware knowledge to do it and write it all down somewhere.
Give us all a lever (on a budget)...
DaR
http://www.greenarraychips.com/home/documents/budget.html
I've got that setup, of a GA144, a SchmartBoard|ez and a Sparkfun FTDI board, but I realized yesterday that there's quite a bit of the details missing from that page. Getting it all setup is going to take someone with hardware knowledge to do it and write it all down somewhere.
Give us all a lever (on a budget)...
DaR
rickman
May 28, 2012, 3:09:17 PM5/28/12
to
Someone had a report of trying to use the board and they got it to
work, but found that without decoupling caps it would not support all
of the processors running at once! I don't get what the point is.
Why produce a mounting adapter for a board that doesn't deal properly
with power distribution?
Otherwise, what is missing? The web page says, "This appears to be a
complete, minimal system for about $60.00 in parts plus some bypass
capacitors, wire, and labor."
Rick
Dennis Ruffer
May 29, 2012, 11:04:31 AM5/29/12
to
Stop dreaming and make the chip accessible to as many people as possible.
DaR
rickman
May 29, 2012, 4:42:11 PM5/29/12
to
Can"?) I have not looked at it hard because of the obvious issues.
The FTDI module is just an RS232 converter to USB. I don't know if
the FTDI module omits or bypasses the RS232 level conversions which
are not needed in this usage.
I would be happy to provide some hardware complete with good docs as
open source hardware if I could find a few people who would be
committed to helping with the software.
The more I look at my o'scope idea the more I like it. My first pass
at hardware will be the BeagleBone (BB) daughter card ("cape" as it is
called in BB parlance). I expect to use an ICE40 chip from Lattice
(formerly Silicon Blue), likely the HX8K in a 256 pin package to get
enough I/Os to map to all of the expansion pins as well as other
connectors. The board would get multiple uses then, as a BB cape
board and as a stand alone BB replacement board (able to use other
cape boards without the BB CPU board). Heck, leave off the GA144 and
it could be an ICE40 eval board... lol
To get it started I think it would need software support on the BB and
that is likely a bigger bite than I can chew at this time.
Rick
Dennis Ruffer
May 30, 2012, 10:33:42 AM5/30/12
to
> I would be happy to provide some hardware complete with good docs as
> open source hardware if I could find a few people who would be
> committed to helping with the software.
> The more I look at my o'scope idea the more I like it. My first pass
> at hardware will be the BeagleBone (BB) daughter card ("cape" as it is
> called in BB parlance). I expect to use an ICE40 chip from Lattice
> (formerly Silicon Blue), likely the HX8K in a 256 pin package to get
> enough I/Os to map to all of the expansion pins as well as other
> connectors. The board would get multiple uses then, as a BB cape
> board and as a stand alone BB replacement board (able to use other
> cape boards without the BB CPU board). Heck, leave off the GA144 and
> it could be an ICE40 eval board... lol
>
> To get it started I think it would need software support on the BB and
> that is likely a bigger bite than I can chew at this time.
>
> Rick
DaR
Paul Rubin
May 30, 2012, 11:42:44 AM5/30/12
to
rickman <gnu...@gmail.com> writes:
> The more I look at my o'scope idea the more I like it. My first pass
> at hardware will be the BeagleBone (BB) daughter card ("cape" as it is
> called in BB parlance). I expect to use an ICE40 chip from Lattice
> (formerly Silicon Blue), likely the HX8K in a 256 pin package to get
Looks like a rather powerful low powered FPGA:
> The more I look at my o'scope idea the more I like it. My first pass
> at hardware will be the BeagleBone (BB) daughter card ("cape" as it is
> called in BB parlance). I expect to use an ICE40 chip from Lattice
> (formerly Silicon Blue), likely the HX8K in a 256 pin package to get
http://www.latticesemi.com/products/cpld/ice40series.cfm
I'm not sure what it's supposed to do, or what the GA144 in this picture
is supposed to do either. The Beaglebone has its own A/D's: are they
not fast enough? The HX8K has a lot of on-chip ram so maybe it could
handle the synchronous data acquisition from an external A/D, or even
implement a successive approximation A/D with a resistor ladder,
buffering the info for the Beaglebone? So the GA144 seems sort of otu
in the cold.
Bernd Paysan
May 30, 2012, 1:28:46 PM5/30/12
to
Dennis Ruffer wrote:
> I would hope that the FTDI module can also provide power. Even if it
> can't provide enough current to support all nodes running at the same
> time, using a wall wart on a low power prototype, just seems wrong.
Well, it is connected to USB, so you can use the 5V lines to generate
> I would hope that the FTDI module can also provide power. Even if it
> can't provide enough current to support all nodes running at the same
> time, using a wall wart on a low power prototype, just seems wrong.
power yourself (up to 500mA, which is ample). The FTDI module generates
3.3V, too ("line level" for USB D+/D-), but you can't hook that much on
it.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
Jan Coombs
May 30, 2012, 1:51:11 PM5/30/12
to
On 30/05/12 16:42, Paul Rubin wrote:
> rickman<gnu...@gmail.com> writes:
>> The more I look at my o'scope idea the more I like it. My first pass
>> at hardware will be the BeagleBone (BB) daughter card ("cape" as it is
>> called in BB parlance). I expect to use an ICE40 chip from Lattice
>> (formerly Silicon Blue), likely the HX8K in a 256 pin package to get
There is enough block RAM in the HX8K to build 64 processors of
> rickman<gnu...@gmail.com> writes:
>> The more I look at my o'scope idea the more I like it. My first pass
>> at hardware will be the BeagleBone (BB) daughter card ("cape" as it is
>> called in BB parlance). I expect to use an ICE40 chip from Lattice
>> (formerly Silicon Blue), likely the HX8K in a 256 pin package to get
memory capacity equal to the F18A
> Looks like a rather powerful low powered FPGA:
>
> http://www.latticesemi.com/products/cpld/ice40series.cfm
iCEblink40 Development Kit
Available
2Q 2012
Features
• iCE40HX1K-VQ100
• Powered by USB input
• 1Mbit SPI PROM (enough for two iCE40HX1K images using WarmBoot)
• Four capacitive-touch buttons (requires FPGA logic)
• Four user LEDs
• Dual PMOD header compatible with Digilent PMOD boards (6x2 header)
• 3.33 MHz oscillator (can be modified to support 33.33 MHz or 333 kHz)
• 1.2V and 3.3V power supplies
• All iCE40HX1K I/O available on headers or 0.1” through-holes
• iCE40HX1K-VQ100
Logic Cells: 1,280
Embedded RAM Bits: 64k (bits!!)
PLLs: 1
Icc (clock stopped): 267uA
Packages: CB132(8x8mm), VQ100, TQ144
RAMs are (in 65k parts) 256x16 ie 4kb so this part
seems to have 16 of them.
Currently I'm targeting an older but similar part from
Actel/Microsemi, and expect to get an average of 13M Forth
instructions per sec, with max data size of about 32b, and a
maximum of 8 processors per chip, one per available block RAM.
Jan Coombs.
--
rickman
May 30, 2012, 2:06:30 PM5/30/12
to
a BB cape for I/O expansion. Adding the GA144 to the cape provides
additional processing power as well as letting the board operate stand
alone. By including the ice40 all of the I/Os on the headers can be
driven when the board is used stand alone allowing it to use other
cape boards like the 7" LCD module for example. Also, the GA144 only
does 1.8 volt I/O, the ice40 can do everything up to 3.3 volts. When
the GA144 board is used with the BB the BB can provide external USB
and Ethernet connectivity with a minimum of effort.
Rick
rickman
May 30, 2012, 2:32:43 PM5/30/12
to
On May 30, 10:33 am, Dennis Ruffer <daruf...@gmail.com> wrote:
> On Tuesday, May 29, 2012 1:42:11 PM UTC-7, rickman wrote:
> > The FTDI module is just an RS232 converter to USB. I don't know if
> > the FTDI module omits or bypasses the RS232 level conversions which
> > are not needed in this usage.
>
> I would hope that the FTDI module can also provide power. Even if it can't provide enough current to support all nodes running at the same time, using a wall wart on a low power prototype, just seems wrong.
I think if anything, it would be the other way around, the FTDI module
> On Tuesday, May 29, 2012 1:42:11 PM UTC-7, rickman wrote:
> > The FTDI module is just an RS232 converter to USB. I don't know if
> > the FTDI module omits or bypasses the RS232 level conversions which
> > are not needed in this usage.
>
> I would hope that the FTDI module can also provide power. Even if it can't provide enough current to support all nodes running at the same time, using a wall wart on a low power prototype, just seems wrong.
is expecting to be powered. I don't think this module gets power from
the USB connector, but I might be wrong.
> > I would be happy to provide some hardware complete with good docs as
> > open source hardware if I could find a few people who would be
> > committed to helping with the software.
>
> What software are you looking for, at the base level? I would hope that it would behave just like plugging the USB cable into port C of the eval board. That way we can leverage the entire colorForth IDE. Application specific software is an entirely separate issue, which can grow over time. The 1st step is to crawl into the chip, one node at a time.
then we are in trouble. I don't plan to deal with creating my own
tools, at least not at that level. Node crawling is not the part I am
worried about.
I am thinking mostly about the BeagleBone side of the interface. For
people who are familiar with Linux and the BB that should not be a big
deal. They have several different types of interfaces which can be
used SPI, I2C, etc. This would be useful for control. But I would
like to not impinge on other cape boards so they can be used at the
same time if possible. But this may not be possible. The BB people
say that due to the I/O switch which route signals to the I/Os as
needed for each type of cape, they don't even try to organize which
capes are compatible with each other.
So far the only available capes (that aren't just prototyping capes)
are the DVI and the 7" LCD capes which I expect would be mutually
exclusive. Other capes are proprietary so I guess I don't have to
worry about them.
> > The more I look at my o'scope idea the more I like it. My first pass
> > at hardware will be the BeagleBone (BB) daughter card ("cape" as it is
> > called in BB parlance). I expect to use an ICE40 chip from Lattice
> > (formerly Silicon Blue), likely the HX8K in a 256 pin package to get
> > enough I/Os to map to all of the expansion pins as well as other
> > connectors. The board would get multiple uses then, as a BB cape
> > board and as a stand alone BB replacement board (able to use other
> > cape boards without the BB CPU board). Heck, leave off the GA144 and
> > it could be an ICE40 eval board... lol
>
> > To get it started I think it would need software support on the BB and
> > that is likely a bigger bite than I can chew at this time.
>
> > Rick
>
> I don't know anything about doing software on a BB either, and I'm not sure how you are envisioning the division of functionality. I can envision the GA144 doing all of the work, but then I may be overestimating what can be down on the hardware side. Maybe a sketch of a block diagram would help.
(maybe). The GA144 board connects to the outside world through analog
and digital I/O. I think of the BB as providing the GUI, the user
interface. The GA144 board does the hardware I/O and the number
crunching.
I had been thinking of including op amps to the ADC inputs, but I am
thinking of leaving that off now. It is too restrictive in terms of
bandwidth and flexibility. Maybe add the parts to the design and
optionally populate them?
Rick
0 new messages