Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54229 > unrolled thread
| Started by | Dale Scott <dalescottnet@gmail.com> |
|---|---|
| First post | 2017-01-21 11:27 -0800 |
| Last post | 2017-01-23 18:46 -0300 |
| Articles | 20 on this page of 138 — 21 participants |
Back to article view | Back to comp.lang.forth
embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-21 11:27 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-21 11:31 -0800
Re: embedded forth stephen@mpeforth.com - 2017-01-22 00:52 -0800
Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-22 17:09 +0000
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 09:43 -0800
Re: embedded Forth stephen@mpeforth.com - 2017-01-22 12:19 -0800
Re: embedded Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-22 21:25 +0100
Re: embedded Forth john <anon@example.com> - 2017-01-22 21:04 +0000
Re: embedded Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-01-22 12:30 -1000
Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 20:45 -0800
Re: embedded Forth stephen@mpeforth.com - 2017-01-22 14:08 -0800
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 14:55 -0800
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 20:41 -0800
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 21:19 -0800
Re: embedded Forth hughaguilar96@gmail.com - 2017-01-22 21:36 -0800
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:09 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 04:15 -0500
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 08:41 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 14:32 -0500
Re: embedded Forth Dale Scott <dalescottnet@gmail.com> - 2017-01-23 11:53 -0800
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 15:10 -0500
Re: embedded Forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 14:34 -0800
Re: embedded Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-24 03:14 -0600
Re: embedded Forth rickman <gnuarm@gmail.com> - 2017-01-23 03:43 -0500
Re: embedded Forth john <anon@example.com> - 2017-01-23 10:32 +0000
keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 08:58 -0300
Re: keep secrets (was Re: embedded Forth) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-01-23 07:47 -0500
Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:18 -0300
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:15 -0500
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 14:38 -0500
Re: keep secrets (was Re: embedded Forth) "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:43 -0300
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 19:48 -0500
Re: keep secrets (was Re: embedded Forth) "Elizabeth D. Rather" <erather@forth.com> - 2017-01-23 16:30 -1000
Re: keep secrets (was Re: embedded Forth) rickman <gnuarm@gmail.com> - 2017-01-23 22:23 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-22 13:44 -0500
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-22 13:38 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 00:45 -0500
Re: embedded forth Dale Scott <dalescottnet@gmail.com> - 2017-01-22 22:44 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-23 00:48 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 03:51 -0500
Re: embedded forth john <anon@example.com> - 2017-01-23 10:02 +0000
Re: embedded forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-23 09:01 +0000
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-23 13:05 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-23 14:40 -0500
Re: embedded forth Mark Wills <markwills1970@gmail.com> - 2017-01-24 01:12 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-24 14:38 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-24 19:51 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-25 11:34 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-25 22:13 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-26 11:36 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:07 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-26 00:19 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-26 14:15 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 13:08 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 17:54 -0500
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-27 15:29 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-27 16:28 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-27 23:58 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 11:58 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 15:36 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-28 15:05 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-28 15:57 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 09:53 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-29 19:32 +0100
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:53 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 01:10 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 23:11 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-29 23:34 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:42 +0100
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-30 12:36 +0100
Re: embedded forth ctmalan@gmail.com - 2017-01-30 11:02 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 11:04 -0800
Re: embedded forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-01-31 04:34 -0600
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:15 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 10:15 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 12:20 -0800
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 14:09 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-31 03:04 +0100
Re: embedded forth Paul Rubin <no.email@nospam.invalid> - 2017-01-30 20:19 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 17:10 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-30 14:38 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-30 23:09 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-31 09:32 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 18:22 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:46 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:11 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 01:30 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-12 10:21 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-12 19:37 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-14 13:26 -0800
Re: embedded forth Gary Bergstrom <forthprgrmr@gmail.com> - 2017-02-14 11:36 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-14 18:13 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 21:51 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 10:20 -0800
Re: embedded forth Cecil Bayona <cbayona@cbayona.com> - 2017-01-29 12:38 -0600
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-01-29 11:49 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-04 04:22 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-04 17:54 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-04 20:26 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-05 07:53 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:08 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 11:39 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 06:46 -0800
Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-13 19:17 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 06:23 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-15 11:09 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-15 15:24 -0800
Re: embedded forth jkn_gg@nicorp.f9.co.uk - 2017-02-16 09:49 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 09:12 -0800
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-17 12:47 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-17 16:18 -0800
Re: embedded forth luser droog <mijoryx@yahoo.com> - 2017-02-16 08:43 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 20:47 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 13:36 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-05 23:18 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:10 -0800
Re: embedded forth Alex <alex@rivadpm.com> - 2017-02-06 11:12 +0000
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 21:15 -0800
Re: embedded forth hughaguilar96@gmail.com - 2017-02-05 22:45 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-06 12:04 +0100
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 03:08 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 06:39 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-08 07:15 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-08 15:49 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 01:14 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-09 05:19 -0500
Re: embedded forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-09 03:48 -0800
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-05 16:08 -0500
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-02-07 21:59 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 11:10 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 06:15 -0500
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:48 +0100
Re: embedded forth rickman <gnuarm@gmail.com> - 2017-01-28 14:37 -0500
Re: embedded forth mhx@iae.nl - 2017-01-28 07:48 -0800
Re: embedded forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-01-28 19:53 +0100
Re: embedded forth mhx@iae.nl - 2017-01-28 15:49 -0800
Re: embedded forth "Wolfgang Allinger" <all2001@spambog.com> - 2017-01-23 18:46 -0300
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | john <anon@example.com> |
|---|---|
| Date | 2017-01-23 10:02 +0000 |
| Message-ID | <MPG.32efe52e835fd0969896e9@news.virginmedia.com> |
| In reply to | #54252 |
In article <87lgu2epwg.fsf@nightsong.com>, no.email@nospam.invalid says... > > rickman <gnuarm@gmail.com> writes: > > On 1/21/2017 2:27 PM, Dale Scott wrote: > >> It's being prototyped using the MSP432 launchpad platform > > I've worked with Mecrisp, but it was on an ARM based launchpad. > > The MSP432 is an ARM based line, whose name resembles the older 16-bit > MSP430 line, presumably to call attention to its low-power emphasis. > The MSP432 launchpad is a nice little board for $12.99 USD > > http://www.ti.com/tool/msp-exp432p401r > From the TI link above: "You can browse all documentation online with TI Resource Explorer and start development with the online CCS Cloud IDE." Presumably TI users have had their brains replaced by cauliflowers. -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-01-23 09:01 +0000 |
| Message-ID | <2017Jan23.100126@mips.complang.tuwien.ac.at> |
| In reply to | #54246 |
rickman <gnuarm@gmail.com> writes:
>I've worked with Mecrisp, but it was on an ARM based launchpad.
Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing
great?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-23 13:05 +0100 |
| Message-ID | <o64rhj$6sf$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54281 |
In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >rickman <gnuarm@gmail.com> writes: >>I've worked with Mecrisp, but it was on an ARM based launchpad. > >Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >great? What do you mean? The similarity with the name MSP430? I expect that many TI users use the same c-API's on the MSP430 and MSP432 to address the same peripherals. For them the peripherals and how to use them is more important then the underlying processor. There are already 20 bit MSP430, the noforth team is working on that. It is a crutch however for a 16 bit processor and it make sense for TI to migrate to 32 bits. A 50 Mhz MSP432 suggest that we will never see a fast (>100 Mhz) MSP430. :-( Forthers would like to see a 1000 Mhz 6809. That too has never happened. > >- anton -- 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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-23 14:40 -0500 |
| Message-ID | <o65m3r$asp$2@dont-email.me> |
| In reply to | #54297 |
On 1/23/2017 7:05 AM, Albert van der Horst wrote: > In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> rickman <gnuarm@gmail.com> writes: >>> I've worked with Mecrisp, but it was on an ARM based launchpad. >> >> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >> great? > > What do you mean? The similarity with the name MSP430? > I expect that many TI users use the same c-API's on the > MSP430 and MSP432 to address the same peripherals. > For them the peripherals and how to use them is more > important then the underlying processor. There are already > 20 bit MSP430, the noforth team is working on that. > It is a crutch however for a 16 bit processor and it make > sense for TI to migrate to 32 bits. > > A 50 Mhz MSP432 suggest that we will never see a fast > (>100 Mhz) MSP430. :-( What is the allure of a 100 MHz MSP430? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-01-24 01:12 -0800 |
| Message-ID | <5afa7925-2dd9-4670-8ff3-d452733cac77@googlegroups.com> |
| In reply to | #54313 |
On Monday, 23 January 2017 19:40:16 UTC, rickman wrote: > On 1/23/2017 7:05 AM, Albert van der Horst wrote: > > In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, > > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> rickman <gnuarm@gmail.com> writes: > >>> I've worked with Mecrisp, but it was on an ARM based launchpad. > >> > >> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing > >> great? > > > > What do you mean? The similarity with the name MSP430? > > I expect that many TI users use the same c-API's on the > > MSP430 and MSP432 to address the same peripherals. > > For them the peripherals and how to use them is more > > important then the underlying processor. There are already > > 20 bit MSP430, the noforth team is working on that. > > It is a crutch however for a 16 bit processor and it make > > sense for TI to migrate to 32 bits. > > > > A 50 Mhz MSP432 suggest that we will never see a fast > > (>100 Mhz) MSP430. :-( > > What is the allure of a 100 MHz MSP430? > > -- > > Rick C Indeed. At some point it makes sense to move over to a more capable platform. Moving over to ARM/32 bit has more advantages than just faster clocks. One reason for wanting to stick with MSP430 might be the instruction set if you're a native assembly programmer. In that case, you will have invested quite a lot of time in learning all the control registers and the instruction set, so there would be a natural tendency to want to stick with that, which is understandable. Unfortunately, us assembly language types are a dying breed. The *vast* majority (I'd wager more than 90%) of MSP430 programmers (and maybe more generally: microcontroller programmers) are programming in C or C++, so there's less of an impact on your software if your underlying CPU changes.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-24 14:38 +0100 |
| Message-ID | <o67ld7$dg5$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54313 |
In article <o65m3r$asp$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 1/23/2017 7:05 AM, Albert van der Horst wrote: >> In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, >> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> I've worked with Mecrisp, but it was on an ARM based launchpad. >>> >>> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >>> great? >> >> What do you mean? The similarity with the name MSP430? >> I expect that many TI users use the same c-API's on the >> MSP430 and MSP432 to address the same peripherals. >> For them the peripherals and how to use them is more >> important then the underlying processor. There are already >> 20 bit MSP430, the noforth team is working on that. >> It is a crutch however for a 16 bit processor and it make >> sense for TI to migrate to 32 bits. >> >> A 50 Mhz MSP432 suggest that we will never see a fast >> (>100 Mhz) MSP430. :-( > >What is the allure of a 100 MHz MSP430? My idea for a very low distortion sine generator is held back by MSP430 clock speed. It is almost a troll question as there are always more applications possible at higher speeds. I give you that if you really need fast processing, you also need really large memories, or you run out of data to process. If I want to OCR based on 1200 dpi 32 bit color pages, I want a run of the mill 8 core x86 with Gbyte and GHz . Groetjes Albert > >-- > >Rick C -- 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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-24 19:51 -0500 |
| Message-ID | <o68smu$otg$1@dont-email.me> |
| In reply to | #54356 |
On 1/24/2017 8:38 AM, Albert van der Horst wrote: > In article <o65m3r$asp$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 1/23/2017 7:05 AM, Albert van der Horst wrote: >>> In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, >>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>> rickman <gnuarm@gmail.com> writes: >>>>> I've worked with Mecrisp, but it was on an ARM based launchpad. >>>> >>>> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >>>> great? >>> >>> What do you mean? The similarity with the name MSP430? >>> I expect that many TI users use the same c-API's on the >>> MSP430 and MSP432 to address the same peripherals. >>> For them the peripherals and how to use them is more >>> important then the underlying processor. There are already >>> 20 bit MSP430, the noforth team is working on that. >>> It is a crutch however for a 16 bit processor and it make >>> sense for TI to migrate to 32 bits. >>> >>> A 50 Mhz MSP432 suggest that we will never see a fast >>> (>100 Mhz) MSP430. :-( >> >> What is the allure of a 100 MHz MSP430? > > My idea for a very low distortion sine generator is held back > by MSP430 clock speed. It is almost a troll question as > there are always more applications possible at higher speeds. So why can't you use a different processor that has more umpfff? I don't understand why it needs to be an MSP430. BTW, sine generation is *very* easy to do in a PLD and can be made to run *very* fast. I did some work on this a while back and a DDS in an FPGA can be made using multipliers instead of a large lookup table to minimize phase noise. In essence you can get any noise level in the digital logic that you require and generate samples at 100s of MHz. :) > I give you that if you really need fast processing, you > also need really large memories, or you run out of data > to process. If I want to OCR based on 1200 dpi 32 bit > color pages, I want a run of the mill 8 core x86 with > Gbyte and GHz . I don't agree. For a given application more data may be desirable, but there are always apps that need more crunching on the same data set. For example, I worked on test equipment that did performance testing on comms. We needed to up the data rate by about 4 fold... and in the same FPGA! Our *only* technical problem in this was speed. The amount of data being processed was essentially the same. If the unit had the required interface we likely would have been asked to up it 4 fold again, and be told to stuff it! lol They had another product for that which used a newer and faster... and larger FPGA. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-25 11:34 +0100 |
| Message-ID | <o69uur$kmr$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54371 |
In article <o68smu$otg$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 1/24/2017 8:38 AM, Albert van der Horst wrote: >> In article <o65m3r$asp$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>> On 1/23/2017 7:05 AM, Albert van der Horst wrote: >>>> In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, >>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>> rickman <gnuarm@gmail.com> writes: >>>>>> I've worked with Mecrisp, but it was on an ARM based launchpad. >>>>> >>>>> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >>>>> great? >>>> >>>> What do you mean? The similarity with the name MSP430? >>>> I expect that many TI users use the same c-API's on the >>>> MSP430 and MSP432 to address the same peripherals. >>>> For them the peripherals and how to use them is more >>>> important then the underlying processor. There are already >>>> 20 bit MSP430, the noforth team is working on that. >>>> It is a crutch however for a 16 bit processor and it make >>>> sense for TI to migrate to 32 bits. >>>> >>>> A 50 Mhz MSP432 suggest that we will never see a fast >>>> (>100 Mhz) MSP430. :-( >>> >>> What is the allure of a 100 MHz MSP430? >> >> My idea for a very low distortion sine generator is held back >> by MSP430 clock speed. It is almost a troll question as >> there are always more applications possible at higher speeds. > >So why can't you use a different processor that has more umpfff? I >don't understand why it needs to be an MSP430. I know the msp430 inside out. A sine generator would be an experimental project. I don't want to learn a new processor for doing that. > >BTW, sine generation is *very* easy to do in a PLD and can be made to >run *very* fast. I did some work on this a while back and a DDS in an >FPGA can be made using multipliers instead of a large lookup table to >minimize phase noise. In essence you can get any noise level in the >digital logic that you require and generate samples at 100s of MHz. :) That looks like the opposite of my idea, not simple, not elegant, expensive and a lot of work. <SNIP> > >-- > >Rick C 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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-25 22:13 -0500 |
| Message-ID | <o6bpd0$gge$1@dont-email.me> |
| In reply to | #54385 |
On 1/25/2017 5:34 AM, Albert van der Horst wrote: > In article <o68smu$otg$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 1/24/2017 8:38 AM, Albert van der Horst wrote: >>> In article <o65m3r$asp$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>>> On 1/23/2017 7:05 AM, Albert van der Horst wrote: >>>>> In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, >>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>> rickman <gnuarm@gmail.com> writes: >>>>>>> I've worked with Mecrisp, but it was on an ARM based launchpad. >>>>>> >>>>>> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >>>>>> great? >>>>> >>>>> What do you mean? The similarity with the name MSP430? >>>>> I expect that many TI users use the same c-API's on the >>>>> MSP430 and MSP432 to address the same peripherals. >>>>> For them the peripherals and how to use them is more >>>>> important then the underlying processor. There are already >>>>> 20 bit MSP430, the noforth team is working on that. >>>>> It is a crutch however for a 16 bit processor and it make >>>>> sense for TI to migrate to 32 bits. >>>>> >>>>> A 50 Mhz MSP432 suggest that we will never see a fast >>>>> (>100 Mhz) MSP430. :-( >>>> >>>> What is the allure of a 100 MHz MSP430? >>> >>> My idea for a very low distortion sine generator is held back >>> by MSP430 clock speed. It is almost a troll question as >>> there are always more applications possible at higher speeds. >> >> So why can't you use a different processor that has more umpfff? I >> don't understand why it needs to be an MSP430. > > I know the msp430 inside out. A sine generator would be an experimental > project. I don't want to learn a new processor for doing that. > >> >> BTW, sine generation is *very* easy to do in a PLD and can be made to >> run *very* fast. I did some work on this a while back and a DDS in an >> FPGA can be made using multipliers instead of a large lookup table to >> minimize phase noise. In essence you can get any noise level in the >> digital logic that you require and generate samples at 100s of MHz. :) > > That looks like the opposite of my idea, not simple, not elegant, > expensive and a lot of work. My initial reply to this must have been lost by a glitch in my newsgroup server. To make it simple... If you don't understand my approach (which it would seem you don't if you think it is not simple, elegant and is expensive), I'm happy to explain it in more detail. I just don't feel like retyping it at the moment. I have other typing to do. What is your approach? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-01-26 11:36 +0100 |
| Message-ID | <o6cjff$t2l$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54406 |
In article <o6bpd0$gge$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >On 1/25/2017 5:34 AM, Albert van der Horst wrote: >> In article <o68smu$otg$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>> On 1/24/2017 8:38 AM, Albert van der Horst wrote: >>>> In article <o65m3r$asp$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>>>> On 1/23/2017 7:05 AM, Albert van der Horst wrote: >>>>>> In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, >>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>>> rickman <gnuarm@gmail.com> writes: >>>>>>>> I've worked with Mecrisp, but it was on an ARM based launchpad. >>>>>>> >>>>>>> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >>>>>>> great? >>>>>> >>>>>> What do you mean? The similarity with the name MSP430? >>>>>> I expect that many TI users use the same c-API's on the >>>>>> MSP430 and MSP432 to address the same peripherals. >>>>>> For them the peripherals and how to use them is more >>>>>> important then the underlying processor. There are already >>>>>> 20 bit MSP430, the noforth team is working on that. >>>>>> It is a crutch however for a 16 bit processor and it make >>>>>> sense for TI to migrate to 32 bits. >>>>>> >>>>>> A 50 Mhz MSP432 suggest that we will never see a fast >>>>>> (>100 Mhz) MSP430. :-( >>>>> >>>>> What is the allure of a 100 MHz MSP430? >>>> >>>> My idea for a very low distortion sine generator is held back >>>> by MSP430 clock speed. It is almost a troll question as >>>> there are always more applications possible at higher speeds. >>> >>> So why can't you use a different processor that has more umpfff? I >>> don't understand why it needs to be an MSP430. >> >> I know the msp430 inside out. A sine generator would be an experimental >> project. I don't want to learn a new processor for doing that. >> >>> >>> BTW, sine generation is *very* easy to do in a PLD and can be made to >>> run *very* fast. I did some work on this a while back and a DDS in an >>> FPGA can be made using multipliers instead of a large lookup table to >>> minimize phase noise. In essence you can get any noise level in the >>> digital logic that you require and generate samples at 100s of MHz. :) >> >> That looks like the opposite of my idea, not simple, not elegant, >> expensive and a lot of work. > >My initial reply to this must have been lost by a glitch in my newsgroup >server. To make it simple... > >If you don't understand my approach (which it would seem you don't if >you think it is not simple, elegant and is expensive), I'm happy to >explain it in more detail. I just don't feel like retyping it at the >moment. I have other typing to do. In my book your approach is not simple by the fact that it uses a PLD and I don't even know what that is. > >What is your approach? Potentially silly and potentially patentable. > >-- > >Rick C 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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-26 14:07 -0500 |
| Message-ID | <o6dhb9$i7j$1@dont-email.me> |
| In reply to | #54416 |
On 1/26/2017 5:36 AM, Albert van der Horst wrote: > In article <o6bpd0$gge$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >> On 1/25/2017 5:34 AM, Albert van der Horst wrote: >>> In article <o68smu$otg$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>>> On 1/24/2017 8:38 AM, Albert van der Horst wrote: >>>>> In article <o65m3r$asp$2@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >>>>>> On 1/23/2017 7:05 AM, Albert van der Horst wrote: >>>>>>> In article <2017Jan23.100126@mips.complang.tuwien.ac.at>, >>>>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>>>>>> rickman <gnuarm@gmail.com> writes: >>>>>>>>> I've worked with Mecrisp, but it was on an ARM based launchpad. >>>>>>>> >>>>>>>> Despite its name, MSP432 has an ARM Cortex-M4 CPU. Isn't marketing >>>>>>>> great? >>>>>>> >>>>>>> What do you mean? The similarity with the name MSP430? >>>>>>> I expect that many TI users use the same c-API's on the >>>>>>> MSP430 and MSP432 to address the same peripherals. >>>>>>> For them the peripherals and how to use them is more >>>>>>> important then the underlying processor. There are already >>>>>>> 20 bit MSP430, the noforth team is working on that. >>>>>>> It is a crutch however for a 16 bit processor and it make >>>>>>> sense for TI to migrate to 32 bits. >>>>>>> >>>>>>> A 50 Mhz MSP432 suggest that we will never see a fast >>>>>>> (>100 Mhz) MSP430. :-( >>>>>> >>>>>> What is the allure of a 100 MHz MSP430? >>>>> >>>>> My idea for a very low distortion sine generator is held back >>>>> by MSP430 clock speed. It is almost a troll question as >>>>> there are always more applications possible at higher speeds. >>>> >>>> So why can't you use a different processor that has more umpfff? I >>>> don't understand why it needs to be an MSP430. >>> >>> I know the msp430 inside out. A sine generator would be an experimental >>> project. I don't want to learn a new processor for doing that. >>> >>>> >>>> BTW, sine generation is *very* easy to do in a PLD and can be made to >>>> run *very* fast. I did some work on this a while back and a DDS in an >>>> FPGA can be made using multipliers instead of a large lookup table to >>>> minimize phase noise. In essence you can get any noise level in the >>>> digital logic that you require and generate samples at 100s of MHz. :) >>> >>> That looks like the opposite of my idea, not simple, not elegant, >>> expensive and a lot of work. >> >> My initial reply to this must have been lost by a glitch in my newsgroup >> server. To make it simple... >> >> If you don't understand my approach (which it would seem you don't if >> you think it is not simple, elegant and is expensive), I'm happy to >> explain it in more detail. I just don't feel like retyping it at the >> moment. I have other typing to do. > > In my book your approach is not simple by the fact that it uses > a PLD and I don't even know what that is. Ah, that explains a lot. Programmable Logic Device. In my use I am referring specifically to FPGAs (Field Programmable Logic Arrays, my area of specialty) which allow you to design with hardware rather than software. In essence when you design PLD hardware, it all runs 100% of the time (so can achieve humongous speeds) while when writing software for sequential processors each step is done one at a time by a single execution unit (typically with MCUs anyway, otherwise some small number of execution units) which greatly limits the overall speed. If sequential execution at the CPU clock speed is good enough, fine. But you seem to be saying your processor is not fast enough. That simple fact alone makes me think your algorithm is rather more complex than other methods. Unless you are creating RF sine waves with high speed DACs, any MCU would be fast enough to generate an optimum sine wave at the sample rates the on chip DAC would support. >> What is your approach? > > Potentially silly and potentially patentable. Ok. What noise level do you expect to achive? What sort of DAC will you be using? I will say, if you aren't aware of existing methods of sine wave generation, it is not likely your method will be better. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-26 00:19 -0800 |
| Message-ID | <423bc49f-f47d-415d-80d6-53fb0472c929@googlegroups.com> |
| In reply to | #54371 |
> BTW, sine generation is *very* easy to do in a PLD and can be made to > run *very* fast. I did some work on this a while back and a DDS in an > FPGA can be made using multipliers instead of a large lookup table to > minimize phase noise. In essence you can get any noise level in the > digital logic that you require and generate samples at 100s of MHz. :) You may take a look on CORDIC algorithm as well. It is another example of a module, not very effective for generic MCU, but perfect for FPGA. CORDIC IP-core can provide one bit of sin/cos per clock cycle (pipelining is allowed too), so it is possible to have 16 or 32-bit sine wave with 200+ MHz clock speed. No multipliers are needed.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-26 14:15 -0500 |
| Message-ID | <o6dhov$l5l$1@dont-email.me> |
| In reply to | #54411 |
On 1/26/2017 3:19 AM, Ilya Tarasov wrote: >> BTW, sine generation is *very* easy to do in a PLD and can be made to >> run *very* fast. I did some work on this a while back and a DDS in an >> FPGA can be made using multipliers instead of a large lookup table to >> minimize phase noise. In essence you can get any noise level in the >> digital logic that you require and generate samples at 100s of MHz. :) > > You may take a look on CORDIC algorithm as well. It is another example of a module, not very effective for generic MCU, but perfect for FPGA. CORDIC IP-core can provide one bit of sin/cos per clock cycle (pipelining is allowed too), so it is possible to have 16 or 32-bit sine wave with 200+ MHz clock speed. No multipliers are needed. When I see the claim of the CORDIC algorithm not needing multipliers I have to smile. No, technically the CORDIC algorithm does not need a single multiplier. But the algorithm performs an operation that is functionally equivalent to a multiply, N operations on N bit quantities which is order N**2 complexity. The difference is that multiplication is typically supported by hardware and is *very* fast while the CORDIC algorithm must be done step by step and so is much less efficient. In FPGAs with hard IP multipliers the CORDIC uses much more space than just using the hard IP. In software the CORDIC takes N steps where N is the number of bits and a multiply is often a single instruction. The CORDIC algorithm saw much more use a decades or two ago when dedicated multipliers were much less common. Now the CORDIC algorithm is typically used in niche applications where there is some limitation on using a multiplier. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-27 13:08 -0800 |
| Message-ID | <ef764024-296b-463c-b522-31366ded00da@googlegroups.com> |
| In reply to | #54438 |
четверг, 26 января 2017 г., 22:15:18 UTC+3 пользователь rickman написал: > On 1/26/2017 3:19 AM, Ilya Tarasov wrote: > >> BTW, sine generation is *very* easy to do in a PLD and can be made to > >> run *very* fast. I did some work on this a while back and a DDS in an > >> FPGA can be made using multipliers instead of a large lookup table to > >> minimize phase noise. In essence you can get any noise level in the > >> digital logic that you require and generate samples at 100s of MHz. :) > > > > You may take a look on CORDIC algorithm as well. It is another example of a module, not very effective for generic MCU, but perfect for FPGA. CORDIC IP-core can provide one bit of sin/cos per clock cycle (pipelining is allowed too), so it is possible to have 16 or 32-bit sine wave with 200+ MHz clock speed. No multipliers are needed. > > When I see the claim of the CORDIC algorithm not needing multipliers I > have to smile. No, technically the CORDIC algorithm does not need a > single multiplier. But the algorithm performs an operation that is The idea of CORDIC is to limit one of multiplication operands by the power of 2, so multiplier can be replaced by shifter. > functionally equivalent to a multiply, N operations on N bit quantities > which is order N**2 complexity. The difference is that multiplication > is typically supported by hardware and is *very* fast while the CORDIC > algorithm must be done step by step and so is much less efficient. In > FPGAs with hard IP multipliers the CORDIC uses much more space than just > using the hard IP. In software the CORDIC takes N steps where N is the > number of bits and a multiply is often a single instruction. Pipelined version require one cycle per output with N stages of pipeline. Size is N times larger, of course. > The CORDIC algorithm saw much more use a decades or two ago when > dedicated multipliers were much less common. Now the CORDIC algorithm > is typically used in niche applications where there is some limitation > on using a multiplier. For FPGA, there is a balance between cells, memory and multipliers. For DSP system, there DSP block are key components, it is likely you will count every DSP48 block and don't be able to spent some of them to sine wave generation. Logic cells may be free and CORDIC is a good solution in this case. If you know another effective algorithm with hardware multipliers and exact result (not approximated), please give me a link.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-27 17:54 -0500 |
| Message-ID | <o6gj07$ner$1@dont-email.me> |
| In reply to | #54468 |
On 1/27/2017 4:08 PM, Ilya Tarasov wrote: > четверг, 26 января 2017 г., 22:15:18 UTC+3 пользователь rickman > написал: >> On 1/26/2017 3:19 AM, Ilya Tarasov wrote: >>>> BTW, sine generation is *very* easy to do in a PLD and can be >>>> made to run *very* fast. I did some work on this a while back >>>> and a DDS in an FPGA can be made using multipliers instead of a >>>> large lookup table to minimize phase noise. In essence you can >>>> get any noise level in the digital logic that you require and >>>> generate samples at 100s of MHz. :) >>> >>> You may take a look on CORDIC algorithm as well. It is another >>> example of a module, not very effective for generic MCU, but >>> perfect for FPGA. CORDIC IP-core can provide one bit of sin/cos >>> per clock cycle (pipelining is allowed too), so it is possible to >>> have 16 or 32-bit sine wave with 200+ MHz clock speed. No >>> multipliers are needed. >> >> When I see the claim of the CORDIC algorithm not needing >> multipliers I have to smile. No, technically the CORDIC algorithm >> does not need a single multiplier. But the algorithm performs an >> operation that is > > The idea of CORDIC is to limit one of multiplication operands by the > power of 2, so multiplier can be replaced by shifter. Dig into the algorithm. It is iterative over the bits. Each operation is equivalent to the stepwise operations in a multiply. Not much difference. I don't have an implementation handy, so there may be some simplification, but I think a stepwise multiply is actually simpler. The difference is to calculate a sine calculation requires up to two multiplies if you want high resolution and minimum phase jitter. >> functionally equivalent to a multiply, N operations on N bit >> quantities which is order N**2 complexity. The difference is that >> multiplication is typically supported by hardware and is *very* >> fast while the CORDIC algorithm must be done step by step and so is >> much less efficient. In FPGAs with hard IP multipliers the CORDIC >> uses much more space than just using the hard IP. In software the >> CORDIC takes N steps where N is the number of bits and a multiply >> is often a single instruction. > > Pipelined version require one cycle per output with N stages of > pipeline. Size is N times larger, of course. Yep. Very similar to a multiplier. >> The CORDIC algorithm saw much more use a decades or two ago when >> dedicated multipliers were much less common. Now the CORDIC >> algorithm is typically used in niche applications where there is >> some limitation on using a multiplier. > > For FPGA, there is a balance between cells, memory and multipliers. > For DSP system, there DSP block are key components, it is likely you > will count every DSP48 block and don't be able to spent some of them > to sine wave generation. Logic cells may be free and CORDIC is a good > solution in this case. Multipliers are function blocks like anything else. There are FPGAs with over 10,000 multipliers. Think those need to be rationed? Pick the chip that suits your needs. > If you know another effective algorithm with hardware multipliers and > exact result (not approximated), please give me a link. There's no such thing as "exact" digital trig solutions unless you have an infinitely long word. What do you mean by exact? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-01-27 15:29 -0800 |
| Message-ID | <87tw8knksp.fsf@nightsong.com> |
| In reply to | #54470 |
rickman <gnuarm@gmail.com> writes: > Multipliers are function blocks like anything else. There are FPGAs > with over 10,000 multipliers. Think those need to be rationed? Pick > the chip that suits your needs. Those exist, but are enormous and expensive :). > There's no such thing as "exact" digital trig solutions unless you > have an infinitely long word. What do you mean by exact? Exact would mean all the bits are correct, though typically an error of 1 ULP (unit in the last place) is ok.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-27 16:28 -0800 |
| Message-ID | <7f7415ad-9ba0-4d9a-ba9d-d08fad5c344e@googlegroups.com> |
| In reply to | #54470 |
> > The idea of CORDIC is to limit one of multiplication operands by the > > power of 2, so multiplier can be replaced by shifter. > > Dig into the algorithm. It is iterative over the bits. Each operation > is equivalent to the stepwise operations in a multiply. Not much > difference. I don't have an implementation handy, so there may be some > simplification, but I think a stepwise multiply is actually simpler. I think you slightly miss the interpretation. Yes, it based on vector rotating, represented by phase increment/decrement, which require a pair of multiplication. We can implement, for example sin(a+b) with sin table and multipliers, where a - coarse-grained angle, and b - fine-grained. With 1 and 0.01 degree step this gives us [0, 0.01, ... 89.99, 90] as an argument. CORDIC doing principally same thing, but rotating by angles with tangent is a power of 2. Mathematically this is a multiplication, but implementation can be done with shifs only. > The difference is to calculate a sine calculation requires up to two > multiplies if you want high resolution and minimum phase jitter. With CORDIC we can measure phase shift between Rubidium and Cesium atomic clocks :) They has about 1E-11 and 1E-14 precision respectively. Pure Forth system. > Multipliers are function blocks like anything else. There are FPGAs > with over 10,000 multipliers. Think those need to be rationed? Pick > the chip that suits your needs. Xilinx Virtex US+ - more than 12,000. Price is very high. DSP blocks started from 8 in Spartan-6LX4. When designer choose an FPGA, it is not so good to have twice a size just for implementing function generators coupled with MAC blocks. > > If you know another effective algorithm with hardware multipliers and > > exact result (not approximated), please give me a link. > > There's no such thing as "exact" digital trig solutions unless you have > an infinitely long word. What do you mean by exact? All bits, up to least significant, are true. For example, Taylor series don't provide this property.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-27 23:58 -0500 |
| Message-ID | <o6h8a0$6ns$1@dont-email.me> |
| In reply to | #54474 |
On 1/27/2017 7:28 PM, Ilya Tarasov wrote: >>> The idea of CORDIC is to limit one of multiplication operands by >>> the power of 2, so multiplier can be replaced by shifter. >> >> Dig into the algorithm. It is iterative over the bits. Each >> operation is equivalent to the stepwise operations in a multiply. >> Not much difference. I don't have an implementation handy, so >> there may be some simplification, but I think a stepwise multiply >> is actually simpler. > > I think you slightly miss the interpretation. Yes, it based on vector > rotating, represented by phase increment/decrement, which require a > pair of multiplication. We can implement, for example sin(a+b) with > sin table and multipliers, where a - coarse-grained angle, and b - > fine-grained. With 1 and 0.01 degree step this gives us [0, 0.01, ... > 89.99, 90] as an argument. CORDIC doing principally same thing, but > rotating by angles with tangent is a power of 2. Mathematically this > is a multiplication, but implementation can be done with shifs only. What you aren't grasping is that what you call "shifts only" is virtually the same as multiplication. When you multiply two numbers examining one multiplier bit at a time, the product gets shifted each time and the multiplicand is conditionally added each time. Where is the difference? It was touted long and loud that the CORDIC was so much more efficient than a multiplier when in fact it is essentially the same thing. >> The difference is to calculate a sine calculation requires up to >> two multiplies if you want high resolution and minimum phase >> jitter. > > With CORDIC we can measure phase shift between Rubidium and Cesium > atomic clocks :) They has about 1E-11 and 1E-14 precision > respectively. Pure Forth system. > >> Multipliers are function blocks like anything else. There are >> FPGAs with over 10,000 multipliers. Think those need to be >> rationed? Pick the chip that suits your needs. > > Xilinx Virtex US+ - more than 12,000. Price is very high. DSP blocks > started from 8 in Spartan-6LX4. When designer choose an FPGA, it is > not so good to have twice a size just for implementing function > generators coupled with MAC blocks. Uh, it is seldom a chip is selected because of the multiplier. You have to be doing some serious math to burn all the multipliers. You ignore the large LUT count of a CORDIC done at speed. It is essentially order N^2 which is a *lot* of FPGA fabric. >>> If you know another effective algorithm with hardware multipliers >>> and exact result (not approximated), please give me a link. >> >> There's no such thing as "exact" digital trig solutions unless you >> have an infinitely long word. What do you mean by exact? > > All bits, up to least significant, are true. For example, Taylor > series don't provide this property. That is not a huge problem. Just look up sine generation using trig identities. If you want a lot of resolution you use multiplies. If you need less resolution a look up table will suffice. I recall a lot of work was done on this in the 70s when chips were much more limited and they needed to cut down the size of the calculations. CORDIC would have been way too much logic so they coded the trig lookups and multiplies as tables. Something like sin(a)cos(b) + cos(a)sin(b), where a would be the msbs of the phase and b is the lsbs. By using separate tables for the various trig portions with multiplies, you can get as much resolution as you desire. Two multiplies is nothing to get this solution and can run very fast. I evaluated this in a spread sheet and found that once you are working in the area of 18 bit resolution, the linear interpolations are virtually perfect because they are over such a short section. I was able to achieve over 100 dB of SNR with an 18 bit phase word. When using CORDIC, how do you change the frequency? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2017-01-28 11:58 -0800 |
| Message-ID | <efb05d34-e13b-47c0-8a0b-5075fcb43ca6@googlegroups.com> |
| In reply to | #54478 |
> > I think you slightly miss the interpretation. Yes, it based on vector > > rotating, represented by phase increment/decrement, which require a > > pair of multiplication. We can implement, for example sin(a+b) with > > sin table and multipliers, where a - coarse-grained angle, and b - > > fine-grained. With 1 and 0.01 degree step this gives us [0, 0.01, ... > > 89.99, 90] as an argument. CORDIC doing principally same thing, but > > rotating by angles with tangent is a power of 2. Mathematically this > > is a multiplication, but implementation can be done with shifs only. > > What you aren't grasping is that what you call "shifts only" is > virtually the same as multiplication. When you multiply two numbers > examining one multiplier bit at a time, the product gets shifted each > time and the multiplicand is conditionally added each time. Where is > the difference? The difference is only in amount of resources required for each kind of operations. Shifting costs virtually nothing. If you want to multiply by any operand, many shifters must be used with corresponding AND to calculate partial results, combining by adder tree. If you know multiplicand cannot contain '1' at certain positions, you don't need to calculate that results and adder tree will be simplier. CORDIC use an ultimate approach, where only one bit may be '1'. This is very similar to serial multiplier, when clock cycles are traded for area. So you have two ultimate implementation of N-bit CORDIC - N cycles for result with small area or *N area with 1 cycle. > It was touted long and loud that the CORDIC was so much more efficient > than a multiplier when in fact it is essentially the same thing. Of course, it is not a magic, just a rational way to rotate angle, friendly to silicon resorces. > Uh, it is seldom a chip is selected because of the multiplier. You have > to be doing some serious math to burn all the multipliers. You ignore > the large LUT count of a CORDIC done at speed. It is essentially order > N^2 which is a *lot* of FPGA fabric. You may refer to this document https://www.xilinx.com/support/documentation/ip_documentation/ru/cordic.html This is not too much resources for serious system. For example, 32-bit sin/cos use 403 LUTs in word serial and 3411 in parallel mode. For Kintex-7, the ratio of LUT/DSP is about 200-300. And yes, math in FPGA can be serious :) > That is not a huge problem. Just look up sine generation using trig > identities. If you want a lot of resolution you use multiplies. If you > need less resolution a look up table will suffice. I recall a lot of > work was done on this in the 70s when chips were much more limited and > they needed to cut down the size of the calculations. CORDIC would have > been way too much logic so they coded the trig lookups and multiplies as > tables. Something like sin(a)cos(b) + cos(a)sin(b), where a would be > the msbs of the phase and b is the lsbs. By using separate tables for > the various trig portions with multiplies, you can get as much > resolution as you desire. Two multiplies is nothing to get this > solution and can run very fast. Oh, when I think I know what you are talking about. > I evaluated this in a spread sheet and found that once you are working > in the area of 18 bit resolution, the linear interpolations are > virtually perfect because they are over such a short section. I was > able to achieve over 100 dB of SNR with an 18 bit phase word. 120 dB is nice for us, 160-200 dB achieved in models, but we facing jitter and stability problems with quartz. Rubidium atomic clock is nice for such class of precision, and we can see a difference. > When using CORDIC, how do you change the frequency? Simplest way based on the wide phase accumulator and control the phase increment value. Also, you can change base frequency of overall DSP path in hardware using dynamic reconfiguration port in Clock Management Tile (I mean Xilinx chips).
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-01-28 15:36 -0500 |
| Message-ID | <o6iv9j$je6$1@dont-email.me> |
| In reply to | #54498 |
On 1/28/2017 2:58 PM, Ilya Tarasov wrote: > >>> I think you slightly miss the interpretation. Yes, it based on >>> vector rotating, represented by phase increment/decrement, which >>> require a pair of multiplication. We can implement, for example >>> sin(a+b) with sin table and multipliers, where a - coarse-grained >>> angle, and b - fine-grained. With 1 and 0.01 degree step this >>> gives us [0, 0.01, ... 89.99, 90] as an argument. CORDIC doing >>> principally same thing, but rotating by angles with tangent is a >>> power of 2. Mathematically this is a multiplication, but >>> implementation can be done with shifs only. >> >> What you aren't grasping is that what you call "shifts only" is >> virtually the same as multiplication. When you multiply two >> numbers examining one multiplier bit at a time, the product gets >> shifted each time and the multiplicand is conditionally added each >> time. Where is the difference? > > The difference is only in amount of resources required for each kind > of operations. Shifting costs virtually nothing. If you want to > multiply by any operand, many shifters must be used with > corresponding AND to calculate partial results, combining by adder > tree. If you know multiplicand cannot contain '1' at certain > positions, you don't need to calculate that results and adder tree > will be simplier. CORDIC use an ultimate approach, where only one bit > may be '1'. This is very similar to serial multiplier, when clock > cycles are traded for area. So you have two ultimate implementation > of N-bit CORDIC - N cycles for result with small area or *N area with > 1 cycle. I think you are still not getting it, but I can't tell for sure. The point is that either the CORDIC or a multiplier uses pretty much the same resources if designed in the fabric. Don't focus on one insignificant part (the shifting which is always free in an FPGA). What is important is what is done with the data after it is shifted. Both the multiplier and the CORDIC can be done time sequentially using logic for one layer of operation or can be pipelined with N layers of logic and registers producing a result on every clock cycle. >> It was touted long and loud that the CORDIC was so much more >> efficient than a multiplier when in fact it is essentially the same >> thing. > > Of course, it is not a magic, just a rational way to rotate angle, > friendly to silicon resorces. > >> Uh, it is seldom a chip is selected because of the multiplier. You >> have to be doing some serious math to burn all the multipliers. >> You ignore the large LUT count of a CORDIC done at speed. It is >> essentially order N^2 which is a *lot* of FPGA fabric. > > You may refer to this document > https://www.xilinx.com/support/documentation/ip_documentation/ru/cordic.html > This is not too much resources for serious system. For example, > 32-bit sin/cos use 403 LUTs in word serial and 3411 in parallel mode. > For Kintex-7, the ratio of LUT/DSP is about 200-300. That is a pretty large usage. I can do the same thing using a handful of multipliers. In 403 LUTs I can build a CPU. In 3400 LUTs I can build a RISC pipelined CPU with advanced features. The FPGAs I use in a product that generate sine waves (among other things) has a total of 3000 LUTs. Of course it only runs at 8 ksps and these are 16 bit samples. > And yes, math in FPGA can be serious :) > >> That is not a huge problem. Just look up sine generation using >> trig identities. If you want a lot of resolution you use >> multiplies. If you need less resolution a look up table will >> suffice. I recall a lot of work was done on this in the 70s when >> chips were much more limited and they needed to cut down the size >> of the calculations. CORDIC would have been way too much logic so >> they coded the trig lookups and multiplies as tables. Something >> like sin(a)cos(b) + cos(a)sin(b), where a would be the msbs of the >> phase and b is the lsbs. By using separate tables for the various >> trig portions with multiplies, you can get as much resolution as >> you desire. Two multiplies is nothing to get this solution and can >> run very fast. > > Oh, when I think I know what you are talking about. > >> I evaluated this in a spread sheet and found that once you are >> working in the area of 18 bit resolution, the linear interpolations >> are virtually perfect because they are over such a short section. >> I was able to achieve over 100 dB of SNR with an 18 bit phase >> word. > > 120 dB is nice for us, 160-200 dB achieved in models, but we facing > jitter and stability problems with quartz. Rubidium atomic clock is > nice for such class of precision, and we can see a difference. > >> When using CORDIC, how do you change the frequency? > > Simplest way based on the wide phase accumulator and control the > phase increment value. Also, you can change base frequency of overall > DSP path in hardware using dynamic reconfiguration port in Clock > Management Tile (I mean Xilinx chips). That sounds like any other DDS. You either change the phase step or change the reference frequency. So the phase step size can be changed on the fly for frequency modulation? -- Rick C
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web