Ahh, see with that the Prop could comfortably do full speed right now. It's the synchronization / decoding and serialization that consumes quite a bit of the time.
Yes, it should be able to manage it. OTOH, just adding an FTDI chip would be cheaper and easier.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Those limit-cycle tones will still be there, unfortunately. Sorry. I want to get rid of them, too, but they are difficult to eliminate.
The problem is when you have a single decaying string. As it decays toward zero, but still clearly audible the distortion superimposed around each zero cross is wild.
Chip Gracey (Parallax) said...
One way to get rid of them is to use PWM instead of duty modulation. You can do that right now on the current Prop. The only problem with PWM is that it must be run for its whole cycle. If you can tolerate that, it will be very quiet.
There's got to be some way to get rid of the limit-cycle tones in duty modulation without too much dither. Perhaps ultrasonic dither would work.
Ok, so it's not just me. I was starting to feel a bit odd. So many people are using a duty output to reproduce music, but the low level harmonics around the zero cross just drive me up the wall (decaying cymbals and violins are particularly bad). Back to valves and vinyl for me then [noparse]:)[/noparse]
I'd love to solve it too. I suspect with the P-II we might see better PWM resolution at high frequency than with the current chip.
If the dither was ultrasonic enough, a multi-pole analog filter is still cheaper than an external DAC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
These limit cycle tones appear not just at zero-crossings, but begin to be audible as amplitude·approaches a steady state. Here's a thing on wiki about it:
Wikipedia said...
"Limit cycles can appear in quantized systems such as sigma-delta DAC. They appear as faint tones when trying to reconstruct a constant amplitude. Modern DACs have various mechanisms to detect and cancel such tones."
Looks like I gotta woof us up a "modern" DAC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/24/2009 5:19:11 PM GMT
Will the extra 32 "C" pins be identical to group A and B? Is there some special purpose with them?
The original wait* design uses carry to choose group A/B. Has that changed? How will C be selected?
'Looks like your were up all night! You've probably crashed by now.
I just have a comment about standardizing on a crystal frequency for USB and other apps. It may not be entirely necessary. When I designed the Propeller Backpack, I had to use a 10MHz crystal to satisfy space constraints. This meant that I had code that constantly had to be flopped back and forth between 10x8 and 5x16, and it was driving me nuts. So I finally wrote an object that was able to detect the crystal frequency and set the clock registers accordingly. I did it by setting the PLL to 8x (to make sure the program would run) and setting a counter to PLL mode such that it would not lock at 80MHz. If it didn't lock, I knew I had a 10MHz crystal; if not, 5Mhz. This is rather brute force, but I wonder if it would be possible to use an internal RC timer while the crystal oscillator is running to determine the crystal speed. Obviously there would be restrictions, such as not using a 19.6608MHz crystal and expecting the system to distingush it from a 20MHz unit. But it would provide some design flexibility for those wanting to use something other than 20MHz.
BTW, the FT232R uses an internal 6MHz frequency reference that's accurate enough for USB work (but not for color video, it turns out). Any idea how this is implemented?
Who knew, when I first asked how might the on-chip development system be used, this thread would grow so interestingly.
Thanks, Chip, for having the time to comment. Appears that Propeller II, or whatever in-house designation might be, is progressing well. Even if Ken's first comments might have been taken as if Prop II chips might be available in Q1. That got clarified quicky. Thanks for that.
Over 150 responses on this thread! Thanks for all the discussion.
On Pg. 3 of this thread Chip said, "This way, no pins need to be spent on GND and we can get over three 32-pin ports out."· When I first read that--I mean after overcoming my initial shock-and-awe--I wondered if perhaps the third bank of I/O pins would be dedicated to a special purpose like accessing an exernal memory chip or for other types of communications (EEPROM/SPI/USB/SD Card).· Anyway, it seemed a bit odd that Chip just threw that out there nonchalantly-like, as if he were just sitting back to see how long it would take us to notice.· I think that's the first time it has been mentioned.· Perhaps he did it deliberately to see if we would ask whether the third bank had a special function.· Whatever the case, I'm okay with the "progressive disclosure."· Next, he'll parenthetically mention that each COG has a "sister/twin COG" of sorts, and then we'll ask does that mean there are 16 COGS in effect (Now don't start any rumors; he's specifically mentioned that there are only 8).· Anyway, it's likely that he's so busy that there hasn't been time for a formal feature list yet, hence the progressive disclosure.· That is, there's no reason to assume that he's "playing with us," though I don't think any of us would mind if he did that a bit (it's certainly his perogative to spice things up a bit).·*Edit*·Hmm...I just noticed that Chip said "over" three 32-pin ports out.· Does that mean that there could be a "partial" port/bank like a port 'D'?· Let's see:· 3x32=96 for 3 banks of I/O plus 12+8=20 power pins·and 2 for the crystal and say 2 for reset/brownout = 120 pins plus say 4 misc. pins would still leave 8 pins in a 128-pin package.· Wouldn't it be nice if those could be used for EEPROM/SPI/USB/SD Card, that way we'd have three "clean" banks we could depend on (in terms of writing objects) without having to worry so much about stepping on pins others were using when combining objects.· Well, I'm probably missing something in this musing.·
On·Pg. 6·of this thread Chips said, "The delta-sigma streams back through the INA/INB/INx bit."· For that, I found it interesting that he didn't just default to calling the third bank of I/O pins INC.· Why wouldn't he, I mean?· Well, it could just mean that he hasn't decided what to call them, and the x-suffix generally·means that it could stand for many options, such a 'C' or whatever, so that wouldn't necessarily imply anything (but see my edit above in red where in it could mean port INC and partial port IND).· On the other hand, it could stand for something like "extended" or "external" or "expansion."·· Yeah, it's certainly the case that I think too much sometimes (uh...I over-thunk it). ·But why stop now!··In other posts, he refers to symmetrical functions for all the I/O pins in terms of things like A/D and D/A and so on.· So, from a programming perspective, that would seem to indicate that the third bank is at least a "first-class citizen" with the·'A' and 'B' banks.· Although perhaps bank 'C' could be a super-citizen of some sort, to what end, I have no idea (so probably scratch that).
So, assuming that the third "bank" is basically a regular set, that might mean that we'll lose two longs in each COG for INx and OUTx configuration, admittedly a small price to pay for having 32 more I/O pins (unless the special purpose registers can be moved out somehow, which seems unlikely).· Then, as Jazzed mentioned, the WAITPEQ and WAITPNE instructions depend on the Carry flag, so something's gotta budge.· It could be that the 'C' bank is a second-class citizen with respect to these two instruction, wherein such instructions are not applicable to the 'C' bank.· On the other hand, some other opcode or flag magic could be used to include them, or perhaps be used for all three banks.· It will be interesting to find out what's the plan (perhaps it's still in the works...just as the center ground pad hadn't been fully...eh...pinned down yet·(though Chip seems pretty committed to it)).· On another matter, code-wise, we'll need more than 3 bits to refer to all the pin groups (we'll go from 8 8-pin pin groups currently to 12 8-pin pin groups, which will take 4 bits).· Well, I guess/hope that won't be a big deal, and I guess lots of little adjustments (and some big ones timing-wise) will be needed to convert existing objects.· Moreover, the second and third banks could perhaps just be ignored by much of the current·code.·*Edit*· Does anyone know of any other instructions that could enter into consideration in terms of the third bank?
While talking about·pins, I wonder if there's still a plan to allow us to set the voltage 1V8/3V3 for each group of·8 I/O pins.· I think I read that was·planned at one time.· I hope so.· It would be convenient.· For example, some small LCD displays use 3.3-volt logic and some of the newer ones use 1.8-volt logic.· Not having to use level-shifters to match·an·LCD or other logic chips would be a big advantage.· Yeah...I want one chip that does it all, so sue me.· But I'll take what I get.·
Post Edited (JRetSapDoog) : 11/25/2009 12:38:42 AM GMT
Maybe off topic again. But, you know what I would totally get jazzed about? It would be this: Something that I will call a Propple ][noparse][[/noparse]e (copyright me for that)
Now what the heck is that? It would be as small as possible single board computer (reminiscient of Apple ][noparse][[/noparse]e , Kim, Cosmac VIP (I know giving age here maybe)) that was completely self contained, sported an easy to work with expansion bus (PropBus or PropNet?), offered connects for modern HID, support for at least one VGA (or better) screen but did not need any of these to be functional and was dripping with I/O points that could be made to do all sorts of fun and interesting control related tasks.
This little wonder would allow the user to run any number of tasks that could be stored on the unit (real time deteministic multitasking on the platform would be the bomb!). For application development, a number of "full blown obex based widgets and/or drivers" would be pre-loaded into the unit. A graphical means of "hooking up the objects" into "object-chains or worker-sets" with "tap points" at the object boundaries would be very interesting as well for creating customized processing pipelines would be pretty neat as well. However for that to work, the objects would likely need the equivalent of a HAL and or some consistent mechanism of describing the specifics of the hardware mix they are running on.
Is that at all close to what is being discussed in here? Does any of this make any sense to any one except my own feverish imagination?
Chip: Firstly, thanks for sharing the information.
Now, I was pondering overnight, since we may now have 10K or 1K5 pullups or pulldowns, if the 10K and 1K5 were both enabled (in parallel) we get 1K3. This could be useful.
I know you said tolerance is only +/- 15%. I presume the tolerance is process related and therefore the resistors would likely all be the same value on the same die.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Could we have a promise of there being a version of the chip officially mounted on a breakout board, or one from the forum members that hold to a "standard". I work with SM stuff everyday but as we have little in the way of industrial mounting/unmounting I know how much I doubt the home construction possibilities (yeah, I know Parallax has to be·commertial first). So as there is now with the Prop 1, might there be a pin reduced, larger pitched, pluggable version for prototypes and general messing about with. Even if·the 128 pin version were to be placed onto a "daughter board" the connector would either be huge or just a cramped as the chip in the first place. Would a PLCC68/84 be out of the question? Even QFP44 would give the grunt of the Prop2 in Prop1's clothing ( or would that be too much of a thread to Prop1 sales?)
Basically, I am saying "Please can·I have a version that I can see". Otherwise it will be named the "WTFITC 1"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/25/2009 8:46:09 AM GMT
Being able to program, patch, fiddle or otherwise make a "device" "do something" with nothing much other than a PDA, Mobile 'phone or other "device" that can use a serial terminal [noparse][[/noparse]emulation] method is a remarkable achievment. Hear, Hear!
So is the Propeller II (goaled or) intended to be a:
(That should be enough to query the curious or knowledgable)
As far as stable frequencies go; can a "suitable" XTAL oscillator be included on-chip to forego all these speculations?
I see little reference for the use of multiplexed Address/Data line implementations (saving pin usage) [noparse][[/noparse]perhaps for performance reasons but...]; so is it possible to provide a mechanism for a P2 chip to provide an externally available signal to allow determining a RD/WT COG cycle [noparse][[/noparse]and SRC/DST] and/or the COG involved in same. Perhaps this could be done via the "special register" alluded to in previous posts. Could also form part of inter-COG communications providing this is programatically accessible.
Expanding the "special register" - this could also allow for a bit that signifies a "patched" (or updated) version of an instruction or IDE is available (if available from "probed" devices) - causing access of same from an "external" source. [noparse][[/noparse]implies reserved locations].
Of course this presumes that any machine instructions or embedded IDE is not bug free (or as near as is possible), but a carefully designed and implemented record of same would be accaptable to commit to ROM so the need for updating or patching is a moot point - right?
Will the extra 32 "C" pins be identical to group A and B? Is there some special purpose with them?
The original wait* design uses carry to choose group A/B. Has that changed? How will C be selected?
Thanks for taking time for us.
Yes, they will be the same. All pins are equal. No pins are more equal than any other pins. The nearest exception is that some fixed set of pins must be used for booting.
Since we have more than two ports, some rearrangement has been made about port access. In the current Propeller, there are 16 special-purpose registers. In the next Propeller, there are only 6:
$1FA· INDA····- Indirect register A. This is a window to any other RAM register.
$1FB· INDB··· - Indirect register B. This is a window to any other RAM register.
$1FC· INP···· - Port input. Like INA, but pointable to any port.
$1FD· OUTP··· - Port output. Like OUTA, but pointable to any port.
$1FE· DIRP··· - Port direction. Like DIRA, but pointable to any port.
$1FF· ALTP··· - Port alternate. Like the Alt-key for ports, selects new modes.
There are now instructions which are used to select the active port:
SETPORT #0..n······ - select port 0..n
SETPORT pinnumber·· - uses destination register contents' bit4+ to select port
For WAITPEQ/WAITPNE, whatever port is currently selected is what is waited on. There are timeout modes for these instructions, too, for which C=1 afterwards if a timeout occurred.
The counters, video, etc.·are now accessed via instructions, instead of registers. This affords improved functionality. For example, there is a GETPHSA instruction which reads what is now PHSA; there is also a CLRPHSA which reads PHSA and also clears it, eliminating the need to perform any delta calculation. Lots of stuff like this.
'Looks like your were up all night! You've probably crashed by now.
I just have a comment about standardizing on a crystal frequency for USB and other apps. It may not be entirely necessary. When I designed the Propeller Backpack, I had to use a 10MHz crystal to satisfy space constraints. This meant that I had code that constantly had to be flopped back and forth between 10x8 and 5x16, and it was driving me nuts. So I finally wrote an object that was able to detect the crystal frequency and set the clock registers accordingly. I did it by setting the PLL to 8x (to make sure the program would run) and setting a counter to PLL mode such that it would not lock at 80MHz. If it didn't lock, I knew I had a 10MHz crystal; if not, 5Mhz. This is rather brute force, but I wonder if it would be possible to use an internal RC timer while the crystal oscillator is running to determine the crystal speed. Obviously there would be restrictions, such as not using a 19.6608MHz crystal and expecting the system to distingush it from a 20MHz unit. But it would provide some design flexibility for those wanting to use something other than 20MHz.
BTW, the FT232R uses an internal 6MHz frequency reference that's accurate enough for USB work (but not for color video, it turns out). Any idea how this is implemented?
-Phil
Phil,
I think I will build a slower stable-as-I-can-make-it oscillator on the die and let the cogs see its state. This way, some gross timing assessment could be made if someone wanted to.
Making a monolithic and accurate timebase is difficult, but it has been done. Usually, these circuits can be designed to compensate for voltage and temperature variation, but must be tuned via non-volatile bits to overcome process variation. Maybe we'll have such a circuit. I'd have to invest some time in that.
I think the 128QFP is a good package for the PropII since it gives us all the I/O many of us need and its still small enough for people to mount on small carrier boards like those Futurlec ARM boards. Sure they aren't as small as a DIP40 but there's always the PropI for that market segment.
AFAIK the PLCC68/84 packages are a thing of the past for most IC's made today due to manufacturing costs.
JRetSapDoog said...
On Pg. 3 of this thread Chip said, "This way, no pins need to be spent on GND and we can get over three 32-pin ports out."· When I first read that--I mean after overcoming my initial shock-and-awe--I wondered if perhaps the third bank of I/O pins would be dedicated to a special purpose like accessing an exernal memory chip or for other types of communications (EEPROM/SPI/USB/SD Card).· Anyway, it seemed a bit odd that Chip just threw that out there nonchalantly-like, as if he were just sitting back to see how long it would take us to notice.· I think that's the first time it has been mentioned.· Perhaps he did it deliberately to see if we would ask whether the third bank had a special function.· Whatever the case, I'm okay with the "progressive disclosure."· Next, he'll parenthetically mention that each COG has a "sister/twin COG" of sorts, and then we'll ask does that mean there are 16 COGS in effect (Now don't start any rumors; he's specifically mentioned that there are only 8).· Anyway, it's likely that he's so busy that there hasn't been time for a formal feature list yet, hence the progressive disclosure.· That is, there's no reason to assume that he's "playing with us," though I don't think any of us would mind if he did that a bit (it's certainly his perogative to spice things up a bit).·*Edit*·Hmm...I just noticed that Chip said "over" three 32-pin ports out.· Does that mean that there could be a "partial" port/bank like a port 'D'?· Let's see:· 3x32=96 for 3 banks of I/O plus 12+8=20 power pins·and 2 for the crystal and say 2 for reset/brownout = 120 pins plus say 4 misc. pins would still leave 8 pins in a 128-pin package.· Wouldn't it be nice if those could be used for EEPROM/SPI/USB/SD Card, that way we'd have three "clean" banks we could depend on (in terms of writing objects) without having to worry so much about stepping on pins others were using when combining objects.· Well, I'm probably missing something in this musing.·
You figured it all out! The idea is to have three "clean" banks of pins with 8 more useful for booting/memory. The first three banks would be ports 0..2 and the last 1/4 bank would be the top byte of a port 3.
On·Pg. 6·of this thread Chips said, "The delta-sigma streams back through the INA/INB/INx bit."· For that, I found it interesting that he didn't just default to calling the third bank of I/O pins INC.· Why wouldn't he, I mean?· Well, it could just mean that he hasn't decided what to call them, and the x-suffix generally·means that it could stand for many options, such a 'C' or whatever, so that wouldn't necessarily imply anything (but see my edit above in red where in it could mean port INC and partial port IND).· On the other hand, it could stand for something like "extended" or "external" or "expansion."·· Yeah, it's certainly the case that I think too much sometimes (uh...I over-thunk it). ·But why stop now!··In other posts, he refers to symmetrical functions for all the I/O pins in terms of things like A/D and D/A and so on.· So, from a programming perspective, that would seem to indicate that the third bank is at least a "first-class citizen" with the·'A' and 'B' banks.· Although perhaps bank 'C' could be a super-citizen of some sort, to what end, I have no idea (so probably scratch that).
All pins and banks are equal. To make them unequal would be more work, not to mention, incongruous.
So, assuming that the third "bank" is basically a regular set, that might mean that we'll lose two longs in each COG for INx and OUTx configuration, admittedly a small price to pay for having 32 more I/O pins (unless the special purpose registers can be moved out somehow, which seems unlikely).· Then, as Jazzed mentioned, the WAITPEQ and WAITPNE instructions depend on the Carry flag, so something's gotta budge.· It could be that the 'C' bank is a second-class citizen with respect to these two instruction, wherein such instructions are not applicable to the 'C' bank.· On the other hand, some other opcode or flag magic could be used to include them, or perhaps be used for all three banks.· It will be interesting to find out what's the plan (perhaps it's still in the works...just as the center ground pad hadn't been fully...eh...pinned down yet·(though Chip seems pretty committed to it)).· On another matter, code-wise, we'll need more than 3 bits to refer to all the pin groups (we'll go from 8 8-pin pin groups currently to 12 8-pin pin groups, which will take 4 bits).· Well, I guess/hope that won't be a big deal, and I guess lots of little adjustments (and some big ones timing-wise) will be needed to convert existing objects.· Moreover, the second and third banks could perhaps just be ignored by much of the current·code.·*Edit*· Does anyone know of any other instructions that could enter into consideration in terms of the third bank?
Ports will now be·multiplexed to appear into a single set of INP/OUTP/DIRP/ALTP registers. This not only saves register space, but makes things like pin and port selection deterministic code-wise. Of course, video and counter circuits have their own pin-selection muxes which aren't affected by port muxing into the INP/OUTP/DIRP/ALTP registers.
While talking about·pins, I wonder if there's still a plan to allow us to set the voltage 1V8/3V3 for each group of·8 I/O pins.· I think I read that was·planned at one time.· I hope so.· It would be convenient.· For example, some small LCD displays use 3.3-volt logic and some of the newer ones use 1.8-volt logic.· Not having to use level-shifters to match·an·LCD or other logic chips would be a big advantage.· Yeah...I want one chip that does it all, so sue me.· But I'll take what I get.
Every set of 8 pins has its own VSS and VDD connection. The VDD can be set from 1.8 to 3.6 volts. The VSS will be fed from the bottom plate of the package, thereby achieving on-chip isolation from core VSS which will be noisy. This permits analog pin functions to have·a good degree of 'quiet', even though they share the same package-wide VSS.
I wonder if the limit cycle tones could be suppressed by companding, since they're most audible at low volume levels. This would require some non-linear analog post-processing, but it might be worth a try.
I wonder if the limit cycle tones could be suppressed by companding, since they're most audible at low volume levels. This would require some non-linear analog post-processing, but it might be worth a try.
-Phil
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.
(Sorry if this is on topic...··)
Would it make any sense to put a C or Spin LMM interpreter into that unused ROM space?
Or, how about a Prop 1 compatible Spin interpreter, so that Prop 2 could run Prop 1 code?
You guys are going to fast here (one day six pages). Some considerations/opinions from the long reading:
1) I agree with Cluso99 idea of also 1k5 pull-down. Beside led question IIRC this is the difference between a host and a device on the usb bus: host pull down while device pulls up; the line pulled (+ or -) indicates the supported speed.
2) I also like the BGA and the LQFP-128 (with central GND pad) but will prefer QFP-128 (http://www.practicalcomponents.com/amkor/amkor-pq-qfp.htm) for easier and cheaper prototyping (home etching). (A bit larger IC for dummies/hobbists/prototypers and a BGA or even mBGA for high integrated designs)
3) I am very interested in COUNTER modes (something new here, something expanded)? I wish:
if the two counters can have also a quadrature decoder up/down counter mode
if the two counters (even combined - working in tandem) are capable to produce a pwm output with variable duty-cycle.
if the two counters together can form a uart (one as baud generator, the other registers's (frq,phs) as send/receive buffers)
if the clock of the video circuitry can be supplied from the output mux instead of being taken directly from the plla output. In other words can I supply the clock without the plla so that I have the video hardware in sync with the system clock? This design can have the divider on bit 31, just the pll can be by-passed
Boot options:
1) I agree that usb should be the last on list
2) SPI flash and SPI mode SD can share the same pins except for the separete CS
3) SD in 4pin SD mode: license? Now what about the idea of having a driver in the ROM? In this way Parallax can pay the membership to the SD consortium and charge eg.$0.25 more per chip (I think Parallax will sale 4000 chips per year - for me also $0.5 more for high speed SD access is resonable). The user can call the low level block driver routines in rom and develop over the file system. We all have SD card readers and we use sd cards on our PCs. Are we violating some licenses? In this case isn't Parallax selling a product with built-in SD support like many notebook companies are doing and final users are not paying for any license?
Main clock circuitry:
1) The actual rc clock is low power purpose but very unstable. The PLL always multiply by 16 an then divide by X. The divider stage is integrated into the PLL. A mux choose the wished output.
2) Why not eliminate completly the internal RC (force to use an external crystal). The post PLL(x8) divider (I think it is a binary counter) stages are increased from /1 up to /64. The divider have an input mux to choose between the OSC output or the PLL output. The final mux select one of the divider outputs. Result: with a 20M crystal system clocks from 312K to 160M
PASM improvements:
1) just to refresh·the Reg0 issue http://forums.parallax.com/showthread.php?p=858203
2) MOVS:· movs reg2, reg1······· ; move source (reg1) bits 0-8 to destination (reg2) bits·0-8 (direct or indirect as usual) ············· movs reg2, reg1· wc· ; move source (reg1) bits 9-17 to destination (reg2) bits 0-8 (improvement, very useful when you are dealing with pointers and self-modifying code) ··· MOVD:· movd reg2, reg1······· ; move source (reg1) bits 0-8 to destination (reg2) bits·9-17 (direct or indirect as usual) ·············· movd reg2, reg1· wc· ; move source (reg1) bits 9-17 to destination (reg2) bits 9-17 (improvement, very useful when you are dealing with pointers and self-modifying code)
3) During some playing with CycloneIII an idea of basic paging for cog ram (4*496 longs) comes to me. All is floating arround this instruction ···············jmp Address···wc·· wz ···Basically the jump target is one of the available regs, the wc and wz flags is used to·select the page (modify the 2 msb address bits of the 8K space). From now on all the other instructions will refer to the last choosen page. If the PC rolls over the 496 reg it moves to the next page.·The special registers (ina,inb ...) are shadowed in all four the pages. The·feature can be configured with a hub special register like CLK one as not all cogs need all the ram: depending on their jobs. The ram can be relocated from hub ram: imagine this like 2K ICs that are switched from one bus (hub) to the other (cog). Uses: many, I am most working in pasm (it's easier than spin to me), but what about a spin interpreter with a built-in native pasm floating point support, user cofigurable extensions ...
Comments appreciated
PS:@Phipi, I know you are following this thread. I hope you can notice some improvements in my english, I am doing my best.
I am amazed that with all of the added features we even get a more space for code, i was expecting at least a few less. Will the instructions for phsa and such be done like hubop in prop 1, with additional instruction in the source register?
The idea is to have three "clean" banks of pins with 8 more useful for booting/memory. The first three banks would be ports 0..2 and the last 1/4 bank would be the top byte of a port 3.
Oh My! This is incredible!
In one case, we'll have 8 pins for boot support/serial media, and 96 pins for everything else. Time to start thinking very seriously about making some big 32 bit memory modules (up to 2 GB) work [noparse]:)[/noparse] With 384KB on chip, a 640x480 3:3:2 VGA 308KB display is possible along with up to a 64KB cache (no hardware magnitude comparator/cache controller of course). With 16 pins used for VGA, KB/Mouse, Audio, etc.... that still leaves 16 pins available for other applications.
In another case, without all the PC-ish junk the pins could provide enough control lines for a practically humanoid function robot with one chip. Communications with up to 48 PX832As would also be intriguing [noparse]:)[/noparse]
Possibilities become limited only by imagination, ability, time, and money rather than pin restrictions.
I see intense competitions on race to FAB once the IO spec is published [noparse]:)[/noparse]
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.
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
Yeah, I mean 160MHz-updated up-to-32-bit signed dither that gets added to your PHS, along with FRQ. I would certainly jumble up those limit cycle tones and be easily filtered out.
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?
- 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?
- how will the new WAITVID work? Fifo'd? Cog reg range?
- did the Manchester encoding/decoding make it into the counters?
- any way of not using pin dacs for VGA so external DVI/hdmi encoder can be used?
- 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?
I am warming up my CAD programs, raring to design Morpheus 2 (with Propeller 2)!
Great work Chip.
Chip Gracey (Parallax) said...
Phil Pilgrim (PhiPi) said...
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
Yeah, I mean 160MHz-updated up-to-32-bit signed dither that gets added to your PHS, along with FRQ. I would certainly jumble up those limit cycle tones and be easily filtered out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
Comments
Yes, it should be able to manage it. OTOH, just adding an FTDI chip would be cheaper and easier.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Post Edited (Leon) : 11/24/2009 4:14:15 PM GMT
The problem is when you have a single decaying string. As it decays toward zero, but still clearly audible the distortion superimposed around each zero cross is wild.
Ok, so it's not just me. I was starting to feel a bit odd. So many people are using a duty output to reproduce music, but the low level harmonics around the zero cross just drive me up the wall (decaying cymbals and violins are particularly bad). Back to valves and vinyl for me then [noparse]:)[/noparse]
I'd love to solve it too. I suspect with the P-II we might see better PWM resolution at high frequency than with the current chip.
If the dither was ultrasonic enough, a multi-pole analog filter is still cheaper than an external DAC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
These limit cycle tones appear not just at zero-crossings, but begin to be audible as amplitude·approaches a steady state. Here's a thing on wiki about it:
http://en.wikipedia.org/wiki/Limit-cycle
Looks like I gotta woof us up a "modern" DAC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/24/2009 5:19:11 PM GMT
Will the extra 32 "C" pins be identical to group A and B? Is there some special purpose with them?
The original wait* design uses carry to choose group A/B. Has that changed? How will C be selected?
Thanks for taking time for us.
'Looks like your were up all night! You've probably crashed by now.
I just have a comment about standardizing on a crystal frequency for USB and other apps. It may not be entirely necessary. When I designed the Propeller Backpack, I had to use a 10MHz crystal to satisfy space constraints. This meant that I had code that constantly had to be flopped back and forth between 10x8 and 5x16, and it was driving me nuts. So I finally wrote an object that was able to detect the crystal frequency and set the clock registers accordingly. I did it by setting the PLL to 8x (to make sure the program would run) and setting a counter to PLL mode such that it would not lock at 80MHz. If it didn't lock, I knew I had a 10MHz crystal; if not, 5Mhz. This is rather brute force, but I wonder if it would be possible to use an internal RC timer while the crystal oscillator is running to determine the crystal speed. Obviously there would be restrictions, such as not using a 19.6608MHz crystal and expecting the system to distingush it from a 20MHz unit. But it would provide some design flexibility for those wanting to use something other than 20MHz.
BTW, the FT232R uses an internal 6MHz frequency reference that's accurate enough for USB work (but not for color video, it turns out). Any idea how this is implemented?
-Phil
Who knew, when I first asked how might the on-chip development system be used, this thread would grow so interestingly.
Thanks, Chip, for having the time to comment. Appears that Propeller II, or whatever in-house designation might be, is progressing well. Even if Ken's first comments might have been taken as if Prop II chips might be available in Q1. That got clarified quicky. Thanks for that.
Over 150 responses on this thread! Thanks for all the discussion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
On·Pg. 6·of this thread Chips said, "The delta-sigma streams back through the INA/INB/INx bit."· For that, I found it interesting that he didn't just default to calling the third bank of I/O pins INC.· Why wouldn't he, I mean?· Well, it could just mean that he hasn't decided what to call them, and the x-suffix generally·means that it could stand for many options, such a 'C' or whatever, so that wouldn't necessarily imply anything (but see my edit above in red where in it could mean port INC and partial port IND).· On the other hand, it could stand for something like "extended" or "external" or "expansion."·· Yeah, it's certainly the case that I think too much sometimes (uh...I over-thunk it). ·But why stop now!··In other posts, he refers to symmetrical functions for all the I/O pins in terms of things like A/D and D/A and so on.· So, from a programming perspective, that would seem to indicate that the third bank is at least a "first-class citizen" with the·'A' and 'B' banks.· Although perhaps bank 'C' could be a super-citizen of some sort, to what end, I have no idea (so probably scratch that).
So, assuming that the third "bank" is basically a regular set, that might mean that we'll lose two longs in each COG for INx and OUTx configuration, admittedly a small price to pay for having 32 more I/O pins (unless the special purpose registers can be moved out somehow, which seems unlikely).· Then, as Jazzed mentioned, the WAITPEQ and WAITPNE instructions depend on the Carry flag, so something's gotta budge.· It could be that the 'C' bank is a second-class citizen with respect to these two instruction, wherein such instructions are not applicable to the 'C' bank.· On the other hand, some other opcode or flag magic could be used to include them, or perhaps be used for all three banks.· It will be interesting to find out what's the plan (perhaps it's still in the works...just as the center ground pad hadn't been fully...eh...pinned down yet·(though Chip seems pretty committed to it)).· On another matter, code-wise, we'll need more than 3 bits to refer to all the pin groups (we'll go from 8 8-pin pin groups currently to 12 8-pin pin groups, which will take 4 bits).· Well, I guess/hope that won't be a big deal, and I guess lots of little adjustments (and some big ones timing-wise) will be needed to convert existing objects.· Moreover, the second and third banks could perhaps just be ignored by much of the current·code.· *Edit*· Does anyone know of any other instructions that could enter into consideration in terms of the third bank?
While talking about·pins, I wonder if there's still a plan to allow us to set the voltage 1V8/3V3 for each group of·8 I/O pins.· I think I read that was·planned at one time.· I hope so.· It would be convenient.· For example, some small LCD displays use 3.3-volt logic and some of the newer ones use 1.8-volt logic.· Not having to use level-shifters to match·an·LCD or other logic chips would be a big advantage.· Yeah...I want one chip that does it all, so sue me.· But I'll take what I get.·
Post Edited (JRetSapDoog) : 11/25/2009 12:38:42 AM GMT
But limit you to serial only. Having a full-speed interface would allow the prop to emulate any USB device.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
Yes, it might even be used for USB OTG.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Now what the heck is that? It would be as small as possible single board computer (reminiscient of Apple ][noparse][[/noparse]e , Kim, Cosmac VIP (I know giving age here maybe)) that was completely self contained, sported an easy to work with expansion bus (PropBus or PropNet?), offered connects for modern HID, support for at least one VGA (or better) screen but did not need any of these to be functional and was dripping with I/O points that could be made to do all sorts of fun and interesting control related tasks.
This little wonder would allow the user to run any number of tasks that could be stored on the unit (real time deteministic multitasking on the platform would be the bomb!). For application development, a number of "full blown obex based widgets and/or drivers" would be pre-loaded into the unit. A graphical means of "hooking up the objects" into "object-chains or worker-sets" with "tap points" at the object boundaries would be very interesting as well for creating customized processing pipelines would be pretty neat as well. However for that to work, the objects would likely need the equivalent of a HAL and or some consistent mechanism of describing the specifics of the hardware mix they are running on.
Is that at all close to what is being discussed in here? Does any of this make any sense to any one except my own feverish imagination?
Now, I was pondering overnight, since we may now have 10K or 1K5 pullups or pulldowns, if the 10K and 1K5 were both enabled (in parallel) we get 1K3. This could be useful.
I know you said tolerance is only +/- 15%. I presume the tolerance is process related and therefore the resistors would likely all be the same value on the same die.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Maybe that's because 'inc' and 'ind' are opcodes?
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Could we have a promise of there being a version of the chip officially mounted on a breakout board, or one from the forum members that hold to a "standard". I work with SM stuff everyday but as we have little in the way of industrial mounting/unmounting I know how much I doubt the home construction possibilities (yeah, I know Parallax has to be·commertial first). So as there is now with the Prop 1, might there be a pin reduced, larger pitched, pluggable version for prototypes and general messing about with. Even if·the 128 pin version were to be placed onto a "daughter board" the connector would either be huge or just a cramped as the chip in the first place. Would a PLCC68/84 be out of the question? Even QFP44 would give the grunt of the Prop2 in Prop1's clothing ( or would that be too much of a thread to Prop1 sales?)
Basically, I am saying "Please can·I have a version that I can see". Otherwise it will be named the "WTFITC 1"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Post Edited (Toby Seckshund) : 11/25/2009 8:46:09 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
So is the Propeller II (goaled or) intended to be a:
1. Micro Controller
2. Advanced Micro Controller
3. Micro Processor
4. Micro Computer
5. Mini Computer
6. Computer
7. Mainframe Brain
8. On-Chip Cluster?
(That should be enough to query the curious or knowledgable)
As far as stable frequencies go; can a "suitable" XTAL oscillator be included on-chip to forego all these speculations?
I see little reference for the use of multiplexed Address/Data line implementations (saving pin usage) [noparse][[/noparse]perhaps for performance reasons but...]; so is it possible to provide a mechanism for a P2 chip to provide an externally available signal to allow determining a RD/WT COG cycle [noparse][[/noparse]and SRC/DST] and/or the COG involved in same. Perhaps this could be done via the "special register" alluded to in previous posts. Could also form part of inter-COG communications providing this is programatically accessible.
Expanding the "special register" - this could also allow for a bit that signifies a "patched" (or updated) version of an instruction or IDE is available (if available from "probed" devices) - causing access of same from an "external" source. [noparse][[/noparse]implies reserved locations].
Of course this presumes that any machine instructions or embedded IDE is not bug free (or as near as is possible), but a carefully designed and implemented record of same would be accaptable to commit to ROM so the need for updating or patching is a moot point - right?
Cheers,
Since we have more than two ports, some rearrangement has been made about port access. In the current Propeller, there are 16 special-purpose registers. In the next Propeller, there are only 6:
$1FA· INDA····- Indirect register A. This is a window to any other RAM register.
$1FB· INDB··· - Indirect register B. This is a window to any other RAM register.
$1FC· INP···· - Port input. Like INA, but pointable to any port.
$1FD· OUTP··· - Port output. Like OUTA, but pointable to any port.
$1FE· DIRP··· - Port direction. Like DIRA, but pointable to any port.
$1FF· ALTP··· - Port alternate. Like the Alt-key for ports, selects new modes.
There are now instructions which are used to select the active port:
SETPORT #0..n······ - select port 0..n
SETPORT pinnumber·· - uses destination register contents' bit4+ to select port
For WAITPEQ/WAITPNE, whatever port is currently selected is what is waited on. There are timeout modes for these instructions, too, for which C=1 afterwards if a timeout occurred.
The counters, video, etc.·are now accessed via instructions, instead of registers. This affords improved functionality. For example, there is a GETPHSA instruction which reads what is now PHSA; there is also a CLRPHSA which reads PHSA and also clears it, eliminating the need to perform any delta calculation. Lots of stuff like this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I think I will build a slower stable-as-I-can-make-it oscillator on the die and let the cogs see its state. This way, some gross timing assessment could be made if someone wanted to.
Making a monolithic and accurate timebase is difficult, but it has been done. Usually, these circuits can be designed to compensate for voltage and temperature variation, but must be tuned via non-volatile bits to overcome process variation. Maybe we'll have such a circuit. I'd have to invest some time in that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
AFAIK the PLCC68/84 packages are a thing of the past for most IC's made today due to manufacturing costs.
Chip Gracey
Parallax, Inc.
I wonder if the limit cycle tones could be suppressed by companding, since they're most audible at low volume levels. This would require some non-linear analog post-processing, but it might be worth a try.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Would it make any sense to put a C or Spin LMM interpreter into that unused ROM space?
Or, how about a Prop 1 compatible Spin interpreter, so that Prop 2 could run Prop 1 code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
1) I agree with Cluso99 idea of also 1k5 pull-down. Beside led question IIRC this is the difference between a host and a device on the usb bus: host pull down while device pulls up; the line pulled (+ or -) indicates the supported speed.
2) I also like the BGA and the LQFP-128 (with central GND pad) but will prefer QFP-128 (http://www.practicalcomponents.com/amkor/amkor-pq-qfp.htm) for easier and cheaper prototyping (home etching). (A bit larger IC for dummies/hobbists/prototypers and a BGA or even mBGA for high integrated designs)
3) I am very interested in COUNTER modes (something new here, something expanded)? I wish:
Boot options:
1) I agree that usb should be the last on list
2) SPI flash and SPI mode SD can share the same pins except for the separete CS
3) SD in 4pin SD mode: license? Now what about the idea of having a driver in the ROM? In this way Parallax can pay the membership to the SD consortium and charge eg.$0.25 more per chip (I think Parallax will sale 4000 chips per year - for me also $0.5 more for high speed SD access is resonable). The user can call the low level block driver routines in rom and develop over the file system. We all have SD card readers and we use sd cards on our PCs. Are we violating some licenses? In this case isn't Parallax selling a product with built-in SD support like many notebook companies are doing and final users are not paying for any license?
Main clock circuitry:
1) The actual rc clock is low power purpose but very unstable. The PLL always multiply by 16 an then divide by X. The divider stage is integrated into the PLL. A mux choose the wished output.
2) Why not eliminate completly the internal RC (force to use an external crystal). The post PLL(x8) divider (I think it is a binary counter) stages are increased from /1 up to /64. The divider have an input mux to choose between the OSC output or the PLL output. The final mux select one of the divider outputs. Result: with a 20M crystal system clocks from 312K to 160M
PASM improvements:
1) just to refresh·the Reg0 issue http://forums.parallax.com/showthread.php?p=858203
2) MOVS:· movs reg2, reg1······· ; move source (reg1) bits 0-8 to destination (reg2) bits·0-8 (direct or indirect as usual)
············ · movs reg2, reg1· wc· ; move source (reg1) bits 9-17 to destination (reg2) bits 0-8 (improvement, very useful when you are dealing with pointers and self-modifying code)
··· MOVD:· movd reg2, reg1······· ; move source (reg1) bits 0-8 to destination (reg2) bits·9-17 (direct or indirect as usual)
·············· movd reg2, reg1· wc· ; move source (reg1) bits 9-17 to destination (reg2) bits 9-17 (improvement, very useful when you are dealing with pointers and self-modifying code)
3) During some playing with CycloneIII an idea of basic paging for cog ram (4*496 longs) comes to me. All is floating arround this instruction
···············jmp Address··· wc·· wz
···Basically the jump target is one of the available regs, the wc and wz flags is used to·select the page (modify the 2 msb address bits of the 8K space). From now on all the other instructions will refer to the last choosen page. If the PC rolls over the 496 reg it moves to the next page.·The special registers (ina,inb ...) are shadowed in all four the pages. The·feature can be configured with a hub special register like CLK one as not all cogs need all the ram: depending on their jobs. The ram can be relocated from hub ram: imagine this like 2K ICs that are switched from one bus (hub) to the other (cog). Uses: many, I am most working in pasm (it's easier than spin to me), but what about a spin interpreter with a built-in native pasm floating point support, user cofigurable extensions ...
Comments appreciated
PS:@Phipi, I know you are following this thread. I hope you can notice some improvements in my english, I am doing my best.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Post Edited (dMajo) : 11/25/2009 7:07:20 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
In one case, we'll have 8 pins for boot support/serial media, and 96 pins for everything else. Time to start thinking very seriously about making some big 32 bit memory modules (up to 2 GB) work [noparse]:)[/noparse] With 384KB on chip, a 640x480 3:3:2 VGA 308KB display is possible along with up to a 64KB cache (no hardware magnitude comparator/cache controller of course). With 16 pins used for VGA, KB/Mouse, Audio, etc.... that still leaves 16 pins available for other applications.
In another case, without all the PC-ish junk the pins could provide enough control lines for a practically humanoid function robot with one chip. Communications with up to 48 PX832As would also be intriguing [noparse]:)[/noparse]
Possibilities become limited only by imagination, ability, time, and money rather than pin restrictions.
I see intense competitions on race to FAB once the IO spec is published [noparse]:)[/noparse]
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
-Phil
Addendum: Or will the longer (programmable?) PLL time constant solve this?
Post Edited (Phil Pilgrim (PhiPi)) : 11/25/2009 9:35:06 PM GMT
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?
- 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?
- how will the new WAITVID work? Fifo'd? Cog reg range?
- did the Manchester encoding/decoding make it into the counters?
- any way of not using pin dacs for VGA so external DVI/hdmi encoder can be used?
- 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?
I am warming up my CAD programs, raring to design Morpheus 2 (with Propeller 2)!
Great work Chip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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