Well done! Have to order a few 4050s @ next Reichelt order! 
Greets,
Peter
i didn’t draw it in, but of course if your’e connecting a 2nd lcd to d1, use additonal i/o on that chip. 11/12, 14/15, etc. you’d probably figured it out but i was just wiring it up and thinking about what i forgot.
i improved the schem so it makes sense for a 2nd display. if any more are necessary, i can draw it. a third could still be connected to this chip, but after that another 74hc4050 would be needed. i also can now verify that this works, since i have the voxel demo running on my display 1!
ultra
Great work! Are there any display flickering/stability issues with this setup, now?
Very cool!
Bye,
Peter
seems to be a slight flicker in the voxel demo. i should really install some capacitors.
the only way i’m going to be able to write a driver is to base it off existing code. is anything at all implemented here? i changed my lcd type environmental variable to ssd1322 and compiled/loaded the glcd tutorial. i don’t get anything on the display. i’m not sure if you meant nothing in the driver is working, or just the part that lets you print bitmaps.
okay I figured out that I have to edit the display type in the makefile and set the environment variable back to universal. I haven’t worked with custom displays before. I looked at the mios32 display types and I didn’t see the ssd1322 on there. but if your demo works then it must be implemented somewhere. I will try it when I get home.
Very slight screen flickering might be also due to the “improvised” display initialization - i experimented for hours with different init values - all completely different than the newhaven values
But putting a “buffering” cap to the 2.5V main display power supply is a good idea!
Regarding font output - it depends on your timeframe, i might get some code running next (not this) weekend, it should not be soo hard…
For my intended use, i´d like the screen to be divided into 64x16 pixel rectangle regions (each one corresponding to an encoder), each region filled with either two lines of 8 pixel high text (tiny) or one line with 16 pixel high text (well readable).
Bye!
Peter
that’s exactly the layout I’m looking for. let me know when you get something done. I’m just not experienced enough to write something from scratch.
edit: forget that… i’m gonna figure this out. after looking at your test screen code, it’s a lot more clear.
another edit: using the test screen, i can see the flicker is really bad. hopefully only some capacitors will help. do you recommend a value?
Combine something big and small - smaller is typically faster and bigger has more oomph - you want both. Somewhere between 10-100uF + ~100nF should work well.
yes, if tha caps don´t work, the display initialization needz moar brainz have a great weekend and have fun experimenting with tha font codez 
i’ll try the caps later. for now i’m having a lot of fun with this. i got some nice single pixel wide horizontal meters written (i ditched the idea of having a meter behind text) with a light gray bar for the entire meter, and a brighter one showing the value. can be put anywhere on the display using parameters. i think i might go all out and make my own custom font and everything. that way i don’t have to have fixed width characters and i can get more info from the screen. wheeeeee!
I am usually working with variable-width fonts as well. Has lots of advantages, but makes aligning text a lot harder. A pretty nice workaround is (if you use smallish fonts and have all upper-case letters anyways) to use fixed-width upper-case and variable-width lower-case letters
got some things working now.
Yo, man! Looking great already!
Greets,
Peter
hawkeye:
is there some pattern to the shading?
i have a 2d array that stores information on individual pixels. this doesn’t include what value i get when both pixels are on.
so if array[0] stores the value that gives me only the left pixel at a certain shade, and array[1] stores the value that gives me only the right pixel at a certain shade, is there an operation that can combine the two to give me two pixels at the same shade?
i hope i’m clear on this.
thanks
Hi Ultra,
don´t know, if I completely understand the question, but will formulate a possible answer
as you have only 16 shades of grey/blue, you only need 4 bits for that information.
The memory is organized in bytes with 8 bits, so you can store 2 pixels in each byte.
If you want to set both pixels to color 15 (lightest shade/white), the byte would have to look like 1111-1111 in binary.
Example:
If the left one should be light grey (1000), the right one dark grey (0100), it would have to look like 1000-0100.
The C notation for entering binary numbers is to use the prefix “0b”, you may not need this, just enter the values directly in decimal format (0-15) or copy them from your font bitmap source buffer.
The computation operation to combine these two values from 0-15 is first a “left shift” operation, which shifts your left pixel value so that it is on the left side:
unsigned char bothPixels = 0; // Yet unknown
unsigned char leftPixel = 0b1000; // Light grey
bothPixels = leftPixel << 4; // Shift bit pattern to the left, bothPixels now contains "1000-0000"
Then you just add the right pixel on top of that value
unsigned char rightPixel = 0b0100; // Dark grey
bothPixels += rightPixel;
Now you can write this two-pixel byte to display memory (you usually write two bytes or four pixels at once). Regarding your question on how to calculate the “one byte” value with two pixels of the same color, it can be shortened to
unsigned char pixelColor = 5; // Decimal example
unsigned char bothPixels = (pixelColor << 4) + pixelColor;
Have lots of fun!
Greets,
Peter
this is exactly what i was looking for, thanks!
You are most welcome - when seeing all those nice font pics, my fingers also ache to code
Me also hopes to attract moar people to this nice display
Maybe you can share the font engine, when ready?
Greets,
Peter
I added one of those badboy OLEDs to my last Digi-key order, plus a white 16x2 OLED from Reichelt and some of those x4050 buffers. Guess there will be some experimentation with that and those Core LPCs laters :whistle:
FS1r programmer or this MB3396 look like the targets in line. Unless we get an MB-SIDv3 soon.
hawkeye,
right now i don’t have any code that would be useful to anybody else, unless they wanted to use my specific format. but i’m finding it limiting even for myself, so i’m going to work this afternoon to make it more universal.
my current method is to store an array[64][256] that simply contains 1’s and 0’s to tell whether or not a pixel should be on or off. this array is used for the entire region of the display. i’m going to change that to store 0-15 so the shade will be stored instead, which is why i asked my question earlier.
then i wrote a simple loop to read four slots out of the array at a time, and test them for on/off and write out the correct 2-byte codes to the display. it works great and i won’t need to change it much for displaying the overall picture, except for changing the algorithm a little bit to account for shades. maybe this is the standard way of doing this, i don’t know. i just started working out what makes sense to me as i don’t have any previous experience in writing a display driver.
to draw my font, i wrote code specifically that would work with this font. i’d like to do it an entirely different way though, which i’ll describe later. i have 3 functions to draw them: write_h_line and write_v_line will ‘draw’ horizontal and vertical lines into the main array based on starting x/y coordinates and length. a third function, write_pixel will write a single pixel based on x/y coordinates. calling them has to include whatever offsets i want (tall/short letter, etc). so when i feed in a string like “this”, it loops each character, writes each to the main array, and puts an extra pixel for spacing. i just keep a running counter to show where the x-coordinate is for the start of a letter.
i’d like to just store fonts in different files. i like to have space available on both the top and the bottom to account for letters such as ‘h’ and ‘g’. so for example, if i account for a font being 11 px tall (7 for a short letter like ‘o’, two px above that for a letter like ‘h’, and two below that for a letter like ‘g’) and want to write ‘h’, it’ll be stored like this:
1000000
1000000
1000000
1111111
1000001
1000001
1000001
1000001
1000001
0000000
0000000
that’s essentally an ‘h’ in the superpoint square font. but the same engine could easily read other fonts if the 1’s and 0’s (or actually, the value representing the shade) was stored for it.
my biggest setback is that i’m really not that great at C, and OOP makes more sense to me. i want to store data that contains the following information:
font name
overall font height
each character of the font, which has the following:
width (if even necessary)
left offset (i posted a pic below to show what that means)
an array storing the 1’s and 0’s (or shade values) that can be returned to the function calling it,a nd then inserted into the main array
i think i just need to learn more about defining types to store this data, and using pointers to make the array usable. i’ll figure that out this afternoon maybe.
once this is done, and a small library of fonts are stored, the programmer or user could just select a font based on name, then size (i find that odd # sizes work best), and then write the letters where they want.
also i’m wondering how to handle words that are bigger than the space allowed (i want to code this to let the user define regions like you said), so if a word is too wide, it gets truncated. my thoughts were ‘truncate’ would turn into 'trunca.." if there wasn’t enough space. if i go that route, i already have a good idea of how to do it. also, i’m going to incorporate left/center/right justification based on the user defined region.
anyway, i’m not really looking for you to answer anything unless you can tell me what’s best for storing/retrieving the font data. i’m just throwing out what i’ve figured out so far and hoping for somebody to tell me if i’m going about it the wrong way.
the attached image shows what i mean by ‘left offset’. the lowercase ‘j’ got it’s own bit of code, which (if it’s not the first char) backs up the counter to make the bottom part of the ‘j’ wrap around the previous letter. maybe switching from windows to a macbook has made me put too much emphasis on style. 
