Back
[00:30:07] <hypermagic> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
[01:34:11] <Casper> rue_* ?
[06:38:30] <mzbotre_> Hi! Im trying to turn my ATMega328 into a SPI encoder for flashing a BIOS chip. I have everything figured out electronically and have set the control pins to digital output on my little ardweenie microcontroller.
[06:39:27] <Tachyon`> given the arduino programmers are themselves SPI I'm surprised nobody has written software for reflashing BIOS chips using it
[06:40:17] <sebus> Tachyon mzbotre_ datasheet for spi flash chips and code.
[06:40:19] <mzbotre_> Me too. I've ran into some "flashrom" programmers, etc, but none of the options really give you a good option.
[06:40:51] <mzbotre_> sebus: this is the datasheet
http://www.eonssi.com/upfile/p200892918920.pdf
[06:43:53] <mzbotre_> Code is in the midst of being written, here's what I have so far.
[06:43:55] <mzbotre_> http://pastebin.com/KaqxrWnk
[06:45:25] <mzbotre_> And then I found something pretty interesting. Seems to be written for the linux kernel, original version was commented in chinese. Hard to emulate SPI on SPI, but what I *do* have is an AT91SAM9N12 which I could embed linux to.
[06:46:40] <mzbotre_> http://pastebin.com/ydqTW3eB
[06:49:40] <mzbotre_> The second is preferred tbh, but that would be an entire process of building a microcontroller around this code to have kzalloc
[06:57:00] <sebus> hum.... linux thingy on SAM9N12?
[06:58:35] <mzbotre_> Yeah, my current setup is all ATMega328, but that's a different thread. A SPI link spawning SPI links seems less crazy with that setup.
[08:34:33] <Lambda_Aurigae> http://www.precisionmicrodrives.com/application-notes-technical-guides/application-bulletins/ab-021-measuring-rpm-from-back-emf
[08:34:39] <Lambda_Aurigae> iiinteresting.
[11:06:49] <FL4SHK> Annyone here familiar with using assembly with an Arduino?
[11:07:35] <Jan-> do I need to avoid I2C over SPI, or is it fine
[11:10:15] <FL4SHK> I did find some information about the subject by using a search engine, but I'm kind of interested in doing stuff without the Arduino IDE
[11:10:49] <FL4SHK> The only problem is that I don't know how I would be able to use the USB serial features of the Arduino board without the Arduino IDE
[11:11:07] <FL4SHK> I mostly use the USB serial features for debugging :V
[11:12:34] <Jan-> I'm annoyed. Almost all the documentation that you can easily find these days refers to arduino.
[11:12:44] <sebus> FL4SHK i use as6.2... Why you need assembly language?
[11:12:45] <Jan-> I can't find much information about doing things in raw AVR.
[11:12:51] <Jan-> I've no objection to arduino but sheesh.
[11:14:31] <osteri> Jan-: datasheet ftw
[11:14:51] <FL4SHK> sebus: the reason is that I do some timing-critical stuff
[11:14:58] <sebus> osteri++;
[11:15:00] <Jan-> osteri: datasheets are often a bit unfriendly.
[11:15:15] <Jan-> I tried to read the atmel description of how to make i2c work and it was utterly impenetrable.
[11:15:33] <osteri> it might be overwhelming at first but i tell you: it's the best source of information
[11:15:43] <osteri> there is c code examples for i2c
[11:15:50] <Jan-> AVR stuff is often a bit tricky, inasmuch as everything is called OMGMSK and WTFCR
[11:16:00] <sebus> again osteri++
[11:16:15] <Jan-> that was the main problem, the pdf referred to C code but didn't actually include the C code.
[11:16:16] <Jan-> err.
[11:16:21] <osteri> Jan-: all of the AVR datasheets that i have read have c examples for i2c
[11:17:02] <FL4SHK> Oh and I'd like to just do some stuff in pure assembly sometimes sebus
[11:17:16] <FL4SHK> Then I can have custom "calling conventions"
[11:17:19] <sebus> FL4SHK you can mix c/asm anyway, useful in some cases
[11:17:28] <FL4SHK> Yeah but it's not the same :V
[11:17:38] <sebus> writing whole stuff in asm... geeez this is not 80's
[11:17:42] <FL4SHK> I don't care
[11:17:57] <FL4SHK> I like assembly
[11:18:18] <FL4SHK> Most of the things I do with an AVR aren't that large anyway
[11:18:27] <sebus> I liked it too, but then someone gave me a book about C... :D
[11:18:32] <FL4SHK> I don't even use C
[11:18:46] <FL4SHK> I use C++
[11:19:03] <osteri> Jan-: it's called TWI in AVR datasheets because some company owns the I²C term iirc
[11:19:16] <Jan-> yeah
[11:19:43] <Jan-> this one
http://www.atmel.com/images/doc2564.pdf
[11:19:50] <FL4SHK> I still want to learn how to make a whole project in assembly for an Arduino
[11:19:51] <sebus> iirc i2c was made by Philips?
[11:20:08] <Jan-> it talks about various c files
[11:20:15] <osteri> sebus: i think so, too laxy to google
[11:20:15] <Jan-> but doesn't provide any information on what is in them
[11:20:49] <FL4SHK> sebus: I don't write large projects in only assembly
[11:20:54] <FL4SHK> I am not an NES Programmer
[11:21:09] <Jan-> twi_master.c, twi_master.h and main.c
[11:21:22] <osteri> Jan-: what is your controller?
[11:21:41] <Jan-> mega328, it's actually an arduino board but I'm avoiding using the libraries
[11:21:44] <osteri> that is not the datasheet of your controller, that is application note
[11:22:03] <Jan-> nonetheless, it mentions C files but doesn't actually include the code.
[11:22:08] * Jan- scratches her head
[11:22:17] <Jan-> I hate when they do that. It's a secret!
[11:22:20] <sebus> about i2c...
http://www.atmel.com/webdoc/AVRLibcReferenceManual/group__twi__demo_1twi_demo_src.html and
https://github.com/vancegroup-mirrors/avr-libc/blob/master/avr-libc/doc/examples/twitest/twitest.c
[11:22:39] <sebus> good keywords in search engine = voila
[11:23:29] <Jan-> well OK but hang on, that's just talking *about* the C files.
[11:23:47] <Jan-> Again, where is the actual code? the actual contents of twi_master.c and so on?
[11:23:54] <Jan-> you know, the actual C source code?
[11:24:26] <sebus> that can be found...
[11:24:35] <FL4SHK> That's what Jan- wanted
[11:25:28] <Jan-> it's crazy! they're talking about this magic code then refusing to actually provide it.
[11:25:30] <Jan-> what's the point?
[11:25:48] <FL4SHK> Maybe it's in the source code of the AVR libc?
[11:25:54] <FL4SHK> (that's a guess)
[11:25:59] <Jan-> I found this:
http://asf.atmel.com/docs/latest/thirdparty.services.atmel_rf4ce.examples.avr477_target.project/html/twi__master_8c.html
[11:26:08] <Jan-> but again, it just lists the contents of the file
[11:26:13] <Jan-> the functions it defines
[11:26:22] <osteri> Jan-: c code example in page 216
http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf
[11:26:23] <Jan-> where on earth is the actual source ffs?
[11:26:46] <sebus> https://www.das-labor.org/trac/browser/microcontroller/src-atmel/lib/i2c/trunk/twi_master/twi_master.c?rev=3612
[11:26:48] <sebus> huh?
[11:27:01] <sebus> https://www.das-labor.org/trac/browser/microcontroller/src-atmel/lib/i2c/trunk/twi_master/twi_master.h?rev=3612
[11:27:47] <Jan-> that's not the code Atmel talk about in their docs
[11:27:51] <Jan-> is it something you have to pay for?
[11:29:37] <sebus> i got those files like twitest.c and so on with as6.2
[11:29:58] <Jan-> the code in the datasheet is in assembly language.
[11:30:37] <osteri> Jan-: there is c code as well
[11:30:54] <Jan-> sure, but it's not what's talked about in the application notes
[11:38:19] <sebus> found avr315 twi_master.c/twi_master.h if you're interested. real ones
https://github.com/denilsonsa/atmega8-magnetometer-usb-mouse/tree/master/firmware/avr315
[11:38:22] <sebus> seems like
[11:38:33] <Jan-> that's a start, thanks :)
[11:38:43] <Jan-> the document also talked about a main.c which presumably contained the actual example
[11:38:54] <osteri> Jan-: those headers TWI_master.c/h might be propietary, because the application note says something about IAR and it's not free compiler, as far as i know
[11:39:25] <osteri> so these actually shouldn't be uploaded to github, but lucky you :)
[11:39:31] <sebus> and also
http://www.atmel.com/images/AVR1315.zip
[11:39:52] <sebus> ahhhhh
[11:39:54] <sebus> grrr
[11:40:00] <Jan-> so what's the point in the app note
[11:40:22] <osteri> to sell IAR compilers :)
[11:40:38] <osteri> i guess
[11:40:43] <sebus> remove 1 from file link
http://www.atmel.com/images/AVR315.zip
[11:41:21] <sebus> avr315 is that what you were looking for
[11:41:23] <sebus> 3 files
[11:42:03] <Jan-> ooh.
[11:42:10] <Jan-> so why is that so insanely hard
[11:42:14] <sebus> no
[11:42:15] <sebus> http://www.atmel.com/products/microcontrollers/avr/default.aspx?tab=documents&Asset_Type=020%20Application%20Note
[11:42:24] <Jan-> and er, will that actually compile with GCC
[11:42:26] <sebus> if there's source file here, you can download a .zip
[11:43:31] <Jan-> the target by the way is something like this:
http://www.banggood.com/5Pcs-0_96-Inch-White-SPI-OLED-Display-Module-12864-LED-For-Arduino-p-959193.html?currency=GBP&createTmp=1&utm_source=google&utm_medium=shopping&utm_content=saul&utm_campaign=Electronic-xie-uk&gclid=CObMycrLj8YCFcsBwwod_7wA2g
[11:43:45] <Jan-> Some of them claim to be SPI or I2C for basically the same unit so I have no idea what's really going on
[11:44:06] <Jan-> my impression is that SPI is simpler and probably more appropriate for just running one display.
[11:44:44] <sebus> spi might be / is fast
[11:45:01] <sebus> also, spi is easy to make by bit-banging
[11:45:29] <FL4SHK> How do you get the timing correct without assembly?
[11:46:24] <sebus> well... I use asm for critical stuff in ISRs
[11:47:20] <sebus> isr naked to be honest, compiler just put there a lot of push, pop stuff by default
[11:49:05] <sebus> if you need to write really critical stuff in avr8, then... maybe it's time to use something more powerful than avr8?
[11:49:32] <Jan-> do you guys have any opinion on the displays I linked
[11:49:49] <FL4SHK> sebus you'd be surprised
[11:50:05] <FL4SHK> I want to generate composite video
[11:50:14] <FL4SHK> I want to control everything
[11:50:29] <FL4SHK> (I'd build the CPU myself if I had the tools, knowledge, and time :P)
[11:50:47] <FL4SHK> I do want to use my own code for generating the composite video signal
[11:51:14] <sebus> pal/ntsc... 4.43MHz chroma, crazy.
[11:51:30] <FL4SHK> Probably just NTSC in my case, and no color for sure
[11:51:37] <sebus> FL4SHK find some code (i belive uzebox can be useful)
[11:51:42] <sebus> this one used ad724 iirc
[11:52:12] <FL4SHK> I tried generating composite video from C before, but the timing is so critical that it didn't work properly
[11:52:22] <FL4SHK> I have to use assembly for it
[11:52:43] <FL4SHK> I'd also just like to get into the nitty gritty of it
[11:52:56] <FL4SHK> Write my own ISR and whatnot
[12:04:26] <BusError> Ahyone know if optiboot can work on mega2560?
[12:05:37] <sebus> FL4SHK why do you want to reinvent the wheel ?
[12:05:49] <sebus> i belive there are many sources for such things
[12:05:59] <sebus> for vga, composite video...
[12:06:44] <Lambda_Aurigae> the most common video generating these days is to use the SPI device in slave mode.
[12:07:04] <Lambda_Aurigae> configure a bit of manual feedback to initiate it and away you go...several people have done it.
[12:57:16] <DKordic> BusError: grep returned nothing for ``mega256''. Looking at it's source I would rather search for something else :D .
[12:58:39] <DKordic> FL4SHK: What is precise version of You Arduino board? If it has USB2UART bridge (FTDI or similar) You might take a look at [[
https://github.com/vsergeev/c-periphery][C Wrappers for Linux Peripheral IO]] and [[
https://pyserial.sourceforge.net/][pySerial]].
[12:59:23] <DKordic> I also prefer `assembly' on AVR.
[13:34:56] <ferdna> i need music... what you guys recommend?
[13:41:45] <Lambda_Aurigae> the 8-track still works
[13:41:53] <Lambda_Aurigae> but won't fit in the truck without some mods.
[13:42:56] <ferdna> hehehe
[13:43:06] <Lambda_Aurigae> the reel to reel died though.
[13:43:23] <Lambda_Aurigae> and I sold it and all the tapes for a pretty penny or three.
[13:43:38] <ferdna> i guess i'll stick to shoutcast...
[13:43:39] <ferdna> http://www.shoutcast.com/Search
[13:44:34] <ferdna> bbl
[14:26:44] <ferdna> nice license type...
[14:26:45] <ferdna> http://www.wtfpl.net/about/
[15:26:15] <ferdna> guys i need help calculating led resistors...
[15:26:30] <ferdna> i have two row of 5 leds...
[15:26:47] <ferdna> connected to a 82ohm resistor each row...
[15:26:55] <ferdna> to a 9v battery
[15:28:13] <ferdna> connected in parallel
[15:31:10] <ferdna> now i need to control the led brightness....
[15:31:20] <ferdna> and i would like to add a pot...
[16:49:33] <Jan-> oh and some engineering. but that's not my bother :)
[16:53:37] <LeoNerd> Wellthen.. I do believe I have just made myself a 4-way capacitive touch sensor
[17:02:08] <Jan-> I haven't even read the datasheet for the magnetic encoder yet.
[17:02:22] <Jan-> It's probably scary but I understand it just outputs 16 bits of data using some sort of serial interface.
[17:03:27] <Jan-> I did read the datasheets for the nordic RF radio modem chips before, it's not too scary.
[17:03:34] <Jan-> they have an onboard 6502 processor core, or something
[17:03:54] <aandrew> the nordic radio?
[17:04:09] <aandrew> nRF24L01 has no CPU, nRF51822 is ARM Cortex-M0
[17:04:32] <aandrew> chances are if it's an embedded core that's not ARM, it's 8051
[17:04:34] <Lambda_Aurigae> you are worried about using i2c and no problems with nordic radios? HAHAHA
[17:04:44] <aandrew> ra
[17:04:48] <Jan-> we've done that before
[17:04:55] <aandrew> oops, trying to route in the IRC channel doesn't work
[17:05:23] <LeoNerd> Password:
[17:05:43] <Jan-> swordfish
[17:05:46] <aandrew> *******
[17:06:20] <Jan-> the nordic radios are SPI
[17:06:46] <Jan-> there's just a lot of choices as to how you make them work
[17:06:52] <aandrew> yes
[17:07:05] <aandrew> but they are considerably more complex than bitbanging I2C
[17:07:26] <LeoNerd> I generally like the nRF24 radios, but the CE pin confuses me
[17:07:43] <LeoNerd> I don't see why it has to be an entire hardware pin, when it could be another config register bit
[17:07:51] <Jan-> I just went through the datasheet
[17:08:14] <Jan-> you have to make sure you set both ends up to the same settings and turn off the encoding and so on
[17:08:26] <LeoNerd> Ohyes, I know *how* to drive it, I'm just not sure *why* they decided that CE should be a hardware pin
[17:08:40] <LeoNerd> It eats up an extra GPIO on my tiny84 that I'd really quite like to use for other things
[17:08:45] <Lambda_Aurigae> LeoNerd, as in Chip Enable CE?
[17:08:59] <LeoNerd> Yeah
[17:08:59] <Jan-> isn't having a chip enable line normal for spi?
[17:09:10] <LeoNerd> No, it's not the SPI SS line, that's a different pin
[17:09:35] <aandrew> well they use CE for low power mode as well
[17:09:38] <LeoNerd> It has a normal SPI bus of MOSI/MISO/SCK/SS (which it calls CSN); an IRQ, and a CE pin. You have to pull CE high to send a packet
[17:09:44] <LeoNerd> Or be in receive mode
[17:09:45] <aandrew> yep
[17:09:50] <Jan-> the irq is quite handy
[17:09:54] <Jan-> you can be signalled when data arrives
[17:09:57] <LeoNerd> What I don't get, is why that CE behaviour can't just be another bit in the CONFIG register
[17:09:58] <aandrew> it's intentional and used for power control
[17:10:04] <Chillum> Jan-: the chip enable line is to share devices on the same bus
[17:10:13] <aandrew> LeoNerd: I think they brought it out because you might have external hardware you want to use to gate it off
[17:10:33] <Jan-> Chillum: isn't that just normal for spi
[17:10:34] <Chillum> (nevermind, misread)
[17:10:47] <Chillum> it is part of the standard
[17:10:51] <Lambda_Aurigae> the nordics have both SS and CE.
[17:11:07] <Jan-> there's just a bunch of stuff on the nrf chips yo uhave to set up
[17:11:17] <Jan-> "data pipes" and such which sort of don't help much but you have to set them up anyway
[17:11:22] <LeoNerd> aandrew: Perhaps.. in that case, I'd have preferred some config bits to decide whether I get software control of that over a register, or it uses the hardware
[17:11:27] <Jan-> I just used 0
[17:11:31] <aandrew> LeoNerd: yep me too
[17:11:35] <Jan-> it worked
[17:11:53] <LeoNerd> I'd also ideally love a config bit to set the IRQ line into open-collector mode, but at least that one's an easy workaroudn with a diode
[17:12:03] <LeoNerd> So in practice it's no big deal
[17:12:04] <Lambda_Aurigae> you think nrf is fun to setup? oled setup is rather picky.
[17:13:41] <Lambda_Aurigae> and you can damage the oled if you don't set it up right.
[17:15:32] <aandrew> if it's running one of the standard OLED controllers they usually have init sequences in the datasheets
[17:16:28] <LeoNerd> Ohman those things
[17:16:32] <LeoNerd> They're horrendous
[17:16:45] <Lambda_Aurigae> aahh.
[17:16:59] <Lambda_Aurigae> only messed with one of the ones that didn't have self-init.
[17:19:13] <Jartza> ouch
[17:19:30] <Jartza> chinese oled displays and their "init sequences"
[17:19:34] <Jartza> and example code :)
[17:19:46] <Jartza> multi-ouch
[17:20:43] <Jartza> one of my favorites:
http://www.buydisplay.com/download/democode/ER-OLED0.96-1_I2C_DemoCode.txt
[17:20:46] <Jartza> :D
[17:23:22] <Xark> Hey, at least it has comments. :)
[17:23:35] <Jartza> mm... yea.. kinda
[17:23:54] <Jartza> really. it's horrendous.
[17:27:54] <Xark> Not ideal. But, really just one "binary blob" for init. Most of the crap is font and demo pictures you (probably) don't need/want.
[17:30:05] <Xark> Jartza: I have had to deal with similar for several TFT LCDs. If you care, you can "decode" the binary init blob using datasheet as I did (and make it use #define'd command names etc.). Looks nicer, but not super useful. :)
[17:33:44] <Jartza> yea
[17:38:36] <Jan-> I'm not sure I should have bought these displays
[17:38:42] <Jan-> they come from a website called "bang good"
[17:38:53] <Jan-> personally with regard to electronics I've always felt that bang was bad/
[17:41:29] <Xark> Yeah, I have bought a bunch of stuff from them. Very similar to DX or FastTech.
[17:43:07] <Xark> Those same OLEDs are all over ebay too. I recently got a very similar one that is I2C (www. helterc.cn "brand").
[17:46:17] <Jan-> I'm really not sure about this i2c stuff
[17:46:20] <Jan-> I think I'm going to fail hard
[17:46:32] <Jan-> the more I read about it the more complex I realise it is
[17:46:47] <Jan-> you have to write code to deal with more than one master on each bus
[17:47:06] <aandrew> Jan-: you won't fail. you'll be an i2c expert in a week
[17:47:16] <aandrew> how many masters are on the bus?
[17:47:24] <Jan-> You can't tell.
[17:47:29] <Jan-> Lots are allowed.
[17:47:39] <aandrew> you have the micro which is the master. the oled is a slave. the encoder is a slave. ... what else is on the bus?
[17:47:41] <Jan-> and there's this weird call to something called "start wait"
[17:47:45] <Jan-> start wait?
[17:47:56] <aandrew> In 20 years of embedded systems work I can count on two fingers the number of I2C multimaster environments I've had to work with
[17:48:00] <Jan-> "send data" I understand, "receive data" would be on an interrupt or something, but er.
[17:48:03] <Jan-> "start wait"?
[17:48:13] <Xark> Jan-: Hmm, I2C each device has an "address" on a shared bus...
[17:48:14] <aandrew> I'd need more info. "start wait" doesn't mean much in i2c context
[17:48:47] <Jan-> http://homepage.hispeed.ch/peterfleury/doxygen/avr-gcc-libraries/group__pfleury__ic2master.html
[17:49:01] <Jan-> one line reads "i2c_start_wait(Dev24C02+I2C_WRITE); // set device address and write mode"
[17:49:13] <aandrew> yep
[17:49:17] <aandrew> what about it
[17:49:34] <aandrew> i2c devices are address with their address plus a "read not write" bit. 1 for read, 0 for write.
[17:49:51] <aandrew> so what happens is you send a start condition which tells all the I2C slaves to listen up
[17:50:05] <aandrew> then you send the address+RnW and clock 1 more bit
[17:50:27] <aandrew> if the I2C device you're interested in is functioning, you will read a zero for the 9th bit (the ACK)
[17:50:52] <Jan-> um
[17:50:53] <aandrew> then you can continue as needed (usually means sending a register address inside the device (and reading ACK) followed by the data you want to write (and reading ACK)
[17:50:57] <aandrew> then you send a stop condition and it's done
[17:51:02] <Jan-> how can i read a 9th bit if I'm writing
[17:51:09] * Jan- scratches head
[17:51:19] <aandrew> that's why I suggested writing the lowlevel bitbang code
[17:51:34] <Lambda_Aurigae> I just use peter fleury's library and don't bother with all the behind the scenes stuff.
[17:51:35] <Jan-> also, it isn't going to have to do this for like every pixel on the display or anything crazy like ythat is it?
[17:53:33] * Jan- starts going through https://www.adafruit.com/datasheets/SSD1306.pdf
[17:53:36] * Jan- weeps
[17:53:53] <Xark> Jan-: I think each byte is 8 vertical pixels. :)
[17:54:31] <Jan-> you can send more than one byte per message surely
[17:55:45] <Jan-> also I wonder if there's a more friendly way to do it. I mean, you don't really want to have to frame buffer the whole thing
[17:57:47] <aandrew> for (i=7; i>=0; i--) { write_bit(address & (1 << i)); } ack = read_bit();
[17:57:57] <aandrew> that's your write routine... sorry, I don't know how well that works with a screen reader
[17:58:07] <Jan-> woah, the i2c part of the ssd1306 is horrifyingly more complicated than the SPI part
[17:58:23] <aandrew> it's a loop clocking out 8 bits, calling a write_bit function for each one, then calling read_bit to read the ack.
[17:59:13] <Jan-> I guess if each byte is 8 vertical pixels, that actually works quite well because that's basically one line of text.
[17:59:14] <aandrew> Jan-: you can usually do burst writes, where you specify a start address and then the address pointer automatically increments. so you write 10 bytes in one go and it writes 10 pixels type of thing
[17:59:28] <Jan-> you wouldn't want it to be 8 *horizontal* pixels.
[17:59:36] <aandrew> there is no limit ot the length of an i2c transaction but the device itself may have a limit
[17:59:47] <aandrew> Jan-: just rotate the display 90 degrees. problem solved. :-)
[17:59:54] <Jan-> nono vertical is good
[18:00:03] <Jan-> because then you write five bytes per 5x7 ascii character
[18:00:08] <aandrew> Jan-: it depends on the part and how it's wired up
[18:00:18] <aandrew> you could be lucky, but knowing Murphy, you're not.
[18:00:20] <Jan-> I uhoh. Someone said that ws what it was
[18:01:58] <Jan-> it's hard to tell
[18:02:01] <Jan-> the datasheet is massive
[18:03:10] <Xark> Jan-: I see on page 25 it confirms vertical pixels (with LSB at top and MSB at bottom).
[18:03:44] <Jan-> *sigh* sorry if I'm being thick
[18:03:48] <Xark> (with several "pages" for each line)
[18:03:57] <Jan-> that's kinda OK
[18:04:00] <Jan-> can write rows
[18:04:12] <Jan-> I think it has a scroll mode too, not sure what that does
[18:04:21] <Xark> Jan-: Yeah, as you mentioned looks pretty reasonable for 8 high font.
[18:04:34] <Jan-> 7 high font plus line spacing/underline I guess
[18:05:05] <Xark> Yeah, aka 8 high (but you could save a bit in font table). :)
[18:06:18] <Jan-> so these eight pages represent the eight rows of eight pixels each to create a 64 high display?
[18:06:31] <Jan-> so "page" could just mean "row of 8 pixels" I think
[18:07:31] <Xark> Jan-: Yes. The displays come in several flavors like 128x16,. 128x32 128x64 (so sometimes all pages not visible).
[18:07:38] <Jan-> uhhuh
[18:07:43] <Jan-> we got the big one
[18:08:06] <Jan-> usually with these you have to go through and set a middling contrast range, display enable, etc before they do anything
[18:08:27] * Xark notes page 33/34 of PDF has info on commands to write data.
[18:09:24] <Jan-> I'm sort of skimming through the command table
[18:09:30] <Jan-> it's big but it makes sense sorta
[18:11:38] <Xark> Hmm, while it does have scrolling, doesn't look too useful (since no "off screen" pixels to reveal). Either wraps top to bottom or has "black/blank" lines.
[18:11:51] <Jan-> sure
[18:11:54] <Jan-> that's what I assumed
[18:12:22] <Xark> I guess it could be useful if you want "smooth scroll" text mode (without doing scrolling by "shifting bits").
[18:12:31] <Jan-> yeah
[18:12:41] <Jan-> you could scroll up 8 then just plunk the bottom line in, for instance
[18:12:44] <Jan-> and it'd be OK
[18:12:52] <Xark> (but their diagram shows "black" coming onto bottom lines if that isn't blank, then sounds ugly)
[18:13:04] <Jan-> eh whatever
[18:13:09] <Jan-> if you have to scroll line by line it'll work
[18:13:39] <Xark> Or just re-draw "text screen" seems almost as easy.
[18:13:45] <Jan-> that's what I mean
[18:13:56] <Jan-> looks like the row and column addresses just keep ticking up as you write
[18:14:29] <Xark> Jan-: Yeah. I could see just always blasting entire display from "bitmap" in memory (I believe this is what Adafruit libs do).
[18:14:35] <Jan-> Yes
[18:14:41] <Jan-> Although you could do better performance-wise
[18:14:56] <Jan-> I think you *can* set the pointers manually, so if you had a strip in the middle of the display you wanted to animate, you could just animate that
[18:15:03] <Xark> Probably not an issue (but maybe).
[18:15:16] <Jan-> also a ram thing
[18:15:26] <Jan-> what's 128x64/8
[18:15:27] <Xark> Yes, could be a RAM issue.
[18:15:47] <Jan-> that's exactly 1k of ram
[18:15:51] <Xark> 128x64 mono is 1/2 of (e.g.) 328 AVR. :)
[18:15:57] <Jan-> yeah.
[18:16:02] * Jan- thinks this may require the bigger avr
[18:16:31] <Jan-> or you know I don't think that anything we would need to do would necessarily require holding the whole display
[18:16:37] <Jan-> or at least you could just as easily write the changes in
[18:17:11] <Xark> Jan-: If you were only showing text, could just have a character map (~160 bytes).
[18:17:30] <Lambda_Aurigae> or, use an external spi sram
[18:18:02] <Jan-> Xark: that might be a thing.
[18:18:24] <Jan-> what we might end up with is something that's mainly text, or mainly 2 sizes of text, but has small animated strips in it.
[18:18:35] <Jan-> which to some extent can work with this
[18:19:22] <Jan-> the thing is this datasheet obviously is very complete but you have to worry about what the required setup procedure is.
[18:20:09] <Jan-> it's hard to figureout exactly what the required steps to go through are, to get something on the display
[18:20:55] <Xark> Jan-: In my experience, you blast a "binary blob" to display to init it. :) Hopefully you have a working example to get this from (in theory, you could work it out from datasheet....but).
[18:24:32] <Jan-> that's exactly what I mean
[18:24:39] <Xark> Jan-: Like
http://www.codeforge.com/read/249139/OLED_I2C.c__html
[18:24:51] <Jan-> from what I see you'd set a sensible contrast number, send display enable, and write some crap to the display ram
[18:24:56] <Jan-> but I bet there's other stuff
[18:25:29] <Xark> Jan-: From that (questionable) link above, this looks like the important bits ->
http://hastebin.com/ujexosamaz.coffee
[18:25:46] <Xark> (with English comments even!) :)
[18:25:58] <Xark> (mostly)
[18:26:50] <Jan-> the thing with someone else's driver is that a "driver" implies at least some knowledge of what you want to do with it
[18:26:55] <Jan-> but the setup stuff, I guess
[18:27:46] <Jan-> jeeeezus have you seen that oled_init function
[18:27:46] <Xark> Jan-: Heh, not like this code is ready to paste into an operating system (so I would take "driver" with a grain of salt). :)
[18:28:00] <Jan-> there's like 40 commands to set it up
[18:28:20] <Xark> Jan-: Well...I just created a pastebin for it, so yes.
[18:28:23] <Jan-> one of which is WriteCmd(0x20); //0x20,0.77xVcc
[18:28:28] <Jan-> dowhat?
[18:28:30] <Xark> Jan-: That is rather small compared to TFT LCD screens.
[18:28:33] * Jan- looks up command 0x20
[18:29:06] <Xark> (you can put that in a table vs inline commands to save flash, of course)
[18:29:19] <Jan-> well, yes
[18:30:45] <Jan-> hmm
[18:30:50] <Jan-> "set memory addressing mode" is 20
[18:31:33] <Jan-> oh no that's not a command that's data
[18:32:12] <Jan-> it's data for command DB which is "set vcomh level" and 20 means 0.77 time vcc
[18:32:15] <Jan-> whatever that means
[18:33:49] <Jan-> something to do with some sort of current regulator. errr
[18:35:38] <Xark> Jan-: Seems believable. Probably configurable for different types/colors of OLED.
[18:35:56] <Jan-> uhhuh
[18:36:09] <Jan-> one of the things he's poking in "display enable" is called "charge pump command"
[18:36:26] <Lambda_Aurigae> yup.
[18:36:39] <Lambda_Aurigae> you have to turn the charge pump on, in the right order.
[18:37:18] <Jan-> christ on a harley davidson
[18:37:26] <Jan-> this is double plus un simple
[18:37:28] <Lambda_Aurigae> you are the one wanted oled.
[18:38:14] <Jan-> and if I get this wrong, I fry the oled panel?
[18:38:27] <Lambda_Aurigae> possibly.
[18:39:11] * Jan- swallows
[18:39:14] <Jan-> Ulp.
[18:40:12] <Jan-> "The internal regulator circuit in SSD1306 accompanying only 2 external capacitors can generate a 7.5V voltage supply, V CC, from a low voltage supply input, V BAT . The V CC is the voltage supply to the OLED driver block. This is a switching capacitor regulator circuit, designed for handheld applications. This regulator can be turned on/off by software command setting."
[18:40:21] <Jan-> ...okay
[18:40:51] <Lambda_Aurigae> guessing that is total greek to you?
[18:40:57] <Jan-> nono that's OK
[18:41:17] <Jan-> it has a little DC to DC converter built in which uses 2 external capacitors to henerate a high voltage that's required by the oled glass.
[18:41:31] <Lambda_Aurigae> yup.
[18:41:45] <Jan-> it basically just means you have to send 8D (charge pump setting), 14 (enable charge pump) then AF (display on)
[18:42:27] <Jan-> also he's setting some things that I think probably have sensible defaults but I'm not sure if you can rely on the power up state of something like this so it's probably sensible to set them.
[18:42:46] <Jan-> like the display memory start addresses and so on
[18:46:20] <Jan-> eh I think we can do this, especially if I just copy this guy's startup code :)
[18:47:25] <aandrew> heh
[18:47:28] <aandrew> I see 8D as an emoticon
[18:47:32] <aandrew> a very happy one
[18:48:05] <Jan-> it means "charge pump control"
[18:48:20] <aandrew> I know, I've used this controller before
[18:48:24] <aandrew> actually that is only half true
[18:48:40] <aandrew> I've got a panel that has that controller but when I tried using it I discovered I'd fried the controller some time ago
[18:48:47] <aandrew> so I had to switch to an LCD I had handy
[18:49:03] <Jan-> you have to do many things
[18:49:12] <Jan-> I'm not sure if some of this stuff wouldn't just get zeroed on reset
[18:50:32] <aandrew> probably, it's good to just write an init_display() routine that takes care of it
[18:50:41] <Jan-> some of these modes could be quite handy
[18:50:57] <Jan-> there's a "horizontal addressing mode" that auto increments across an 8 pixel "page", but then resets to the start of that page
[18:51:05] <Jan-> so you could quickly animate an 8 pixel high strip
[18:51:11] <Jan-> s'quite sweet
[18:51:22] <aandrew> yep
[18:54:16] <Jan-> in serial modes (as opposed to microprocessor bus type parallel modes) they actually don't support return data anyway
[18:54:34] <Jan-> which is why that SPI one had a MOSI but no MISO.
[18:56:05] <Jan-> "com output scan direction" just flips it horizontally
[18:59:06] <Jan-> these things are weird, they don't seem to have a concept of command followed by data. for instance 00h is "set column address low nibble" and 10h is "set column address high nibble" but the nibble becomes the second half of the command byte.
[18:59:35] <Jan-> so if you send 00h 10h you just set the column address to 0, if you sen 01h 10h you set it to 1
[19:03:38] <Xark> Jan-: So it is just like 16 commands. Sounds more efficient. :)
[19:10:37] <Jan-> what's 16 commands
[19:11:52] <Jan-> OK I hit something I don't get
[19:12:26] <Jan-> "set multiplex ratio A8h: thiis command switches the default 63 multiplex mode to any multiplex ratio ranging from 16 to 63. theoutput pads com0 to com63 will be switched to the corresponding com signal"
[19:12:35] <Jan-> is that how you select what size display you're driving?
[21:52:12] -rajaniemi.freenode.net:#avr- [freenode-info] help freenode weed out clonebots -- please register your IRC nick and auto-identify:
http://freenode.net/faq.shtml#nicksetup