TK. Posted December 23, 2013 Report Share Posted December 23, 2013 I guess that you only tried the long cable, but not the short cable to J15, right? Anyhow, although the actual issue isn't clarified (I hoped that we are able to achieve this), we should go for Plan B: connecting the 16 CS lines to two DOUT SRs which are connected to J28. Unfortunately I can't give you new code till next week (Merry Christmas! :smile:) Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
novski Posted December 23, 2013 Report Share Posted December 23, 2013 HI TK. no thats a wrong assumption. Yes, i had to take a different cable because i tested with 16 header Female DIL contacts and to take one connection out is impossible, so i now tested with single wires. No, the Cable length is kept as short as possible. one thing i just recognized is that if i disconnect oled9-16 and reboot than the oled 1-8 work perfect. A question: I see the Serial IN of IC2 (SR of oled1-8) is connected over 1kOhm to LCDvolt. And the Serial IN of a DOUT is not. What is the difference between those 2 use-cases of 74HC595? ( {Thinking loud...} is it possible that that Serial input is inverted and the inversion causes a delay so the alignment of the Datalines D0,D1,DC is not coherent with the CS lines anymore, or something like that...) i don't care to wait. I hope we get that running someday... :-) but first, i wish you a merry Christmas and a Happy New Year of coarse as well! best regards novski Quote Link to comment Share on other sites More sharing options...
TK. Posted December 24, 2013 Report Share Posted December 24, 2013 I see the Serial IN of IC2 (SR of oled1-8) is connected over 1kOhm to LCDvolt. And the Serial IN of a DOUT is not. What is the difference between those 2 use-cases of 74HC595? This pull-up resistor shouldn't make a difference for the SSD1306 driver (but thanks for the hint, I should doublecheck my assumption). It's intended for displays which work at 5V, in this case the IO pins will be configured for open drain mode, so that the resistor pulls the output level to ca. 5V. The SSD1306 driver configures IO pins for push-pull mode instead, so that they are switched between 0V and 3.3V ( {Thinking loud...} is it possible that that Serial input is inverted and the inversion causes a delay so the alignment of the Datalines D0,D1,DC is not coherent with the CS lines anymore, or something like that...) I thought that I already doublechecked this, but let me tribble check the implementation next week ;) My own assumption was the following: the SDA input of the SSD1306 displays was connected to J15:RW This pin is also connected to the OE# (Low-Active Output Enable) input of IC2 Which means: whenever a "1" was transmitted to the displays, the 74HC595 outputs were in high impedance state for a short moment. Although experiments showed me, that the short high-impedance is hard to notice with a scope (and therefore would be acceptable), I'm unsure if it has a more dramatic effect once much longer cables are used (very likely...) Therefore in the last modification, SDA was driven from another pin, so that RW (and accordingly OE#) is always 0, and accordingly the outputs of the 74HC595 should always be active. I expected that this avoids the potential problem, but now you noticed an even worse effect, which really puzzles me! :-/ However, I'm sure that we will find a solution (regardless if fully understood or not) this year! :) Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
TK. Posted December 29, 2013 Report Share Posted December 29, 2013 Here the next try: http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769_20131229.zip This package contains two .hex variants: one where SDA is available at RW (like in the official schematics), and another one where SDA is available at J15B:E2 I noticed, that the on-board 74HC595 was loaded faster than expected (ca. 750 nS instead of 1.5 uS), this could cause the unstable CS1..8 lines. It was faster than the SR load of J28 based DOUT chain... Please try it. Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
novski Posted December 30, 2013 Report Share Posted December 30, 2013 (edited) Hi TK. I tested the two. SDA@RW & SDA@E2: All oled show content now thats the good news. But at my side they still flip over the edge and get corrupted on oled 1-8, when 9-16 continues stable. As soon as i detach the D0,D1,DC lines from the oled 9-16 the oleds 1-8 become steady (the flipped ones stay fliped and don't change their layout anymore). And after a reboot they show stable and correct content of Test.app. Thats a bit different then with the software before Christmas. Because before Christmas they immediately cached up and get steady content without a reboot... its so hard to describe so i made a video where i show you the tests. First a old app then the two new ones... https://www.dropbox.com/s/vox221xgtzgxacr/2013-12-30%2011.03.29.mov Please note that oled #1 is right hand sided and 8 at left. Count Displays from Right to Left... best regards novski Edited December 30, 2013 by novski Quote Link to comment Share on other sites More sharing options...
novski Posted December 30, 2013 Report Share Posted December 30, 2013 Just had a idea witch is not a solution, but more a test. Can we use the Serial Output of IC2 (pin 9) to connect other Shiftregisters as done on DOUT boards...? Wold may be interesting what happens to the following displays... (?) novski Quote Link to comment Share on other sites More sharing options...
TK. Posted December 30, 2013 Report Share Posted December 30, 2013 Thanks for the video! It proves, that the problem is related to the SCLK line (and I had this assumption some weeks ago, but didn't follow this further). Meanwhile I assume that it's not related to CS lines (therefore also the usage of the serial output of IC2 would be the wrong direction). E.g. at 0:55 you can see a typical effect if an invalid command is shifted into the display. The display outpuz get's scrambled, but we can see that graphics are still changing - so, data transfers are still working correctly. Sometimes the display is scrolled down - again due to an invalid (received) command. If a display is turned off, then this could be caused by a wrong command as well. At 1:01 display 4 and 6 are working w/o re-initialisation, which means that previously they probably haven't received the data. I did some experiments at my side to provoke similar effects, and had success: by connecting a 100 Ohm resistor between 3.3V and SCLK (D0), the display content of some OLEDs (but not all OLEDs) get's corrupted like in the video. The interesting point: if I connect the resistor to D0 of display #1, content of #1 and #2 are still ok, and #3 and #4 get corrupted (currently I can only test this with 4 OLEDs) - again, similar to your video where different OLEDs show different behaviour. The effect doesn't happen with a 220 Ohm (or higher) resistor. But I guess, that I would see an effect if I would use more OLEDs. So, what does it mean: we've a 1k pull-up at E1 (outputs the SCLK), which results into a weak load. It could be, that the load get's relevant than more displays are connected. My experiment showed, that such a load can cause corrupted display contents at various (but not all) displays. Next experiments required at your side: 1) of course, it would be nice if you could desolder the R33 resistor network (it isn't required for the SSD1306 setup anyhow), but it will be difficult... 2) therefore, before doing this, please try out mios32_test_app_lcd_ssd1306_LPC1769_20131229_sda_at_rw.hex under following conditions: - disconnect the SCLK line of display #9..16 - are display #1..#8 working properly now? - connect SCLK line of display #9..16 with J15B:E2 (the alternative SCLK output) - are all displays working now? Please note, that you've to power-off the core for at least 5 seconds between each experiment to ensure, that the OLEDs are reseted properly. Otherwise they could still have a wrong configuration which leads to invalid output. Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
novski Posted December 30, 2013 Report Share Posted December 30, 2013 (edited) #2 Works!!!! https://www.dropbox.com/s/7c4lfav0hokuo5i/2013-12-30%2017.15.45.mov Taking out R33 didn't change the behavior. It still does not work on E1. E2 works well. So what solution do you consider for future? Seams to get quite difficult to get a oled chain working with J15A,J15B & J28.... best regards novski Edited December 30, 2013 by novski Quote Link to comment Share on other sites More sharing options...
TK. Posted December 30, 2013 Report Share Posted December 30, 2013 Finally!!! :turned: Here the appr. MIDIbox NG release with the modified driver: http://www.ucapps.de/mios32/midibox_ng_v1_029_pre2.zip So what solution do you consider for future? I will prefer the duplicated SCLK output at J15B.E2 If somebody really plans to add more than 16 OLEDs, I will recommend to buffer SCLK and SDA with a 74HC541 Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
novski Posted December 30, 2013 Report Share Posted December 30, 2013 Thanks for the quick implementation! Wold you recommend to buffer SCLK and SDA after every eighth display or less? updated the schematic, do you mean like this? best regards novski Quote Link to comment Share on other sites More sharing options...
TK. Posted January 1, 2014 Report Share Posted January 1, 2014 updated the schematic, do you mean like this? I would connect the first 8 displays to buffered outputs as well. Change the schematic the following way: connect the J15 based SCLK output to A0, A2, A4, A6 of the 74HC541 connect the J15 based SDA output to A1, A3, A5, A7 of the 74HC541 connect D0/D1 of the first 8 displays to Y0/Y1 of the 74HC541 connect D0/D1 of the next 8 displays to Y2/Y3 of the 74HC541 Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
TK. Posted January 19, 2014 Report Share Posted January 19, 2014 Novski, could you please do me a favor and check if following binary is still working at your side? -> http://www.ucapps.de/tmp/mios32_test_app_lcd_ssd1306_LPC1769__20140119.zip In the last days I did some changes in the LCD driver to support STM32F4. I want to ensure that I haven't broken the LPC17 variant before releasing a new bootloader (and MBNG) firmware Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
novski Posted January 19, 2014 Report Share Posted January 19, 2014 works perfect on a LPC17 core. Quote Link to comment Share on other sites More sharing options...
TK. Posted January 19, 2014 Report Share Posted January 19, 2014 Thanks! :) Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
schoko11 Posted February 3, 2014 Report Share Posted February 3, 2014 Hi! Hopefully this is the right place to ask this question.. I have bought 16 SSD1306, and i want to use them for a mackie control clone (+ extension). I have to make pcbs, and in terms of reduced complexity the "function" of the ledring should be handled by the SSD´s That would be similar to the Picture in the LCD Hardware option page. Example: the bottom line displays: PAN | PAN VOL | VOL indicating the Position / Value. Would this be possible to implement ? thanks so far klaus Quote Link to comment Share on other sites More sharing options...
John E. Finster Posted February 3, 2014 Report Share Posted February 3, 2014 Hi, maybe you are looking for something like this Above the tracknames I created a small bar indicating the vpot position. I did this by creating some custom fonts for Midibox NG, which is running a mackie clone script. But I experienced some problems with mackie control protocol and ssd1306 displays. You can read about them in this topic I was able to resolve some of the problems myself, but not all. Unfortunately I ran out of free time after that and wasn´t able to get back to them yet. Maybe the newest NG firmware fixes the remaining problems, but I can´t rule out technical issues either for sure. greets Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.