Back
[00:13:31] <megal0maniac_afk> for what it's worth, it'll be a standard HD44780 screen with a pcf8574 bus expander. Display will be set up in 4 bit mode and the spare io is connected to the backlight pin through a transistor
[00:16:52] <megal0maniac_afk> i quite like this
http://www.stanford.edu/class/ee281/handouts/lcd_tutorial.pdf
[04:47:25] <naquad> https://gist.github.com/9247611 - could somebody please take a look and tell me what am i doing wrong? i'm fighting this damn screen for hours already :( got just empty screen, no text
[04:47:53] <naquad> file:///home/naquad/Downloads/LCDD-01-datasheet.pdf - thats the datasheet i'm using
[04:48:09] <naquad> AVR is ATMega168P
[04:48:25] <Flecks> naquad: nice link to pdf :D lol
[04:48:32] <naquad> oops
[04:48:47] <naquad> http://oomlout.com/parts/LCDD-01-datasheet.pdf
[04:48:51] <naquad> thats the one
[05:17:43] <naquad> so any ideas?
[06:08:41] <Lambda_Aurigae> naquad, did you get the software off the fleury site I linked to last night?
[06:33:49] <Lambda_Aurigae> what temp you got there FreezingCold ?
[06:34:02] <FreezingCold> -15C I think
[06:34:31] <Lambda_Aurigae> -20.5C here.
[06:35:20] <Lambda_Aurigae> with windchill of -33C
[06:36:19] <FreezingCold> yeah, I have to move somewhere warmer
[06:36:21] <Lambda_Aurigae> and I'm considerably south of you I do believe.
[06:36:23] <FreezingCold> it's stupid
[06:36:33] <Lambda_Aurigae> you in Ontario area?
[06:36:41] <FreezingCold> yep
[06:36:41] <Lambda_Aurigae> I'm way down in Iowa, USA
[06:36:54] <FreezingCold> eastern ontario
[06:37:34] <Lambda_Aurigae> daym canadians keep sending us your cold air...keep it up there!
[06:37:51] <Lambda_Aurigae> we are gonna build a wall on the border to stop those unauthorized imports.
[06:41:55] <Lambda_Aurigae> anyhow, time to go get out in that crap and freeze my gnads off.
[06:41:57] <Lambda_Aurigae> later.
[07:05:59] <Tom_itx> Lambda_Aurigae keep that crap up there mkay?
[09:05:07] <phinxy> mmk.
[12:50:13] <naquad> Lambda_Aurigae, about lcd library: yes, i've tried it. same effect. either i've got it wired wrong or it is just broken. can i somehow check lcd is ok?
[13:14:29] <PoppaVic> heh.. Don't feel bad: every time I breadboard the dogm163, it works. Everytime I try to build it to a small protoboard, it fails.
[13:23:14] <daggett> hi all
[13:24:02] <daggett> I'm trying to program a ATMEGA164P : I'm on Linux (Fedora) and installed avrdude, avr-gcc
[13:24:48] <daggett> I wrote a little "blink" C program, then compiled it, then flashed it using USBTiny ISP and avrdude : it blinks
[13:25:42] <daggett> then now, I added a function : added the prototype in my ".h" file : it compiles ok, then flashed, it still blinks
[13:26:27] <daggett> then I added the empty function in my "blink.c" file : it compiles but it does not blink anymore !
[13:27:36] <daggett> So it seems that whenever there is a function body (empty or not) in my blink.c file, the whole thing ceases working.
[13:28:32] <PoppaVic> sounds like it optimized out - was it even called? did it spec a return you didn't provide? were there warnings or errors?
[13:28:58] <daggett> no warning (-Wall) on compilation
[13:29:17] <daggett> the function is not called from anywhere, I just added the body
[13:30:01] <daggett> if I remove that body, it still compiles fine, no error, no wrning, and it starts to blink again
[13:31:33] <PoppaVic> sounds fun
[13:31:34] <daggett> I tried that on 2 computers, two different gcc version, on both computers I have "Arduino" stuff installed and functioning ok (compilation and flash), but I'm NOT using Arduino stuff for now
[13:32:11] <daggett> maybe I'm missing something, so I'll detail how I compile this
[13:32:35] <daggett> I have 2 files : blink.cpp and blink.h
[13:33:35] <daggett> I have my void main(void) prototype in the .h, and the content of the main() in the .cpp
[13:34:04] <daggett> My "loop()" function has its prototype in .h and body in .cpp
[13:34:28] <daggett> the .cpp has an include for the .h
[13:35:02] <daggett> I compile it using : avr-g++ -mmcu=atmega164p -I. -Os -g -Wall -fno-exceptions -c blink.cpp
[13:36:05] <daggett> then : avr-g++ -o blink.elf blink.o
[13:36:32] <daggett> avr-objcopy -j .text -O ihex blink.elf blink.hex
[13:36:39] <daggett> that's it
[13:37:05] <daggett> then I burn it : avrdude -c usbtiny -p m164p -U flash:w:blink.hex
[13:37:31] <daggett> so what am I doing wrong ?
[13:47:50] <daggett> well, in fact, it IS blinking but really slowly, and faintly : I have only 1.5V for a "1" instead of 5V when I remove the function's body
[13:48:05] <daggett> puzzling
[13:51:51] <PoppaVic> I fail to see how volts relates to a function. You have posted no code at all, and I've not used avr-gcc yet - although I've tested the arduino ide and coded C for eons
[13:53:15] <daggett> ok, I can post my code : where should I post it ?
[13:53:15] <PoppaVic> I would suggest the ops here link to an url with a Minimal, "standard" makefile as well. A simple "hello world!" tarball is a trivial project - and many newbs could be expected to use that as the basic example and building-block for conversation and apps.
[13:53:50] <PoppaVic> codepad is what I recall, there are several - pastebin remains "popular", although I loath it
[13:55:03] <daggett> well anyway my code is 10 lines ... so how could 10 lines go that wrong ? I will try to find a Makefile
[14:23:09] <daggett> if that can help : here is the code :
http://pastebin.com/sRmRbRbC
[14:26:00] <PoppaVic> I have no idea why you define FCPU or the main.h - hinky
[15:05:26] <daggett> PoppaVic, I define it for delay.h
[15:06:32] <PoppaVic> Not sure why YOU provide it, but it's an odd place nonetheless
[15:07:59] <daggett> ok
[15:09:11] <PoppaVic> #1: I have never - in my LIFE - written a proto for main() - ever. Anywhere. #2: you don't need "main.h" at all. #3: Not sure why YOU define that value, but.. #4: I'd define it BEFORE the include IN the main.c file.
[15:14:13] <megal0maniac_afk> PoppaVic: +1
[15:28:15] <codyps> daggett: typically fractional voltages (where unexpected) indicate an electrical issue, not a code issue.
[15:29:02] <megal0maniac_afk> Anyone here know what usb-serial controller cisco uses for management ports? Is it ftdi?
[16:01:34] <myself> megal0maniac_afk: you could download the driver pack and inspect it
[16:25:24] <daggett> codyps, ok, but for me it was a compilation issue that did it
[16:29:49] <codyps> daggett: can you explain further? I don't see a "before" / "after" note in my scroll back.
[16:31:54] <daggett> I compiled specifying my mcu, but linked without specifying it, it ran ok without a function, but not with it. and a side effect was that the voltage of a "1" was reduced ... I can't understand that, baut now that I linked correctly, it just runs ok.
[16:54:41] <hotch> I'm just getting into using AVRs with avr-gcc vs. Arduino ... I work as a software dev so I'm curious as to any major benefits of ASM vs. C on the AVR?
[16:55:22] <specing> go C++
[17:06:13] <PoppaVic> c++ bwahahahahahahaha
[17:09:09] <synic> hotch: same comparison of C and ASM anywhere else?
[17:13:51] <specing> PoppaVic: don't make me slap_cast you
[17:14:24] <hotch> synic: You would compare programming a nix box with programming an mcu in ASM :)
[17:14:51] <synic> hotch: what are the benefits of programming a nix box in asm vs C?
[17:14:59] <PoppaVic> if it isn't as fun as a oil-rubdown and spanking, don't consider it
[17:16:14] <hotch> synic: with an mcu I am targeting low level things like reading voltage. generally on a pc you would not need that level of control unless you were coding a driver - hence why people usually use C.
[17:18:09] <synic> you didn't really answer my question
[17:19:04] <PoppaVic> asm is going to be twice or more the work, and could save 10-50% on space, perhaps runtime as well. and, of course, every assembler speaks a different language
[17:21:32] <specing> asm is going to be 20x the work
[17:22:45] <PoppaVic> it certainly can be.
[17:22:53] <PoppaVic> even more, on a bad day
[17:59:38] <Xata> Hello. I am learning asm for AVR on some early stages, and i don't get why ret in the end of this
http://pastebin.com/qMcJFtw9 code does not work. Is it because of brlo?
[18:06:09] <Lambda-Aurigae> hotch, C for rapid development. ASM for timing precision stuff. I use and mix both. Main programs written in C with timing critical stuff done in ASM, specially when dealing with video output.
[18:06:11] <Lambda-Aurigae> hotch, C for rapid development. ASM for timing precision stuff. I use and mix both. Main programs written in C with timing critical stuff done in ASM, specially when dealing with video output.
[18:06:15] <Lambda-Aurigae> oops
[18:06:34] <hotch> Ahh interesting. Much to learn, thanks everyone :)
[18:06:59] <Xata> Hello. I am learning asm for AVR on some early stages, and i don't get why ret in the end of this
http://pastebin.com/qMcJFtw9 code does not work. Is it because of brlo?
[18:09:50] <Lambda-Aurigae> the way the AVR is made insures it works nicely with C too. C tends to be rather stack heavy and the AVR has a real stack in sram, or at least the majority of AVRs that actually have an sram bank do.
[18:14:04] <Lambda-Aurigae> not sure there Xata
[18:14:40] <Lambda-Aurigae> I don't see any stack initialization though but I could be missing it.
[18:23:10] <Xata> Lambda-Aurigae: so, it helped. looks like stack pointer shows the address where to ret to, and where current subroutine was called from. where do i read such obvious things for understanding?
[18:23:24] <Xata> Lambda-Aurigae: alsa thanks
[18:23:27] <Lambda-Aurigae> the datasheet
[18:23:54] <Lambda-Aurigae> and the AVR instructin set document.
[18:24:38] <Xata> Lambda-Aurigae: like doc8155 (for m32) and doc0856?
[18:24:39] <Lambda-Aurigae> those two documents are your bible and qur'an when programming in assembler.
[18:27:59] <Xata> i'm an edgy atheist, so let's say they are The GOd Delusion, kek
[18:30:22] <Lambda-Aurigae> I'm an agnostic with anti-religion tendencies that border on homocidal.
[18:32:37] <bblaze> whatsup.. i'm looking for a bootloader for attiny that i can load from an i2c host (atmega)
[18:32:56] <bblaze> does such a thing exist?
[18:33:22] <Lambda-Aurigae> probably.
[18:33:29] <Lambda-Aurigae> have you tried google?
[18:33:56] <Xata> Lambda-Aurigae: nah, i am an atheist, but i think anybody has a right for his fallacy, that is just an advantage for me.
[18:34:18] <bblaze> man, i've been googling all day!
[18:34:39] <Lambda-Aurigae> Atmel AVR112: TWI Bootloader for Devices without Boot Section
[18:34:40] <Lambda-Aurigae> (file size: 880806, 14 pages, revision A, updated: 08/2011)
[18:34:40] <Lambda-Aurigae> This application note describes the implementation of bootloader using TWI or USI hardware as TWI communication channel for 8-bit AtmelŽ AVRŽ microcontrollers, without on-chip boot section and with at least 2 Kbytes of flash memory.
[18:34:57] <Lambda-Aurigae> second link on a google search for AVR twi bootloader.
[18:34:58] <bblaze> i've basically got any number of i2c slaves attiny's on my atmega and i want to push firmware thru the master down
[18:35:14] <bblaze> see, i was searching attiny i2c bootloader, not so much luck there
[18:35:20] <bblaze> and various combinations
[18:35:32] <Xata> bblaze: twi=i2c=iic
[18:35:37] <Lambda-Aurigae> right straight from atmel there.
[18:36:01] <bblaze> yeh, well tell google, so i don't have to come here and ask :-P i'm just coming into avr from arduino, so cut me some slack ehh? :-)
[18:36:04] <Lambda-Aurigae> twi is what atmel calls it so they don't have to pay phillips a royalty.
[18:39:01] <Xata> bblaze: arduino=avr+peripherals. almost always useless and ovepriced
[18:39:43] <bblaze> oh yeh, i know.. thats why i'm moving stuff over.. it was a good intro to connect my programming skills to the uc world, but i've def outgrown it
[18:40:47] <bblaze> I'm trying to devise a means to connect an atMega master to a series of attiny slaves each controlling a portion of hardware. getting the bootloader seems like a legit first step
[18:40:53] <Xata> bblaze: i've started straight from the atmega32, because i had no money for arduino. povetry can help sometimes
[18:41:05] <Lambda-Aurigae> Xata, actually, there are some super cheap arduino boards out there....but the software is horrid far as I'm concerned.
[18:41:17] <bblaze> yeh, i'd done straight PIC stuff years ago.. the IDE is THE WORST!
[18:41:25] <Lambda-Aurigae> ide...blah.
[18:41:28] <bblaze> i spend my whole day in a few diff ide's and i cringe when i have to open ide
[18:41:34] <bblaze> arduino ide i mean
[18:41:35] <Lambda-Aurigae> ide is for old harddrives.
[18:41:46] <bblaze> lol.. wrong ide?
[18:41:49] <bblaze> IDE
[18:41:55] <bblaze> i guess they're both cap'd
[18:41:55] <bblaze> ha
[18:41:59] <Xata> Lambda-Aurigae: hex editor and opcodes to firmware straight from your memory!
[18:42:09] <bblaze> like a boss
[18:42:24] <Lambda-Aurigae> I once setup a switch set for programming an avr for the fun of it.
[18:42:34] <Lambda-Aurigae> flip the switches, hit the load button, flip switches, hit button.
[18:42:38] <Xata> that's too much for me yet. but i figured aout, that asm is the best for avr, i leave C for stm32
[18:43:16] <Lambda-Aurigae> just like we used to do on the old TI-980B "minicomputers" of days gone by.
[18:43:31] <Lambda-Aurigae> C has its place on AVR, specially the larger ones.
[18:44:30] <Xata> Lambda-Aurigae: fun fact: mostly i learn avr asm so i could understand asm on more-less modern platform and code for my C64 later.
[18:45:00] <Lambda-Aurigae> hehe.
[18:45:08] <Lambda-Aurigae> I learned ASM on the VIC-20
[18:45:15] <Lambda-Aurigae> and the apple-II
[18:45:17] <Xata> Lambda-Aurigae: idk, but almost everything i create is time-critical, and that's no place for C
[18:46:00] <Lambda-Aurigae> last weekend I finally got a port of picoc running on an atmega1284p.
[18:46:03] <Lambda-Aurigae> it's a C interpreter.
[18:46:10] <Lambda-Aurigae> well, C subset
[18:46:33] <Xata> Lambda-Aurigae: yeah, got a bunch of m68k's and z80's - i have an idea to create my own neo-retro microcomputer some day
[18:46:47] <Xata> *got recently
[18:46:52] <Lambda-Aurigae> that is also one of my projects.
[18:47:16] <Xata> Lambda-Aurigae: picoc?
[18:47:17] <Lambda-Aurigae> using a combination of pic32, AVR, and 8052 chips, I'm building a retroish computer system.
[18:47:59] <Lambda-Aurigae> picoC is a C interpreter....like a basic interpreter but you write your code in a subset of C.
[18:48:15] <Lambda-Aurigae> http://code.google.com/p/picoc/
[18:48:24] <Lambda-Aurigae> I've had to cut and hack some to get it to fit on the atmega1284p.
[18:49:39] <Xata> Lambda-Aurigae: i recently had an idea, and well if i have to come back to avr, than i want to implement it in asm, not in C like i used to do. the idea is quite simple. i am experimenting with hardware development of microcomputer, but i don't want to erase eprom each time with UV, that's complex and too time-consuminig
[18:50:01] <Lambda-Aurigae> so use eeprom
[18:50:07] <Lambda-Aurigae> or nvsram
[18:50:40] <Lambda-Aurigae> unfortunately the AVR can't execute code from external memory so you need an interpreter...
[18:51:08] <Xata> so i've found a solution. i'll stuff the sram with data from i2c eeprom using avr, and than let the RESET pin of z80 be free - it will boot from sram, like from rom
[18:51:24] <Casper> I find that to be kinda stupid from atmel
[18:52:23] <Xata> Lambda-Aurigae: i don't want to use avr as a core. it is neoretro, so core will be z80 on first stages, and m68k later
[18:53:05] <Lambda-Aurigae> Casper, yeah, agreed...which is why I use 8052 chips on occasion.
[18:53:30] <Lambda-Aurigae> Xata, if you are gonna go retro, go 6502!
[18:54:15] <Casper> but still... usually there is plently of flash
[18:54:26] <Casper> but the ability to load external code could be usefull at time
[18:54:33] <Lambda-Aurigae> http://www.smbc-comics.com/comics/20140227.png totally offtopic, but,,,wth..
[18:55:12] <Lambda-Aurigae> Casper, yeah, or to switch programs on the fly like a PC...yeah, I know, not von newman architecture, but,,
[18:55:14] <Xata> am i still here?
[18:55:14] <Xata> laaag.
[18:55:27] <Lambda-Aurigae> Xata, nope, you aren't here...you are there.
[18:59:32] <Xata> Lambda-Aurigae: problem is that i almost can't find any eeprom/flash memory here with parallel adressing
[18:59:32] <Xata> i just got your messages. what is wrong? i am from ukraine, maybe IT IS HABBENING?
[18:59:32] <Xata> http works great. maybe freenode is lagging?
[19:00:14] <Casper> Xata: 146.11secs... you do lag badly
[19:00:42] <Lambda-Aurigae> http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=71301&mid=&lang=en
[19:00:44] <Lambda-Aurigae> parallel flash from microchip.
[19:38:22] <naquad> is there any super huge cheat-sheet on all flags and registers with descriptions?
[19:38:27] <naquad> prefferably in txt format
[19:55:32] <myself> naquad: that seems like something akafugu would make.
[19:56:16] <naquad> Tom_itx, yeah, but it is in PDF and i don't see any easy way to parse it (tried pdf2txt, but that didn't help much)
[19:56:22] <naquad> myself, who?
[19:56:27] <Tom_itx> why not just search it
[19:56:34] <Tom_itx> ctrl-f
[19:56:48] <Tom_itx> very user friendly
[19:57:07] <Tom_itx> actually easier to find stuff than a printout
[19:57:31] <naquad> Tom_itx, autcompletion with description is much more userfriendly
[19:57:54] <Tom_itx> you can waste some time if you like
[19:58:59] <naquad> Tom_itx, i do :)
[20:00:34] <myself> naquad: they make a nice pinout reference sheet:
http://www.akafugu.jp/posts/resources/reference-sheet/
[20:01:41] <naquad> myself, awesome thing, yet not exactly what i've meant. i've meant stuff like registers and their flags
[20:04:13] <Tom_itx> naquad i'd print the summary and search the docs for what you find there
[22:06:27] <AndinhoPrimao> Anybody can talk about PWM generation with atmega328p device?
[22:07:17] <AndinhoPrimao> How can I use the comparator for make this?
[22:07:23] <myself> naquad: Yup, it sounds like you need to put together your own reference and share it. :)
[22:11:20] <AndinhoPrimao> But you know such that works?
[22:11:46] <AndinhoPrimao> How I implement this, it's my question.
