uOLED-96-Prop - Propeller Clock Speed Limitations
Greg P
Posts: 58
I have just begun playing with the uOLED-96-Prop. This product is incredibly fun !!! Modifying the supplied spin code to display my own text, graphics, etc. was just too easy.
The next step is to gain access to the uSD card onboard. To assist in this effort, I decided to first add to the 96-Prop demo code my slightly modified version of a FullDuplexSerial object.
I assume the latest version of the FullDuplexSerial object is much enhanced over the original ... I haven't checked recently ... but my older & modified version allows for up to a 256 byte Fifo buffers for both send and receive. It has been tweeked by the required number of clock cycle delays to permit reliable operation up to 115.2kbaud. I have also added receive stop-bit detection and the option for the FullDuplexSerial cog to "auto transmit buffer" by sequentially testing several SPIN-level-defined buffers for a non-zero entry in their first byte, and if present use this first byte as a 'byte count' to send the remaining bytes in the buffer via the tx-line to the PC. This way another 'data acquistion' cog can supply new data to one buffer while the serial cog transmits the other buffer's content out to the PC.
When I added FullDuplexSerial to the uOLED-96-Prop demo code I was surprised to discover that it failed to function. From my visual-basic-based "serial terminal" I could 'see' that the Propeller was sending an endless stream of data ..00h ..00h ..00h .... These null characters were being sent immediately following Propeller power-up ... prior to issuing any specific serial commands from the console program. WHAT WAS GOING ON ? The modified FullDuplexSerial code has served me reliably in many other prior applications. What changed ?
I decided to go back to my 40-pin DIP version of the Propeller and see if I could replicate the problem there. The primary difference between the uOLED-96-Prop and my previous working applications was the use of an 8MHZ crystal using x16 PLL mode. My applications have always used a 5MHZ crystal with x16 PLL mode. Sure enough, the protoboarded DIP-version propeller circuit reproduced the same unwanted transmission of null characters to the PC at the higher 8Mhz PLLx16 operating frequency.
I dug deeper into the FullDuplexSerial cog and discovered after much effort that the test for "tx_tail index == tx_head index" was failing. If these two indexes are equal, there are no characters in the tx FIFO to send. If they differ, the data pointed to by the tx_tail index is acquired from the hub-memory based tx FIFO buffer, the tx_tail index is advanced (rolled over if necessary), and the acquired data byte is then transmitted. The tx_tail and tx_head indexes are both read from hub memory using two rdlong assembly instructions prior to a comparison test (with a cmp instruction) . It was this compare instruction which was apparently failing to behave properly. ADDING a single NOP instruction following the RDLONG (for the tx_tail index value) and the CMP instruction was sufficient to prevent transmission of the unwanted null characters. Unfortunately, this 'fix' did not restore proper operation. Even when multiple NOPs were intentionally added after every rdlong and wrlong instruction throughout the FullDuplexSerial cog code the problem persisted. While attempting to troubleshoot by having the Propeller send various 'bit patterns' via an unused test pin, I noticed those instructions which read or write the carry or zero flag seemed most likely to be affected at the higher operating frequency. Perhaps the 'wires' within the Propeller carrying those two signals are 'long' and numerous, adding additional internal capacitance, thus slowing them down by more than a clock tick at 120 Mhz ( 8.3 nS). Just a guess. Perhaps the spec should be adjusted downward somewhat. We don't want great companies like 4D Systems encountering undocumented surprises late in the game.
I decided to drive the 40-pin DIP Propeller circuit with my waveform generator. I started at 5Mhz output with the propeller configured for x16 PLL operation (80 Mhz internal oscillator). As expected all went well. I then stepwise increased the waveform generator's operating frequency, uploaded new propeller code with a modified_xinfreq statement adjusted to match this new frequency, and tested the FullDuplexSerial propeller code by sending from the PC serial console a simple command which expects a short multibyte reply at 115.2kbaud. Everything continued to behave correctly UNTIL I REACHED FREQUENCIES ABOVE 7.4 MHZ. At 7.4 Mhz (with an internal 118.4 Mhz oscillator) I still observe reliable operation. Between 7.4 and 7.5 Mhz data corruption begins ....
I went back to the uOLED-96-Prop device, and set it to operate at x8 PLL. With its 8 Mhz crystal, that's a 64 Mhz internal oscillator frequency (about 20% less performance than the typical 80 Mhz operation ). PROBLEM SOLVED. My FullDuplexSerial code now works perfectly fine.
Onward to the uSD access problem !!
CONCLUSIONS:
1) Definitely run any multi-cog-based uOLED-96-Prop applications using the x8 PLL setting.
2) It's likely 4D Systems ran all their code from SPIN and this hid any problems. I don't know why
running interpeted code from the hub should perform better then assembler cog at higher frequencies.
Any thoughts ?
3) The demo code for accessing the OLED display is written in SPIN code. It can be made to run much faster!!
Consider: 30 frame per second video goal
(I believe uOLED displays have a high frame rate near 100 fps ... not for sure ! )
96 x 64 pixels, at 2-bytes per pixel
That's: 30 x 96 x 64 pixel writes per second, or 184,320 pixel updates per second
[noparse][[/noparse]That's 368.64 kbytes per second (from the uSD card).... which I believe is do-able .. we'll see ! ]
The above math works out to 5.425 microseconds per pixel update for full 30fps video.
For a 8Mhz@ PLL: x8 configuration, with a 64 Mhz system clock, individual cogs run at 16 MIPS,
and require 62.5 nanoseconds per non-hub instruction to execute.
5425 nS / 62.5 nS = 86.8 assembly instructions may be executed per pixel update.
( By the way, if running at 80 Mhz, with 50nS instructions, 108 instruction cycles would be available per pixel )
My rough estimate of the number of assembly instruction cycles required to perform the 'PutPixel' instruction is about 80 ( this is very rough!) There are some initial bit shifts to compress the three RGB bytes into two bytes, then 6 low-level byte write operations to specify the row & column to be updated, followed by 2 low-level byte writes of the compressed 2-byte RGB color value. Note, from the timing diagram supplied by 4D Systems for their uOLED display, at least 3 instruction cycles (at 62.5 nS each) will be required at a minimum to hold the chip select line low. Perhaps other assembler code (hub data read for the next cycle ?) could be performed during this pause (instead of NOPs) to enhance overall performance.
This tentatively suggests that full-frame video may be possible (barely .. even 15 fps would be acceptable ..right? ). A double-buffered approach in which data acquired from the uSD card is alternately written to a pair of buffers by one cog while another cog alternately reads these same two buffers for updating to the uOLED display would be the method of choice. The buffers should be 512 bytes each ( the standard data block size for read/write access to the uSD card.)
Also, please note: a 2GB uSD card could hold about 90 minutes of uncompressed video! ( 368,640 bytes/sec x 60sec/min x 90min) About 60 MBs would be required to hold 90 minutes of audio (8-bit signed, sampled at 11 kHz), so just take about 3 minutes (~60MB) of video away from the 90 minutes figure above. Remember, at 15 fps, a 2GB card holds 3 hours of video! Now syncing the audio to the video ... that's a whole separate problem !!
The next step is to gain access to the uSD card onboard. To assist in this effort, I decided to first add to the 96-Prop demo code my slightly modified version of a FullDuplexSerial object.
I assume the latest version of the FullDuplexSerial object is much enhanced over the original ... I haven't checked recently ... but my older & modified version allows for up to a 256 byte Fifo buffers for both send and receive. It has been tweeked by the required number of clock cycle delays to permit reliable operation up to 115.2kbaud. I have also added receive stop-bit detection and the option for the FullDuplexSerial cog to "auto transmit buffer" by sequentially testing several SPIN-level-defined buffers for a non-zero entry in their first byte, and if present use this first byte as a 'byte count' to send the remaining bytes in the buffer via the tx-line to the PC. This way another 'data acquistion' cog can supply new data to one buffer while the serial cog transmits the other buffer's content out to the PC.
When I added FullDuplexSerial to the uOLED-96-Prop demo code I was surprised to discover that it failed to function. From my visual-basic-based "serial terminal" I could 'see' that the Propeller was sending an endless stream of data ..00h ..00h ..00h .... These null characters were being sent immediately following Propeller power-up ... prior to issuing any specific serial commands from the console program. WHAT WAS GOING ON ? The modified FullDuplexSerial code has served me reliably in many other prior applications. What changed ?
I decided to go back to my 40-pin DIP version of the Propeller and see if I could replicate the problem there. The primary difference between the uOLED-96-Prop and my previous working applications was the use of an 8MHZ crystal using x16 PLL mode. My applications have always used a 5MHZ crystal with x16 PLL mode. Sure enough, the protoboarded DIP-version propeller circuit reproduced the same unwanted transmission of null characters to the PC at the higher 8Mhz PLLx16 operating frequency.
I dug deeper into the FullDuplexSerial cog and discovered after much effort that the test for "tx_tail index == tx_head index" was failing. If these two indexes are equal, there are no characters in the tx FIFO to send. If they differ, the data pointed to by the tx_tail index is acquired from the hub-memory based tx FIFO buffer, the tx_tail index is advanced (rolled over if necessary), and the acquired data byte is then transmitted. The tx_tail and tx_head indexes are both read from hub memory using two rdlong assembly instructions prior to a comparison test (with a cmp instruction) . It was this compare instruction which was apparently failing to behave properly. ADDING a single NOP instruction following the RDLONG (for the tx_tail index value) and the CMP instruction was sufficient to prevent transmission of the unwanted null characters. Unfortunately, this 'fix' did not restore proper operation. Even when multiple NOPs were intentionally added after every rdlong and wrlong instruction throughout the FullDuplexSerial cog code the problem persisted. While attempting to troubleshoot by having the Propeller send various 'bit patterns' via an unused test pin, I noticed those instructions which read or write the carry or zero flag seemed most likely to be affected at the higher operating frequency. Perhaps the 'wires' within the Propeller carrying those two signals are 'long' and numerous, adding additional internal capacitance, thus slowing them down by more than a clock tick at 120 Mhz ( 8.3 nS). Just a guess. Perhaps the spec should be adjusted downward somewhat. We don't want great companies like 4D Systems encountering undocumented surprises late in the game.
I decided to drive the 40-pin DIP Propeller circuit with my waveform generator. I started at 5Mhz output with the propeller configured for x16 PLL operation (80 Mhz internal oscillator). As expected all went well. I then stepwise increased the waveform generator's operating frequency, uploaded new propeller code with a modified_xinfreq statement adjusted to match this new frequency, and tested the FullDuplexSerial propeller code by sending from the PC serial console a simple command which expects a short multibyte reply at 115.2kbaud. Everything continued to behave correctly UNTIL I REACHED FREQUENCIES ABOVE 7.4 MHZ. At 7.4 Mhz (with an internal 118.4 Mhz oscillator) I still observe reliable operation. Between 7.4 and 7.5 Mhz data corruption begins ....
I went back to the uOLED-96-Prop device, and set it to operate at x8 PLL. With its 8 Mhz crystal, that's a 64 Mhz internal oscillator frequency (about 20% less performance than the typical 80 Mhz operation ). PROBLEM SOLVED. My FullDuplexSerial code now works perfectly fine.
Onward to the uSD access problem !!
CONCLUSIONS:
1) Definitely run any multi-cog-based uOLED-96-Prop applications using the x8 PLL setting.
2) It's likely 4D Systems ran all their code from SPIN and this hid any problems. I don't know why
running interpeted code from the hub should perform better then assembler cog at higher frequencies.
Any thoughts ?
3) The demo code for accessing the OLED display is written in SPIN code. It can be made to run much faster!!
Consider: 30 frame per second video goal
(I believe uOLED displays have a high frame rate near 100 fps ... not for sure ! )
96 x 64 pixels, at 2-bytes per pixel
That's: 30 x 96 x 64 pixel writes per second, or 184,320 pixel updates per second
[noparse][[/noparse]That's 368.64 kbytes per second (from the uSD card).... which I believe is do-able .. we'll see ! ]
The above math works out to 5.425 microseconds per pixel update for full 30fps video.
For a 8Mhz@ PLL: x8 configuration, with a 64 Mhz system clock, individual cogs run at 16 MIPS,
and require 62.5 nanoseconds per non-hub instruction to execute.
5425 nS / 62.5 nS = 86.8 assembly instructions may be executed per pixel update.
( By the way, if running at 80 Mhz, with 50nS instructions, 108 instruction cycles would be available per pixel )
My rough estimate of the number of assembly instruction cycles required to perform the 'PutPixel' instruction is about 80 ( this is very rough!) There are some initial bit shifts to compress the three RGB bytes into two bytes, then 6 low-level byte write operations to specify the row & column to be updated, followed by 2 low-level byte writes of the compressed 2-byte RGB color value. Note, from the timing diagram supplied by 4D Systems for their uOLED display, at least 3 instruction cycles (at 62.5 nS each) will be required at a minimum to hold the chip select line low. Perhaps other assembler code (hub data read for the next cycle ?) could be performed during this pause (instead of NOPs) to enhance overall performance.
This tentatively suggests that full-frame video may be possible (barely .. even 15 fps would be acceptable ..right? ). A double-buffered approach in which data acquired from the uSD card is alternately written to a pair of buffers by one cog while another cog alternately reads these same two buffers for updating to the uOLED display would be the method of choice. The buffers should be 512 bytes each ( the standard data block size for read/write access to the uSD card.)
Also, please note: a 2GB uSD card could hold about 90 minutes of uncompressed video! ( 368,640 bytes/sec x 60sec/min x 90min) About 60 MBs would be required to hold 90 minutes of audio (8-bit signed, sampled at 11 kHz), so just take about 3 minutes (~60MB) of video away from the 90 minutes figure above. Remember, at 15 fps, a 2GB card holds 3 hours of video! Now syncing the audio to the video ... that's a whole separate problem !!
Comments
Have fun experimenting with the video idea.· Any thoughts for the conversion process from some standard digital video format to the kind of bitmap sequences you describe?· The issue of audio synchronization implies that video frames should carry some kind of timestamp that can be compared to a similar audio timestamp.
Post Edited (Mike Green) : 11/1/2007 10:50:23 PM GMT
Can anyone read Russian? http://display.chipexpo.ru/press/OLED_Mithp_2007_2.pdf
little controller chip on the OLED-96. And I also think running the Prop at 64MHz is where you want to be; running it at
128MHz is doing simultaneous debugging of your code and praying that your Prop actually works correctly that much out
of spec. I've got enough issues getting my code to work without worrying about electron flight time, internal setup and
hold times, etc.etc.etc.
I suspect we're pretty close to these specs. Judging by how the chips are offered, they are categorized by display size
.
Post Edited (Fred Hawkins) : 11/1/2007 11:39:53 PM GMT
http://www.websitetoolbox.com/tool/post/4d/vpost?id=2254404
I think Atilla answers the question.
Don't be fooled. In his answer he shows Spin code with assembly language timing.
Lucidman
It does seem inexplicable. The Spin Interpreter has to do hub reads and writes and I cannot believe the entire interpreter is written without using C or Z flags. It seems more luck than anything else that problems have not appeared with Spin code. Maybe it's the running of more cogs which starts to upset things ?
You could possibly have got a 'bad batch' of Propeller when it comes to reliable 128MHz operation. 4D Systems apparently guarantee you can have 128MHz at room temperature or they'll replace it. It may be worthwhile contacting them direct or through their forums at www.websitetoolbox.com/mb/4d?forum=80924. It would be beneficial at least to find out what guarantees there are and the conditions attached.
Running at PLL8x is a solution, but it's a shame to have to drop to 64MHz when 96MHz ( 6MHz x 16 ) appears to have proven itself reliable.
Previous discussion on the uOLED-96-PROP and discussion of its 128MHz operation can be found here : http://forums.parallax.com/showthread.php?p=679308
Let me ask you; Why have you not heard one single word from Parallax during this discussion? Are they not aware that the·reliability of the Propeller chip has come into question (bad batch, good batch, lucky batch)? Are they unaware that there are some serious questions about the believability of the published specification for the Propeller chip (products manufactured to the published specification fail).
Parallax is in an interesting position with respect to the uOLED-96-PROP. It's their chip, they sold it to the Mfr. with implicit warrantees of servicability and performance·(the datasheet) and now, having sold the chip once to the Mfr., they get to sell it AGAIN in the form of a finished product.
And in spite of·and in the face of evidence to the contrary, some of you will continue to believe, and defend, statements made by a company that won't defend itself or its product or provide a single word to clarify these discussions. The only meaningful response has been from the innocent Mfr. (4D Systems in Australia),·who's only mistake was designing a product around a piece of hardware that apparently fails to·live up to its published specification.
I can hear you now: "You don't understand the value of products like the Propeller!" I do understand, but don't try to tell·me that building some collection of parts on a breadboard that will play an MP3 file is·an iPod. Don't tell me that the Propeller chip is 'cutting-edge technology', when most users on this forum couldn't make it do what a calculator from the Dollar Store can do (Add, Subtract, Multiply, Divide and display the results). The Propeller is an interesting chip, not so much for what it is, but for what it tries to be. How many commercial products use the Propeller chip (the uOLED-96-PROP being a notable exception). And you've probably made the Mfr. sorry he even tried to give you something of value. You cry FOUL, HERACY, IT CAN"T BE TRUE!·And then you set out to prove that everything that's been poured in you ears for the past year or so is gospel and there is no truth except the Parallax truth.
SHEEP!
Adoy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
One's true identity can only be learned through reflection.
I don't think you understand. Parallax has rated this chip to run at 80MHz, and it appears many times in different documents, ie Page 16 of the Propeller Manual. 4D systems, while they are using a crystal that is in spec, are using a PLL setting with the combination of the crystal that puts the chip core frequency way over spec, 60% over. The 8MHz Crystal is not a problem, because the Hydra has used a 10MHz Crystal(also sold by Parallax) reliably for 18 months. I think it rediculous if I overclocked my 1.2GHz PentiumM processor in my notebook to 1.92GHz and complained to Intel or Sony that it didn't work reliably and it "must be flawed to the point it won't perform to its specification."
Hope this helps,
Doug
It is not the fault of Parallax when adventurous members of this forum - against all warnings and explanations given in this forum why it will not and cannot work reliably - will continue to report:" Oh, with me it runs A LIITLE BIT at 128 MHz".
If you want you call them "SHEEP" - but for different reasons
I think it is a wise move from Parallax to not comment these things: They can just repeat their former statements.
Each and every processor in the world can be set to dangerous und unreliable parameters! There is no design flaw in the OLED-thing, except "4D" spokespersons should have been a little bit more prudent about their performance statements...
Post Edited (deSilva) : 11/2/2007 5:52:38 AM GMT
i know you pride yourself in acting like "a man among boys", but I'm surprised to find that you are one of the sheep.
When you say: [noparse][[/noparse]quote] against all warnings and explanations given in this forum why it will not and cannot work reliably - will continue to report:" Oh, with me it runs A LIITLE BIT at 128 MHz".[noparse][[/noparse]/quote]
Please·avail yourself·of the following from Page 13 of the Propeller Datasheet Version 0.3 (latest that I'm aware of):
PLLENA Effect
Enables the PLL circuit. The PLL internally multiplies the XIN pin frequency by 16. OSCENA must be ‘1’ to propagate the XIN signal to the PLL. The PLL’s internal frequency must be kept within 64 MHz to 128 MHz – this translates to an XIN frequency range of 4 MHz to 8 MHz. Allow 100 µs for the PLL to stabilize before switching to one of its outputs via the CLKSEL bits.
A designer cannot rely on anecdotal "evidense" when designing a product, but rather must rely on published data from the manufacturer of the part in question.
[noparse][[/noparse]quote] They can just repeat their former statements.[noparse][[/noparse]/quote]· Right! And expect the sheep to continue to believe.
[noparse][[/noparse]quote] Each and every processor in the world can be set to dangerous und (and)·unreliable parameters![noparse][[/noparse]/quote]. Please point out where Parallax warns in publically available documentation (again not anecdotal remarks) where using an 8MHz crystal and PLL16x is "dangerous and unreliable" or even words that approximate that statement.
You comments here prove my point Re: sheep.
@ hinv
No, I do understand. It's you who refuses to accept the evidence before you. I will quote again from Page 13 of the most recent Propeller datasheet: "The PLL’s internal frequency must be kept within 64 MHz to 128 MHz – this translates to an XIN frequency range of 4 MHz to 8 MHz."
How you can read that information and conclude that [noparse][[/noparse]quote] that puts the chip core frequency way over spec, 60% over.[noparse][[/noparse]\quote] is behond all reason. And then compound the error by suggesting that operating a processor at or near the top of its "specified" range is somehow "overclocking".
Accepted wisdom is not the same as the truth.
Adoy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
One's true identity can only be learned through reflection.
Post Edited (Adoy Esiw) : 11/2/2007 6:48:06 AM GMT
Harrison
(the PLL8X "tap" is the PLL frequency divided by 2). The PLL is designed to run up to 128MHz. But the Prop
itself only runs up to 80MHz. The only way to run the Prop at (for instance) 60MHz is to run the PLL at 120 MHz
and then choose the PLL8X tap.
4D systems has a great product. I don't know who Adoy Esiw is, but if he's in any way affiliated with the
company, he seriously runs the risk of embarrassing that company. There's nothing wrong with the OLED-96;
it runs fine at 64MHz.
The specifications very clearly and unambiguously state the system clock speed is rated between DC
and 80MHz. I can't even believe we're having this discussion.
Pardon me while I get back to·developing a more efficient circle method, a polygon·method and getting full duplex serial comms working on the poor little, and much maligned, uOLED-96-PROP (still running at 128MHz without a problem).
As an aside, there is a small bug in the V4 Propeller object for the 96-PROP that prevents writing text to the rightmost column of the display when using the PutText method..· The simple fix: in the PutText method, change both occurrances of "95" to "96" as below.
if X > 96 / 8 X := 0 Y += 1 elseif X > 96 / 6Adoy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
One's true identity can only be learned through reflection.
Thanks for that, I'm sure it's greatly appreciated by all of us. It gave me a cheering smile anyway.
Can you show any warranty, datasheet, documentation or statement where Parallax has said that the Propeller Chip is guaranteed to work reliably at 128MHz at room temperature ?
Parallax have said that the oscillator / clock PLL will work up to 160MHz but that is nowhere near the same as saying that the Propeller Chip will function reliably at 128MHz. Indeed, Parallax staff have indicated the opposite if means are not taken to ensure that ( eg forced cooling ).
4D System's 'innocent mistake' may have been to assume that if the PLL works up to 160MHz as promised then the rest of the chip will work reliably at 128MHz.
I actually hope 4D are proven right that Propeller Chips can run reliably at 128MHz at room temperature using nothing more than good design, even if it does mean a bit of picking and choosing chips, and I am pretty sure everyone else here would like to see that too. 4D have given a plausible explanation as to why they believe it should, why it appears to do so, and initial evidence suggests it does. However, there are cracks appearing with regards to operation at 128MHz.
Coming over like a fanboy, accusing people of being sheep, Parallax of having given warranties and published specifications that guarantees 128MHz operation of the Propeller Chip when there is no evidence to support that they have done so does not help in anyway.
Time to hit the 'thumbs down' ignore button for Adoy Esiw.
If he consulted an attorney rather than try to speak with the authority of one, I suspect he would find 80Mhz is the well-documented and well-supported claim - while Parallax has often said you are welcome to overclock at your own risk because we know it is likely to run all day [noparse][[/noparse]but hot] at 100Mhz.
If we are all sheep, you are a paper tiger. BAAA. Or a tempest in a teapot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
Guess we SHEEP will be treated to braying about the Force soon. Wonder who makes it? This too shall be revealed. Then if we're really good we can troop over to the True Believers Site and get beat over the head some more.
Adoy, you have a total misunderstanding of the reasons behind data sheets and the spirit they are used in. Datasheets give - among others - maximum ratings for many (not all!) relevant parameters, as
-- environment temperature
-- input voltage
-- power dissipation
to just mention the most important.
There are important couplings between those parameters, not easy to compute, if at all.
Comprehensive data sheets thus give you diagrams for pairs of these parameters, sometimes hiding a third dimension in parametrized curves.
It is well understood, by all developers, that maximum values have to be obeyed in total, not just one of them.
From time to time there is the discussion of "Which input voltage is allowed for the ProtoBoard?"
Parallax says : 9V. This is very wise, as it will delimit the max dissipation at the regulator to a reasonable value when drawing a resonable current.
Parallax could as well have said: "30V", because this is something to be found in the datasheet of the regulator.
But the (regulator) datasheet also makes clear that this would drastically reduce the allowed current to an unpractical value. This is obvious to everyone understanding how a regulator works. In fact you will find little "rational" in the regulator datasheet HOW it works, even if you find - which you generally will! - a complete circuit sketch of it.
I agree that discussions about what "works" and what not is sometimes a little bit too pragmatical here.....
I am working in an area where "safety critical" devices are needed and used... I still remember a phrase from a customer, when - many years ago - I presented him a very sweet solution to his requirements, just "slightly" out of his formal spec. He said: "We don't want a system that will work just by chance"
Post Edited (deSilva) : 11/2/2007 6:06:21 PM GMT
I would offer an analogy: Just because·a car maker claims that their car can go 120 MPH (~200 KPH), doesn't mean that you should blame the maker because it won't "corner" at 120 MPH! Straight-line speed and the maximum speed under all conditions are very different values. So it is with the 96-PROP. If one can run the module at reliably at 128MHz for a particular function, why wouldn't one. If however, one's project does not lend itself to "flat out, like a lizard drinking" speed, then throttle it back to a usable speed. Rokicki had the right idea when he said that the 96-PROP works very well at 64MHz for many purposes.
Adoy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
One's true identity can only be learned through reflection.
Running reliably ALSO needs "testing", but in the first place needs a theoretical foundation. I will never under no circumstances believe what I see when I encounter a "perpetuum mobile" - and I am in good company since 1775..
You will find many, many postings here from Parallax staff, freely having given their results from testing the Propeller under some extreme conditions, also describing the effects to be expected when you "over do". The symptoms are the symptoms the OP gave in his posting. So: NO surprise atall.
Except the analogy is not correct. You still appear to be trying to claim that Parallax has made misleading claims and is unable to deliver on what it promises.
Parallax have said the Propeller Chip will work at 80MHz ( 20MIPS per Cog, as it says in the datasheet ). Their 'car' goes just as fast as they claim it does, straight line and corners at 80MHz.
They have also said it is possible to make it go much faster but added that things will start to 'fall off' or break, or you'll have to do things to achieve those higher speed, and even then they've only said it should probably work but have offered no guarantees of that, nor made any promises.
Nowhere in the datasheet, which you take as Gospel, do Parallax say the Propeller Chip as a whole will run at 128MHz. They say some parts of the Propeller Chip will ( up to 160MHz ), but not the whole.
You cannot blame Parallax for things not working out when they've never promised that and the datasheet doesn't claim that it will work. Neither can Parallax be blamed for anyone failing to understand what the datasheet does say or drawing incorrect conclusions based upon what it states.
·I think that this discussion have no sense.
So as hippy talks Propeler of ship there is specify on 80MHz and giving from itself to to near 100/110 Mkhz gives much more than it is possible to expect.
And so as I gave in my test more than satisfy me that. At the good cooling it is possible to have yet anymore but as I wrote in the test in beginning – This is Customers responsibility.
·
As also I wrote in the temperature of room I achieve a bit over 110MHz and at attempts small problems come forward with greater speed. If PLL is not used in COG it is possible to reach to higher speed But it has a less value already.
·
Major as someone already here wrote that achievement of 30-40% more than specification is much better than most IC chips.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Thanks, and sorry for the out-of-band transmission.
More telling is that in spite of a direct question (in http://forums.parallax.com/forums/default.aspx?f=25&m=220292&p=3): do the cog counters still work at 128Mhz, no answer was forthcoming. So until we know that they work 100% of the time at that speed, as far as I am concerned, 64mhz is the best practice.
Meanwhile, I would still like a decent datasheet for the Solomon Systech controller. A handful of machine language lines (thanks Atilla) don't suffice.
http://www.websitetoolbox.com/tool/post/4d/vpost?id=2264823
I get a subtle·feeling that they are trying to protect their family jewels.
Lucidman
I suppose that Americans get used to arguing about one phrase out of context rather than considering the meaning of the content as a whole.
After all, we have our politicians who do this once every four years. They are very bad role models.
Meaning is more that one item. It is a pattern of symbols repeated from various points of view that test and reaffirm what is really meant to be represented.
Since I was called a sheep so many times, I got the meaning of that and jumped in. But it is all rather silly and as usual -- all is forgiven.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······