I run one prop with 120MHz and have litle problem in Video PLL. But rest in Prop funktion corect.
I have no problem to Crystal 14_318_180/PLLx8 = 114.545.440MHz.
I don't think that is the point, some chips may run at higher speeds others not, at least according to Chip et al.
I don't see how there can be any trick, if the processors are running at 128Mhz then they are running at 128Mhz and that according to parallax sources is too high for all propeller chips. Perhaps they vet the chips for chips that do operate at 128Mhz and perhaps not. Either way I think it is something worth a real answer. We can take it even if it is "some small % may fail but we will replace them".
I wish they had just stook a 10Mhz crystal on like the prop stamp has as I want my stuff to run at 80Mhz most of the time full stop.
I'm sure the new week will bring all the answers we need, this display is just so cool. And Mike's comments about booting programs from the SD card really got me thinking!!
I think you may be onto something. It may also be the packaging as well. Most of run q44 and dip40 versions of the propeller. The m44 version has a big square pad in the middle. Is that working like a heat sink, or is it just connected by a thin gold wire like the other pads?
POST EDIT: It looks like hinv already read the response from 4D!
The surprising thing to me throughout this whole discussion about running the Propeller chip at a given speed (whether it be 80MHz,100MHz or 128MHz), is that there is never a mention of which Propeller chip we're talking about or the layout of components (there's a HUGE difference between a breadboarded 40 pin DIP Propeller and the highly optimized design of the uOLED-96-PROP using a QFN Propeller chip). Someone asks: "Can the Propeller run at 100MHz?" and people start jumping in with all manner of opinions based on who knows what design criteria.
It wasn't even clear to me from the responses from Parallax (that people love to quote) about seeing failures at 110MHz what the physical setup was and what chip was being tested. Many use the term "Propeller Chip" as if it were a single part instead of being specific about which of the three available Propeller chips they're talking about. Also, there are a number of Prop development platforms. From the PEK and Starter kit on breadboards, the Prop Dev board, the Prop Proto board, Bean's Prop Dongle, the uOLED-96-PROP and others. All different and with, I'm sure, very different performance characteristics when it comes to the Propeller chip. For example, it wouldn't surprise me that trying to run the PEK setup with an 8MHz Xtal at 128MHz would have problems. By the same token, it wouldn't surprise me to find that the 96-PROP could run with a 10MHz Xtal at 160MHz. Different chip, VERY different design, different results.
This whole thing about there being some "trick" to running a particular version of the Propeller chip at it's designed speed was meant to be tongue-in-cheek. Why the lengthy discussions about can or can't when it's obvious that it can perform according to spec because you can have a product in your hand that does it. And yet, because of some obscure reference to observed failures (without a frame of reference as to exactly what was being tested), people will doubt the evidence before them.
Maybe Parallax could·test·all of the uOLED-96-PROP displays that they have in stock to see·if the Propeller chip is running at 128MHz. Maybe that would make the results believable. If they're not, maybe they should sell them for half price as defective parts.
@ Duffer : Thanks for a more detailed explanation and to 4D Systems also.
I'm sure most people here are aware that it's possible to over-clock anything providing that's done in the right environment, and Chip has said as much himself. Obviously achieving the right environment to run at 128MHz is somewhat easier than I ( and probably others ) thought, requiring appropriate design rather than anything else.
Scepticism and disbelief stems from not being able to see how it could be that easily achieved. A more direct explanation would have been better earlier, but we can put that behind us.
You are quite right, statements from Parallax on maximum speed have been given without much reference to environment and are somewhat vague on what can be achieved and how. That's one of the reasons I'd like to see more definitive statements from Parallax as I mentioned earlier. Likewise it would be interesting to know the temperature range over which 128MHz can be sustained.
I think the impressive thing is that 4D Systems have achieved a 60% execution speed improvement over the 80MHz many Propellers use even though that wasn't their particular goal. Assuming it is 'that easy' I hope we will see that being capitalised on in the future.
Atilla at 4D Systems asked that I post their response which I think is a reasonable request ...
Hippy,
I was wondering what all this commotion was about so I went to the Parallax forum and had a look. First let me make a few points clear before I give away our so called "secrets" and tell you (and the Propeller community) about our so called "tricks".
* uOLED-96-PROP is the 1st design that we've ever used the Propeller. We don't normally design with the Propeller, we have our own GOLDELOX and the PICASO (DSP based controller on steroids) chips that we use in majority of our products with ample power and grunt left over.
* We've had lots of requests in the past from Propeller users (and others) wanting a bit more access to the "internals" of our serial uOLED/uLCD modules. We decided the best way to do this is to give them the uOLED-96-PROP with full access to the Propeller. Soon all of our serial based modules will run the 4DGL (4D Graphics Language) platform where the user applications written in 4DGL will run directly on the GOLDELOX and the PICASO chips allowing the user full access to all of the internal resources.
* We did not set out to design or promote a product, using the Propeller chip, out of spec and make claims such as " Hey guys...look what we can do..". No where in the uOLED-96-PROP promo or documentation we make this claim, in fact we don't even make any mention of the clock/Xtal speed.
* The uOLED-96-PROP is a neat tiny Propeller development module with an integrated OLED display and a uDS card socket with a 10 pin expansion header allowing the user to then further develop their application. The user has full access to the display, the uSD card and the Propeller. We've also written some spin code to allow access to all of the available graphics primitives for users to build on. THATS IT!!!
Now to the "Holly Grail" secrets of the uOLED-96-PROP. Make sure you have your seat belt fastened.
* There are no SECRETS or TRICKS. We employed the same design techniques that we do in all our designs.
* 1st we analysed the available data on the Propeller. The specs clearly state that an external crystal of 8.0Mhz can be used with 16xPLL. There were no errata releases we were aware of that stated otherwise. We were also not aware that the Propeller could not run at 128Mhz or higher under normal conditions. A design engineers "Bible" is the information made available in the form of data sheets and application notes by the manufacturer.
* Now that we have been made aware of the problems running at 128Mhz here is my explanation of why the Propeller runs at that speed reliably on our 96-PROP:
o The PCB: The 96-PROP PCB is 0.8mm thick and its a 4 layer board. In fact all of our PICASO/GOLDELOX boards are 4 layers minimum. There is a dedicated Vcc layer, a dedicated Ground layer and 2 signal layers resulting in a quiet and noise free platform with reduced Power/GND inductance.
o The crystal: It sits on top of the Propeller (Prop chip is on the other side of the board sandwiched between the PCB and the OLED). The tracks from the crystal to the Prop are extremely short, minimal track inductance, minimal noise.
o The Propeller chip: The 96-PROP uses the QFN version and this is the smallest form factor the Prop die is packaged in. The connection of the silicon to the pads/pins inside the QFN Prop are very close, resulting in shorter wires used for the bonding process, hence minimised inductance.The QFN package is the only one with a large metallic GND pad under it that all QFN packages have. On the 96-PROP this metallic pad is directly soldered onto the GND layer of the PCB which effectively acts as a heat sink or as you mention "suitable cooling", thus reducing the excess heat that would result from higher speeds. This is called Thermal Run-away.
o Components: All of our components are highly specked, we pay extra. We also use surface mount components resulting in closer and tighter grouping such as the decoupling caps close to the chips and not inches away.
o We ordered stock standard parts from Parallax, we did not ask them to "pick and choose" chips. As mentioned above our goal was not to design the fastest Propeller based product.
I hope my response is satisfactory and that it sheds some light into the uOLED-96-PROP. In the overall scheme of what we do, the 96-PROP design was a "no-brainer". The Propeller is a nice chip and easy to design with and the 96-PROP is a "no-fuss" development module packed with lots of practical features into a compact footprint. I also hope that you'd copy and paste my response in its entirety in your post to the Propeller forum so that others may see.
I only wish Attila worked a little harder at bringing those five ignored i/o pins out from under the prop chip. As it stands the 4 or 6 available will be stretched quite thin.
PS. Does anyone have a photo of the backside of the QFN package? I've never seen one.
Post Edited (Fred Hawkins) : 10/27/2007 11:57:51 PM GMT
@ Fred - I've already explained about the design choices that were made with the uOLED-96-PROP with regard to the I/O pins. Trust me, you do not want me to get Atilla involved in a discussion about "not enough I/O pins".
His feeling has been that people don't make good use of the I/O they have and that's why they always want more and more. Example: Using 5 pins to read 5 switches when 5 resistors and a cap would do the job on one pin. If you need more I/O for a particular project, use multiplexers/expanders, don't complain about not enough I/O pins. Get on with the coding.
@ All - My hope is that we've put some of the distracting hardware issues behind us today and that we can move on to developing some interesting applications for the uOLED-96-PROP. That was the exciting part for me from the beginning.
Atilla wasn't happy with me for dragging·him into the discussions going on here (he and the others at 4D Systems/Labs are unbelievably busy right now with a·number of new products ready for release), but he does understand that dwelling on minor hardware issues sidetracks users from·moving on to developing usable functionality for the device. 4D Systems does not expect the 96-PROP to be a huge commercial success and sell millions of them (unless someone wants to step up now and place a really big order ), but it's an interesting little project for them. Thier main interest is in uOLED, uLCD, uVGA and other products that employ their own GOLDELOX and PICASO embedded processors. As long as things remain interesting and do not become more trouble than they're worth, I think that they will continue to produce more products that use the Propeller chip (As Atilla said: "The Propeller is a nice chip and easy to design with").
I can tell you from experience that the guys at 4D get interested and excited about the products and projects that people design using their products, not spending endless hours explaining how their product works the way it does.
If the 96-PROP Object·is to grow and become a resource for the Propeller community,·I'm afraid that someone or some interested group of users will have to take ownership of the object and put forth the effort to maintain it as it grows. If you look at the graphics, image,·text and uSD commands that are available with·a displays like the·uOLED-128-GMD1, you can see that there·is much room for growth. The thing to consider, and I hope excite, is that you don't have to stop there. If you want to design your own font (or remap existing characters with you own special characters), go ahead, examples of how to do that are in the object now. If you need the display to be "landscape" for your project, go ahead and figure out how to make that work by remapping the X,Y values of commands. And the list goes on. You can build and tweak to your heart's content. You don't have to wait for the Mfr. to offer the custom feature that's perfect for your project, just build it yourself.
I was hoping that it might be possible to have a "sticky" for the 96-PROP where the current version of the Object/Demo could be found and where users could offer suggestions on what is needed and where other users could offer code for inclusion in the object. The 96-PROP represents an opportunity for the Propeller community to "own the code" for this device and help to develop its full potential. Mike Green, in my opinion, has already begun this process with his modification of Femto Basic to make use of the 96-PROP's unique combination of hardware components and the Propeller chip.
I'm going to stop for now and let others comment on what I've said and, I hope, come up with some good suggestions/ideas on how we can move forward, now that we're all friends again.
I don't think anyone should feel guilty about wanting to clear this up no matter how busy 4D are. I think Hippy made his point quite clearly and politely and once Attila understood where the concerns came from he gave a very suitable answer.
You just seemed to want Hippy to shut up and accept half an answer. I half expected a cry of heracy! Yes we hadn't fully understood the full scope of frequency limits mentioned by parallax, that was why the question was being asked so were we wrong to ask the question? Well if we had realized that these limits were not all encompassing then yes otherwise it was totally reasonable ( a reasonable mistake if you must).
FWIW I would find more io pins helpful too because an io expander won't help if I want to output multiple pulse trains from the counters. However it's crazy small and not all that practical so I'm still singing its praises.
@ Graham - You said: "You just seemed to want Hippy to shut up and accept half an answer. I half expected a cry of heracy!"
Funny that you should use just those words.·I had the feeling that I was being told to shut up and accept the prevailing wisdom available here regarding the ability of the Prop to run at anything over 110MHz, let alone 128MHz. I also felt that I was in danger of being labeled a heratic for even suggesting such a thing.
And please be aware that the posts here and on the 4D forum by Atilla and me last night and today was not something that just happened. Atilla and I have been talking about where this was going for several days now and were discussing how to bring closure to what seemed like an argument that I couldn't win and that I felt would ultimately hurt the acceptance of the 96-PROP. He was reluctant to get involved, and didn't initially feel compelled to "defend" the uOLED-96-PROP to anyone.·I was able to convince him that it wouldn't take much of his time and that the information,·in and of itself, might be of value to more than just the "non-believers" and the curious.
For those interested in expanding the I/O capability of the uOLED-96-Prop, the PCA9554 I2C I/O Expander is easily attached to two I/O pins. It runs on 3.3V, but has 5V tolerant I/O pins with a Voh around 2.8V with a 3.3V Vdd. BoeBotBasic uses this Expander to run the HM-55 Compass and other devices (including other SPI devices) could be interfaced using it as well. You can attach up to 8 PCA9554 devices to the same 2 I/O pins for a total of 64 I/O pins and could even add another 8 PCA8554A devices which use a different select code. The BoeBotBasic code could easily be included in uOLED-96-Prop Basic.
Post Edited (Mike Green) : 10/29/2007 12:01:02 AM GMT
I'm quite happy using my OLED-PROP at 64MHz and have no intent to run it at 128MHz no matter what anyone tells me.
Remember, 64MHz is only 20% slower than 80MHz; for most applications, that's not even something that will be
noticeable. Sure, I would have preferred a 10MHz crystal, but I knew what I was getting when I got it, and I'm quite
happy.
I too just want to see the cool applications for this device. I hope to get to spend some more time programming it
soon.
I'd love to talk power options. Right now I'm powering mine with 3 AA cells. Has anyone else set this thing up to be
battery powered? What cells are you using? What is the lifetime? Has anyone measured the current consumption
under different conditions?
I'm just happy they made it available and saved me a ton of soldering.
@ Fred - I've already explained about the design choices that were made with the uOLED-96-PROP with regard to the I/O pins. Trust me, you do not want me to get Atilla involved in a discussion about "not enough I/O pins".
His feeling has been that people don't make good use of the I/O they have and that's why they always want more and more. Example: Using 5 pins to read 5 switches when 5 resistors and a cap would do the job on one pin. If you need more I/O for a particular project, use multiplexers/expanders, don't complain about not enough I/O pins. Get on with the coding.
@ All - My hope is that we've put some of the distracting hardware issues behind us today and that we can move on to developing some interesting applications for the uOLED-96-PROP. That was the exciting part for me from the beginning.
....
I was hoping that it might be possible to have a "sticky" for the 96-PROP where the current version of the Object/Demo could be found and where users could offer suggestions on what is needed and where other users could offer code for inclusion in the object. The 96-PROP represents an opportunity for the Propeller community to "own the code" for this device and help to develop its full potential. Mike Green, in my opinion, has already begun this process with his modification of Femto Basic to make use of the 96-PROP's unique combination of hardware components and the Propeller chip.
I'm going to stop for now and let others comment on what I've said and, I hope, come up with some good suggestions/ideas on how we can move forward, now that we're all friends again.
Duffer
Duffer,
Hmm. So Attila gets to use an 8-pin databus and 6 more for the oLED module, another 4 or so for the micro SD, plus the standard RxTx eeprom lines, and then says 'quit yer squawking about pins, you have 7 cogs left·to do whatever you want with the 4 I·left'.··Permit me to be a little bit doubtful about that and to wish that the other 5 made it out of the prop.
What I really would like is a concise run down on the graphics chip that the prop drives in the 96-Prop. I've looked at the shell and demo programs and downloaded the manual (3x just to be certain that it was indeed a skimpy 13 pages). Compared to the docs that accompany the other oLED's -128, -160, it's safe to say there's no comparison. Solomon hasn't responded to a request for a datasheet and I'm not at all hopeful that they may.
Other desires -- a longer discussion of why oLED's are sensitive to powerdowns and the steps required to avoid problems. On one hand we have a terse warning and on the other we have implication that 96-Prop can be used as a tiny development platform. It'd be no fun at all if a simple program-bug-and-reset fries the display -- it's way too small to be a doorstop and dubiously light to be·a decent paperweight. What do you say? Should we test and debug our prop programs on another platform before we put them on this one?
Thirdly, one thing does jump out from the shell and demo code: the display alphabet is in the code. This seems a step back from the controllers in the other oLEDs. That said, I'll bet a vector based alphabet is much smaller than multiple bitmapped fonts.
Fred
ps. I've two of these buggers and two of the 128s. I get to·(expletive) all I want. I am a customer and I get to ask questions.
I'm really pleased you are in close contact with 4D about this product, it's really exciting and excellent. But I think you will see that once presented with actual evidence we were more than happy to accept new wisdom so we are in no way devout in our max frequency beliefs. If you had understood why it could run on 128Mhz you would have told us why (adequate heatsinking because of the package) but you relied on your faith in Attila which I am sure is well founded but in this case not required, there are cold hard reasons why the numbers quoted elsewhere are not absolute figures and why this implementation works.
"I was able to convince him that it wouldn't take much of his time and that the information, in and of itself, might be of value to more than just the "non-believers" and the curious.
rokicki said...
I'm quite happy using my OLED-PROP at 64MHz and have no intent to run it at 128MHz no matter what anyone tells me.
Remember, 64MHz is only 20% slower than 80MHz; for most applications, that's not even something that will be
noticeable. Sure, I would have preferred a 10MHz crystal, but I knew what I was getting when I got it, and I'm quite
happy.
I too just want to see the cool applications for this device. I hope to get to spend some more time programming it
soon.
I'd love to talk power options. Right now I'm powering mine with 3 AA cells. Has anyone else set this thing up to be
battery powered? What cells are you using? What is the lifetime? Has anyone measured the current consumption
under different conditions?
I'm just happy they made it available and saved me a ton of soldering.
I got 5 minutes 23 seconds out of a new 2032 lion battery at 128mhz, now testing it at 8mhz...
Yes, you all can run it as slow as 8 mhz if you are afraid of burning it up or if it outputs funny video. I run mine now at pllx8 normally.
There is more than heat.... During one clock tick, signals go their way through a multiture of transistors, each contributing a small - constant! - delay to them. At the end the signals have to meet again.. There is only a limited window for that and - dependent on the design margins - the end comes earlier or later...
However, "constant" was not quite correct, as this also depends on the temperature. A chips cooled down to -100 degrees celsius will behave differently than a chip with a good heat sink...
Like I said, if you dont want to run it at 128mhz, dont. Just modify your pll timer.
I personally plan on running it in a battery operated device, but if soeone wants to use spites/animation they can, but at a cost.
From my reading up on the limitations and risks.....
If your end product HAS to be fast, you better get a big battery or run off the wall AND possibly a fan and maybe a peltier plate ~ 1 inch from the device to insure a really long life.
You are correct, keeping a cpu cool will extend its life and using internal timers is not 100% accurate in any MCU, but lets not loose sight... the display does not care if you run it at 8mhz or 128mhz, and 64mhz is plenty fast for me and Rokiki.
FYI·22·minutes and still running on a 3.6v button battery @ 8 mhz drawing the splash screen, a 8bit 96x64 bitmap, then scrolling in a loop..
Post Edited (bassmaster) : 10/28/2007 3:35:40 PM GMT
WOW! more than I expected!, at·34 minutes it is now resetting in the middle of the 8k bitmap painting, but still "Running" and makes it throgh the Splash sceen everytime,·It started doing this at 25:23.
UPDATE: STILL running and making through the·splash screen at 46:25 minutes.
NEW UPDATE: @ 1hour 1 minute and 35 seconds it is no longer painting all of the "7" font in 2007...
NEW UPDATE: @ 1hour·13 minutes and 35 seconds it is still running but only making it to the O character in PROP.
NEW UPDATE: @ 1hour·35 minutes and·17 seconds it is still running but only making it to the·green L·in uoled.
NEW UPDATE: @ 1hour·44 minutes and·08 seconds it is still running but only making it to the·last charater s in Systems ·NEW UPDATE:··@ 2hours· 23 seconds it started only·flashing 1st line every 3 seconds Unplugged it for 2 seconds and it painted the image of the first line and started flashing again.
· FINALLY·IT IS NO LONGER RUNNING··@ 2:15:11 (Just flashing snow after I unplugged it for 2 seconds and tried to power it up)
BUT After· 5 minutes unplugged the battery came back to life a bit and gave me ~ 10 minutes.
Conclusions:
Without the bitmap filling every pixel up early on, like in my code below:
This thing would likely have ran for a few hours....·Maybe days in the actual application, i.e.·if on a 10 second on / off timer when a user touches my qtee chip sensor.··(now to see how much the qtee uses, If I remember right it only draws .001 ma.
Next test, remove bitmap,·fill the screen·with 8X8 font alphabet loop in all color with a 5 second delay in between with a newly charged battery.
Sean
Post Edited (bassmaster) : 10/28/2007 5:32:46 PM GMT
Duffer said...
Paul Sr.,
I'm glad we cleared that up. When can I expect to see a "Circle" function from you for the 96-PROP. Get coding!
Enjoy, Duffer
Well, not ever having to even think about the theory behind drawing a circle, I went on a Google trip that that (typically) flooded me with sufficient information to hurt my brain! Seems that Bresenham's circle algorithm is about as pervasive as you can find! I read enough!
Attached are versions of the V4 code that I have hacked up with tweaked sample code turned into SPIN. I take no creative credit for the code I used in the methods in the driver - I pretty much just adapted pseudo code to SPIN. It does what I was looking for, but perhaps not so elegantly - I leave it to the theorists and math heavy's to show me my errant ways! A little fun was included in my experimentation, as you will see....
In the driver, you will see 2 versions of CIRCLE code:
1 - a single part version (commented out) - right under the ARC method which is obviously the same with an additional input parameter to indicate the ARC quadrant
2 - a 2 part (Method) version that theoretically should draw a "more symmetrical" circle - but I don't see a difference.
Feel free to critique away. I would love to hear anyone's comments. There is a bit I am unclear on the theory side, but I also struggled with Calculus...
Paul
EDIT: I reuploaded the DEMO. I used a SCROLL in my demo method, but if I leave the original "Scroll" enabled after the "Splash" call, my scroll won't work! Need to figure it out! BUG??
Post Edited (Paul Sr.) : 10/28/2007 7:16:36 PM GMT
Paul, nice job! I like the mr. bill animation, try your demo at 8mhz, it is cool seeing bill say oh nooo....
An important note on my battery testing, I had no sd card in the slot, so some more testing might be needed to see how accessing it will effect the power, but I am sure it would diminish the lifetime, and drop below what the regulator could handle pretty quickly with a 3.6v battery.
Here's a first cut at including a circle routine in uOLED96Prop Basic. "CIRCLE <X>,<Y>,<Rad>,<R>,<G>,<B>" calls Circle and "CIRCLE <X>,<Y>,<Rad>,<Quad>,<R>,<G>,<B>" calls Arc. In the demo, note that the circle doesn't fill completely with decreasing radii.
I'd like to have a filled circle option before I release this to the Object Exchange.
Paul,
You might consider a general purpose fill routine that can be given any point on the screen and will fill the enclosed space (enclosed by other colors) with a new color. The trick is to allow for slight gaps in the boundary ... you don't want the fill color to "escape" and fill the entire screen.
Hi, i am thinking about buying a 96-prop for some micro controller fun. I love the awesomeness of a full color display thats small, doesn't weigh a lot, or suck tons of power. I have one question though about downloading programs to the 96-prop. Almost everywhere, people are trying to sell me a usb to serial converter for programming micro controllers. I see no point of spending 25+ bucks when i already have a serial port. I was wondering if i could just cut off the end of a DB-9 serial cable and hook it up to the 96-prop with some resistors? There is a schematic on how to hook up a serial cable to a prop controller in its data sheet with some transistors and stuff. Would this apply to the 96-prop or not? I can easily build this circuit after a trip to the rad-shack and some bread-boarding. Also, has anyone tried to hook up a miniature keyboard to the 96-prop for a user interface. Theres plenty of I/O for a full sized, so why not a blackberry style keyboard. Wouldn't some polymer batteries also be perfect to go with this display. They're flat, light, and rechargeable.
It's still a propeller so anything that programs the propeller should work just get the oin out right.
Adding a keyboard only needs two pins for PS/2 but I have not seen an blackberry type keyboards that are PS/2 in fact the subject of really small keyboards has come up several times and I've never seen something that is suitable. Not for hand held use anyway.
Comments
I run one prop with 120MHz and have litle problem in Video PLL. But rest in Prop funktion corect.
I have no problem to Crystal 14_318_180/PLLx8 = 114.545.440MHz.
Look on this link.
http://forums.parallax.com/forums/default.aspx?f=25&m=215415
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I don't see how there can be any trick, if the processors are running at 128Mhz then they are running at 128Mhz and that according to parallax sources is too high for all propeller chips. Perhaps they vet the chips for chips that do operate at 128Mhz and perhaps not. Either way I think it is something worth a real answer. We can take it even if it is "some small % may fail but we will replace them".
I wish they had just stook a 10Mhz crystal on like the prop stamp has as I want my stuff to run at 80Mhz most of the time full stop.
I'm sure the new week will bring all the answers we need, this display is just so cool. And Mike's comments about booting programs from the SD card really got me thinking!!
Graham
I think if you not run PLL in video mode mostly Props can run 128 but if you run video PLL then it faill.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I think you may be onto something. It may also be the packaging as well. Most of run q44 and dip40 versions of the propeller. The m44 version has a big square pad in the middle. Is that working like a heat sink, or is it just connected by a thin gold wire like the other pads?
Just a thaught,
Doug
4D Systems' response to the questions posed by me, lucidman and hippy can be found at:
http://www.websitetoolbox.com/tool/post/4d/vpost?id=2250413
POST EDIT: It looks like hinv already read the response from 4D!
The surprising thing to me throughout this whole discussion about running the Propeller chip at a given speed (whether it be 80MHz,100MHz or 128MHz), is that there is never a mention of which Propeller chip we're talking about or the layout of components (there's a HUGE difference between a breadboarded 40 pin DIP Propeller and the highly optimized design of the uOLED-96-PROP using a QFN Propeller chip). Someone asks: "Can the Propeller run at 100MHz?" and people start jumping in with all manner of opinions based on who knows what design criteria.
It wasn't even clear to me from the responses from Parallax (that people love to quote) about seeing failures at 110MHz what the physical setup was and what chip was being tested. Many use the term "Propeller Chip" as if it were a single part instead of being specific about which of the three available Propeller chips they're talking about. Also, there are a number of Prop development platforms. From the PEK and Starter kit on breadboards, the Prop Dev board, the Prop Proto board, Bean's Prop Dongle, the uOLED-96-PROP and others. All different and with, I'm sure, very different performance characteristics when it comes to the Propeller chip. For example, it wouldn't surprise me that trying to run the PEK setup with an 8MHz Xtal at 128MHz would have problems. By the same token, it wouldn't surprise me to find that the 96-PROP could run with a 10MHz Xtal at 160MHz. Different chip, VERY different design, different results.
This whole thing about there being some "trick" to running a particular version of the Propeller chip at it's designed speed was meant to be tongue-in-cheek. Why the lengthy discussions about can or can't when it's obvious that it can perform according to spec because you can have a product in your hand that does it. And yet, because of some obscure reference to observed failures (without a frame of reference as to exactly what was being tested), people will doubt the evidence before them.
Maybe Parallax could·test·all of the uOLED-96-PROP displays that they have in stock to see·if the Propeller chip is running at 128MHz. Maybe that would make the results believable. If they're not, maybe they should sell them for half price as defective parts.
Duffer
I'm sure most people here are aware that it's possible to over-clock anything providing that's done in the right environment, and Chip has said as much himself. Obviously achieving the right environment to run at 128MHz is somewhat easier than I ( and probably others ) thought, requiring appropriate design rather than anything else.
Scepticism and disbelief stems from not being able to see how it could be that easily achieved. A more direct explanation would have been better earlier, but we can put that behind us.
You are quite right, statements from Parallax on maximum speed have been given without much reference to environment and are somewhat vague on what can be achieved and how. That's one of the reasons I'd like to see more definitive statements from Parallax as I mentioned earlier. Likewise it would be interesting to know the temperature range over which 128MHz can be sustained.
I think the impressive thing is that 4D Systems have achieved a 60% execution speed improvement over the 80MHz many Propellers use even though that wasn't their particular goal. Assuming it is 'that easy' I hope we will see that being capitalised on in the future.
Atilla at 4D Systems asked that I post their response which I think is a reasonable request ...
Hippy,
I was wondering what all this commotion was about so I went to the Parallax forum and had a look. First let me make a few points clear before I give away our so called "secrets" and tell you (and the Propeller community) about our so called "tricks".
* uOLED-96-PROP is the 1st design that we've ever used the Propeller. We don't normally design with the Propeller, we have our own GOLDELOX and the PICASO (DSP based controller on steroids) chips that we use in majority of our products with ample power and grunt left over.
* We've had lots of requests in the past from Propeller users (and others) wanting a bit more access to the "internals" of our serial uOLED/uLCD modules. We decided the best way to do this is to give them the uOLED-96-PROP with full access to the Propeller. Soon all of our serial based modules will run the 4DGL (4D Graphics Language) platform where the user applications written in 4DGL will run directly on the GOLDELOX and the PICASO chips allowing the user full access to all of the internal resources.
* We did not set out to design or promote a product, using the Propeller chip, out of spec and make claims such as " Hey guys...look what we can do..". No where in the uOLED-96-PROP promo or documentation we make this claim, in fact we don't even make any mention of the clock/Xtal speed.
* The uOLED-96-PROP is a neat tiny Propeller development module with an integrated OLED display and a uDS card socket with a 10 pin expansion header allowing the user to then further develop their application. The user has full access to the display, the uSD card and the Propeller. We've also written some spin code to allow access to all of the available graphics primitives for users to build on. THATS IT!!!
Now to the "Holly Grail" secrets of the uOLED-96-PROP. Make sure you have your seat belt fastened.
* There are no SECRETS or TRICKS. We employed the same design techniques that we do in all our designs.
* 1st we analysed the available data on the Propeller. The specs clearly state that an external crystal of 8.0Mhz can be used with 16xPLL. There were no errata releases we were aware of that stated otherwise. We were also not aware that the Propeller could not run at 128Mhz or higher under normal conditions. A design engineers "Bible" is the information made available in the form of data sheets and application notes by the manufacturer.
* Now that we have been made aware of the problems running at 128Mhz here is my explanation of why the Propeller runs at that speed reliably on our 96-PROP:
o The PCB: The 96-PROP PCB is 0.8mm thick and its a 4 layer board. In fact all of our PICASO/GOLDELOX boards are 4 layers minimum. There is a dedicated Vcc layer, a dedicated Ground layer and 2 signal layers resulting in a quiet and noise free platform with reduced Power/GND inductance.
o The crystal: It sits on top of the Propeller (Prop chip is on the other side of the board sandwiched between the PCB and the OLED). The tracks from the crystal to the Prop are extremely short, minimal track inductance, minimal noise.
o The Propeller chip: The 96-PROP uses the QFN version and this is the smallest form factor the Prop die is packaged in. The connection of the silicon to the pads/pins inside the QFN Prop are very close, resulting in shorter wires used for the bonding process, hence minimised inductance.The QFN package is the only one with a large metallic GND pad under it that all QFN packages have. On the 96-PROP this metallic pad is directly soldered onto the GND layer of the PCB which effectively acts as a heat sink or as you mention "suitable cooling", thus reducing the excess heat that would result from higher speeds. This is called Thermal Run-away.
o Components: All of our components are highly specked, we pay extra. We also use surface mount components resulting in closer and tighter grouping such as the decoupling caps close to the chips and not inches away.
o We ordered stock standard parts from Parallax, we did not ask them to "pick and choose" chips. As mentioned above our goal was not to design the fastest Propeller based product.
I hope my response is satisfactory and that it sheds some light into the uOLED-96-PROP. In the overall scheme of what we do, the 96-PROP design was a "no-brainer". The Propeller is a nice chip and easy to design with and the 96-PROP is a "no-fuss" development module packed with lots of practical features into a compact footprint. I also hope that you'd copy and paste my response in its entirety in your post to the Propeller forum so that others may see.
__________________
Regards,
Atilla
PS. Does anyone have a photo of the backside of the QFN package? I've never seen one.
Post Edited (Fred Hawkins) : 10/27/2007 11:57:51 PM GMT
His feeling has been that people don't make good use of the I/O they have and that's why they always want more and more. Example: Using 5 pins to read 5 switches when 5 resistors and a cap would do the job on one pin. If you need more I/O for a particular project, use multiplexers/expanders, don't complain about not enough I/O pins. Get on with the coding.
@ All - My hope is that we've put some of the distracting hardware issues behind us today and that we can move on to developing some interesting applications for the uOLED-96-PROP. That was the exciting part for me from the beginning.
Atilla wasn't happy with me for dragging·him into the discussions going on here (he and the others at 4D Systems/Labs are unbelievably busy right now with a·number of new products ready for release), but he does understand that dwelling on minor hardware issues sidetracks users from·moving on to developing usable functionality for the device. 4D Systems does not expect the 96-PROP to be a huge commercial success and sell millions of them (unless someone wants to step up now and place a really big order
I can tell you from experience that the guys at 4D get interested and excited about the products and projects that people design using their products, not spending endless hours explaining how their product works the way it does.
If the 96-PROP Object·is to grow and become a resource for the Propeller community,·I'm afraid that someone or some interested group of users will have to take ownership of the object and put forth the effort to maintain it as it grows. If you look at the graphics, image,·text and uSD commands that are available with·a displays like the·uOLED-128-GMD1, you can see that there·is much room for growth. The thing to consider, and I hope excite, is that you don't have to stop there. If you want to design your own font (or remap existing characters with you own special characters), go ahead, examples of how to do that are in the object now. If you need the display to be "landscape" for your project, go ahead and figure out how to make that work by remapping the X,Y values of commands. And the list goes on. You can build and tweak to your heart's content. You don't have to wait for the Mfr. to offer the custom feature that's perfect for your project, just build it yourself.
I was hoping that it might be possible to have a "sticky" for the 96-PROP where the current version of the Object/Demo could be found and where users could offer suggestions on what is needed and where other users could offer code for inclusion in the object. The 96-PROP represents an opportunity for the Propeller community to "own the code" for this device and help to develop its full potential. Mike Green, in my opinion, has already begun this process with his modification of Femto Basic to make use of the 96-PROP's unique combination of hardware components and the Propeller chip.
I'm going to stop for now and let others comment on what I've said and, I hope, come up with some good suggestions/ideas on how we can move forward, now that we're all friends again.
Duffer
You just seemed to want Hippy to shut up and accept half an answer. I half expected a cry of heracy! Yes we hadn't fully understood the full scope of frequency limits mentioned by parallax, that was why the question was being asked so were we wrong to ask the question? Well if we had realized that these limits were not all encompassing then yes otherwise it was totally reasonable ( a reasonable mistake if you must).
FWIW I would find more io pins helpful too because an io expander won't help if I want to output multiple pulse trains from the counters. However it's crazy small and not all that practical so I'm still singing its praises.
Graham
Funny that you should use just those words.·I had the feeling that I was being told to shut up and accept the prevailing wisdom available here regarding the ability of the Prop to run at anything over 110MHz, let alone 128MHz. I also felt that I was in danger of being labeled a heratic for even suggesting such a thing.
And please be aware that the posts here and on the 4D forum by Atilla and me last night and today was not something that just happened. Atilla and I have been talking about where this was going for several days now and were discussing how to bring closure to what seemed like an argument that I couldn't win and that I felt would ultimately hurt the acceptance of the 96-PROP. He was reluctant to get involved, and didn't initially feel compelled to "defend" the uOLED-96-PROP to anyone.·I was able to convince him that it wouldn't take much of his time and that the information,·in and of itself, might be of value to more than just the "non-believers" and the curious.
Maybe I was wrong, ·good by.
Duffer, out.
Just read the whole thing. Intriguing product! Got some good info on speed of Propeller too. Should be no worries for anyone.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (Mike Green) : 10/29/2007 12:01:02 AM GMT
Remember, 64MHz is only 20% slower than 80MHz; for most applications, that's not even something that will be
noticeable. Sure, I would have preferred a 10MHz crystal, but I knew what I was getting when I got it, and I'm quite
happy.
I too just want to see the cool applications for this device. I hope to get to spend some more time programming it
soon.
I'd love to talk power options. Right now I'm powering mine with 3 AA cells. Has anyone else set this thing up to be
battery powered? What cells are you using? What is the lifetime? Has anyone measured the current consumption
under different conditions?
I'm just happy they made it available and saved me a ton of soldering.
This is a sweet product.
4D is great, and I hope they come up with more cool things for the Prop.
Lucidman
Hmm. So Attila gets to use an 8-pin databus and 6 more for the oLED module, another 4 or so for the micro SD, plus the standard RxTx eeprom lines, and then says 'quit yer squawking about pins, you have 7 cogs left·to do whatever you want with the 4 I·left'.··Permit me to be a little bit doubtful about that and to wish that the other 5 made it out of the prop.
What I really would like is a concise run down on the graphics chip that the prop drives in the 96-Prop. I've looked at the shell and demo programs and downloaded the manual (3x just to be certain that it was indeed a skimpy 13 pages). Compared to the docs that accompany the other oLED's -128, -160, it's safe to say there's no comparison. Solomon hasn't responded to a request for a datasheet and I'm not at all hopeful that they may.
Other desires -- a longer discussion of why oLED's are sensitive to powerdowns and the steps required to avoid problems. On one hand we have a terse warning and on the other we have implication that 96-Prop can be used as a tiny development platform. It'd be no fun at all if a simple program-bug-and-reset fries the display -- it's way too small to be a doorstop and dubiously light to be·a decent paperweight. What do you say? Should we test and debug our prop programs on another platform before we put them on this one?
Thirdly, one thing does jump out from the shell and demo code: the display alphabet is in the code. This seems a step back from the controllers in the other oLEDs. That said, I'll bet a vector based alphabet is much smaller than multiple bitmapped fonts.
Fred
ps. I've two of these buggers and two of the 128s. I get to·(expletive) all I want. I am a customer and I get to ask questions.
I'm really pleased you are in close contact with 4D about this product, it's really exciting and excellent. But I think you will see that once presented with actual evidence we were more than happy to accept new wisdom so we are in no way devout in our max frequency beliefs. If you had understood why it could run on 128Mhz you would have told us why (adequate heatsinking because of the package) but you relied on your faith in Attila which I am sure is well founded but in this case not required, there are cold hard reasons why the numbers quoted elsewhere are not absolute figures and why this implementation works.
"I was able to convince him that it wouldn't take much of his time and that the information, in and of itself, might be of value to more than just the "non-believers" and the curious.
Maybe I was wrong, good by. "
It was of value and you weren't wrong, good bye
Graham
Yes, you all can run it as slow as 8 mhz if you are afraid of burning it up or if it outputs funny video. I run mine now at pllx8 normally.
Sean
However, "constant" was not quite correct, as this also depends on the temperature. A chips cooled down to -100 degrees celsius will behave differently than a chip with a good heat sink...
I personally plan on running it in a battery operated device, but if soeone wants to use spites/animation they can, but at a cost.
From my reading up on the limitations and risks.....
If your end product HAS to be fast, you better get a big battery or run off the wall AND possibly a fan and maybe a peltier plate ~ 1 inch from the device to insure a really long life.
You are correct, keeping a cpu cool will extend its life and using internal timers is not 100% accurate in any MCU, but lets not loose sight... the display does not care if you run it at 8mhz or 128mhz, and 64mhz is plenty fast for me and Rokiki.
FYI·22·minutes and still running on a 3.6v button battery @ 8 mhz drawing the splash screen, a 8bit 96x64 bitmap, then scrolling in a loop..
Post Edited (bassmaster) : 10/28/2007 3:35:40 PM GMT
UPDATE: STILL running and making through the·splash screen at 46:25 minutes.
NEW UPDATE: @ 1hour 1 minute and 35 seconds it is no longer painting all of the "7" font in 2007...
NEW UPDATE: @ 1hour·13 minutes and 35 seconds it is still running but only making it to the O character in PROP.
NEW UPDATE: @ 1hour·35 minutes and·17 seconds it is still running but only making it to the·green L·in uoled.
NEW UPDATE: @ 1hour·44 minutes and·08 seconds it is still running but only making it to the·last charater s in Systems
·
BUT After· 5 minutes unplugged the battery came back to life a bit and gave me ~ 10 minutes.
Conclusions:
Without the bitmap filling every pixel up early on, like in my code below:
PUB Demo
·
· DELAY.Init(8_000_000)
· OLED.InitOLED
· OLED.CLS
· repeat
· '
··· splash
·· rawwrite
·· scroll·
·····
pub rawwrite
· oled.Set_GRAM_Access (0,95,0,63)
· temp := 0
··
· REPEAT 6144··································· ' 96x64 pixels
··· OUTA[noparse][[/noparse]CS_OLED] := 0
··· OUTA[noparse][[/noparse]WR_OLED] := 0
··· OUTA[noparse][[/noparse]7..0] := ((bitmap[noparse][[/noparse]temp]<<3) >> 6)······· 'MSB
··· OUTA[noparse][[/noparse]WR_OLED] := 1
··· OUTA[noparse][[/noparse]WR_OLED] := 0
··· OUTA[noparse][[/noparse]7..0]··· := ((bitmap[noparse][[/noparse]temp])>>6)<<2······ ' LSB
··· OUTA[noparse][[/noparse]WR_OLED] := 1··
··· OUTA[noparse][[/noparse]CS_OLED] := 1
··· temp++
This thing would likely have ran for a few hours....·Maybe days in the actual application, i.e.·if on a 10 second on / off timer when a user touches my qtee chip sensor.··(now to see how much the qtee uses, If I remember right it only draws .001 ma.
Next test, remove bitmap,·fill the screen·with 8X8 font alphabet loop in all color with a 5 second delay in between with a newly charged battery.
Sean
Post Edited (bassmaster) : 10/28/2007 5:32:46 PM GMT
Well, not ever having to even think about the theory behind drawing a circle, I went on a Google trip that that (typically) flooded me with sufficient information to hurt my brain! Seems that Bresenham's circle algorithm is about as pervasive as you can find! I read enough!
Attached are versions of the V4 code that I have hacked up with tweaked sample code turned into SPIN. I take no creative credit for the code I used in the methods in the driver - I pretty much just adapted pseudo code to SPIN. It does what I was looking for, but perhaps not so elegantly - I leave it to the theorists and math heavy's to show me my errant ways! A little fun was included in my experimentation, as you will see....
In the driver, you will see 2 versions of CIRCLE code:
1 - a single part version (commented out) - right under the ARC method which is obviously the same with an additional input parameter to indicate the ARC quadrant
2 - a 2 part (Method) version that theoretically should draw a "more symmetrical" circle - but I don't see a difference.
Feel free to critique away. I would love to hear anyone's comments. There is a bit I am unclear on the theory side, but I also struggled with Calculus...
Paul
EDIT: I reuploaded the DEMO. I used a SCROLL in my demo method, but if I leave the original "Scroll" enabled after the "Splash" call, my scroll won't work! Need to figure it out! BUG??
Post Edited (Paul Sr.) : 10/28/2007 7:16:36 PM GMT
An important note on my battery testing, I had no sd card in the slot, so some more testing might be needed to see how accessing it will effect the power, but I am sure it would diminish the lifetime, and drop below what the regulator could handle pretty quickly with a 3.6v battery.
Sean.
I'd like to have a filled circle option before I release this to the Object Exchange.
I am working on that a this very moment!
Paul
You might consider a general purpose fill routine that can be given any point on the screen and will fill the enclosed space (enclosed by other colors) with a new color. The trick is to allow for slight gaps in the boundary ... you don't want the fill color to "escape" and fill the entire screen.
Kevin(?)
Adding a keyboard only needs two pins for PS/2 but I have not seen an blackberry type keyboards that are PS/2 in fact the subject of really small keyboards has come up several times and I've never seen something that is suitable. Not for hand held use anyway.
Graham