Jump to content

Josh

Members
  • Posts

    3
  • Joined

  • Last visited

Everything posted by Josh

  1. I haven't bothered to play with the timings, but attached is my current efforts. I've got a 10 by X variable width font engine working which I'm pleased with. I had it at 8 high to begin with, but 10 lets you have hanging letters and for what I want to do I can have 5x11px rows (10+1 space) and then 9px for a status bar at the top. Conveniently it takes almost no RAM and doesn't need much in the way of a buffer though it's just fast enough at 1MHz (fine because only a few characters change at any one time), at 8 it's more than quick. Fonts can be stored in program memory space (around 2k out of 32k for 8-bit ASCII) and the engine renders one character at a time into a 4x10 pixel block , compensates for overflow into the next block and adds an (ascii) space afterwards. It also pads up to 4 pixels on the end to ensure the entire string prints. The print string function returns an x-offset so instead of concatenating strings, you could do: /* printstring(uint8_t * input_string , char intensity, uint8_t x, uint8_t y, uint8_t * x offset); */ printstring("ADC Value", 15,0,0,&offset); printstring(itoa(ADC), 15, offset,0,&offset); You might lose up to 3 pixels - as the previous string could have forced 3px of space maximum, but it's not such a big deal. Ignore the little battery thing at the top right, I was experimenting. You can fit nearly 6 rows of text, allowing for some tails being cut off on the bottom row. The number of characters per line is variable due to the changing letter widths, but you should be able to get at least 32 full width characters worst case, and often more. It's cool now it works, debugging programs via the screen is so much easier than simulating in Proteus and staring at logic traces! Apologies for the blurrycam, my SLR is at home :(
  2. Ok, so after a bit of fiddling I got it working. I think the problem was with my serial code, rather than the init sequence itself. I had the clock signal with the wrong polarity (idle low rather than idle high)... I'm running it at 3.3V with the following assumptions: 1. The data pins are 3.3V tolerant in the datasheet 2. The VCC pin on the Newhaven board simultaneously powers VDD, VDDIO and VCI 3. If you power on with 3.3V and turn on the internal 2.5V regulator (via command) for VDD, you're now essentially running the whole board (VDDIO and VCI) at 3.3V hence it's not going to damage anything. Plus, the onboard 2.5 is probably better than what we're slinging into it with cheap LDO regulators. Anything less than this gives very flickery or dim displays. I've also got 220uF and 0.1uF capacitors in parallel to give it a bit of extra oomph. I'm not particularly concerned about the lifetime of the display, it looks rock solid with all the pixels on at 3.3V so that's where it's going to stay! The init sequence is essentially yours, I believe, I've set the contrast to 127 after initialisation which looks nice. I've uploaded working C code. It's an extremely simple circuit, 5V USB goes to a 3.3V LDO regulator which powers both the micro and the display. The display is set up in 4-wire serial mode directly to the MOSI/SCK pins on the AVR and a couple of extra GPIOs dealing with Reset, CS and DC. I'm going to look into getting some fonts and other bits and pieces working today. Only one other question - high contrast causes a fair amount of banding, not sure if that's normal? Thanks for this thread, it's a lifesaver! Josh oledtest.c
  3. Hi chaps, I've bought a couple of these displays and I'm generally banging my head against the wall trying to get some initialisation code to work on them. I'm using an Atmel AVR powered by 2.5V which is from stepped-down 5V USB. As far as I can tell my code works, and I've checked it on the scope, but I can't get anything to light up. I'm going to have a look at adding a cap and I'll report back. Essentially my mission at the moment is to write up full documentation for both initialization and the command set because frankly what's provided by Solomon and Newhaven is terrible! Really looking forward to getting it working, though the micro only has 1K of RAM, so a 256x64 4-byte buffer is a no-no for me (I should point out I'm not involved with MIDI devices, but I really want to get this screen working and I'd be happy to share code/otherwise collaborate!) The main problem seems to be that Newhaven have taken a completely backwards approach to interpreting the SSD1322 datasheet. The impression I got was that you provide a 3.3V line (VCI) to power the logic and then you turn on an internal 2.5V regulator (VDD). The data pins are set to VDDIO which is 0-VCI, i.e. 3.3V tolerant. So the obvious choice, to me, is to provide a 3.3V interface and regulate VDD internally. They've gone the opposite way and forced you to provide a highly stable 2.5V power signal which also means you need to provide 2.5V data lines, etc. I'm hoping to get some sample C code working over the next couple of days, but I was annoyed enough that I designed a new backboard for the display which you can see here: http://img23.imageshack.us/img23/1598/screenshot20120412at024.png It's an 8 pin breakout, 3V3, GND, CS, DC, CLK, SDIN, RES and 12VENABLE. There's an onboard 3.3V-12V step-up converter and you can enable the 12V line using the 12VENABLE pin - based on the datasheet, the OLED power line should be turned on after core logic. Newhaven don't seem to have bothered and it doesn't look like it makes a difference, so you could just tie it to 3V3 and have done with it. Otherwise, I think it's a lot simpler and a lot neater than their board. Not entirely finished - I need to draw up the holes for the display, but otherwise it's done. I don't think many people are interested in programming this in parallel, so I figured go for the minimal number of pins. Best, Josh
×
×
  • Create New...