Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #18710 > unrolled thread
| Started by | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| First post | 2013-01-13 06:37 +0000 |
| Last post | 2013-01-13 12:44 +0000 |
| Articles | 20 on this page of 100 — 35 participants |
Back to article view | Back to comp.lang.forth
Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 06:37 +0000
Re: Parallax Propeller MK <mk@nospam.co.uk> - 2013-01-13 10:26 +0000
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:22 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-13 07:24 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 13:55 +0000
Re: Parallax Propeller mhx@iae.nl (Marcel Hendrix) - 2013-01-13 17:13 +0200
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 06:23 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:01 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 09:12 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:36 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-16 10:59 -0600
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 23:38 +0000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-17 04:04 -0600
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-17 04:52 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:48 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:10 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:42 -0800
Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:05 -0500
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 08:41 -0600
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-05 10:21 -0800
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-05 21:37 +0100
Re: Parallax Propeller "Elizabeth D. Rather" <erather@forth.com> - 2013-02-05 10:44 -1000
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-05 15:52 -0600
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:29 -0800
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-06 00:31 -0800
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-06 19:46 +0100
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-02-09 00:11 -0800
Re: Parallax Propeller anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-09 10:25 +0000
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 18:26 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:07 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:49 -0800
Re: Parallax Propeller "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-05 06:04 -0500
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-05 15:21 -0800
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-16 18:09 -0500
Re: Parallax Propeller Ben Bradley <ben_u_bradley@etcmail.com> - 2013-01-18 21:07 -0500
Re: Parallax Propeller "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-01-19 10:06 +0000
Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-19 13:04 +0100
Re: Parallax Propeller "A. K." <akk@nospam.org> - 2013-01-19 13:22 +0100
Re: Parallax Propeller Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-19 13:38 +0100
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-19 17:12 +0100
Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-19 16:45 +0000
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 17:49 +0100
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 20:54 +0200
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 11:04 -0800
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-19 23:05 +0200
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-20 01:05 -0800
Re: Parallax Propeller Arlet Ottens <usenet+5@c-scape.nl> - 2013-01-20 12:11 +0100
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:53 +0200
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-20 13:26 +0200
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:23 -0600
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-19 14:18 -0600
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-20 20:32 +0100
Re: Parallax Propeller Les Cargill <lcargill99@comcast.com> - 2013-01-20 18:08 -0600
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 17:12 -0500
Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-20 19:19 -0500
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-20 21:12 -0500
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-21 09:01 +0100
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-21 21:11 -0500
Re: Parallax Propeller upsidedown@downunder.com - 2013-01-22 09:39 +0200
Re: Parallax Propeller Mel Wilson <mwilson@the-wire.com> - 2013-01-22 10:14 -0500
Re: Parallax Propeller Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2013-01-20 02:03 +0000
Re: Parallax Propeller George Neuner <gneuner2@comcast.net> - 2013-01-19 12:29 -0500
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:29 -0500
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-24 14:03 -0800
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-24 22:55 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-24 23:03 -0800
Re: Parallax Propeller Coos Haak <chforth@hccnet.nl> - 2013-01-25 20:02 +0100
Re: Parallax Propeller Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-01-28 17:13 -0800
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-29 09:15 +0100
Re: Parallax Propeller Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-01-30 12:19 +0000
Re: Parallax Propeller David Brown <david.brown@removethis.hesbynett.no> - 2013-01-30 21:18 +0100
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-30 22:57 -0800
Re: Parallax Propeller Alex McDonald <blog@rivadpm.com> - 2013-01-31 10:38 -0800
Re: Parallax Propeller Mark Wills <forthfreak@gmail.com> - 2013-01-31 12:34 -0800
Re: Parallax Propeller Paul Rubin <no.email@nospam.invalid> - 2013-01-19 10:42 -0800
Re: Parallax Propeller bob@bob.com - 2013-01-19 19:56 -0600
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-23 12:40 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-24 23:26 +0000
Re: Parallax Propeller Walter Banks <walter@bytecraft.com> - 2013-01-25 11:49 -0500
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-25 09:25 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-25 21:57 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-26 18:07 -0500
Re: Parallax Propeller Mark Wills <markrobertwills@yahoo.co.uk> - 2013-01-27 00:50 -0800
Re: Parallax Propeller Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-27 03:30 -0600
Re: Parallax Propeller Dombo <dombo@disposable.invalid> - 2013-01-27 12:58 +0100
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:38 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-27 03:09 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-28 21:51 -0500
Re: Parallax Propeller None <vandys@vsta.org> - 2013-01-30 02:10 +0000
Re: Parallax Propeller rickman <gnuarm@gmail.com> - 2013-01-30 18:32 -0500
Re: Parallax Propeller David Schultz <abuse@127.0.0.1> - 2013-01-20 11:21 -0600
Re: Parallax Propeller albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-01-13 16:24 +0000
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-14 10:51 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:06 +0000
Re: Parallax Propeller David Brown <david@westcontrol.removethisbit.com> - 2013-01-16 13:43 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 15:27 +0000
Re: Parallax Propeller Rafael Deliano <rafael_deliano@arcor.de> - 2013-01-15 21:10 +0100
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-16 06:26 +0000
Re: Parallax Propeller gavino_himself <visploveslisp@gmail.com> - 2013-01-22 06:26 -0800
Re: Parallax Propeller Peter Jakacki <peterjakacki@gmail.com> - 2013-01-13 12:44 +0000
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | None <vandys@vsta.org> |
|---|---|
| Date | 2013-01-25 21:57 +0000 |
| Message-ID | <20130125214801.18426.45870@localhost.localdomain> |
| In reply to | #19107 |
rickman <gnuarm@gmail.com> writes:
> How do you know the display "fuzziness" was due to software timing? I
> would expect software timing on a clocked processor to be on par with
> other means of timing. There are other aspects of design that could
> cause fuzziness or timing ambiguities in the signal.
If you look at the inner loop driving the output pin, you can do a min/max
skew calculation which ends up with quite a bit of jitter on the table.
The product is the PockeTerm, you can pick one up at:
http://www.brielcomputers.com/wordpress/?cat=25
It's open source, VGA_HiRes_Text.spin is the low level driver for
VGA output. Note it actually uses *two* CPUs, and is some pretty darn
cool assembly code--written by the president of the Propeller company!
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-01-26 18:07 -0500 |
| Message-ID | <ke1nkh$bb2$3@dont-email.me> |
| In reply to | #19156 |
On 1/25/2013 4:57 PM, None wrote: > rickman<gnuarm@gmail.com> writes: >> How do you know the display "fuzziness" was due to software timing? I >> would expect software timing on a clocked processor to be on par with >> other means of timing. There are other aspects of design that could >> cause fuzziness or timing ambiguities in the signal. > > If you look at the inner loop driving the output pin, you can do a min/max > skew calculation which ends up with quite a bit of jitter on the table. > The product is the PockeTerm, you can pick one up at: > > http://www.brielcomputers.com/wordpress/?cat=25 > > It's open source, VGA_HiRes_Text.spin is the low level driver for > VGA output. Note it actually uses *two* CPUs, and is some pretty darn > cool assembly code--written by the president of the Propeller company! > > Andy Valencia > Home page: http://www.vsta.org/andy/ > To contact me: http://www.vsta.org/contact/andy.html I don't follow what causes the skew you mention. Instruction timings are deterministic, no? If not, trying to time using code is hopeless. If the timings are deterministic, the skew should not be cumulative since they are all based on the CPU clock. Is the CPU clock from an accurate oscillator like a crystal? If it is using an internal RC clock, again timing to sufficient accuracy is hopeless. Rick
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2013-01-27 00:50 -0800 |
| Message-ID | <21dec89e-d55c-4acd-9cf4-2b9bccdfe22a@k4g2000yqn.googlegroups.com> |
| In reply to | #19181 |
On Jan 26, 11:07 pm, rickman <gnu...@gmail.com> wrote:
> On 1/25/2013 4:57 PM, None wrote:
>
>
>
>
>
>
>
>
>
> > rickman<gnu...@gmail.com> writes:
> >> How do you know the display "fuzziness" was due to software timing? I
> >> would expect software timing on a clocked processor to be on par with
> >> other means of timing. There are other aspects of design that could
> >> cause fuzziness or timing ambiguities in the signal.
>
> > If you look at the inner loop driving the output pin, you can do a min/max
> > skew calculation which ends up with quite a bit of jitter on the table.
> > The product is the PockeTerm, you can pick one up at:
>
> > http://www.brielcomputers.com/wordpress/?cat=25
>
> > It's open source, VGA_HiRes_Text.spin is the low level driver for
> > VGA output. Note it actually uses *two* CPUs, and is some pretty darn
> > cool assembly code--written by the president of the Propeller company!
>
> > Andy Valencia
> > Home page:http://www.vsta.org/andy/
> > To contact me:http://www.vsta.org/contact/andy.html
>
> I don't follow what causes the skew you mention. Instruction timings
> are deterministic, no? If not, trying to time using code is hopeless.
> If the timings are deterministic, the skew should not be cumulative
> since they are all based on the CPU clock. Is the CPU clock from an
> accurate oscillator like a crystal? If it is using an internal RC
> clock, again timing to sufficient accuracy is hopeless.
>
> Rick
The instruction times are deterministic (presumably; never written
code on the propeller), but when generating video in software, *per
scan line* all possible code-paths have to add up to the same number
of cycles in order to completely avoid jitter. That's very hard to do.
Consider a single scan line that contains text interspersed with
spaces. For the current horizontal position the software has to:
* Determine if background or foreground (i.e. a pixel of text colour)
should be drawn
* If background
* select background colour to video output register
* If foreground
* determine character under current horizontal position
* determine offset (in pixels) into the current line of the
character
* is a pixel to be drawn?
* If yes, load pixel colour
* otherwise, load background colour
The second code path is a lot more complex, containing many more
instructions, yet both code paths have to balance in terms of
execution time. This is just one example.
This is how video is done on the original Atari VCS console. 100%
software, with the hardware only providing horizontal interrupts (one
per scan line) and VBLNK interrupts, IIRC.
Caveat: The above assumes that there is no interrupt per horizontal
pixel. With interrupts, it's much easier. The Propeller doesn't have
any interrupts so software video generation would be non-trivial to
say the least. The easiest way would be to provide a pixel clock and
use an I/O pin to sync to, as Chuck found out for himself when
implementing video on the GA144.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2013-01-27 03:30 -0600 |
| Message-ID | <r7GdnQeLSvMAbpnMnZ2dnUVZ_hmdnZ2d@supernews.com> |
| In reply to | #19185 |
In comp.lang.forth Mark Wills <markrobertwills@yahoo.co.uk> wrote: > Caveat: The above assumes that there is no interrupt per horizontal > pixel. With interrupts, it's much easier. I really don't understand why you say this. You need to be able to sync to a timing pulse; whether this is done with interrupts doesn't matter. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2013-01-27 12:58 +0100 |
| Message-ID | <ke34ln$k8i$1@dont-email.me> |
| In reply to | #19185 |
Op 27-Jan-13 9:50, Mark Wills schreef: > On Jan 26, 11:07 pm, rickman <gnu...@gmail.com> wrote: >> On 1/25/2013 4:57 PM, None wrote: >> >> >> >> >> >> >> >> >> >>> rickman<gnu...@gmail.com> writes: >>>> How do you know the display "fuzziness" was due to software timing? I >>>> would expect software timing on a clocked processor to be on par with >>>> other means of timing. There are other aspects of design that could >>>> cause fuzziness or timing ambiguities in the signal. >> >>> If you look at the inner loop driving the output pin, you can do a min/max >>> skew calculation which ends up with quite a bit of jitter on the table. >>> The product is the PockeTerm, you can pick one up at: >> >>> http://www.brielcomputers.com/wordpress/?cat=25 >> >>> It's open source, VGA_HiRes_Text.spin is the low level driver for >>> VGA output. Note it actually uses *two* CPUs, and is some pretty darn >>> cool assembly code--written by the president of the Propeller company! >> >>> Andy Valencia >>> Home page:http://www.vsta.org/andy/ >>> To contact me:http://www.vsta.org/contact/andy.html >> >> I don't follow what causes the skew you mention. Instruction timings >> are deterministic, no? If not, trying to time using code is hopeless. >> If the timings are deterministic, the skew should not be cumulative >> since they are all based on the CPU clock. Is the CPU clock from an >> accurate oscillator like a crystal? If it is using an internal RC >> clock, again timing to sufficient accuracy is hopeless. >> >> Rick > > The instruction times are deterministic (presumably; never written > code on the propeller), but when generating video in software, *per > scan line* all possible code-paths have to add up to the same number > of cycles in order to completely avoid jitter. That's very hard to do. > > Consider a single scan line that contains text interspersed with > spaces. For the current horizontal position the software has to: > > * Determine if background or foreground (i.e. a pixel of text colour) > should be drawn > * If background > * select background colour to video output register > * If foreground > * determine character under current horizontal position > * determine offset (in pixels) into the current line of the > character > * is a pixel to be drawn? > * If yes, load pixel colour > * otherwise, load background colour > > The second code path is a lot more complex, containing many more > instructions, yet both code paths have to balance in terms of > execution time. This is just one example. > > This is how video is done on the original Atari VCS console. 100% > software, with the hardware only providing horizontal interrupts (one > per scan line) and VBLNK interrupts, IIRC. On the Atari VCS the software did not have to send out the individual pixels. The TIA chip had memory for a single scan-line, which the TIA chip converted to a video signal autonomously. The software just had to make sure that the right data was loaded into the TIA chip in time for each scan-line, it could finish doing that before the end of the scan-line, but not after that. The TIA chip has also a function to stall the CPU until the start of the next scan line. I.o.w. the software had to be fast enough for each possible execution flow, but did not have to complete in the exact same number of cycles.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-01-28 21:38 -0500 |
| Message-ID | <ke9i4g$49q$1@dont-email.me> |
| In reply to | #19185 |
On 1/27/2013 3:50 AM, Mark Wills wrote: > On Jan 26, 11:07 pm, rickman<gnu...@gmail.com> wrote: >> On 1/25/2013 4:57 PM, None wrote: >> >> >> >> >> >> >> >> >> >>> rickman<gnu...@gmail.com> writes: >>>> How do you know the display "fuzziness" was due to software timing? I >>>> would expect software timing on a clocked processor to be on par with >>>> other means of timing. There are other aspects of design that could >>>> cause fuzziness or timing ambiguities in the signal. >> >>> If you look at the inner loop driving the output pin, you can do a min/max >>> skew calculation which ends up with quite a bit of jitter on the table. >>> The product is the PockeTerm, you can pick one up at: >> >>> http://www.brielcomputers.com/wordpress/?cat=25 >> >>> It's open source, VGA_HiRes_Text.spin is the low level driver for >>> VGA output. Note it actually uses *two* CPUs, and is some pretty darn >>> cool assembly code--written by the president of the Propeller company! >> >>> Andy Valencia >>> Home page:http://www.vsta.org/andy/ >>> To contact me:http://www.vsta.org/contact/andy.html >> >> I don't follow what causes the skew you mention. Instruction timings >> are deterministic, no? If not, trying to time using code is hopeless. >> If the timings are deterministic, the skew should not be cumulative >> since they are all based on the CPU clock. Is the CPU clock from an >> accurate oscillator like a crystal? If it is using an internal RC >> clock, again timing to sufficient accuracy is hopeless. >> >> Rick > > The instruction times are deterministic (presumably; never written > code on the propeller), but when generating video in software, *per > scan line* all possible code-paths have to add up to the same number > of cycles in order to completely avoid jitter. That's very hard to do. > > Consider a single scan line that contains text interspersed with > spaces. For the current horizontal position the software has to: > > * Determine if background or foreground (i.e. a pixel of text colour) > should be drawn > * If background > * select background colour to video output register > * If foreground > * determine character under current horizontal position > * determine offset (in pixels) into the current line of the > character > * is a pixel to be drawn? > * If yes, load pixel colour > * otherwise, load background colour > > The second code path is a lot more complex, containing many more > instructions, yet both code paths have to balance in terms of > execution time. This is just one example. > > This is how video is done on the original Atari VCS console. 100% > software, with the hardware only providing horizontal interrupts (one > per scan line) and VBLNK interrupts, IIRC. I'm not getting it. I guess the software had to be done this way to optimize the CPU utilization. The "proper" way to time in software is to have the video data already calculated in a frame buffer and use spin loops to time when pixels are shifted out. That way you don't have lots of processing to figure out the timing for. But you spend most of your processing time in spin loops. Why was it done this way? To save a few bucks on video hardware? That's just not an issue now days... unless you are really obsessive about not using hardware where hardware is warranted. > Caveat: The above assumes that there is no interrupt per horizontal > pixel. With interrupts, it's much easier. The Propeller doesn't have > any interrupts so software video generation would be non-trivial to > say the least. The easiest way would be to provide a pixel clock and > use an I/O pin to sync to, as Chuck found out for himself when > implementing video on the GA144. I would have to go back and reread the web pages, but I think Chuck's original attempt was to time the *entire* frame timing in software with NO hardware timing at all. He found the timings drifted too much from temperature (that's what async processors do after all, they are timed by the silicon delays which vary with temp) so that with the monitor he was using it would stop working once the board warmed up. I'm surprised he had to build it to find that out. But I guess he didn't have specs on the monitor. His "compromise" to hardware timing was to use a horizontal *line* interrupt (with a casual use of the word "interrupt", it is really a wait for a signal) which was driven from the 10 MHz oscillator node, like you described the Atari VCS. He still did the pixel timing in a software loop. With 144 processors it is no big deal to do that... *OR* he could have sprinkled a few counters around the chip to be used for *really* low power timing. Each CPU core uses 5 mW when it is running a simple timing loop. One of the big goals of the chip is to be low power and software timing is the antithesis of low power in my opinion. But then you would need an oscillator and a clock tree... I think there is an optimal compromise between a chip with fully async CPUs, with teeny tiny memories, no clocks, no peripherals (including nearly no real memory interface) and a chip with a very small number of huge CPUs, major clock trees running at very high clock rates, massive memories (multiple types), a plethora of hardware peripherals and a maximal bandwidth memory interface. How about an array of many small CPUs, much like the F18 (or an F32 which rumor has is under development), each one with a few kB of memory, with a dedicated idle timer connected to lower speed clock trees (is one or two small clock trees a real power problem?), some real hardware peripherals for the higher speed I/O standards like 100/1000 Mbps Ethernet, real USB (including USB 3.0), some amount of on chip block RAM and some *real* memory interface which works at 200 or 300 MHz clock rates? I get where Chuck is coming from with the minimal CPU thing. I have said before that I think it is a useful chip in many ways. But so far I haven't been able to use it. One project faced the memory interface limitation and another found the chip to be too hard to use in the low power modes it is supposed to be capable of, just not when you need to do real time stuff at real low power. It only needs a few small improvements including *real* I/O that can work at a number of voltages rather than just the core voltage. Oh yeah, some real documentation on the development system would be useful too. I think you have to read some three or more documents just to get started with the tools. I know it was pretty hard to figure it all out, not that I *actually* figured it out. Rick
[toc] | [prev] | [next] | [standalone]
| From | None <vandys@vsta.org> |
|---|---|
| Date | 2013-01-27 03:09 +0000 |
| Message-ID | <20130127030725.21245.80472@localhost.localdomain> |
| In reply to | #19156 |
rickman <gnuarm@gmail.com> writes:
> I don't follow what causes the skew you mention. Instruction timings
> are deterministic, no?
The chip has a lower level bit stream engine which the higher level CPU
("cog") is feeding. Well, a pair of cogs. Each cog has local memory
and then a really expensive path through a central arbiter ("hub"). It
fills its image of the scanlines from the shared memory, then has to
feed it via waitvid into the lower level. Note that it's bit stream
engine *per cog*, so you also have to worry about their sync.
So yes, instruction timings are deterministic (although your shared
memory accesses will vary modulo the hub round-robin count). You
need to reach the waitvid before it's your turn to supply the next value.
But given that, this is much like the old wait state sync feeding bytes
to a floppy controller. PLL and waitvid sync are achieved with
magic incantations from Parallax, and it is not 100%.
> If the timings are deterministic, the skew should not be cumulative
> since they are all based on the CPU clock. Is the CPU clock from an
> accurate oscillator like a crystal? If it is using an internal RC
> clock, again timing to sufficient accuracy is hopeless.
The board has a CPU clock from which the PLL derives the video output
frequency. I recall the CPU clock being based on a crystal, but not one
with any consideration for video intervals. And the PLL's are per cog,
again my comment about (potential lack of) global sync.
Anyway, you should buy one and check it out. I'd be curious to hear
if (1) you also observe the same video quality, and (2) if you think it's
the waitvid mechanism, more the PLL->SVGA generation, or the sync issues
of the paired video generators. They even supply the schematic, FWIW.
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-01-28 21:51 -0500 |
| Message-ID | <ke9i4l$49q$2@dont-email.me> |
| In reply to | #19183 |
Weird, your posts all show up in my reader as replies to your own
messages rather than replies to my posts. The trimming made it hard for
me to figure out just what we were talking about with the odd
connections in my reader.
On 1/26/2013 10:09 PM, None wrote:
> rickman<gnuarm@gmail.com> writes:
>> I don't follow what causes the skew you mention. Instruction timings
>> are deterministic, no?
>
> The chip has a lower level bit stream engine which the higher level CPU
> ("cog") is feeding. Well, a pair of cogs. Each cog has local memory
> and then a really expensive path through a central arbiter ("hub"). It
> fills its image of the scanlines from the shared memory, then has to
> feed it via waitvid into the lower level. Note that it's bit stream
> engine *per cog*, so you also have to worry about their sync.
I can't picture the processing with this description. I don't know
about the higher level and lower level CPUs you describe. Are you
saying there is some sort of dedicated hardware in each CPU for video?
Or is this separate from the CPUs? Why a *pair* of COGs? I assume a
COG is the Propeller term for a CPU?
> So yes, instruction timings are deterministic (although your shared
> memory accesses will vary modulo the hub round-robin count). You
> need to reach the waitvid before it's your turn to supply the next value.
> But given that, this is much like the old wait state sync feeding bytes
> to a floppy controller. PLL and waitvid sync are achieved with
> magic incantations from Parallax, and it is not 100%.
Not 100%? What does that mean? Magic? I guess this is the magic smoke
you want to keep from getting out of the chip?
>> If the timings are deterministic, the skew should not be cumulative
>> since they are all based on the CPU clock. Is the CPU clock from an
>> accurate oscillator like a crystal? If it is using an internal RC
>> clock, again timing to sufficient accuracy is hopeless.
>
> The board has a CPU clock from which the PLL derives the video output
> frequency. I recall the CPU clock being based on a crystal, but not one
> with any consideration for video intervals. And the PLL's are per cog,
> again my comment about (potential lack of) global sync.
I still don't know enough about the architecture to know what this
means. I don't care if the CPUs are not coordinated closely. If you
have a video engine providing the clock timing, why would the CPU timing
matter?
> Anyway, you should buy one and check it out. I'd be curious to hear
> if (1) you also observe the same video quality, and (2) if you think it's
> the waitvid mechanism, more the PLL->SVGA generation, or the sync issues
> of the paired video generators. They even supply the schematic, FWIW.
I appreciate your enthusiasm, but I have my own goals and projects. I
am currently oriented towards absurdly low power levels in digital
designs and am working on a design that will require no explicit power
source, it will scavenge power from the environment. I don't think a
Propeller is suitable for such a task is it?
Rick
[toc] | [prev] | [next] | [standalone]
| From | None <vandys@vsta.org> |
|---|---|
| Date | 2013-01-30 02:10 +0000 |
| Message-ID | <20130130020344.24932.38142@localhost.localdomain> |
| In reply to | #19183 |
rickman <gnuarm@gmail.com> writes:
> Weird, your posts all show up in my reader as replies to your own
> messages rather than replies to my posts. The trimming made it hard for
> me to figure out just what we were talking about with the odd
> connections in my reader.
Sorry. I'm assuming your reader is threading via the "References" field?
It looks like my posting software is preserving that.
> > The chip has a lower level bit stream engine which the higher level CPU
> > ("cog") is feeding. Well, a pair of cogs. Each cog has local memory
> > and then a really expensive path through a central arbiter ("hub"). It
> > fills its image of the scanlines from the shared memory, then has to
> > feed it via waitvid into the lower level. Note that it's bit stream
> > engine *per cog*, so you also have to worry about their sync.
> I can't picture the processing with this description. I don't know
> about the higher level and lower level CPUs you describe. Are you
> saying there is some sort of dedicated hardware in each CPU for video?
> Or is this separate from the CPUs? Why a *pair* of COGs? I assume a
> COG is the Propeller term for a CPU?
Yes, each cog has its own PLL and "video" bit stream engine (quotes because
they claim it can be used for any sort of analog stream in general). They
needed to use a pair of cogs (CPU's) because of the time it takes to pull
from screen memory as conceived by the ANSI emulation and generate the
scan lines to represent the font plus underline plus cursor. So the idea
is one is doing all that while the other is painting scan lines. Double
buffering, basically.
> Not 100%? What does that mean? Magic? I guess this is the magic smoke
> you want to keep from getting out of the chip?
Yes, there is no formal/deterministic way to lock the PLL's of the two
cogs. Everybody uses the sample code Parallax provided, and it has
definitely been shown that their "lock" can be skewed.
> I still don't know enough about the architecture to know what this
> means. I don't care if the CPUs are not coordinated closely. If you
> have a video engine providing the clock timing, why would the CPU timing
> matter?
They have *two* video engines. Each is generated from its own PLL, so
the first global clock is a crystal oscillator.
> > Anyway, you should buy one and check it out. I'd be curious to hear
> > if (1) you also observe the same video quality, and (2) if you think it's
> > the waitvid mechanism, more the PLL->SVGA generation, or the sync issues
> > of the paired video generators. They even supply the schematic, FWIW.
> I appreciate your enthusiasm, but I have my own goals and projects. I
> am currently oriented towards absurdly low power levels in digital
> designs and am working on a design that will require no explicit power
> source, it will scavenge power from the environment. I don't think a
> Propeller is suitable for such a task is it?
Darn, because I'm pretty sure you are much better equipped to drill
down into this than I. :-> But, no way, a Propeller is definitely a
traditional CPU for your purposes.
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2013-01-30 18:32 -0500 |
| Message-ID | <kecajg$oip$1@dont-email.me> |
| In reply to | #19275 |
On 1/29/2013 9:10 PM, None wrote: > rickman<gnuarm@gmail.com> writes: > > Yes, each cog has its own PLL and "video" bit stream engine (quotes because > they claim it can be used for any sort of analog stream in general). They > needed to use a pair of cogs (CPU's) because of the time it takes to pull > from screen memory as conceived by the ANSI emulation and generate the > scan lines to represent the font plus underline plus cursor. So the idea > is one is doing all that while the other is painting scan lines. Double > buffering, basically. More like splitting the work load between two processors. I did timing analysis of this (back of the envelope type stuff) for the GA144 and it would be pretty simple with 100's of MIPs per CPU. I wouldn't think it would be that hard with any processor running at reasonable clock rates. Not sure why they need two CPUs. It all depends on the pixel clock rate. For a terminal (what you seem to be describing) the pixel rate should be fairly low, 50-80 MHz. That gives a character rate of 10 MHz max, so I guess that could tax a 100 MIPS processor. >> Not 100%? What does that mean? Magic? I guess this is the magic smoke >> you want to keep from getting out of the chip? > > Yes, there is no formal/deterministic way to lock the PLL's of the two > cogs. Everybody uses the sample code Parallax provided, and it has > definitely been shown that their "lock" can be skewed. I don't know what the architecture of this design is. Ideally there would be no need to lock the two processors. >> I still don't know enough about the architecture to know what this >> means. I don't care if the CPUs are not coordinated closely. If you >> have a video engine providing the clock timing, why would the CPU timing >> matter? > > They have *two* video engines. Each is generated from its own PLL, so > the first global clock is a crystal oscillator. I have no image of how or why you would want to use *two* video engines, although two could be used with one for the char data and one for the cursor overlay. I also don't know anything about these "video engines". If they are indeed video engines, they should be doing all the addressing and fetching from memory. One way a terminal saves memory bandwidth is by not fetching the same chars again for each line. In an old implementation I remember seeing they used a shift register to recycle the same char data for each scan line. >> I appreciate your enthusiasm, but I have my own goals and projects. I >> am currently oriented towards absurdly low power levels in digital >> designs and am working on a design that will require no explicit power >> source, it will scavenge power from the environment. I don't think a >> Propeller is suitable for such a task is it? > > Darn, because I'm pretty sure you are much better equipped to drill > down into this than I. :-> But, no way, a Propeller is definitely a > traditional CPU for your purposes. I'm happy to discuss this with you. Rick
[toc] | [prev] | [next] | [standalone]
| From | David Schultz <abuse@127.0.0.1> |
|---|---|
| Date | 2013-01-20 11:21 -0600 |
| Message-ID | <xIVKs.1091041$2a.996934@en-nntp-14.dc1.easynews.com> |
| In reply to | #18889 |
On 01/18/2013 08:07 PM, Ben Bradley wrote: > It's against that designer guru guy's religion or something. I remember reading an article in Nuts & Volts on the propeller which discussed the interrupt thing. Digging into the archives... "There were only a few rules: it had to be fast, it had to be relatively easy to program, and it had to be able to do multiple tasks without using interrupts -- the bane of all but the heartiest programmers." April 2006, page 16. In other words, interrupts are too hard. By this standard, I am a hearty programmer. -- David W. Schultz http://home.earthlink.net/~david.schultz Returned for Regrooving
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2013-01-13 16:24 +0000 |
| Message-ID | <50f2dfcd$0$6073$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #18713 |
In article <LFxIs.2582$Ow3.159@viwinnwfe02.internal.bigpond.com>, Peter Jakacki <peterjakacki@gmail.com> wrote: >On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote: > >> On 13/01/2013 06:37, Peter Jakacki wrote: <SNIP> > > >Seeing that each cog only has 512 longs of RAM which it directly >addresses both source and destination in each 32-bit instruction, it >becomes necessary then to run a virtual machine for high level >application code. This is what Spin does as it compiles bytecode in hub >RAM while one or more cogs may have the Spin interpreter loaded. My >Tachyon Forth does something similar but has a much faster runtime speed >and of course the target hosts a Forth development and runtime system. So >I use bytecode that directly addresses the code in the first 256 longs of >the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode >instructions/second and since there are no interrupts!! nor any need for >them then each cog runs unencumbered. Realtime software development and >testing has never been easier. > >Hopefully I've put it in some kind of nutshell. What do you think? >Weird? Yes, but it works really well :) It sounds like GA144 done properly. > >*peter* > > > > -- 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 | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-01-14 10:51 +0100 |
| Message-ID | <FvCdnda0ZcC2SG7NnZ2dnUVZ7qqdnZ2d@lyse.net> |
| In reply to | #18713 |
On 13/01/13 13:22, Peter Jakacki wrote: > On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote: > >> On 13/01/2013 06:37, Peter Jakacki wrote: >>> >>> For some reason I found myself reading these newsgroups which I haven't >>> really used for many years. It seems that although the Parallax >>> Propeller web forums are extremely active there never seems to be much >>> discussion elsewhere. Aren't you all curious as to what you are missing >>> out on? >>> >>> I have used just about every kind of micro and architecture over the >>> decades and while I might still use some small "one buck" micros for >>> certain tasks and some special ARM chips for higher end tasks I have >>> almost exclusively been using Propeller chips for everything else. The >>> reason is very simple, they are so simple to work with and there are no >>> "peripheral modules" to worry about other than the counters and video >>> hardware per cog. Every pin is general-purpose and any one of the eight >>> 32-bit cores can use them, you don't have to worry about trying to >>> route a special pin or have the dilemma of using the special pin for >>> one function but not the other etc. The 32-bit CPUs or cogs are a >>> breeze to program and you can work with a variety of languages besides >>> the easy to use Spin compiler that comes with it. >>> >>> For you Forth enthusiasts there has been a big flurry of Forth related >>> threads on the Propeller forums of late and there are several versions >>> of Forth including my own Tachyon Forth. IMHO this is the best way to >>> get into the Propeller and it's hardware. I just can't be bother trying >>> to cram functions and debug interrupts on other chips when I can set a >>> cog to work on a task and still have plenty of resources left over >>> including video on-chip. >>> >>> If you are intrigued or just plain curious it won't kill you unless you >>> are a cat to have a look at my introduction page which has links to >>> projects and the forum etc. >>> http://goo.gl/VX7pc >>> >>> There is the sup'ed up version of the Propeller, the Propeller II >>> coming out in the following months which has 96 I/O, 8 cogs, 128K RAM >>> and 160MIPS/core. >>> >>> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) >>> that hang off the "I2C bus" from the Propeller and I can load new >>> firmware into each chip using just one extra line to program them >>> in-circuit. >>> >>> *peter* >>> >>> >> Had a quick look (again) - it's not very fast and it's not very cheap >> (compared with a CortexM4 clocked at 150MHz or more). Then there is all >> the pain of programming and synching multiple cores which is (I think) >> worse than the pain of managing DMA on a typical M4 based >> micro-controller. >> For some applications I'm sure it's a really good fit but I haven't hit >> one yet. It's similar in concept to XMOS and Greenchip offerings but >> like them suffers from a less than first rank supplier which would worry >> most of my customers. >> >> MK > > Since I've had a lot of experience with the Propeller and ARMs and I'm > familiar with M4s (still pushing out a design) then I can say that unless > you actually sit down with it for an hour or two that you will probably > continue to have this misconceptions. Is that the way that the Propeller > comes across? I've always wondered about that. > > No, your idea of the Propeller is so off the mark, I'm saying that not to > offend, just setting the record straight although I appreciate the honest > opinion as this gives me something to work on in explaining what it is > and what it is not. > > First off, don't try to compare this with an XMOS or GreenArrays (I think > you mean) as they are very different. No, the Propeller is more like 8 > identical 32-bit CPUs + counter and video hardware and 512 longs of RAM > each sharing all 32 I/O in common and coupled to a multi-port 32kB RAM > (hub). Sounds strange? Okay, but the eight cogs are not really utilised > for "parallel processing" but think of each cog as either a CPU or a > virtual peripheral or both. The way it's used is that you might setup one > cog as an intelligent quad port UART, another as the VGA cog, another as > keyboard and mouse etc while maybe only one cog is processing the > application. When you see it in action it is very simple to program even > for a beginner. I don't know about GreenArrays, but this sounds very much like XMOS devices. There are differences in the details, and the main languages for the XMOS are C, C++ and XC (sort of C with a few bits removed, and some parallel processing and XMOS features added) rather than Forth. But it's the same idea - you have multiple CPUs so that you can make your peripherals in software in a CPU rather than as dedicated hardware. And I'd imagine it is similarly "easy" to work with - some things /will/ be easy, but other things will be a lot harder in practice. In particular, 8 cores/threads sounds great when you start, and you can write very elegant UARTs, flashing lights, etc. But in the real application you need more than 8 cores, and you start having to combine tasks within a single core/thread and the elegance, clarity, and ease of development go out the window. The other big problem is the small memories - you start off thinking how cool these devices are that are so fast you can make USB or Ethernet peripherals in software cores, using ready-made "software components" from the company's website. But then you discover that to actually /use/ them for something more than a flashing lights demo takes more ram than the chips have. So it's a nice idea for some types of problem - but it is not unique, and it is only really good for a small number of applications. > > Seeing that each cog only has 512 longs of RAM which it directly > addresses both source and destination in each 32-bit instruction, it > becomes necessary then to run a virtual machine for high level > application code. This is what Spin does as it compiles bytecode in hub > RAM while one or more cogs may have the Spin interpreter loaded. My > Tachyon Forth does something similar but has a much faster runtime speed > and of course the target hosts a Forth development and runtime system. So > I use bytecode that directly addresses the code in the first 256 longs of > the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode > instructions/second and since there are no interrupts!! nor any need for > them then each cog runs unencumbered. Realtime software development and > testing has never been easier. > > Hopefully I've put it in some kind of nutshell. What do you think? > Weird? Yes, but it works really well :) > > *peter* >
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-16 06:06 +0000 |
| Message-ID | <crrJs.2632$1k5.1504@viwinnwfe01.internal.bigpond.com> |
| In reply to | #18752 |
On Mon, 14 Jan 2013 10:51:39 +0100, David Brown wrote: > I don't know about GreenArrays, but this sounds very much like XMOS > devices. There are differences in the details, and the main languages > for the XMOS are C, C++ and XC (sort of C with a few bits removed, and > some parallel processing and XMOS features added) rather than Forth. But > it's the same idea - you have multiple CPUs so that you can make your > peripherals in software in a CPU rather than as dedicated hardware. > > And I'd imagine it is similarly "easy" to work with - some things /will/ > be easy, but other things will be a lot harder in practice. In > particular, 8 cores/threads sounds great when you start, and you can > write very elegant UARTs, flashing lights, etc. But in the real > application you need more than 8 cores, and you start having to combine > tasks within a single core/thread and the elegance, clarity, and ease of > development go out the window. The other big problem is the small > memories - you start off thinking how cool these devices are that are so > fast you can make USB or Ethernet peripherals in software cores, using > ready-made "software components" from the company's website. But then > you discover that to actually /use/ them for something more than a > flashing lights demo takes more ram than the chips have. > > > So it's a nice idea for some types of problem - but it is not unique, > and it is only really good for a small number of applications. > > Well it seems that unless you try it you can't really judge it, that's for sure and in trying to judge it everyone is way off the mark. In terms of critique of your critique I would have to give you a very poor mark though. To mention flashing lights followed by "etc" is indicative of an early negative response and a attempt at minimalizing, as if you were Bill Gates talking about Linux. As for real applications I am always producing real commercial products with this chip so I think I know (actually, I do know) what goes into real apps having worked with a very wide variety of small to large micros through the decades (and still do). Having read the rest of your comments I can't see where your fascination for flashing lights is coming from but I hope you are cured soon :) BTW, the Propeller does very nice blinking lights along with simultaneous VGA and graphics rendering along with audio and SD, HID etc while still handling critical I/O in real deterministic time. The language and tools were the easiest to learn and use of any processor I've worked with. Can't you see I'm not trying to sell them, I just didn't want to keep on being selfish keeping this good thing all to myself and the secret Propeller "Illuminati". *peter*
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2013-01-16 13:43 +0100 |
| Message-ID | <6oSdnWb3bYHDPWvNnZ2dnUVZ8tGdnZ2d@lyse.net> |
| In reply to | #18840 |
On 16/01/13 07:06, Peter Jakacki wrote: > On Mon, 14 Jan 2013 10:51:39 +0100, David Brown wrote: > > >> I don't know about GreenArrays, but this sounds very much like XMOS >> devices. There are differences in the details, and the main languages >> for the XMOS are C, C++ and XC (sort of C with a few bits removed, and >> some parallel processing and XMOS features added) rather than Forth. But >> it's the same idea - you have multiple CPUs so that you can make your >> peripherals in software in a CPU rather than as dedicated hardware. >> >> And I'd imagine it is similarly "easy" to work with - some things /will/ >> be easy, but other things will be a lot harder in practice. In >> particular, 8 cores/threads sounds great when you start, and you can >> write very elegant UARTs, flashing lights, etc. But in the real >> application you need more than 8 cores, and you start having to combine >> tasks within a single core/thread and the elegance, clarity, and ease of >> development go out the window. The other big problem is the small >> memories - you start off thinking how cool these devices are that are so >> fast you can make USB or Ethernet peripherals in software cores, using >> ready-made "software components" from the company's website. But then >> you discover that to actually /use/ them for something more than a >> flashing lights demo takes more ram than the chips have. >> >> >> So it's a nice idea for some types of problem - but it is not unique, >> and it is only really good for a small number of applications. >> >> > > Well it seems that unless you try it you can't really judge it, that's > for sure and in trying to judge it everyone is way off the mark. In terms > of critique of your critique I would have to give you a very poor mark > though. To mention flashing lights followed by "etc" is indicative of an > early negative response and a attempt at minimalizing, as if you were > Bill Gates talking about Linux. As for real applications I am always > producing real commercial products with this chip so I think I know > (actually, I do know) what goes into real apps having worked with a very > wide variety of small to large micros through the decades (and still do). I have worked with XMOS chips - but I never claimed to have used the Parallax (or GreenArray). I have just read some of the information from the web site, and considered possible applications and problems based on my XMOS experience - since the XMOS and the Parallax have a similar philosophy. I have no doubt that you can do lots of fun things with a Parallax - and I have no doubt that you can do commercial projects with it. But I also have no doubt that 8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system. > > Having read the rest of your comments I can't see where your fascination > for flashing lights is coming from but I hope you are cured soon :) > Did you not know that every electronics card needs a flashing light, so that customers will know that it is working? Seriously, it was obviously just a reference to test or demo software rather than fully functional software. > BTW, the Propeller does very nice blinking lights along with simultaneous > VGA and graphics rendering along with audio and SD, HID etc while still > handling critical I/O in real deterministic time. The language and tools > were the easiest to learn and use of any processor I've worked with. > > Can't you see I'm not trying to sell them, I just didn't want to keep on > being selfish keeping this good thing all to myself and the secret > Propeller "Illuminati". That's fine - and I am not trying to be critical to the devices (or your work). I am just pointing out a few realities about the devices, such as their similarities to the XMOS and limitations that I think users will quickly encounter. They look like an interesting architecture - and I am always a fan of considering new architectures and languages - but I am not convinced that they are a great idea for general use. > > > *peter* > >
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-16 15:27 +0000 |
| Message-ID | <eFzJs.2731$Ow3.1360@viwinnwfe02.internal.bigpond.com> |
| In reply to | #18844 |
On Wed, 16 Jan 2013 13:43:10 +0100, David Brown wrote: > > I have worked with XMOS chips - but I never claimed to have used the > Parallax (or GreenArray). I have just read some of the information from > the web site, and considered possible applications and problems based on > my XMOS experience - since the XMOS and the Parallax have a similar > philosophy. > > I have no doubt that you can do lots of fun things with a Parallax - and > I have no doubt that you can do commercial projects with it. But I also > have no doubt that 8 cores/threads is far too few to be able to dedicate > a core to each task in non-trivial real world applications. And when > you have to multiplex tasks within each core/thread, you have lost much > of the elegance that you had by using the multi-core system. > > Did you not know that every electronics card needs a flashing light, so > that customers will know that it is working? > > Seriously, it was obviously just a reference to test or demo software > rather than fully functional software. > > > That's fine - and I am not trying to be critical to the devices (or your > work). I am just pointing out a few realities about the devices, such > as their similarities to the XMOS and limitations that I think users > will quickly encounter. They look like an interesting architecture - > and I am always a fan of considering new architectures and languages - > but I am not convinced that they are a great idea for general use. From what I know about XMOS and also from those who work with the chip it is quite a different beast from the Propeller. The Propeller appears to be a simpler and easier to use chip and it's eight cogs are eight CPUs, not tasks. Indeed I know that every pcb needs a flashing light!! How is it that there are so many designs out there that do not have such a rudimentary indicator just to tell you that there is power and activity/status. But indicators do not require the resources of a whole CPU and normally I run these directly from code positions or even from a more general-purpose timer "task" which looks after multiple timeouts and actions including low priority polling. Not sure what you are getting at by referring to "non-trivial" real world applications :) How non-trivial is this? Are all the real-time industrial control functions, communications and network protocols (wired, RF, and SM fibre), H-bridge motor and microstepping control, graphic display and input processing, SD file systems etc trivial? Okay, if so then I think you might be thinking that just because the Propeller has eight cores that it is some kind of parallel processing "beastie" but it's actually classed as a "microcontroller", not a PC killer. *peter*
[toc] | [prev] | [next] | [standalone]
| From | Rafael Deliano <rafael_deliano@arcor.de> |
|---|---|
| Date | 2013-01-15 21:10 +0100 |
| Message-ID | <50f5b79d$0$6574$9b4e6d93@newsspool3.arcor-online.net> |
| In reply to | #18713 |
> you will probably > continue to have this misconceptions. Is that the way that the Propeller > comes across? I've always wondered about that. Un unusal/non-mainstream architecture will always be initally misjudged. But some of the misconceptions are due to Parallax: if it has a smallish videogenerator then its probably a retro arcade game machine chip ? While the spin language is usable, there is nothing people like less then learning new weird languages. ( http://www.parallax.com/portals/0/propellerqna/Content/QnaTopics/QnaSpin.htm "Spin was inspired by portions of C, Delphi, and Python, and a host of problem/solution scenarios ..." ) It could have easily been an extended BASIC or FORTH. There are issues in implementation: The upper half of the 64k byte memorymap is a 32kbyte ROM that contains the small 4k byte spin interpreter. That ROM is rather underutilized with data tables. This spin interpreter firmware is encrypted http://propeller.wikispaces.com/Cracking+Open+the+Propeller+-+Original+Page Which makes implementing other languages ontop of it certainly much fun. Not much copy protection for the user as the chip boots the application from an external serial EEPROM to its internal SRAM. There are issues in the basic concept: The round-robin access doesn´t scale very well. If you go from 8 to 16 cores, the clock has to double otherwise speed is down. So a 100 pin chip can hardly have 64 cores. One can think of COG-RAM to HUB-RAM as an analogy to the zero-page of an old 6502. But the speed penalty is much worse: 4 clocks for COG versus 8...23 for HUB. Identical cores are one-size-fits-all. The propeller may be flexible and fast concerning I/O, bit banging. But an I/O core that interprets bytecode is probably no match for even the smallest ARM in executing high level language. MfG JRD
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-16 06:26 +0000 |
| Message-ID | <aKrJs.2633$1k5.2262@viwinnwfe01.internal.bigpond.com> |
| In reply to | #18829 |
On Tue, 15 Jan 2013 21:10:08 +0100, Rafael Deliano wrote: >> you will probably continue to have this misconceptions. Is that the way >> that the Propeller comes across? I've always wondered about that. > > Un unusal/non-mainstream architecture will always be initally misjudged. > > But some of the misconceptions are due to Parallax: > if it has a smallish videogenerator then its probably > a retro arcade game machine chip ? > While the spin language is usable, there > is nothing people like less then learning new weird languages. > ( > http://www.parallax.com/portals/0/propellerqna/Content/QnaTopics/ QnaSpin.htm > "Spin was inspired by portions of C, Delphi, and Python, > and a host of problem/solution scenarios ..." ) > It could have easily been an extended BASIC or FORTH. > > There are issues in implementation: > The upper half of the 64k byte memorymap is a 32kbyte ROM > that contains the small 4k byte spin interpreter. That ROM is rather > underutilized with data tables. > This spin interpreter firmware is encrypted > http://propeller.wikispaces.com/Cracking+Open+the+Propeller+-+Original +Page > Which makes implementing other languages ontop of it certainly much fun. > Not much copy protection for the user > as the chip boots the application from an external serial EEPROM to its > internal SRAM. > > There are issues in the basic concept: > The round-robin access doesn´t scale very well. > If you go from 8 to 16 cores, the clock has to double otherwise speed is > down. So a 100 pin chip can hardly have 64 cores. > One can think of COG-RAM to HUB-RAM as an analogy > to the zero-page of an old 6502. But the speed penalty is much worse: 4 > clocks for COG versus 8...23 for HUB. > Identical cores are one-size-fits-all. The propeller > may be flexible and fast concerning I/O, bit banging. > But an I/O core that interprets bytecode is probably no match for even > the smallest ARM in executing high level language. > > MfG JRD Round-robin access doesn't have to scale, it is what it is and trying to judge it based on how it might operate as it is but with 64 cores is weird!! Just judge it as it is. Besides, the successor chip still has 8 cores but allows 8 longs to be accessed in one "round-robin" cycle. The fixed round-robin access provides a guaranteed access time for cogs which might otherwise have been upset by some resource crazed object. The smallest or largest ARM has to handle more than one task plus interrupts etc so it never ever achieves it's full speed. If everything fits in 512 longs of a very code efficient cog then it is very fast but even more so because it's not bogged down like an ARM. I can't write any ARM code that doesn't have to do everything including washing the dishes but the ARM does have a large code space without a doubt. The high level code rarely needs to run fast though, it's all the low-level stuff that needs priority which on an ARM requires some complex interrupt processing to hopefully service that special interrupt in time. No such problem ever with the Propeller though. When I first developed code for the ARM it was on the LPC2148 which I ended up entering into the Philips/NXP 2005 ARM design contest as the "noPC" with which I was bit-banging VGA graphics under interrupts along with SD access, audio generation, PS/2 keyboard & mouse as well as serial etc. That was a lot of hard work on the ARM and left very little processing time left for the application but doing the same thing on a Propeller chip is better, easier, and faster. Perhaps you have been Googling and clicking on some very old links but the Spin interpreter source code etc is openly available and has been for years although I don't know why whether it's encrypted or not should have been worthy of any kind of mention. Higher-end CPU users and those who require secured firmware should take a look at the forthcoming Propeller 2 due out sometime in the next few months or so. *peter*
[toc] | [prev] | [next] | [standalone]
| From | gavino_himself <visploveslisp@gmail.com> |
|---|---|
| Date | 2013-01-22 06:26 -0800 |
| Message-ID | <ebec24a7-9bc4-4fb1-9ceb-7a32e4393017@googlegroups.com> |
| In reply to | #18713 |
On Sunday, January 13, 2013 4:22:03 AM UTC-8, Peter Jakacki wrote: > On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote: > > > > > On 13/01/2013 06:37, Peter Jakacki wrote: > > >> > > >> For some reason I found myself reading these newsgroups which I haven't > > >> really used for many years. It seems that although the Parallax > > >> Propeller web forums are extremely active there never seems to be much > > >> discussion elsewhere. Aren't you all curious as to what you are missing > > >> out on? > > >> > > >> I have used just about every kind of micro and architecture over the > > >> decades and while I might still use some small "one buck" micros for > > >> certain tasks and some special ARM chips for higher end tasks I have > > >> almost exclusively been using Propeller chips for everything else. The > > >> reason is very simple, they are so simple to work with and there are no > > >> "peripheral modules" to worry about other than the counters and video > > >> hardware per cog. Every pin is general-purpose and any one of the eight > > >> 32-bit cores can use them, you don't have to worry about trying to > > >> route a special pin or have the dilemma of using the special pin for > > >> one function but not the other etc. The 32-bit CPUs or cogs are a > > >> breeze to program and you can work with a variety of languages besides > > >> the easy to use Spin compiler that comes with it. > > >> > > >> For you Forth enthusiasts there has been a big flurry of Forth related > > >> threads on the Propeller forums of late and there are several versions > > >> of Forth including my own Tachyon Forth. IMHO this is the best way to > > >> get into the Propeller and it's hardware. I just can't be bother trying > > >> to cram functions and debug interrupts on other chips when I can set a > > >> cog to work on a task and still have plenty of resources left over > > >> including video on-chip. > > >> > > >> If you are intrigued or just plain curious it won't kill you unless you > > >> are a cat to have a look at my introduction page which has links to > > >> projects and the forum etc. > > >> http://goo.gl/VX7pc > > >> > > >> There is the sup'ed up version of the Propeller, the Propeller II > > >> coming out in the following months which has 96 I/O, 8 cogs, 128K RAM > > >> and 160MIPS/core. > > >> > > >> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) > > >> that hang off the "I2C bus" from the Propeller and I can load new > > >> firmware into each chip using just one extra line to program them > > >> in-circuit. > > >> > > >> *peter* > > >> > > >> > > > Had a quick look (again) - it's not very fast and it's not very cheap > > > (compared with a CortexM4 clocked at 150MHz or more). Then there is all > > > the pain of programming and synching multiple cores which is (I think) > > > worse than the pain of managing DMA on a typical M4 based > > > micro-controller. > > > For some applications I'm sure it's a really good fit but I haven't hit > > > one yet. It's similar in concept to XMOS and Greenchip offerings but > > > like them suffers from a less than first rank supplier which would worry > > > most of my customers. > > > > > > MK > > > > Since I've had a lot of experience with the Propeller and ARMs and I'm > > familiar with M4s (still pushing out a design) then I can say that unless > > you actually sit down with it for an hour or two that you will probably > > continue to have this misconceptions. Is that the way that the Propeller > > comes across? I've always wondered about that. > > > > No, your idea of the Propeller is so off the mark, I'm saying that not to > > offend, just setting the record straight although I appreciate the honest > > opinion as this gives me something to work on in explaining what it is > > and what it is not. > > > > First off, don't try to compare this with an XMOS or GreenArrays (I think > > you mean) as they are very different. No, the Propeller is more like 8 > > identical 32-bit CPUs + counter and video hardware and 512 longs of RAM > > each sharing all 32 I/O in common and coupled to a multi-port 32kB RAM > > (hub). Sounds strange? Okay, but the eight cogs are not really utilised > > for "parallel processing" but think of each cog as either a CPU or a > > virtual peripheral or both. The way it's used is that you might setup one > > cog as an intelligent quad port UART, another as the VGA cog, another as > > keyboard and mouse etc while maybe only one cog is processing the > > application. When you see it in action it is very simple to program even > > for a beginner. > > > > Seeing that each cog only has 512 longs of RAM which it directly > > addresses both source and destination in each 32-bit instruction, it > > becomes necessary then to run a virtual machine for high level > > application code. This is what Spin does as it compiles bytecode in hub > > RAM while one or more cogs may have the Spin interpreter loaded. My > > Tachyon Forth does something similar but has a much faster runtime speed > > and of course the target hosts a Forth development and runtime system. So > > I use bytecode that directly addresses the code in the first 256 longs of > > the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode > > instructions/second and since there are no interrupts!! nor any need for > > them then each cog runs unencumbered. Realtime software development and > > testing has never been easier. > > > > Hopefully I've put it in some kind of nutshell. What do you think? > > Weird? Yes, but it works really well :) > > > > *peter* What kinds of apps have you created with this setup?
[toc] | [prev] | [next] | [standalone]
| From | Peter Jakacki <peterjakacki@gmail.com> |
|---|---|
| Date | 2013-01-13 12:44 +0000 |
| Message-ID | <n_xIs.2583$Ow3.737@viwinnwfe02.internal.bigpond.com> |
| In reply to | #18712 |
On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote: > On 13/01/2013 06:37, Peter Jakacki wrote: >> >> For some reason I found myself reading these newsgroups which I haven't >> really used for many years. It seems that although the Parallax >> Propeller web forums are extremely active there never seems to be much >> discussion elsewhere. Aren't you all curious as to what you are missing >> out on? >> >> I have used just about every kind of micro and architecture over the >> decades and while I might still use some small "one buck" micros for >> certain tasks and some special ARM chips for higher end tasks I have >> almost exclusively been using Propeller chips for everything else. The >> reason is very simple, they are so simple to work with and there are no >> "peripheral modules" to worry about other than the counters and video >> hardware per cog. Every pin is general-purpose and any one of the eight >> 32-bit cores can use them, you don't have to worry about trying to >> route a special pin or have the dilemma of using the special pin for >> one function but not the other etc. The 32-bit CPUs or cogs are a >> breeze to program and you can work with a variety of languages besides >> the easy to use Spin compiler that comes with it. >> >> For you Forth enthusiasts there has been a big flurry of Forth related >> threads on the Propeller forums of late and there are several versions >> of Forth including my own Tachyon Forth. IMHO this is the best way to >> get into the Propeller and it's hardware. I just can't be bother trying >> to cram functions and debug interrupts on other chips when I can set a >> cog to work on a task and still have plenty of resources left over >> including video on-chip. >> >> If you are intrigued or just plain curious it won't kill you unless you >> are a cat to have a look at my introduction page which has links to >> projects and the forum etc. >> http://goo.gl/VX7pc >> >> There is the sup'ed up version of the Propeller, the Propeller II >> coming out in the following months which has 96 I/O, 8 cogs, 128K RAM >> and 160MIPS/core. >> >> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) >> that hang off the "I2C bus" from the Propeller and I can load new >> firmware into each chip using just one extra line to program them >> in-circuit. >> >> *peter* >> >> > Had a quick look (again) - it's not very fast and it's not very cheap > (compared with a CortexM4 clocked at 150MHz or more). Then there is all > the pain of programming and synching multiple cores which is (I think) > worse than the pain of managing DMA on a typical M4 based > micro-controller. > For some applications I'm sure it's a really good fit but I haven't hit > one yet. It's similar in concept to XMOS and Greenchip offerings but > like them suffers from a less than first rank supplier which would worry > most of my customers. > > MK Almost forgot, as for "first rank supplier" I can only say that all the big companies are the ones that let you down because they upgrade and suddenly the chip you are using is no longer current and may become hard to get and of course expensive. Parallax have supported the little guy just as well as the big and they have a track record of continuing to support their product (in many ways) over the years with assurances as well. How many companies these days are willing to make their chips available in DIP as well as SMD simply for "that" market? I have STM32F4 designs I'm working on mainly for Ethernet, as well as other vendor's ARMs and while the chips are impressive you can't really compare their raw speed with what the Propeller does and how it does it. Price is relative too but 8 bucks for eight 32-bit fully utilisable cores is very good value but the price goes down to under $4.50 in volume. *peter*
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.forth
csiph-web