re: Limit Cycle Tones, Chip Gracey said...
I've been thinking about this problem and what seems like the simplest solution is to put an LFSR and adder into the duty computation of the counters so that very-high-frequency dither could be added into the bit stream with some programmable level.
That's what I did for Brad, but it was at the 19KHz sampling rate. Doubling or even quadrupling the dither rate in software would be pretty easy, though. Chip, were you thinking of doing this in hardware?
I wish I could find Brad's thread on this topic. If I try the higher-frequency dithering, I'd prefer to post it there, rather than here.
-Phil
I can't find that thread either Phil. I had tried doubling the dither rate though and it made little difference.
I suspect a higher frequency might work.
Here's a snip from a Crystal Semiconductor white paper for their CS43122.
"A bilinear dither generator, using a 23-bit
LFSR, outputs a signal that is ±0.625% of full scale, and is summed at the quantizer input in the multi-bit
modulator. The pseudo-random sequence repetition rate is less than 1 Hz, at a 6.144 MHz sampling rate,
and is not audible. This helps to randomize delta tones, occurring at Fmodulator/2, which are seen when the
DC output level is exactly mid-way between any pair of adjacent quantization levels. Visible in band limit
cycle tones, although extremely low in amplitude, are effectively randomized by the dither generator."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Chip Gracey said...
Yeah, I mean 160MHz-updated up-to-32-bit signed dither that gets added to your PHS, along with FRQ.
Oh. Wow. Could this be done in PLL mode, too? It might help to spread out and knock down the birdies that occur in RF generation.
-Phil
Addendum: Or will the longer (programmable?) PLL time constant solve this?
I wonder if it would help. Maybe it would. It would have to bury those most-infrequent phase advances that cause the birdies. We could simulate this by making a short PASM program that sets a CTR to PLL mode and then keeps adding signed LFSR values into PHSA. No... wait. That would cause a frequency shift downwards as the add gets computed over two cycles, effectively always working on an outdated PHS value. Instead, the LFSR data would have to be copied into a register, the normal FRQ value added to it, then that would need to be written to FRQ. I'll post a little code later. Gotta go to the store with my brother-in-law.
BradC said...
Here's a snip from a Crystal Semiconductor white paper for their CS43122.
"A bilinear dither generator, using a 23-bit
LFSR, outputs a signal that is ±0.625% of full scale, and is summed at the quantizer input in the multi-bit
modulator. The pseudo-random sequence repetition rate is less than 1 Hz, at a 6.144 MHz sampling rate,
and is not audible. This helps to randomize delta tones, occurring at Fmodulator/2, which are seen when the
DC output level is exactly mid-way between any pair of adjacent quantization levels. Visible in band limit
cycle tones, although extremely low in amplitude, are effectively randomized by the dither generator."
I think that's it! If it worked for them, it would work for us.
I just figured up to 18x12 0.75mm pitch can be done on a 2 layer 4/4mil goldplated pcb $300 for a panel. If the center pins are used as power. 4 layer would be better for emi.
Phil Pilgrim (PhiPi) said...
Tubular, that's the one. How did you find it? I tried Google with the relevant keywords and got a bunch of other stuff, but not that one.
Using AltaVista, searching for Propeller Dither Bradc came up with 2 results, one was the correct one
I'm not sure why, but Google seems very hit and miss when searching this particular forum. Not just the local google search (search.parallax.com) but also the big google.com. AltaVista is a great backup as it seems to look at things a different way. But I have to admit its 12-15 years since I used AltaVista regularly
I've just finished reading this entire thread that seems to be growing faster than I can read it!
The Prop II sounds perfect. I don't have any suggested changes because I think it is perfect.
Re an on chip development system, I believe this is possible with the prop II and I also believe it is getting close to being possible with the Prop I. The key is to build it up in stages. Consider the zicog, triblade and dracblade. I now have sitting in front of me a propeller chip with external ram that has vga, keyboard, sd card, two serial ports and a small 20x4 LCD. It boots to an operating system (CP/M) but could easily boot to any other sort of operating system including PropDos.
I turn it on and it outputs text to three places - to the serial port and hence a terminal program on a PC, to the 20x4 LCD and to the VGA screen. Input comes from both the terminal program and from the local keyboard. To use this, more and more I'm not bothering to turn on my PC as the prop boots so much faster (2 secs).
So - what can it do? Well, to write a program you really need two things - a word processor and a compiler. Some CP/M programs combined these together (eg Mbasic) and some kept them seperate (C, Sbasic, Fortran). On a PC the trend is to combine them together in an IDE and there is no reason one can't write an IDE in CP/M or in any language you choose. Wordstar or Vedit could be a start though to keep things simple and some wordstar commands still exist (^Y on 2009's BST deletes a line!). Ok, so there already exists a method of editing a propeller text file on a propeller itself. I think there are other word processors that run on the prop directly from propdos that can do the same thing. Can we do color? Yes, I think that is possble so the CON and VAR look familiar. Just add a few custom VT100 escape codes. It might be a bit tedious changing quickly between objects, but I think that is possible. I think it would be a text based IDE, much like QuickBasic from the early 1990s. Blue screen, white text, menu the same as windows with File Edit etc along the top but you access them with the Alt key eg Alt FX to exit. I still use those shortcuts rather than a mouse.
Then there is the 'compiler' part. Brad has written one so maybe he can answer this, but the prop can already run many languages, including C and Basic. Can you write a Spin compiler in C? If so, then you can compile on the prop itself.
I see no technical obstacles to pulling all this together quite soon on a prop I. The only thing I think would be a problem is the speed. Running a C compiler on CP/M takes half a minute for short programs. But Catalina can speed things up there, and Catalina could dump the output to an sd card file that CP/M or PropDos can then use. If you want to then run that file on reset, just edit a .SUB file in CP/M so it runs that new program.
And if this can run on a prop I, it ought to be possible to port it to a Prop II.
With headpnones plugged into a demo board. I can definitely hear a tone. In most, but not all, settings of the shift constant, it's very high pitched, barely within the range of hearing. (Maybe I didn't listen to enough loud rock music when I was younger. )
Rest assured, this is not a phenomenon that's unique to the Prop. I've got a Korg KS-32 keyboard synth that exhibits the same symptoms, but to a much greater degree.
With headpnones plugged into a demo board. I can definitely hear a tone. In most, but not all, settings of the shift constant, it's very high pitched, barely within the range of hearing. (Maybe I didn't listen to enough loud rock music when I was younger. )
Rest assured, this is not a phenomenon that's unique to the Prop. I've got a Korg KS-32 keyboard synth that exhibits the same symptoms, but to a much greater degree.
(BTW, you need to set bit 10 of DIRA.)
-Phil
Phil,
Thanks for trying that.
So, it seems that the dither doesn't do much?
That $8003_0000 frqa value yields a limit cycle of 64k, since the least-significant bit is 16th down from the MSB. 80MHz/65536 (or 2^16) = 1,220Hz, which is in the ear's sensitive range.
Another thing that could be tried would be to integrate the dither into _frqa, then copy _frqa to frqa.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 3:26:04 AM GMT
Bill Henning said...
I have emerged from my cave, and catching up with this thread all I can say is WOW!
I really, really was going to leave you alone, so you can work on Prop2, and not ask any questions... but I'm too excited about the possibilities!
- I can't wait to get details on all the instruction set changes
- I gather the indirection is for either hub or cog registers, right?
The INDA/INDB registers are for the COG registers. The new RDxxxx/WRxxxx instructions have auto-incrementing/scaled pointers with signed constant offsets for easy structure access. Those pointers are initialized to what is now PAR.
- Will the video fifo extension to cog ram make it in, and be indirectly addressible?
Yes. It's mainly a CLUT for the video generator, but can be used for storage.
- does it really only take 5 pins for VGA out? That implies 5 bit dacs on every pin... I know you said dacs on every pin, but I thought we'd need at least a cap!
Yes, and no caps needed - just a direct connection for R/G/B/composite. You can still output discrete digital video to multiple pins, if you want.
- will rdxxx/wrxxx now work with INP and OUT ports directly without having to use a temp register?
Yes, all registers·will be accessible by both S and D, whereas INA is currently only readable by S.
- how will the new WAITVID work? Fifo'd? Cog reg range?
Basically the same, except rather than pass colors and pixels via D and S, you'll pass vscale and pixels, as colors will be read from the CLUT, based on the pixels.
- did the Manchester encoding/decoding make it into the counters?
Not yet. Could you give an example of what you'd like to see?
- any way of not using pin dacs for VGA so external DVI/hdmi encoder can be used? Yes, as explained above.
- I love the SPI boot, note the AT45D321 etc are 512 byte sector erasable vs 4K or greater for the 25xxx series
- what would be the max freq possible for A/D at 7 bits resolution?
160MHz/(2^7) = 160MHz/128 = 1.25MHz sample rate for 7-bit quality.
- perhaps boot partial port should be 0, so later, bigger BGA package could add ports 4,5,6,...
- any more details on high speed serial I/O?
No plans for LVDS, though a synchronous >40MB/s inter-Prop II serial scheme is already implemented.
I am warming up my CAD programs, raring to design Morpheus 2 (with Propeller 2)!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 4:00:33 AM GMT
The additional I/O capacity is really going to blow things out!!!
We've been constrained on this with Prop I. Once the extra memory projects hit, it was obvious the Prop could drive a very large number of pins. It will be interesting to watch that play out on Prop II.
One thing I've been recently wondering about is whether it would be possible to lock some or all IO's states and directions at run time to be modifiable by only one cog. Giving a "system cog" exclusive access to sensitive resources.
I believe the current prop has some locking mechanism for hub memory but I've never tried to use it myself.
Can't wait to see what you guys come up with!
David
INA as destination ... Cool [noparse]:)[/noparse] What is the number of cycles between HUB access per COG now?
We used to have a HUB window every 16 ticks ... this has changed if my memory serves me ... no?
5 pin HVRGB VGA is cool. Do we also get 1 pin TV?
Ethernet compatible Manchester encoding would be welcome ... not delaying the chip for that more so [noparse]:)[/noparse]
It's your baby to deliver though.
1) Built in development environment on the Prop II ROM.
Will this effect those who prefer to program in C (ImageCraft/Catalina)?
The built in development environment is an option and not an edict for use, correct?
It's just there in case the world ends and the Microsoft validation servers are off-line.
2) There was considerable work and cleverness needed in order to figure out how to create a kernel in order to run C compiled code.
Will the Propeller II be more open to C (or other language) development?
It can be programmed and booted however you'd like, launching into pure LOGO mode, if you make one.
3) Windows sucks too.
Please consider Unix(OS X)/Linux as the cross development platform of choice.
We'll probably first support Windows, because we don't know any better, but anything else could follow.
Delus said...
One thing I've been recently wondering about is whether it would be possible to lock some or all IO's states and directions at run time to be modifiable by only one cog. Giving a "system cog" exclusive access to sensitive resources.
I believe the current prop has some locking mechanism for hub memory but I've never tried to use it myself.
Can't wait to see what you guys come up with!
David
There's no locking mechanism for any resource, however there are some LOCK semaphores. We could give a single cog access to certain pins, but that would be the start of a road we won't go all the way down, as protected memory would be next. It seems to me that such stuff has to be worked out from the inception of a design to be fully effective.
jazzed said...
INA as destination ... Cool [noparse]:)[/noparse] What is the number of cycles between HUB access per COG now?
We used to have a HUB window every 16 ticks ... this has changed if my memory serves me ... no?
5 pin HVRGB VGA is cool. Do we also get 1 pin TV?
Ethernet compatible Manchester encoding would be welcome ... not delaying the chip for that more so [noparse]:)[/noparse]
It's your baby to deliver though.
Thank you for the answers - I can't wait to get my paws on Prop2!
You were asking about the Manchester encoding... it is used for Ethernet, and if it was supported by the counters/shifters, 10Mbps Ethernet would be dead easy, and even 100Mpbs might be doable on a Prop2 overclocked to 200Mhz (or at least counters/shift registers at 200MHz. en.wikipedia.org/wiki/Manchester_code
Ohh 1.25Msps samping for 7 bits... on many pins... love it.
40MB/sec inter-prop com implemented... love it even more!
For partial port 0, could we please have the other bits available as internal bits, so they can be used for inter-cog comm?
Or even better, allow cogs to "post" a long to another cog's FIFO, or wait for one - it would allow very fast inter-cog comm.
Great work!
Chip Gracey (Parallax) said...
Bill Henning said...
I have emerged from my cave, and catching up with this thread all I can say is WOW!
I really, really was going to leave you alone, so you can work on Prop2, and not ask any questions... but I'm too excited about the possibilities!
- I can't wait to get details on all the instruction set changes
- I gather the indirection is for either hub or cog registers, right?
- Will the video fifo extension to cog ram make it in, and be indirectly addressible?
<FONT color=blue>Yes. It's mainly a CLUT for the video generator, but can be used for storage.
- does it really only take 5 pins for VGA out? That implies 5 bit dacs on every pin... I know you said dacs on every pin, but I thought we'd need at least a cap!
- will rdxxx/wrxxx now work with INP and OUT ports directly without having to use a temp register?
<FONT color=blue>Yes, all registers will be accessible by both S and D, whereas INA is currently only readable by S.
- how will the new WAITVID work? Fifo'd? Cog reg range?
- did the Manchester encoding/decoding make it into the counters?
<FONT color=blue>Not yet. Could you give an example of what you'd like to see?
- any way of not using pin dacs for VGA so external DVI/hdmi encoder can be used?
<FONT color=#0000ff>
- I love the SPI boot, note the AT45D321 etc are 512 byte sector erasable vs 4K or greater for the 25xxx series
- what would be the max freq possible for A/D at 7 bits resolution?
- perhaps boot partial port should be 0, so later, bigger BGA package could add ports 4,5,6,...
- any more details on high speed serial I/O?
<FONT color=blue>No plans for LVDS, though a synchronous >40MB/s inter-Prop II serial scheme is already implemented.
I am warming up my CAD programs, raring to design Morpheus 2 (with Propeller 2)!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I *REALLY* like 3 pin component video... 1280x720 15-bit color would be great.
Chip Gracey (Parallax) said...
jazzed said...
INA as destination ... Cool [noparse]:)[/noparse] What is the number of cycles between HUB access per COG now?
We used to have a HUB window every 16 ticks ... this has changed if my memory serves me ... no?
5 pin HVRGB VGA is cool. Do we also get 1 pin TV?
Ethernet compatible Manchester encoding would be welcome ... not delaying the chip for that more so [noparse]:)[/noparse]
It's your baby to deliver though.
Happy Thanksgiving!
--Steve
You get one-pin
TV and three-pin component video.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
What I'm not hearing yet is "what input and output would any on board IDE be using?"
Given that the Prop is all about implementing peripheral devices in software making everything as flexible as possible then a raw un-programmed Prop has no peripherals for keyboard, mouse, screen. It has no way of knowing on which pins such things might be if they do exist or how to drive them. So if it's ROM happens to contain the necessary software for and editor and compiler etc then how would it be used?
Seems to me the IDE package in ROM would have to be absent any actual physical I/O and would never be in control at boot time. In the extreme it would simply have a standard input and standard output defined for character I/O as in the C/Unix world. stdio would then need to be physically implemented in COG software and real connected hardware by some booted application code that then calls on the IDE as required.
And what about the file system for saved source files and binaries. Same issue there.
So there it is. It's 2012, the civilized word ended as previously described, I've just looted a Prop II chip from my local distributor. My only possible computing platform is a bicycle dynamo powered ARM based Beagle board running Linux. How do do get into that chips IDE and start hacking Prop code to help rebuild civilization ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If one is getting into adding serial shifters to handle high speed ethernet USB etc doen't it also become necessary to add hardware CRC generation in order to keep up?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I can't find that thread either Phil. I had tried doubling the dither rate though and it made little difference.
I suspect a higher frequency might work.
Here's a snip from a Crystal Semiconductor white paper for their CS43122.
"A bilinear dither generator, using a 23-bit
LFSR, outputs a signal that is ±0.625% of full scale, and is summed at the quantizer input in the multi-bit
modulator. The pseudo-random sequence repetition rate is less than 1 Hz, at a 6.144 MHz sampling rate,
and is not audible. This helps to randomize delta tones, occurring at Fmodulator/2, which are seen when the
DC output level is exactly mid-way between any pair of adjacent quantization levels. Visible in band limit
cycle tones, although extremely low in amplitude, are effectively randomized by the dither generator."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I think this is it. In that thread there are links from Tracy back to earlier discussions
http://forums.parallax.com/showthread.php?p=841792
Yep, that's the one. And as I stated early on in the post I had already tried a 4xFs dither and still found it noisy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
-Phil
Post Edited (Phil Pilgrim (PhiPi)) : 11/26/2009 1:09:10 AM GMT
12x12 would give you 144 pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
Using AltaVista, searching for Propeller Dither Bradc came up with 2 results, one was the correct one
I'm not sure why, but Google seems very hit and miss when searching this particular forum. Not just the local google search (search.parallax.com) but also the big google.com. AltaVista is a great backup as it seems to look at things a different way. But I have to admit its 12-15 years since I used AltaVista regularly
The Prop II sounds perfect. I don't have any suggested changes because I think it is perfect.
Re an on chip development system, I believe this is possible with the prop II and I also believe it is getting close to being possible with the Prop I. The key is to build it up in stages. Consider the zicog, triblade and dracblade. I now have sitting in front of me a propeller chip with external ram that has vga, keyboard, sd card, two serial ports and a small 20x4 LCD. It boots to an operating system (CP/M) but could easily boot to any other sort of operating system including PropDos.
I turn it on and it outputs text to three places - to the serial port and hence a terminal program on a PC, to the 20x4 LCD and to the VGA screen. Input comes from both the terminal program and from the local keyboard. To use this, more and more I'm not bothering to turn on my PC as the prop boots so much faster (2 secs).
So - what can it do? Well, to write a program you really need two things - a word processor and a compiler. Some CP/M programs combined these together (eg Mbasic) and some kept them seperate (C, Sbasic, Fortran). On a PC the trend is to combine them together in an IDE and there is no reason one can't write an IDE in CP/M or in any language you choose. Wordstar or Vedit could be a start though to keep things simple and some wordstar commands still exist (^Y on 2009's BST deletes a line!). Ok, so there already exists a method of editing a propeller text file on a propeller itself. I think there are other word processors that run on the prop directly from propdos that can do the same thing. Can we do color? Yes, I think that is possble so the CON and VAR look familiar. Just add a few custom VT100 escape codes. It might be a bit tedious changing quickly between objects, but I think that is possible. I think it would be a text based IDE, much like QuickBasic from the early 1990s. Blue screen, white text, menu the same as windows with File Edit etc along the top but you access them with the Alt key eg Alt FX to exit. I still use those shortcuts rather than a mouse.
Then there is the 'compiler' part. Brad has written one so maybe he can answer this, but the prop can already run many languages, including C and Basic. Can you write a Spin compiler in C? If so, then you can compile on the prop itself.
I see no technical obstacles to pulling all this together quite soon on a prop I. The only thing I think would be a problem is the speed. Running a C compiler on CP/M takes half a minute for short programs. But Catalina can speed things up there, and Catalina could dump the output to an sd card file that CP/M or PropDos can then use. If you want to then run that file on reset, just edit a .SUB file in CP/M so it runs that new program.
And if this can run on a prop I, it ought to be possible to port it to a Prop II.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 11/26/2009 1:52:06 AM GMT
Could either of you try this out and listen for the tone BradC reported, and then try lowering the dither by increasing the 'sar temp,#8'?:
CON
··_clkmode······=·xtal1·+·pll16x
··_xinfreq······=·5_000_000
PUB·Go
· cognew(@start,0)
DAT
······· org
start·· mov···· ctra,_ctra
:loop·· test··· lfsr,taps··· wc· ··· 'iterate lfsr
······· rcl···· lfsr,#1
······· mov···· temp,lfsr··········· 'make signed dither n bits down
······· sar···· temp,#8
······· add···· temp,_frqa·········· 'add in frequency
······· mov···· frqa,temp··········· 'update frqa (frequency + dither)
······· jmp···· #:loop·············· 'repeat, 32 clocks/loop = 80M/32 = 2.5MHz dither update
_ctra·· long··· %00110 << 26 + 10
_frqa·· long··· $8003_0000
lfsr··· long··· $0000_0001
taps··· long··· $8006_1000
temp··· res···· 1
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
With headpnones plugged into a demo board. I can definitely hear a tone. In most, but not all, settings of the shift constant, it's very high pitched, barely within the range of hearing. (Maybe I didn't listen to enough loud rock music when I was younger.
Rest assured, this is not a phenomenon that's unique to the Prop. I've got a Korg KS-32 keyboard synth that exhibits the same symptoms, but to a much greater degree.
(BTW, you need to set bit 10 of DIRA.)
-Phil
Will this effect those who prefer to program in C (ImageCraft/Catalina)?
The built in development environment is an option and not an edict for use, correct?
2) There was considerable work and cleverness needed in order to figure out how to create a kernel in order to run C compiled code.
Will the Propeller II be more open to C (or other language) development?
3) Windows sucks too.
Please consider Unix(OS X)/Linux as the cross development platform of choice.
Great stuff! Thanks.
Thanks for trying that.
So, it seems that the dither doesn't do much?
That $8003_0000 frqa value yields a limit cycle of 64k, since the least-significant bit is 16th down from the MSB. 80MHz/65536 (or 2^16) = 1,220Hz, which is in the ear's sensitive range.
Another thing that could be tried would be to integrate the dither into _frqa, then copy _frqa to frqa.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 3:26:04 AM GMT
Chip Gracey
Parallax, Inc.
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/26/2009 4:00:33 AM GMT
We've been constrained on this with Prop I. Once the extra memory projects hit, it was obvious the Prop could drive a very large number of pins. It will be interesting to watch that play out on Prop II.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I believe the current prop has some locking mechanism for hub memory but I've never tried to use it myself.
Can't wait to see what you guys come up with!
David
Analog is good to have,
but main feature should be DVI or/and HDMI 10bit (x3) serial output mode.
·
What's the open-circuit P-P output of the "75-ohm" DAC?
-Phil
We used to have a HUB window every 16 ticks ... this has changed if my memory serves me ... no?
5 pin HVRGB VGA is cool. Do we also get 1 pin TV?
Ethernet compatible Manchester encoding would be welcome ... not delaying the chip for that more so [noparse]:)[/noparse]
It's your baby to deliver though.
Happy Thanksgiving!
--Steve
Thanks for the response, awesome!
graham
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
There's no locking mechanism for any resource, however there are some LOCK semaphores. We could give a single cog access to certain pins, but that would be the start of a road we won't go all the way down, as protected memory would be next. It seems to me that such stuff has to be worked out from the inception of a design to be fully effective.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
-Phil
Thank you for the answers - I can't wait to get my paws on Prop2!
You were asking about the Manchester encoding... it is used for Ethernet, and if it was supported by the counters/shifters, 10Mbps Ethernet would be dead easy, and even 100Mpbs might be doable on a Prop2 overclocked to 200Mhz (or at least counters/shift registers at 200MHz. en.wikipedia.org/wiki/Manchester_code
Ohh 1.25Msps samping for 7 bits... on many pins... love it.
40MB/sec inter-prop com implemented... love it even more!
For partial port 0, could we please have the other bits available as internal bits, so they can be used for inter-cog comm?
Or even better, allow cogs to "post" a long to another cog's FIFO, or wait for one - it would allow very fast inter-cog comm.
Great work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Given that the Prop is all about implementing peripheral devices in software making everything as flexible as possible then a raw un-programmed Prop has no peripherals for keyboard, mouse, screen. It has no way of knowing on which pins such things might be if they do exist or how to drive them. So if it's ROM happens to contain the necessary software for and editor and compiler etc then how would it be used?
Seems to me the IDE package in ROM would have to be absent any actual physical I/O and would never be in control at boot time. In the extreme it would simply have a standard input and standard output defined for character I/O as in the C/Unix world. stdio would then need to be physically implemented in COG software and real connected hardware by some booted application code that then calls on the IDE as required.
And what about the file system for saved source files and binaries. Same issue there.
So there it is. It's 2012, the civilized word ended as previously described, I've just looted a Prop II chip from my local distributor. My only possible computing platform is a bicycle dynamo powered ARM based Beagle board running Linux. How do do get into that chips IDE and start hacking Prop code to help rebuild civilization ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 11/26/2009 6:50:10 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.