Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #41625 > unrolled thread
| Started by | dunno <dunno@dunno.dunno> |
|---|---|
| First post | 2015-08-31 07:20 +0000 |
| Last post | 2015-09-14 18:21 -0700 |
| Articles | 20 on this page of 115 — 25 participants |
Back to article view | Back to comp.lang.forth
GA144 use cases dunno <dunno@dunno.dunno> - 2015-08-31 07:20 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-08-31 09:55 -0400
Re: GA144 use cases Syd Rumpo <usenet@nononono.co.uk> - 2015-08-31 16:49 +0100
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-08-31 18:35 -0400
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-08-31 19:08 -0700
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 10:57 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 14:17 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 11:28 -0700
Re: GA144 use cases hughaguilar96@gmail.com - 2015-09-02 13:41 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 16:50 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 15:03 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 18:18 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 16:14 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 20:40 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-02 17:53 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 21:25 -0400
Re: GA144 use cases Mux <Yvo.Zoer@gmail.com> - 2015-09-02 22:28 -0700
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-02 22:53 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 11:32 -0400
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-03 11:57 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-03 10:35 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 15:54 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-03 16:11 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 13:06 -0400
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:07 +0000
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-04 11:49 -0400
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 11:06 +0000
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-05 09:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-05 12:59 -0400
Re: GA144 use cases mhx@iae.nl - 2015-09-05 10:56 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:29 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 22:08 +0200
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-03 14:00 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 01:28 +0200
Re: GA144 use cases franck.bensusan@gmail.com - 2015-09-03 23:04 -0700
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:24 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 15:09 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 15:10 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:04 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:51 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-06 22:51 +0200
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-06 17:30 -0700
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-04 22:27 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 13:07 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 11:22 +0000
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 08:14 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-04 15:13 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-05 16:06 +0000
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 21:05 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:37 +0000
Re: GA144 use cases Andrew Haley <andrew29@littlepinkcloud.invalid> - 2015-11-30 04:17 -0600
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-12-01 23:06 +0100
Re: GA144 use cases Mark Wills <markwills1970@gmail.com> - 2015-09-03 00:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 13:08 -0400
Re: GA144 use cases forther <forther@gmail.com> - 2015-09-07 11:26 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-02 15:15 -0400
Re: GA144 use cases forther <forther@gmail.com> - 2015-09-07 11:21 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-11-30 16:33 -0500
Re: GA144 use cases forther <forther@gmail.com> - 2015-12-03 12:12 -0800
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-12-03 16:10 -0500
Re: GA144 use cases Jason Damisch <jasondamisch@yahoo.com> - 2015-09-02 12:10 -0700
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-03 01:27 -0700
Re: GA144 use cases Syd Rumpo <usenet@nononono.co.uk> - 2015-09-03 13:32 +0100
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-03 11:32 -0400
Re: GA144 use cases mhx@iae.nl (Marcel Hendrix) - 2015-09-03 18:57 +0200
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-03 23:58 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-04 07:52 +0000
Re: GA144 use cases Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-09-05 16:32 +0000
Re: GA144 use cases mhx@iae.nl - 2015-09-05 10:52 -0700
Re: GA144 use cases Bernd Paysan <bernd.paysan@gmx.de> - 2015-09-05 22:11 +0200
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-06 14:18 +0000
Re: GA144 use cases anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-09-07 07:49 +0000
Re: GA144 use cases Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-09-05 23:42 +0000
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-05 17:25 -0700
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-07 03:18 -0700
Re: GA144 use cases Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-09-07 03:31 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-07 15:06 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-08 21:41 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 02:54 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 03:02 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 16:55 -0400
Re: GA144 use cases Paul Rubin <no.email@nospam.invalid> - 2015-09-09 20:12 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 23:40 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-09 23:43 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 00:07 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 21:55 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 01:43 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-09 23:49 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 14:43 -0400
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-10 16:10 -0400
Re: GA144 use cases Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2015-09-12 03:15 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-12 10:28 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 13:05 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-13 18:59 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 18:42 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-13 22:47 -0400
Re: GA144 use cases Greg <abiforth@gmail.com> - 2015-09-13 21:24 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 02:00 -0400
Re: GA144 use cases borota@gmail.com - 2015-09-14 08:35 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 12:06 -0400
Re: GA144 use cases borota@gmail.com - 2015-09-14 09:33 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 13:25 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-14 14:17 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 18:12 -0400
Re: GA144 use cases Greg <schmegner@gmail.com> - 2015-09-14 18:15 -0700
Re: GA144 use cases rickman <gnuarm@gmail.com> - 2015-09-14 22:16 -0400
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-18 14:50 -0700
Re: GA144 use cases Jason Damisch <jasondamisch@yahoo.com> - 2015-09-18 15:11 -0700
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-19 05:32 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-19 08:39 -0700
Re: GA144 use cases Greg <borota@gmail.com> - 2015-09-20 19:03 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-21 06:44 -0700
Re: GA144 use cases Dennis Ruffer <daruffer@gmail.com> - 2015-09-22 13:10 -0700
Re: GA144 use cases Mark Wills <markwills1970@gmail.com> - 2015-09-18 16:18 -0700
Re: GA144 use cases schmegner@gmail.com - 2015-09-14 18:21 -0700
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | dunno <dunno@dunno.dunno> |
|---|---|
| Date | 2015-08-31 07:20 +0000 |
| Subject | GA144 use cases |
| Message-ID | <ms0v7i$icg$1@news.mixmin.net> |
After reading documentation on GA144 I wonder what kind of application could benefit from using it. Can anyone provide real-world examples? -- dunno
[toc] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-08-31 09:55 -0400 |
| Message-ID | <ms1m9i$3li$1@dont-email.me> |
| In reply to | #41625 |
On 8/31/2015 3:20 AM, dunno wrote: > After reading documentation on GA144 I wonder what kind of application > could benefit from using it. > > Can anyone provide real-world examples? I thought I had an application for the GA144 once, but when push came to shove I couldn't verify that it had enough performance to implement an SDRAM controller. Green Arrays won't provide certain information relating to the timing of the I/O and internode comms so that I could do a paper analysis. Their suggestion was to build the design and see if it worked, lol. That completely ignores the various issues of timing in hardware. I also considered using it in a product I am supplying to a major networking company. But again, I couldn't verify the I/O would be fast enough to implement a 33 MHz serial port similar to SPI. This particular app could be done mostly on a conventional MCU, but there are two hardware interfaces that would exceed the capabilities of a 100 MHz CPU. As it turns out the processors in the GA144 aren't really that much faster, just a lot more of them. Since the handling of an I/O port can't be spread over multiple processors, this design wasn't any more suitable for the GA144 than an ARM CM3. Since neither will do the job this design will continue to use an FPGA. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Syd Rumpo <usenet@nononono.co.uk> |
|---|---|
| Date | 2015-08-31 16:49 +0100 |
| Message-ID | <ms1suq$rm$1@dont-email.me> |
| In reply to | #41625 |
On 31/08/2015 08:20, dunno wrote: > After reading documentation on GA144 I wonder what kind of application > could benefit from using it. > > Can anyone provide real-world examples? I've thought long and hard about this, but haven't been able to think of anything useful which can't be done better another way. Maybe it's just me, but GreenArrays don't seem to have come up with anything substantive either. A shame, I like stack machines. Cheers -- Syd
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-08-31 18:35 -0400 |
| Message-ID | <ms2kng$cm0$1@dont-email.me> |
| In reply to | #41628 |
On 8/31/2015 11:49 AM, Syd Rumpo wrote: > On 31/08/2015 08:20, dunno wrote: >> After reading documentation on GA144 I wonder what kind of application >> could benefit from using it. >> >> Can anyone provide real-world examples? > > I've thought long and hard about this, but haven't been able to think of > anything useful which can't be done better another way. Maybe it's just > me, but GreenArrays don't seem to have come up with anything substantive > either. > > A shame, I like stack machines. Yeah, they didn't really provide something with much flexibility because they only provided processing power and not much else. You can make some tradeoffs of processing with memory or the need for dedicated peripherals. But at some point you just need the sorts of things the other embedded processors have... that's why they have them. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Dennis Ruffer <daruffer@gmail.com> |
|---|---|
| Date | 2015-08-31 19:08 -0700 |
| Message-ID | <c94b2de8-16b9-4e0b-8744-c9af80abfbe4@googlegroups.com> |
| In reply to | #41625 |
On Monday, August 31, 2015 at 12:20:21 AM UTC-7, dunno wrote: > Can anyone provide real-world examples? IntellaSys had in mind hearing aids and wireless speakers. I've also heard of video in the automotive industry (forget which company at the moment). Encryption and signal processing are obvious candidates. E.g. anything streaming, but I'm not sure it ever was faster than other technologies. DaR
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 10:57 -0700 |
| Message-ID | <30cf1905-0348-450c-9b8d-172dcd9515db@googlegroups.com> |
| In reply to | #41631 |
A pipelined Mandelbrot :-) Not really a real-world application but something I'd love to write. With an external oscillator for frequency stability, you should be able to dedicated two nodes for display timing, another one control and one (or more) acting as a fifo. The remaining nodes each calculate one iteration of a mandelbrot set. Each node would take the result from the previous one, perform an iteration and pass on the result to the next one until it ends up in the fifo. You'd be able to fill / catch-up during hblank and vblank.. Not a real-world example but it's something I'd want to do if I had a GA144 :-) -Y
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 14:17 -0400 |
| Message-ID | <ms7ebp$at2$1@dont-email.me> |
| In reply to | #41660 |
On 9/2/2015 1:57 PM, Mux wrote: > A pipelined Mandelbrot :-) > > Not really a real-world application but something I'd love to write. > With an external oscillator for frequency stability, you should be > able to dedicated two nodes for display timing, another one control > and one (or more) acting as a fifo. The remaining nodes each > calculate one iteration of a mandelbrot set. Each node would take the > result from the previous one, perform an iteration and pass on the > result to the next one until it ends up in the fifo. You'd be able to > fill / catch-up during hblank and vblank.. > > Not a real-world example but it's something I'd want to do if I had a > GA144 :-) There are any number of toy applications. I suppose you can generate your own display from the GA144, so a "real time" Mandelbrot set display might work ok. Otherwise it is hard to get the data out of the GA144. There is some irony to the DIY attitude shown by this device. It is so incestuous that even the high speed link will only work with other GA144s to the best of my knowledge. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 11:28 -0700 |
| Message-ID | <e08e5d41-ff05-47cd-bd85-04eb866a9275@googlegroups.com> |
| In reply to | #41662 |
It's a tricky subject. Aside from the fact that the status-quo won't go near anything that hasn't wide-spread support, the hardware side of things are a little too alien to designers to leverage it. For example, had it ran at 3.3v or at least have VCCIO at 3.3v, interfacing it would have been a lot easier. Likewise if there was a TQFP package version, I'd have picked them up a lot sooner. The other fact is that 'the competition' is established, has a great support community behind it and this makes the GA fall into this weird category where yes, it's got a lot of power but it's a bitch to utilize. With zero marketing, intuitive / user-friendly tools and a KISS approach that *might* have gone a little too far I'm unfortunately afraid there's little hope. Would there be any defense applications that could benefit from it? I'm guessing Chuck kinda banked on that sector or similar. -Y
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-09-02 13:41 -0700 |
| Message-ID | <ad31a317-8f95-44a3-bd9e-6b48527bc789@googlegroups.com> |
| In reply to | #41663 |
On Wednesday, September 2, 2015 at 11:28:28 AM UTC-7, Mux wrote: > Would there be any defense applications that could benefit from it? I'm guessing Chuck kinda banked on that sector or similar. When I first heard about the GA144, I assumed that it was for encryption-cracking. That is the only application that I know of that involves doing a lot of calculations that are independent of each other (trying out different keys) --- most applications that involve a lot of calculation don't lend themselves to parallel processing because each calculation depends upon the results of a previous calculation. Also, there is the game of Go that is quite difficult. This is similar to encryption-cracking except that instead of trying out different keys, you would be trying out different points on the board to play your stone. I remember a long time ago in "Circuit Cellar Ink." there was a neural-network project described that used hundreds of boards connected together --- I think they were 8080 processors, or something similar --- that would be an another interesting project for the GA144.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 16:50 -0400 |
| Message-ID | <ms7nau$f4d$1@dont-email.me> |
| In reply to | #41663 |
On 9/2/2015 2:28 PM, Mux wrote: > It's a tricky subject. Aside from the fact that the status-quo won't > go near anything that hasn't wide-spread support, the hardware side > of things are a little too alien to designers to leverage it. > > For example, had it ran at 3.3v or at least have VCCIO at 3.3v, > interfacing it would have been a lot easier. Likewise if there was a > TQFP package version, I'd have picked them up a lot sooner. The other > fact is that 'the competition' is established, has a great support > community behind it and this makes the GA fall into this weird > category where yes, it's got a lot of power but it's a bitch to > utilize. With zero marketing, intuitive / user-friendly tools and a > KISS approach that *might* have gone a little too far I'm > unfortunately afraid there's little hope. > > Would there be any defense applications that could benefit from it? > I'm guessing Chuck kinda banked on that sector or similar. I can't begin to figure out what Chuck was thinking would be good applications for this device, but I have followed his blog enough to believe the real possibility that he didn't plan on any specific applications at all. The closest thing to an intended app might be the home theater apps he worked on for ITV. That at least would have been in the back of his mind as he moved forward with this. But in reality I think, as someone else said long ago, Chuck doesn't develop products as much as technology. He thinkers with ideas and the GA144 is the expression of some ideas. It lacks a great deal and suffers from its uniqueness, but it is the missing bits that I think hamper it the most. I have given this a lot of thought and I can't see an easy fix to the issues. BTW, the package is the least of its problems. I think that package is a great compromise between easy prototyping and small size for small designs. There isn't much call for low power devices in larger packages. Just ask the FPGA guys. There are some low power FPGAs out there, but not much in remotely prototyping friendly packages. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 15:03 -0700 |
| Message-ID | <d8ff911c-ba3c-4c65-8769-dd571aef4285@googlegroups.com> |
| In reply to | #41667 |
How about audio synthesis? Given the shear amount of nodes you should be able to generate waveforms pretty easily. Each node / group of nodes could be configured as a simple / complex generator, maybe similar to FM or otherwise just simple square / sine / etc. waveforms. Given that you have on-chip DAC's it could be a really nifty synth.. Adding a software UART and adding some level-converters and an amp you could have a pretty decent audio device :-) -Y
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 18:18 -0400 |
| Message-ID | <ms7sg0$78f$1@dont-email.me> |
| In reply to | #41675 |
On 9/2/2015 6:03 PM, Mux wrote: > How about audio synthesis? Given the shear amount of nodes you should be able to generate waveforms pretty easily. Each node / group of nodes could be configured as a simple / complex generator, maybe similar to FM or otherwise just simple square / sine / etc. waveforms. > > Given that you have on-chip DAC's it could be a really nifty synth.. Adding a software UART and adding some level-converters and an amp you could have a pretty decent audio device :-) Did you read my post? Are you happy with 9 bit audio? The DACs need to be dithered to get higher resolution which reduces effective sample rate. I'm not sure what rates work at what resolutions with the GA144 DACs. I did a simple analysis of the ADCs and they won't convert 16 bit audio fast enough for 20 kHz bandwidth. I think you get a sample rate of around 30 kHz at 16 bits. This is why I mentioned that a large company would have provided sample apps to control the ADCs and DACs allowing users to know what to expect without ramping up the huge learning curve of these devices and trying it for themselves. If GA has such a sample app I missed it. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 16:14 -0700 |
| Message-ID | <5a1458c0-a2b6-4f63-8ea0-57b7f19aa41f@googlegroups.com> |
| In reply to | #41678 |
> Did you read my post? Are you happy with 9 bit audio? The DACs need to > be dithered to get higher resolution which reduces effective sample > rate. I'm not sure what rates work at what resolutions with the GA144 > DACs. I did a simple analysis of the ADCs and they won't convert 16 bit > audio fast enough for 20 kHz bandwidth. I think you get a sample rate > of around 30 kHz at 16 bits. > > This is why I mentioned that a large company would have provided sample > apps to control the ADCs and DACs allowing users to know what to expect > without ramping up the huge learning curve of these devices and trying > it for themselves. If GA has such a sample app I missed it. > > -- > > Rick Must have missed that bit... Yeah, that's not that great. Then again, you could always have an external DAC and use one of the outer nodes push data out. With that in mind though, hearing aids and wifi speakers surely can't be a good target then, no? -Y
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 20:40 -0400 |
| Message-ID | <ms84qf$vod$2@dont-email.me> |
| In reply to | #41679 |
On 9/2/2015 7:14 PM, Mux wrote: >> Did you read my post? Are you happy with 9 bit audio? The DACs need to >> be dithered to get higher resolution which reduces effective sample >> rate. I'm not sure what rates work at what resolutions with the GA144 >> DACs. I did a simple analysis of the ADCs and they won't convert 16 bit >> audio fast enough for 20 kHz bandwidth. I think you get a sample rate >> of around 30 kHz at 16 bits. >> >> This is why I mentioned that a large company would have provided sample >> apps to control the ADCs and DACs allowing users to know what to expect >> without ramping up the huge learning curve of these devices and trying >> it for themselves. If GA has such a sample app I missed it. >> >> -- >> >> Rick > > Must have missed that bit... Yeah, that's not that great. Then again, you could always have an external DAC and use one of the outer nodes push data out. With that in mind though, hearing aids and wifi speakers surely can't be a good target then, no? I think the dither thing can work ok. For a signal generator I would want good resolution at higher frequencies than the GA144 might be able to accomplish... although I'm not sure since I don't know what it will do really. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Greg <borota@gmail.com> |
|---|---|
| Date | 2015-09-02 17:53 -0700 |
| Message-ID | <34f1f225-c6e9-47e7-91cb-ba225d5d9bca@googlegroups.com> |
| In reply to | #41679 |
On Wednesday, September 2, 2015 at 6:14:07 PM UTC-5, Mux wrote: > > Did you read my post? Are you happy with 9 bit audio? The DACs need to > > be dithered to get higher resolution which reduces effective sample > > rate. I'm not sure what rates work at what resolutions with the GA144 > > DACs. I did a simple analysis of the ADCs and they won't convert 16 bit > > audio fast enough for 20 kHz bandwidth. I think you get a sample rate > > of around 30 kHz at 16 bits. > > > > This is why I mentioned that a large company would have provided sample > > apps to control the ADCs and DACs allowing users to know what to expect > > without ramping up the huge learning curve of these devices and trying > > it for themselves. If GA has such a sample app I missed it. > > > > -- > > > > Rick > > Must have missed that bit... Yeah, that's not that great. Then again, you could always have an external DAC and use one of the outer nodes push data out. With that in mind though, hearing aids and wifi speakers surely can't be a good target then, no? > > -Y In this interview: http://www.informit.com/articles/article.aspx?p=1193856 Donald Knuth says: "Let me put it this way: During the past 50 years, I've written well over a thousand programs, many of which have substantial size. I can't think of even five of those programs that would have been enhanced noticeably by parallelism or multi-threading." So maybe that's the problem, most programs that we write are sequential in nature. Or at least our brains have a harder time solving problems by slicing into small independent units and then assembling results together. At the same time, some very bright people have sometimes said pretty stupid things too. Maybe the future will prove Don wrong and we will all have had developed the required skills to solve problems using 144 or even thousands of cores efficiently.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-02 21:25 -0400 |
| Message-ID | <ms87ek$1gf$1@dont-email.me> |
| In reply to | #41685 |
On 9/2/2015 8:53 PM, Greg wrote: > In this interview: http://www.informit.com/articles/article.aspx?p=1193856 > Donald Knuth says: "Let me put it this way: During the past 50 years, I've > written well over a thousand programs, many of which have substantial size. > I can't think of even five of those programs that would have been enhanced > noticeably by parallelism or multi-threading." > > So maybe that's the problem, most programs that we write are sequential in > nature. Or at least our brains have a harder time solving problems by slicing > into small independent units and then assembling results together. > > At the same time, some very bright people have sometimes said pretty stupid > things too. Maybe the future will prove Don wrong and we will all have had > developed the required skills to solve problems using 144 or even thousands of cores efficiently. What about multiple programs running in parallel? That is very common on nearly every computer down to a lowly 8 bit PIC. It may not be done with a multitasking OS, but how many times have UART interfaces been done with interrupts? That is another task, or two actually, TX and RX. How about polling a push button? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Mux <Yvo.Zoer@gmail.com> |
|---|---|
| Date | 2015-09-02 22:28 -0700 |
| Message-ID | <4fbe28fa-b68b-42ca-92f5-b1606a52092b@googlegroups.com> |
| In reply to | #41685 |
> In this interview: http://www.informit.com/articles/article.aspx?p=1193856 > Donald Knuth says: "Let me put it this way: During the past 50 years, I've > written well over a thousand programs, many of which have substantial size. > I can't think of even five of those programs that would have been enhanced > noticeably by parallelism or multi-threading." > > So maybe that's the problem, most programs that we write are sequential in > nature. Or at least our brains have a harder time solving problems by slicing > into small independent units and then assembling results together. > > At the same time, some very bright people have sometimes said pretty stupid > things too. Maybe the future will prove Don wrong and we will all have had > developed the required skills to solve problems using 144 or even thousands of cores efficiently. I think the thing that's overlooked is that we're kinda up to the (economic) wall of Moore's law and the only way to improve performance is to go wide. So yeah, it's a lot harder to write programs that are spread out over a multitude of processors. At the same time, tools have improved as well. If you look GPU's, there's no chance in hell you would have been able to do that without parallelism / multiple cores in hell. I really, really like the premise of the GA144 but what it really needs, like so many other things, is a killer app or something that's a niche and can only be handled by a large number of cores.. -Y
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-09-02 22:53 -0700 |
| Message-ID | <87fv2wgia9.fsf@jester.gateway.sonic.net> |
| In reply to | #41685 |
Greg <borota@gmail.com> writes: > In this interview: http://www.informit.com/articles/article.aspx?p=1193856 > Donald Knuth says: "Let me put it this way: During the past 50 years, I've > written well over a thousand programs, many of which have substantial size. > I can't think of even five of those programs that would have been enhanced > noticeably by parallelism or multi-threading." To be fair, through most of Knuth's career, computer hardware was very expensive and almost all computers had single CPU's. So people didn't care about parallelism as much because they didn't have the hardware for it. There was also no giant Internet so people didn't care about concurrency as much. These days everyone doing anything significant has to think about parallelism. E.g. about half of TAOCP vol 3 is about munching large (for that era) datasets on tape drives connected to a single computer. These days those problems are many OOM bigger, and they're done on Hadoop clusters (or whatever) across 1000's of nodes in a data center.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-09-03 11:32 -0400 |
| Message-ID | <ms9p2g$8t0$2@dont-email.me> |
| In reply to | #41689 |
On 9/3/2015 1:53 AM, Paul Rubin wrote: > Greg <borota@gmail.com> writes: >> In this interview: http://www.informit.com/articles/article.aspx?p=1193856 >> Donald Knuth says: "Let me put it this way: During the past 50 years, I've >> written well over a thousand programs, many of which have substantial size. >> I can't think of even five of those programs that would have been enhanced >> noticeably by parallelism or multi-threading." > > To be fair, through most of Knuth's career, computer hardware was very > expensive and almost all computers had single CPU's. So people didn't > care about parallelism as much because they didn't have the hardware for > it. There was also no giant Internet so people didn't care about > concurrency as much. These days everyone doing anything significant has > to think about parallelism. E.g. about half of TAOCP vol 3 is about > munching large (for that era) datasets on tape drives connected to a > single computer. These days those problems are many OOM bigger, and > they're done on Hadoop clusters (or whatever) across 1000's of nodes in > a data center. What you say is true. Much of what we currently do when designing systems is based on the idea that a CPU is the expensive part of the computer and all else is intended to optimize its use. But I recall an early machine that had 64 compute heads. I don't recall the name, but it may have been Eniac. I think it had 64 ALUs with SIMD. Not the same thing as multiple CPUs, but they were thinking about parallelism even very early on. So obviously there were one of two problems with it. Either it was very hard to do (programming) or it didn't give much improvement to most programming problems. Likely both. But with today's multitasking OSs running on big iron, I can't see how having hundreds of processors wouldn't be useful. Now the bottle neck is in memory access. Even at the low end the use of simple CPUs with lots of performance and extremely low cost per unit has its advantages. Before we see that being used much, it will take a lot of other work to deal with the two problems discovered some 60 years ago. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-09-03 11:57 -0700 |
| Message-ID | <87bndjgwlc.fsf@jester.gateway.sonic.net> |
| In reply to | #41698 |
rickman <gnuarm@gmail.com> writes: > But I recall an early machine that had 64 compute heads. I don't > recall the name, but it may have been Eniac. You probably mean ILLIAC IV. It was an array processor built in the 1960's, but it was a unique, specialized academic research machine, that most programmers wouldn't have thought about. > But with today's multitasking OSs running on big iron, I can't see how > having hundreds of processors wouldn't be useful. Now the bottle neck > is in memory access. Actually graphics cards now have 100's of processors with local memory, and consumer laptop cpu's have graphics extensions with dozens of processors. I forgot about those entirely. And there is the Xeon Phi with 60 or so Pentium-like cores. Big-data parallelism though is done mostly with networks of PC-like computers in a data center.
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web