Back
[08:04:00] <LeoNerd> Who's awake currently, and has any experience of SSD1306 OLED modules? I have a frustrating one here. I have three modules that I've bought; two are I²C attached, one is SPI4.
[08:04:40] <LeoNerd> The SPI4 and one of the I²Cs are working nicely reliably. The other I²C almost never displays any data. I get random noise on the screen and no amount of writing to VGRAM manages to display a real picture. Except *one* time. One time ever, I have drawn to the screen
[08:05:32] <LeoNerd> No code changed, no hardware changed. It just worked once then never again. I do *occasionally* find I can't write to the SPI display properly either; it ignores my requests to draw. In that case, I can "RESET" the chip, because its reset line is brought out of the module on a separate pin; after that it works fine. But I can't do the I²C ones because they don't have a reset pin
[08:06:04] <LeoNerd> I wonder therefore if my initialisation code is somehow missing something? That the chip is somehow getting stuck in a way, I don't know... maybe the VGRAM address pointer is stupid.. could be anything. Something uninitialised
[09:05:06] <carabia> LeoNerd, mind showing some code, then?
[09:05:37] <LeoNerd> https://metacpan.org/source/PEVANS/Device-Chip-SSD1306-0.03/lib/Device/Chip/SSD1306.pm#L100
[09:07:55] <carabia> oh wows, perl
[09:08:26] <aandrew> I've used the SSD1306?
[09:08:29] <aandrew> what's up?
[09:08:35] <aandrew> that was meant to be a statement not a question heh
[09:09:20] <LeoNerd> aandrew: If I flick the "Reset" pin on my SPI4-interface module, then it's nicely reliable. If I don't do that then *occasionaly* it gets stuck where it accepts commands, but requests to write data don't quite work
[09:09:39] <LeoNerd> I can affect the first 8 pixels (the first 8bit byte) but no further. so the rest of the screen contains random vgram junk
[09:09:58] <LeoNerd> This *almost always* happens on one of my I2C-based modules.. I have once ever managed to write data, but normally it just stays as junk
[09:10:07] <aandrew> hm
[09:10:17] <aandrew> let me dig up some code, but IIRC there wasn't any magic to it
[09:10:21] <LeoNerd> I can write *controls* absolutely fine; I can adjust display contrast or lamptest, I can scroll the display and if I do that, the junk moves.
[09:10:36] <LeoNerd> S o Isuspect what's happening is that it's not honouring my requests to write into vgram
[09:10:56] <aandrew> is your supply good and stiff? if you put say 10k across the supply rails of the module and then use a FET to switch power to it you might get a better power on
[09:11:23] <LeoNerd> Ooh.. curious thought. The supply is just switched by the BusPirate, so.. hmm... I'm not sure
[09:13:07] <LeoNerd> E.g. I could imagine if there was some config option to control autoincrement of VGRAM addresses when writing display dayta
[09:13:25] <LeoNerd> If I forgot to initialise that then maybe it wouldn't move the pointer when writing, so I'd only ever be able to write the first byte
[09:13:42] <carabia> Oh by the way, does anyone know for european deliveries, does mouser ship from the states?
[09:14:36] <carabia> LeoNerd, usually the display ram address gets autoincremented with reads and writes no matter what
[09:15:15] <iwancoppa> LeoNerd: My gut instinct, given that the fault is intermittent, is to examine the analog side of the circuit
[09:15:36] <iwancoppa> What's your power supply ripple like, how much over/undershoot on the data lines, how low is your logic low, etc
[09:28:17] <LeoNerd> iwancoppa: Mm.. it's not -exactly- intermittent. So e.g. the vgram noise is different every time. I think when unpowered the ram cells all become randomised
[09:28:30] <LeoNerd> But looking at the power might be a thing, a little tricky though 'cause it's a premade module
[09:29:10] <twnqx> carabia: mouser and digikey ship from the US, yes
[09:29:23] <twnqx> though it's 2 working days here
[09:29:27] <Lambda-Aurigae> digikey has canadian office too.
[09:29:41] <LeoNerd> My mouser.co.uk order arrived a lot quicker than would be US shipping
[09:29:43] <twnqx> doesn't make a difference for the question of shipping to europe
[09:30:03] <twnqx> LeoNerd: i normally have 36h if i order around midnight, from both mouser and digikey, from the US
[09:30:03] <carabia> twnqx, yeah indeed it doesn't
[09:30:16] <carabia> never ordered anything from mouser, just wanted to be sure. Thanks.
[09:30:36] <LeoNerd> (I had to use Mouser because they had a chip whereas Farnell said *November*)
[09:30:50] <LeoNerd> Er.. October actually. But still
[09:31:08] <twnqx> farnell ships from all over the place
[09:31:14] <twnqx> one order, 3 countries
[09:33:59] <iwancoppa> "Maintenance Notice The page you have requested is temporarily not available. Please check back later. We are sorry for any inconvenience."
[09:34:11] <iwancoppa> Well, I suppose that's better than the 'nothing has samples available' of 3 days ago.
[09:39:55] <twnqx> Size 27248806 bytes
[09:40:14] <twnqx> so why does my browser say it's dling roughly 48MB :S
[09:51:37] <Tom_itx> it's giving you a bonus virus
[09:59:31] <twnqx> it's probably 20MB of during-download inserted watermarks
[13:16:52] <_ami_> hey guys
[13:17:17] <_ami_> i think i messed up with avr fuse settings for atmega16a (-U lfuse:w:0xff:m -U hfuse:w:0x99:m )
[13:17:26] <_ami_> is there any way to revive it?
[13:19:42] <_ami_> i hv usbasp programmer.
[13:52:22] <wberger> hello at all !
[14:06:23] <alx741> _ami_: did you see:
http://www.instructables.com/id/AVR-High-voltage-programming-Fuses-rescue/
[15:01:06] <_ami_> alx741: there was some problem with xtal connection. 1 cap was not grounded. loose connection while soldering
[15:01:12] <_ami_> i did fuse correctly.
[15:01:57] <_ami_> it was just the wrong connection. although i should make high volatage programmer for future to get rescue
[19:59:06] <LeoNerd> Huh. Well, that wasn't too hard. I seem to have an interrupt-driven software UART. A duplex-capable one.
[19:59:28] <LeoNerd> Runs fine on my tiny85, anyway
[20:25:44] <Thrashbarg> neat