I'll check the docs to make sure I didn't stuff something up, but here's the skinny. The pin selection for Rx and Tx was arbitraty (Prop Tx to OLED Rx, Prop Rx to OLED Tx). Pick any two pins you like. The schematic in your post is wrong. The 10k resistor is a pullup for the OLED Rx line, it should go from OLED Rx (or Prop Tx if you're looking at it that way)·to Vcc, Vdd (3.3VDC) whatever the name on the board you're using, not from the·Prop Tx to the OLED Rx.
BTW, the RESET pin (pin 5 in the docs),·strictly speaking, is·not required for normal operation of the device. Pulling the reset pin low for at least 20 usec will cause the device to go through a power on reset without having to remove and reattach the device (safer for the on-board electronics). I generally use 4 pin cables with the displays.
The jumper on the back is the RUN jumper and is used to run a stand-alone demo, slideshow, etc when power is applied to the device (no host required). It should NOT be connected (bridged) for normal operation. The little shunt is normally just "stored" on one of the pins.
The Graphics Composer (free download from 4D web site)·allows you to load images, videos, etc. onto the uSD card (either with the card inserted in the display and using a uUSB-MB5 USB to serial adapter·or with the latest version, using a card reader). It loads the content starting at $200000 on the card and automatically writes commands for displaying the images starting at sector zero on the card. That's where the init routines look for slideshow commands if the RUN jumper is installed. It also createds a text file (same name as your project), that contains the full path to you images, the address on the card where they're loaded (HEX and DEC) and the commands used to display the images (the same commands that it writes to sector 0 for the self running demo). Pretty cool, eh?
RE: uSD card. I don't know how the display will react to a 2BG card. The display supports cards up to 1BG. Let me know how using the larger card works out. I haven't tried anything larger than 1GB.
you're right on.· the 10K pullup Resistor connection was wrong - I re connected per your note below, it works like a charm now!!
wrt the SD: I see it taking a lot of time in the ::Clear_Sector() method.· What is the usual time it should take?· it is probably because of the 2GB size.
thanks a lot.
Now let me get off this thread and start playing more [noparse]:)[/noparse]
caio
Nagi
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
Glad that got you going. Clearing the sectors in the demo was just that, a demonstration. No real need to do that in real world use. Like "flipping" the three images in the demo, no practical use, just showing off. I've found that the working speed of uSD (and most other types of flash memory cards) can vary a lot between manufacturers and is somewhat dependant on size. "Your results may vary"· and "You get what you pay for" comes to mind. Some are significantly quicker by design (SanDisk ULTRA II and now the III cards are a lot faster the standard SD and uSD cards).
Good luck and don't have TOOO much fun with that display.
from the [font=Arial,Bold size=5]
SanDisk Secure Digital Card
[/font][font=Arial,Bold size=5]Product Manual [/font]Version 1.9
Document No. 80-13-00169
File System Support
If a design needs to support a file system, such as SanDisk’s Host Developers Tool Kit (HDTK), additional
considerations are necessary.
Reading and writing to an SD Card and MultiMediaCard is generally done in 512 byte blocks, however, erasing
often occurs in much larger blocks. The NAND architecture used by SanDisk and other card vendors currently has
Erase Block sizes of (32) or (64) 512 byte blocks, depending on card capacity. In order to re-write a single 512 byte
block, all other blocks belonging to the same Erase Block will be simultaneously erased and need to be rewritten.
For example—writing a file to a design using a FAT file system takes three writes/updates of the system area of
FAT and one write/update of the data area to complete the file write. First, the directory has to be updated with the
new file name. Second, the actual file is written to the data area. Third, the FAT table is updated with the file data
location. Finally, the directory is updated with the start location, length, date and time the file was modified.
Therefore, when selecting the file size to write into a design, the size should be as large as possible and a multiple of
the Erase Block size. This takes advantage of the architecture. Some designs update the FAT table for every cluster of the data file written. This can slow the write performance,
because the FAT table is constantly being erased and re-written. The best approach is to write all the file clusters
then update the FAT table once to avoid the performance hit of erasing and re-writing all the blocks within the
Erase Block multiple times.
Post Edited (Fred Hawkins) : 9/7/2007 10:10:25 PM GMT
talking abt having too much fun, do these uOLEDs have a lifetime before they die out.· I read somewhere that these LED based displays have a long life time - but, they do have some limit
do you know anything abt that ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
Thanks Fred, good info to have. The byte and sector read/write routines used by the GOLDELOX microcontroller (The G in GMD1) uses low-level read and write commands. No "file system", FAT 10,12,16,32 ect. is used. There's no provision for named files, folders or any·of that currently.
ALIBE,
I'm no expert on OLED technology (but I did stay at a Holiday Inn recently ), but my understanding is that the blue pixels are the "weak" ones and have the shortest life. Organic chemists all over the world are working to find organic compounds that will last longer in OLED displays. Most feel that that's key to OLED technology's acceptance in products like TVs and laptop displays.·That being said, the estimate in the specs for these displays is ~10,000 hours for the blue pixels and somewhere in the range of ~45,000 to ~70,000 hours for the red and green pixels. The hours estimate is not to failure, but is the estimated half-life of·an individual·pixel. That means that somewhere in the neighborhood of 10,000 hours (equivalent to just over a year of continuous use at full brightness), the blue pixel's brightness would be half what it was at the time of manufactur.
Most designers (commercial) ·that use OLEDs know this and try to reduce the amount of blue used in their designs and/or reduce the intensity (brightness) of the blue component of their color choices. These kinds of design choices can extend the half-life of the blue pixels to nearly that of the red and green pixels.
The·passive matrix OLED displays, like those used in the current 128-GMD1 and 160-GMD1 modules, can also suffer from burn-in in much the same way LCD and Plasma displays can, so it's a good idea to incorporate some sort of "contrast reduction", screen saver or power-off mode in your code design if you intend to have the displays running for long periods of time. The new active matrix TFT OLED displays, which are now becoming more readily available do not suffer from burn-in. They're also brighter (if you can believe that) AND they use less power. 4D Systems (Labs) is working on designs that use the new active matrix displays and are hoping to have those available before the end of the year.
Thanks to ALIBE and scotch18 for finding and pointing out the errors in the connection diagrams of both the uOLED-128-GMD1 and uOLED-160-GMD1 objects. The errors have been corrected and objects have been re-submitted.
Luckily it wasn't an error that would lead a user to damage their module. Anybody know of a good cheap proof reading service?
thanks for the notes on the lifetime question.· I am going to set :[noparse]:D[/noparse]isplay(0) after a few seconds and put a h/w button on my bot to set it back to :[noparse]:D[/noparse]isplay(1)
I have a diff ?n - this time on ::Add_Bitmap() and :[noparse]:D[/noparse]isplay_Bitmap(). I am doing the following to add a custom char to memory and then to display it.· I am not seeing the output however.· While adding, i am sending in 8 hex digits to add to 1st slot
······ OLED.ADD_BITMAP(1,· $60, $90, $60, $00, $00, $00, $00, $00) ······ OLED.DISPLAY_BITMAP(1,· 5,5 , 255,255,255) ·what am I missing.· Do i have to do any conversion before adding?
thanks much
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
The problem is in the Object, not your code. The Character # is not being sent to the display as part of the serial command.
The following·changes should take care of it. Add the line: "SERIAL.tx (Chr)" as shown below in both the "Add Bitmapped Character" and "Display Bitmapped Character" methods. I'll get·the object(s)·updated.
Parallax does not carry this (yet?). I am highly thinking of this or at least the "uOLED-128-GMD1".
Is higher resolution and LCD vs OLED the only differences? For double the cost (double the resolution too), it seems like a great product. Are there more commands or memory, etc?
Wow. Those are features are great! However, I will have to balance out the double cost factor to nice to have features.
I also posted on the 4D Systems forum and the moderator stated:
The PICASO chip (on the uLCD-320-PMD2) is a DSP based engine runing at 50 MIPS and the GOLDELOX (on the·µOLED128-GMD1)·is a RISC platform running at 12 MIPS. When 4DGL platform is released, the user application·software written in 4DGL will run much faster on the PICASO.
Although the OLED technology is very good the TFT LCD used in the uLCD-320 is extra special. It employs a special "Black Pixel Mask" which you won't find in many LCD's and this enhances the contrast ratio to an incredible 10,000:1 compared to the OLED which is 1,000:1. You really have to see the uLCD-320 in action to appreciate the viewing quality.
I also saw a YouTube video that used this and a Cannon micro-trackball. Can you actually connect a mouse / trackball input to this with commands to support this (e.g. select an icon and DO SOMETHING?). That would be neat.
But knowing me, I will probably go with the uLCD-320-PMD2.
I very much appreciate it!
Post Edited (T&E Engineer) : 9/17/2007 10:23:41 AM GMT
The current PmmC (Personallity module micro Code)·for the uLCD-320-PMD2 does not support the trackball that you saw in the YouTube video (that was my video - duffer-steve). 4D Systems wanted to test the code for trackball support and created a special PmmC for me to test. The trackball code caused some problems which couldn't be resolved at this time. Their (4D) intention is to provide trackball support in a later PmmC release.
Atilla (4D Systems) was right about the LCD 320, when you first power up the display and see the splash screen for the first time, it looks like neon carved into black velvet! The highest contrast I've ever seen on an LCD!
Just a note on the PmmC concept that 4D has devised for the GOLDELOX and PICASO processors. They are generic processors that require the micro code of the PmmC to give them their "personallity". The same processor (with a different PmmC) can run as an embedded processor for any number of displays while providing a consistant command set for the user. The current PmmCs provide a serial interface. There is nothing to prevent 4D from creating a PmmC for a bussed interface like SPI or 2-wire. The "floating pointer" implemented on the uLCD-320 could be added to the uOLED displays with a change to the PmmC. For 4D, it's just a matter of finding the time to do it. They are so busy with a number of brand new products, they're having trouble getting everything done that they want.
They're philosophy is to get the base products in the hands of their users and then provide feature enhancements via PmmC to add value to their products. This philosophy, in effect, future-proofs their products. For exapmle, you could buy a uLCD-320-PMD2 and put it in a drawer for a couple of years, take it out of the drawer, download the latest PmmC and you would have the same features and functionalities as a person who bought the module last week. PmmCs also give you a choice of what you want the display to "be", a serial interface display, a 4DGP (full-featured, programmable·uController with its own 4DGL language) or whatever else the market demands or 4D decides to produce.
The products that you'll see from 4D over the next 6-12 months are probably going to blow you socks off. Keep an eye on the 4D Systems message board for some exciting announcements of new hardware·AND software to make their products easier to use and integrate into your projects/products.
Bottom line, it probably doesn't matter which display you buy FIRST, you'll probably find·uses for the others in your designs soon enough.
Steve,
Have you tried to send the personality data to a prop plug that is jumpered to the correct -gmd1 pins? Looking at the pin outs, it wouldn't be hard to do on the PE kit. The trick is whether or not the Composer/PPMC programs just use the com port you specify. On the latest version of the Composer it looks like you get to pick the com port.
Thats great information to know. I did purchase a uLCD-320-PMD2 today and hope to have it later in the week (priority shipping). It's a shame about the trackball coding not being there yet. But as long as someone is working on it...that's ok.
I really like LED projects (LED Moving display signs, clocks, etc..) so this will be a nice change. I hope that the commands will be straight forward and not a bit overwhelming like the Propeller. Yes I had a Hydra and did not have the drive to learn everything so I sold it on Ebay a few months ago. I feel more comfortable with the Stamp and SX (probably because their in BASIC) and I'm in no means a hardcore·programmer. I'm more of a hardware guy·that picked up some coding.·However, with all due respect to the good people at Parallax and the Propeller, it just wasn't for me. I needed to keep it simple to follow and understand. Anyway, This· uLCD-320-PMD2 hopes to provide me a break from my LED projects for a while and still keep me in line with the BS2 and SX products.
I feel comfortable with what I have read so far about the uLCD-320-PMD2.
I tested using a Prop plug to hook up the display for PmmC download as well as the Graphics Composer. It works fine. I'm in the process of putting together some instructions with pictures and schematics for using the Prop Plug and·USBtoSerial adapters for PmmC loading and Graphics Composer. It looks like it should also be possible to ues both the serial and USB BOE as well, but I haven't wired it up and tested it yet.
To answer your question, both the PmmC loader and the Graphics Composer let you choose any active Comm port on your PC. Any of the USB to serial bridges should work fine if they're hooked up properly. Keep in mind that the PmmC loader is the only one of the two that MUST have the RESET line connected (the PmmC loader does a reset in order intercept the boot loader to erase the old micro code and load the new code). The Graphics composer just needs +5V, Gnd, Tx and Rx.
I've been having the same problem. Turns out that it's getting sent, but the error persists. I got·all of your PM replys to my earlier message. I thought I was going to have to rewrite the one I sent, but it went through.
Steve
P.S. You said in one of your messages that your interest of late has been with LEDs. If you think of the LCD and OLEDs as just large matrices of tri-color LEDs (with a low power magnifying glass, you can see the three colored (RGB) LEDs that make up each pixel on the OLEDs). The difference is that you use serial commands and RGB color values instead of PWM to achieve the color you want.
Wow, that's really cool.
I remember seeing those screens and knew it was only a matter of time before someone would start using them. [noparse]:)[/noparse]
I have not worked with RGB LEDs or PWM per say yet. I am currently working on a little·larger scale LED display of (5) 8x8 Bi-Colored (actually 3 colors being green, red and yellow) using a serial chip A6821 similar to the parallel chip ULN2803 that I have used in past designs. This allows for useage with an SX-28 and not an SX-48/52 for the high I/O count. It's taking me a while do to the point to point soldering on the board I'm using.
Anyway...as not to give the impression of hijacking the post - I will conclude with that.
Comments
I'll check the docs to make sure I didn't stuff something up, but here's the skinny. The pin selection for Rx and Tx was arbitraty (Prop Tx to OLED Rx, Prop Rx to OLED Tx). Pick any two pins you like. The schematic in your post is wrong. The 10k resistor is a pullup for the OLED Rx line, it should go from OLED Rx (or Prop Tx if you're looking at it that way)·to Vcc, Vdd (3.3VDC) whatever the name on the board you're using, not from the·Prop Tx to the OLED Rx.
BTW, the RESET pin (pin 5 in the docs),·strictly speaking, is·not required for normal operation of the device. Pulling the reset pin low for at least 20 usec will cause the device to go through a power on reset without having to remove and reattach the device (safer for the on-board electronics). I generally use 4 pin cables with the displays.
The jumper on the back is the RUN jumper and is used to run a stand-alone demo, slideshow, etc when power is applied to the device (no host required). It should NOT be connected (bridged) for normal operation. The little shunt is normally just "stored" on one of the pins.
The Graphics Composer (free download from 4D web site)·allows you to load images, videos, etc. onto the uSD card (either with the card inserted in the display and using a uUSB-MB5 USB to serial adapter·or with the latest version, using a card reader). It loads the content starting at $200000 on the card and automatically writes commands for displaying the images starting at sector zero on the card. That's where the init routines look for slideshow commands if the RUN jumper is installed. It also createds a text file (same name as your project), that contains the full path to you images, the address on the card where they're loaded (HEX and DEC) and the commands used to display the images (the same commands that it writes to sector 0 for the self running demo). Pretty cool, eh?
RE: uSD card. I don't know how the display will react to a 2BG card. The display supports cards up to 1BG. Let me know how using the larger card works out. I haven't tried anything larger than 1GB.
Steve
Post Edited (Duffer) : 9/7/2007 9:20:16 PM GMT
you're right on.· the 10K pullup Resistor connection was wrong - I re connected per your note below, it works like a charm now!!
wrt the SD: I see it taking a lot of time in the ::Clear_Sector() method.· What is the usual time it should take?· it is probably because of the 2GB size.
thanks a lot.
Now let me get off this thread and start playing more [noparse]:)[/noparse]
caio
Nagi
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
Post Edited (ALIBE) : 9/7/2007 8:57:46 PM GMT
Glad that got you going. Clearing the sectors in the demo was just that, a demonstration. No real need to do that in real world use. Like "flipping" the three images in the demo, no practical use, just showing off. I've found that the working speed of uSD (and most other types of flash memory cards) can vary a lot between manufacturers and is somewhat dependant on size. "Your results may vary"· and "You get what you pay for" comes to mind. Some are significantly quicker by design (SanDisk ULTRA II and now the III cards are a lot faster the standard SD and uSD cards).
Good luck and don't have TOOO much fun with that display.
Steve
SanDisk Secure Digital Card
[/font][font=Arial,Bold size=5]Product Manual
[/font]Version 1.9
Document No. 80-13-00169
File System Support
If a design needs to support a file system, such as SanDisk’s Host Developers Tool Kit (HDTK), additional
considerations are necessary.
Reading and writing to an SD Card and MultiMediaCard is generally done in 512 byte blocks, however, erasing
often occurs in much larger blocks. The NAND architecture used by SanDisk and other card vendors currently has
Erase Block sizes of (32) or (64) 512 byte blocks, depending on card capacity. In order to re-write a single 512 byte
block, all other blocks belonging to the same Erase Block will be simultaneously erased and need to be rewritten.
For example—writing a file to a design using a FAT file system takes three writes/updates of the system area of
FAT and one write/update of the data area to complete the file write. First, the directory has to be updated with the
new file name. Second, the actual file is written to the data area. Third, the FAT table is updated with the file data
location. Finally, the directory is updated with the start location, length, date and time the file was modified.
Therefore, when selecting the file size to write into a design, the size should be as large as possible and a multiple of
the Erase Block size. This takes advantage of the architecture.
Some designs update the FAT table for every cluster of the data file written. This can slow the write performance,
because the FAT table is constantly being erased and re-written. The best approach is to write all the file clusters
then update the FAT table once to avoid the performance hit of erasing and re-writing all the blocks within the
Erase Block multiple times.
Post Edited (Fred Hawkins) : 9/7/2007 10:10:25 PM GMT
talking abt having too much fun, do these uOLEDs have a lifetime before they die out.· I read somewhere that these LED based displays have a long life time - but, they do have some limit
do you know anything abt that ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
ALIBE,
I'm no expert on OLED technology (but I did stay at a Holiday Inn recently ), but my understanding is that the blue pixels are the "weak" ones and have the shortest life. Organic chemists all over the world are working to find organic compounds that will last longer in OLED displays. Most feel that that's key to OLED technology's acceptance in products like TVs and laptop displays.·That being said, the estimate in the specs for these displays is ~10,000 hours for the blue pixels and somewhere in the range of ~45,000 to ~70,000 hours for the red and green pixels. The hours estimate is not to failure, but is the estimated half-life of·an individual·pixel. That means that somewhere in the neighborhood of 10,000 hours (equivalent to just over a year of continuous use at full brightness), the blue pixel's brightness would be half what it was at the time of manufactur.
Most designers (commercial) ·that use OLEDs know this and try to reduce the amount of blue used in their designs and/or reduce the intensity (brightness) of the blue component of their color choices. These kinds of design choices can extend the half-life of the blue pixels to nearly that of the red and green pixels.
The·passive matrix OLED displays, like those used in the current 128-GMD1 and 160-GMD1 modules, can also suffer from burn-in in much the same way LCD and Plasma displays can, so it's a good idea to incorporate some sort of "contrast reduction", screen saver or power-off mode in your code design if you intend to have the displays running for long periods of time. The new active matrix TFT OLED displays, which are now becoming more readily available do not suffer from burn-in. They're also brighter (if you can believe that) AND they use less power. 4D Systems (Labs) is working on designs that use the new active matrix displays and are hoping to have those available before the end of the year.
Steve
Luckily it wasn't an error that would lead a user to damage their module. Anybody know of a good cheap proof reading service?
thanks for the notes on the lifetime question.· I am going to set :[noparse]:D[/noparse]isplay(0) after a few seconds and put a h/w button on my bot to set it back to :[noparse]:D[/noparse]isplay(1)
I have a diff ?n - this time on ::Add_Bitmap() and :[noparse]:D[/noparse]isplay_Bitmap(). I am doing the following to add a custom char to memory and then to display it.· I am not seeing the output however.· While adding, i am sending in 8 hex digits to add to 1st slot
······ OLED.ADD_BITMAP(1,· $60, $90, $60, $00, $00, $00, $00, $00)
······ OLED.DISPLAY_BITMAP(1,· 5,5 , 255,255,255)
·what am I missing.· Do i have to do any conversion before adding?
thanks much
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
The problem is in the Object, not your code. The Character # is not being sent to the display as part of the serial command.
The following·changes should take care of it. Add the line: "SERIAL.tx (Chr)" as shown below in both the "Add Bitmapped Character" and "Display Bitmapped Character" methods. I'll get·the object(s)·updated.
· SERIAL.tx ("A")
· SERIAL.tx (Chr)·· <<<<<<<<<<<<<<<<<<<<
· SERIAL.tx· (Data1)
· SERIAL.tx ("D")
· SERIAL.tx (Chr)·· <<<<<<<<<<<<<<<<<<<<
· SERIAL.tx (X)
Thanks for the "catch" on this one.
Steve
that fixed it my friend.· Thanks for the pointer and the fix.·
I was wondering where that 'char' param was being passed thru the Tx.
That's the least I could do - you did the toughest part [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
·
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
https://www.littlepcbsolutions.com/uLCD-320-PMD2.html
Parallax does not carry this (yet?). I am highly thinking of this or at least the "uOLED-128-GMD1".
Is higher resolution and LCD vs OLED the only differences? For double the cost (double the resolution too), it seems like a great product. Are there more commands or memory, etc?
I will probably use this with an SX-28 or BS2.
Let me know...
Thanks.
In addition to the much larger screen resolution, the uLCD-320-PMD2 has several features not currently available on the uOLED-128 & 160-GMD1 modules.
1. Expanded User Bitmapped Character support: 8x8 (64 characters), 16x16 (16) and 32x32 (8). The uOLED modules currently support only 8x8.
2. An Ellips drawing command
3. A floating pointer (think floating "cursor")
See the documentation at: http://www.4dsystems.com.au/downloads/micro-LCD/uLCD-320-PMD2/Docs/
The uOLED displays are brighter and higher contrast, but the uLCD-320-PMD2 is one of the brightest LCD displays available.
Steve
Post Edited (Duffer) : 9/17/2007 3:20:59 AM GMT
I also posted on the 4D Systems forum and the moderator stated:
The PICASO chip (on the uLCD-320-PMD2) is a DSP based engine runing at 50 MIPS and the GOLDELOX (on the·µOLED128-GMD1)·is a RISC platform running at 12 MIPS. When 4DGL platform is released, the user application·software written in 4DGL will run much faster on the PICASO.
Although the OLED technology is very good the TFT LCD used in the uLCD-320 is extra special. It employs a special "Black Pixel Mask" which you won't find in many LCD's and this enhances the contrast ratio to an incredible 10,000:1 compared to the OLED which is 1,000:1. You really have to see the uLCD-320 in action to appreciate the viewing quality.
I also saw a YouTube video that used this and a Cannon micro-trackball. Can you actually connect a mouse / trackball input to this with commands to support this (e.g. select an icon and DO SOMETHING?). That would be neat.
But knowing me, I will probably go with the uLCD-320-PMD2.
I very much appreciate it!
Post Edited (T&E Engineer) : 9/17/2007 10:23:41 AM GMT
The current PmmC (Personallity module micro Code)·for the uLCD-320-PMD2 does not support the trackball that you saw in the YouTube video (that was my video - duffer-steve). 4D Systems wanted to test the code for trackball support and created a special PmmC for me to test. The trackball code caused some problems which couldn't be resolved at this time. Their (4D) intention is to provide trackball support in a later PmmC release.
Atilla (4D Systems) was right about the LCD 320, when you first power up the display and see the splash screen for the first time, it looks like neon carved into black velvet! The highest contrast I've ever seen on an LCD!
Just a note on the PmmC concept that 4D has devised for the GOLDELOX and PICASO processors. They are generic processors that require the micro code of the PmmC to give them their "personallity". The same processor (with a different PmmC) can run as an embedded processor for any number of displays while providing a consistant command set for the user. The current PmmCs provide a serial interface. There is nothing to prevent 4D from creating a PmmC for a bussed interface like SPI or 2-wire. The "floating pointer" implemented on the uLCD-320 could be added to the uOLED displays with a change to the PmmC. For 4D, it's just a matter of finding the time to do it. They are so busy with a number of brand new products, they're having trouble getting everything done that they want.
They're philosophy is to get the base products in the hands of their users and then provide feature enhancements via PmmC to add value to their products. This philosophy, in effect, future-proofs their products. For exapmle, you could buy a uLCD-320-PMD2 and put it in a drawer for a couple of years, take it out of the drawer, download the latest PmmC and you would have the same features and functionalities as a person who bought the module last week. PmmCs also give you a choice of what you want the display to "be", a serial interface display, a 4DGP (full-featured, programmable·uController with its own 4DGL language) or whatever else the market demands or 4D decides to produce.
The products that you'll see from 4D over the next 6-12 months are probably going to blow you socks off. Keep an eye on the 4D Systems message board for some exciting announcements of new hardware·AND software to make their products easier to use and integrate into your projects/products.
Bottom line, it probably doesn't matter which display you buy FIRST, you'll probably find·uses for the others in your designs soon enough.
Steve
Have you tried to send the personality data to a prop plug that is jumpered to the correct -gmd1 pins? Looking at the pin outs, it wouldn't be hard to do on the PE kit. The trick is whether or not the Composer/PPMC programs just use the com port you specify. On the latest version of the Composer it looks like you get to pick the com port.
Fred
I really like LED projects (LED Moving display signs, clocks, etc..) so this will be a nice change. I hope that the commands will be straight forward and not a bit overwhelming like the Propeller. Yes I had a Hydra and did not have the drive to learn everything so I sold it on Ebay a few months ago. I feel more comfortable with the Stamp and SX (probably because their in BASIC) and I'm in no means a hardcore·programmer. I'm more of a hardware guy·that picked up some coding.·However, with all due respect to the good people at Parallax and the Propeller, it just wasn't for me. I needed to keep it simple to follow and understand. Anyway, This· uLCD-320-PMD2 hopes to provide me a break from my LED projects for a while and still keep me in line with the BS2 and SX products.
I feel comfortable with what I have read so far about the uLCD-320-PMD2.
Thanks again!
I tested using a Prop plug to hook up the display for PmmC download as well as the Graphics Composer. It works fine. I'm in the process of putting together some instructions with pictures and schematics for using the Prop Plug and·USBtoSerial adapters for PmmC loading and Graphics Composer. It looks like it should also be possible to ues both the serial and USB BOE as well, but I haven't wired it up and tested it yet.
To answer your question, both the PmmC loader and the Graphics Composer let you choose any active Comm port on your PC. Any of the USB to serial bridges should work fine if they're hooked up properly. Keep in mind that the PmmC loader is the only one of the two that MUST have the RESET line connected (the PmmC loader does a reset in order intercept the boot loader to erase the old micro code and load the new code). The Graphics composer just needs +5V, Gnd, Tx and Rx.
HTH,·· Steve
Post Edited (Duffer) : 9/17/2007 9:38:12 PM GMT
I have tried 4 times now to send you a PM and it keeps getting a runtime error.
Just wanted to say thanks again!
I've been having the same problem. Turns out that it's getting sent, but the error persists. I got·all of your PM replys to my earlier message. I thought I was going to have to rewrite the one I sent, but it went through.
Steve
P.S. You said in one of your messages that your interest of late has been with LEDs. If you think of the LCD and OLEDs as just large matrices of tri-color LEDs (with a low power magnifying glass, you can see the three colored (RGB) LEDs that make up each pixel on the OLEDs). The difference is that you use serial commands and RGB color values instead of PWM to achieve the color you want.
Post Edited (Duffer) : 9/18/2007 1:51:48 AM GMT
I remember seeing those screens and knew it was only a matter of time before someone would start using them. [noparse]:)[/noparse]
--Andrew Arsenault.
I have not worked with RGB LEDs or PWM per say yet. I am currently working on a little·larger scale LED display of (5) 8x8 Bi-Colored (actually 3 colors being green, red and yellow) using a serial chip A6821 similar to the parallel chip ULN2803 that I have used in past designs. This allows for useage with an SX-28 and not an SX-48/52 for the high I/O count. It's taking me a while do to the point to point soldering on the board I'm using.
Anyway...as not to give the impression of hijacking the post - I will conclude with that.
Will the uOLED-128-GMD1 object work with the uOLED-128-G2 ?
Cheers