Back
[01:11:18] <rue_bed> Dagger2,
[01:11:52] <rue_bed> arduino?
[01:17:33] <Dagger2> I need bits of the Arduino core library for a library I'm using, and I'm not sure if upstream avrdude supports the Arduino bootloader for flashing
[01:17:53] <Dagger2> but more importantly, their toolchain is a bit more up-to-date than WinAVR
[01:46:11] <rue_bed> what library you going for?
[01:49:37] <Dagger2> fiddling with UTFT at the moment. I could port it away from Arduino fairly easily, but I don't want to do that with everything I ever use
[02:29:15] <vijfhoek_> Hi. Little program: my main function doesn't seem to get called
[02:29:41] <vijfhoek_> I've tried all variants - void main(void), void main(int, char **), int main(void) and int main(int, char **)
[02:29:44] <vijfhoek_> None work
[02:30:57] <vijfhoek_> I've tried several makefiles and am now using one by someone else:
https://github.com/Vijfhoek/profielwerkstuk/blob/master/arduino/Makefile
[02:32:27] <vijfhoek_> https://github.com/Vijfhoek/profielwerkstuk/blob/master/arduino/main.c is where my main function i
[02:32:30] <vijfhoek_> s
[02:33:02] <vijfhoek_> s/program/problem/ in the first line
[02:41:08] <vijfhoek_> Oh never mind
[02:41:11] <vijfhoek_> The bug is somewhere else
[04:55:47] <Dagger2> yay, I got it working! sorta
[04:56:46] <Dagger2> I ended up using the toolchain from here:
http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx together with the `make` from the 1.0.x Arduino IDE (since it's not in Atmel's toolchain or the updated Arduino one...)
[04:57:10] <Dagger2> and it looks like it works great so long as I don't buy any 32-bit microprocessors
[04:57:41] <Dagger2> if I do then I need to downgrade to the old Atmel toolchain version which uses gcc 4.7. joy.
[05:04:54] <malinus> I don't think the 32-bit avr are that attractive, considering you can get the STM dev board much cheaper (last I've checked)
[05:05:04] <malinus> so I wouldn't worry
[05:13:13] <superware> I have an ATmega328P talking with another chip over SPI, and I have an ISP programming header in between (to program the atmega), my question is which protection resistors should I put in series on MISO/MOSI/SCK leading to the other chip? does it matter if it's 10K or 1K?
[05:14:47] <Dagger2> malcom2073:
http://cgi.ebay.co.uk/251518060445 is pretty darn cheap
[05:19:07] <superware> anyone?
[05:22:55] <malinus> interesting question, I would like to know this too superware
[05:26:31] <superware> malinus: <Flea86> superware "does it matterif it's 10K or 1K?" 10K series will limit your top end rate more, ultimately
[05:27:53] <malinus> superware, tell me if it works with 10k. But it should be easy to test. Just test on breadboard, and see if the program freaks out (if you have an isp2 or similar)
[05:28:15] <malinus> *programmer
[05:32:47] <superware> thanks
[05:33:40] <Dagger2> er, not malcom2073, malinus*
[05:33:46] <Dagger2> </way too late>
[06:36:35] <chickensk> hi. i read so many artiles on web but could not make my mega162 to flash. i constantly got mismatch at location 0x00000000 error, now i am getting cannot set sck error. i use external crystal 14.7456MHz. i have shortest usbasp connections possible and 5.06V on supply pins.
[06:40:28] <Lambda_Aurigae> well,,first problem...usbasp
[06:41:34] <chickensk> Lambda_Aurigae the other day i flashed mega8 just fine, so i do not understand
[06:42:01] <Lambda_Aurigae> ok..so there is some information you didn't give.
[06:43:00] <Lambda_Aurigae> it still sounds like the usbasp is at fault.
[06:43:22] <chickensk> Lambda_Aurigae how to check if usbasp is working ?
[06:43:38] <Lambda_Aurigae> no clue. usbasp is bitbanged us
[06:43:42] <Lambda_Aurigae> grrr.
[06:44:24] <Lambda_Aurigae> usbasp uses bitbanged usb, not hardware usb, so it could be having issues...it is not very reliable in my opinion...works with one computer and not another...and sometimes with one usb port and not another on the same computer.
[06:45:03] <Lambda_Aurigae> so, maybe, try another usb port,,,or another computer.
[06:46:14] <chickensk> Lambda_Aurigae hm, i use it under linux debian with avrdude and i had some problems with it overwriting fuses on mega162 which i am now not able to flash, but some two times i was possible to flash, seems random..
[06:46:26] <chickensk> Lambda_Aurigae which programmer do you use ?
[06:46:57] <Lambda_Aurigae> mostly I use my original parallel port interfaced programmer that is just a buffer.
[06:47:06] <Lambda_Aurigae> but sometimes I use the usb programmer I got from Tom_itx
[06:47:52] <Lambda_Aurigae> my old parallel port programmer has never failed me.
[06:48:34] <chickensk> Lambda_Aurigae i only have usb ports on my laptop.
[06:48:43] <Lambda_Aurigae> but, back to your problem....you are having problems writing fuses to the mega162,,,this is the same one you are having problems programming now? If so then you could have a well and truly screwed up chip and might need a HVP programmer to fix it.
[06:49:45] <chickensk> Lambda_Aurigae if I possibly changed lock fuse, how can I change it back to FF ?
[06:50:03] <chickensk> Lambda_Aurigae what is HVP programmer ?
[06:50:06] <Lambda_Aurigae> lock bit shouldnt prevent a reset.
[06:50:17] <Lambda_Aurigae> err..not reset...erase
[06:50:26] <Lambda_Aurigae> have you tried erasing the entire chip yet?
[06:50:31] <Lambda_Aurigae> HVP...high voltage programming
[06:50:43] <chickensk> Lambda_Aurigae now i have could not set sck problem
[06:50:44] <Lambda_Aurigae> it is a way to get around all kinds of sins done to fuses.
[06:51:09] <Lambda_Aurigae> you could have changed the reset line to an i/o pin.
[06:51:51] <chickensk> Lambda_Aurigae i have not changed reset pin. only have simple program to initialize char lcd and print text.
[06:52:03] <Lambda_Aurigae> in the fuses.
[06:52:17] <Jartza> I got arduino uno and the only thing I've made with it is I turned it into a HVSP
[06:52:19] <Lambda_Aurigae> can you get a consistent read of the fuses?
[06:52:36] <chickensk> Lambda_Aurigae so if i accidentally changed reset in fuse it is not possible to use ISP prorgammer ?
[06:52:43] <Lambda_Aurigae> correct.
[06:52:54] <Lambda_Aurigae> I am guessing you have not bothered to actually read the datasheet?
[06:53:45] <chickensk> Lambda_Aurigae i read the datasheet about fuses some 10 times, but could not prevent faulty fuse setup by the usbasp...
[06:54:41] <Lambda_Aurigae> you mentioned you have a notebook...no desktop computer?
[06:54:52] <chickensk> Lambda_Aurigae so what are my possibilities to revive the chip by usb connected something now ?
[06:55:13] <chickensk> Lambda_Aurigae i have docked lenovo x200 to kind of desktop but no serial/paralell
[06:55:20] <Lambda_Aurigae> I have found the vusb software implemented usb has more problems on notebooks than desktop computers...notebook computers tend to be more picky on their usb ports.
[06:55:51] <Lambda_Aurigae> first I would get a programmer that uses hardware usb to know it is stable.
[06:56:06] <Lambda_Aurigae> and if that doesn't work then a fuse doctor or HVPP.
[06:56:44] <Lambda_Aurigae> http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
[06:56:58] <chickensk> Lambda_Aurigae ok, but i would like to solve this programmer, if it is faulty, because i was using it longer than for a year now with very little problems
[06:57:32] <Lambda_Aurigae> or, ultimately, you could have a bad chip.
[06:57:47] <Lambda_Aurigae> have you tried other avr chips since having the problem with the atmega168?
[06:58:13] <chickensk> i tried other mega162 with no luck
[06:58:28] <Lambda_Aurigae> what is your avrdude command?
[06:58:51] <chickensk> avrdude -c usbasp -p m162 -U flash:w:$(NAME).hex
[06:59:00] <Lambda_Aurigae> well there is your problem
[06:59:01] <chickensk> i have it in a bash Makefile
[06:59:05] <Lambda_Aurigae> where is the -e ??
[06:59:17] <Lambda_Aurigae> if you don't erase the chip you can't reprogram it.
[06:59:27] <Lambda_Aurigae> it's right in the datasheet!
[06:59:42] <Lambda_Aurigae> flash must be erased before being reprogrammed
[06:59:54] <chickensk> really ? used this so many times before and it worked on mega8 just fine (of course changed chip)
[07:00:30] <Lambda_Aurigae> first time it will work...second time it will have problems.
[07:00:37] <Lambda_Aurigae> the chip comes erased.
[07:01:55] <chickensk> this is the command from avrdudess: -c usbasp -p m162 -B 0.5 -U flash:w:"/home/michal/elektronika/synth/sw/avr_testing_rgb_enc/main.hex":a
[07:02:22] <Lambda_Aurigae> still need a -e in there to erase the chip.
[07:02:36] <chickensk> ok ill try that
[07:03:07] <Lambda_Aurigae> don't know if that will solve the sck issue though.
[07:03:09] <Lambda_Aurigae> but worth a try.
[07:03:47] <Tom_itx> -B usually solves sck issues
[07:06:18] <chickensk> Tom_itx what is -B and how to use it ? do not understand that from avrdude help
[07:07:30] <Lambda_Aurigae> http://www.nongnu.org/avrdude/user-manual/avrdude_4.html#Option-Descriptions
[07:07:38] <Lambda_Aurigae> about 1/3 the way down the page.
[07:08:27] <chickensk> Lambda_Aurigae well i can not erase the chip without sck set.
[07:08:55] <Lambda_Aurigae> try removing that -B 0.5 from the command and adding -e
[07:09:14] <chickensk> tried with no luck
[07:09:15] <Lambda_Aurigae> it is possible your programmer is not liking having the bitclock set.
[07:09:35] <chickensk> has the bitclock correspond with f_cpu ?
[07:09:44] <Lambda_Aurigae> not directly.
[07:10:09] <Lambda_Aurigae> f_cpu is just so your program can calculate timing internally...has NOTHING to do with programming.
[07:10:40] <chickensk> ok so the programmer do not use external crystal ?
[07:10:43] <Lambda_Aurigae> however, the -B bitclock setting is relevant depending on your actual clock speed.
[07:11:13] <Lambda_Aurigae> external crystal is only relevant if your fuses are set so the chip requires the external crystal.
[07:13:06] <Lambda_Aurigae> aahh...it seems the newer versions of avrdude do an autoerase with the -U..so -e is not necessary...such was not the case with early avrdude.
[07:13:32] <superware> any Thai/Dutch speaker here?
[07:13:35] <chickensk> my fuses were set to H=D9 L=EF E=FF lock=FF
[07:14:06] <chickensk> now i can not read them due to sck not set. :D
[07:14:29] <chickensk> is it the time to try another mega162 ?
[07:16:49] <Lambda_Aurigae> those fuses look ok.
[07:17:28] <superware> chickensk:
http://www.engbedded.com/fusecalc
[07:17:38] <Lambda_Aurigae> ok..I have to run and do some real work.
[07:20:06] <chickensk> Lambda_Aurigae thanks !
[12:24:41] <thekindlyone> I only have 100nf capacitos, how do I connect a 8mhz crystal to my atmega32 mcu?
[12:25:45] <Lambda_Aurigae> with a pair of 22pF caps.
[12:26:39] <Lambda_Aurigae> you can try 100nF and it MIGHT start oscillating but I wouldn't guarantee it.
[12:26:53] <thekindlyone> can it cause permanent damage?
[12:26:55] <Lambda_Aurigae> do you or your parents have any old radios laying around you can rip apart?
[12:27:01] <Lambda_Aurigae> no, won't cause damage.
[12:27:09] <Lambda_Aurigae> the oscillator just may or may not start and run stable.
[12:27:41] <thekindlyone> hmm. okay
[12:27:44] <Lambda_Aurigae> I find if you are working on a solderless breadboard you don't usually need the caps on the crystal because the breadboard provides enough capacitance already.
[12:27:54] <thekindlyone> also I have currently the fuses set to use the internal clock
[12:28:07] <thekindlyone> I would need to re set the fuse bits right?
[12:28:10] <Lambda_Aurigae> then you don't need the crystal at all.
[12:28:19] <thekindlyone> while doing so do I keep the crystal connected?
[12:28:21] <Lambda_Aurigae> if you want to use the crystal you will need to change fuses, yes.
[12:28:59] <Lambda_Aurigae> if it is set to internal oscillator then you don't need the crystal to set fuses to other settings.
[12:29:21] <Lambda_Aurigae> once you change the fuses so it is set for external crystal then you will need the crystal attached to make further changes...that or a high voltage programmer.
[12:29:49] <thekindlyone> I have a usbasp
[12:29:52] <thekindlyone> I don;t think it will work
[12:29:54] <Lambda_Aurigae> I'm sorry
[12:30:04] <Lambda_Aurigae> why people keep buying those things is beyond me.
[12:30:24] <thekindlyone> had no money, this was the cheapest programmer I could find
[12:30:31] <Lambda_Aurigae> first thing any new avr hobbyist should get is fusebit doctor...get or make.
[12:30:37] <Lambda_Aurigae> do you have a computer with a parallel port?
[12:30:46] <thekindlyone> no, I don't think so
[12:30:49] <thekindlyone> no
[12:30:54] <Lambda_Aurigae> you should get one.
[12:31:00] <Lambda_Aurigae> an old p-4 or something.
[12:31:10] <Lambda_Aurigae> that's just my opinion.
[12:31:22] <thekindlyone> what would I do with that?
[12:31:22] <Lambda_Aurigae> otherwise, get a decent usb programmer.
[12:31:34] <Lambda_Aurigae> I use parallel port for 90% of my avr programming.
[12:31:37] <thekindlyone> what is a decent usb programmer?
[12:31:51] <chickensk> hi. good question.
[12:32:10] <Lambda_Aurigae> the one Tom_itx sells is great.
[12:32:26] <Lambda_Aurigae> it's hardware usb, not bitbanged software usb with vusb like the usbasp.
[12:32:38] <Lambda_Aurigae> dangit Tom_itx !!!! your website is down again!
[12:33:36] <thekindlyone> do you mean the USBTinyMKII?
[12:33:41] <Lambda_Aurigae> that's the one.
[12:33:57] <Lambda_Aurigae> it does ISP, PDI, and a third one that I can't remember and never use.
[12:34:08] <thekindlyone> Locating these things in india is harder than making stuff with these components
[12:34:09] <Lambda_Aurigae> but it works with all attiny, atmega, and atxmega chips.
[12:34:28] <Lambda_Aurigae> easy/cheap/good...pick 2
[12:35:02] <thekindlyone> so suppose I change fuse bits
[12:35:14] <thekindlyone> then I try the crystal with 100nf caps
[12:35:26] <thekindlyone> and it doesn't work, I get locked out don't I?
[12:35:30] <Lambda_Aurigae> yup.
[12:35:39] <thekindlyone> damnit.
[12:36:00] <Lambda_Aurigae> then you need the correct capacitors, a HV programmer, or an external clock source.
[12:36:21] <Lambda_Aurigae> which, I've made an external clock source with another avr and one with a 555 timer.
[12:37:28] <Lambda_Aurigae> the usbtinymkii has a clock source built in...I've never had to use it but it has one.
[12:38:02] <Lambda_Aurigae> http://mdiy.pl/atmega-fusebit-doctor-hvpp/?lang=en
[12:38:29] <Lambda_Aurigae> this thing can fix pretty much any fuse setting..it resets the supported chips to factory defaults.
[12:39:54] <thekindlyone> okay
[12:40:34] <thekindlyone> someone on the avr forum says he tried without the caps and it worked. Is 100nf caps better than no caps?
[12:40:36] <thekindlyone> I would think so
[12:40:46] <Lambda_Aurigae> all depends.
[12:40:53] <Lambda_Aurigae> are you on a solderless breadboard?
[12:40:57] <thekindlyone> yes
[12:41:13] <Lambda_Aurigae> then, as I said earlier, there is likely enough capacitance on the breadboard..
[12:41:30] <Lambda_Aurigae> all those big flat plates in there act as capacitors.
[12:41:44] <thekindlyone> hmm
[12:41:45] <thekindlyone> okay
[12:41:49] <thekindlyone> let me try
[12:51:52] <thekindlyone> okay I don't understand fuse setting for 8mz crystal
[12:52:01] <thekindlyone> I am using this tool
http://www.engbedded.com/fusecalc/
[12:52:20] <Lambda_Aurigae> what chip?
[12:52:25] <thekindlyone> atmega 32
[12:52:31] <thekindlyone> atmega 32 A
[12:54:15] <Lambda_Aurigae> try ext. crystal/resonator high freq.; start-up time: 258 CK + 64 ms; [CKSEL=1110 SUT=01]
[12:54:17] <thekindlyone> what is the difference between ext clock and ext RC
[12:54:26] <Lambda_Aurigae> that gives the crystal lots of time to settle in.
[12:54:37] <Lambda_Aurigae> well, you don't want either ext clock or ext RC for starters.
[12:54:49] <Lambda_Aurigae> ext clock is an external clock...NOT an external crystal.
[12:54:58] <Kev> you can use a square signal as a clock
[12:55:02] <Lambda_Aurigae> and ext RC is an external Resistor Capacitor timebase.
[12:55:13] <Kev> square wave *
[12:55:21] <Lambda_Aurigae> but neither of those is an external crystal...
[12:55:22] <thekindlyone> i see
[12:55:36] <Lambda_Aurigae> Kev, yeah, I've used a 555 timer to generate a clock for an AVR in the past.
[12:56:30] <Kev> yeah if you do something wrong with the fuses you might have to ;)
[12:57:23] <chickensk> hi. why sprintf transforms uinit16_t into signed 5decimal string ? :D
[12:57:41] <Lambda_Aurigae> chickensk, because that is the way it was programmed?
[12:58:06] <Lambda_Aurigae> what formatting are you using in sprintf for the variable?
[12:59:14] <Lambda_Aurigae> thekindlyone, starting on page 24 of the datasheet for the atmega32a it talks all about clock sources and what the different sources are and how to configure for them....I suggest reading the datasheet...
[13:00:15] <Lambda_Aurigae> chickensk, it should be %u for an unsigned decimal integer.
[13:00:58] <chickensk> thanks, ill try that
[13:01:06] <Lambda_Aurigae> http://www.tutorialspoint.com/c_standard_library/c_function_sprintf.htm
[13:01:17] <Lambda_Aurigae> chickensk, what format were you using?
[13:02:10] <Kev> also
http://www.nongnu.org/avr-libc/user-manual/group__avr__inttypes.html
[13:03:58] <chickensk> Lambda_Aurigae, sprintf(lcd1,"%6u",counter); is working ok :]
[13:04:08] <thekindlyone> it worked :)
[13:04:14] <chickensk> before it was "%6d"
[13:04:14] <thekindlyone> thank you people!
[13:04:31] <thekindlyone> without caps
[13:06:19] <chickensk> Lambda_Aurigae thanks again ! :]
[13:08:57] <pero_p> hi, i need regex on a project with avr, could it possible to compile include regex in avr code?
[13:10:30] <Yolarina> pero_p, it would be far more efficient to make a manual parser instead.
[13:12:10] <pero_p> Yolarina, it is, but i don't have time to do so, and i just interested in to do regex on avr. the micro is m128 and i think it have enough flash for the process
[13:22:29] <Casper> pero_p: flash maybe, but ram?
[13:24:34] <aandrew> google for embeddded regex... you could probably do a subset of it easily but ask yourself what you're really after and if you really do need regex
[13:26:18] <gjm> gz
[13:27:31] <aandrew> this kind of problem occurs a lot in embedded. "I need opengl" but when you look into it you discover you're only using it for a drawline() function and you find out about bresenham's algorithm and all of a sudden it's very possible
[13:28:33] <aandrew> heh I love the "I dont have time for $x" argument
[13:29:04] <jonored> Hm... which leads me to wonder whether lex can be made to work generating code for uC reasonably.
[13:29:47] <aandrew> that's one library I've never ever used... flex/bison/yacc
[13:29:52] <aandrew> ok 3 libraries. heh
[13:30:10] <jonored> They aren't so much libraries as they are compilers.
[13:31:30] <jonored> flex takes a source file mapping regexes to C snippets and compiles it to a function that runs the snippets when it gets stuff that matches, and bison/yacc is the same for context-free grammars.
[14:15:59] <Jordan_U> To use the internal calibrated real time clock for generating interrupts, do I need to just use the RTC as the system clock as well?
[14:25:16] * Jordan_U just noticed that the internal RTC *is* the default system clock :)
[14:34:10] <Jartza> oh well
[14:35:08] <Jartza> I get my pcb-stuff on monday
[14:35:16] <Jartza> then I'm gonna try this:
https://www.dropbox.com/s/6ncu3bsb90z9e18/Screenshot%202014-07-02%2022.15.39.png
[14:36:03] <Jartza> first ever pcb I designed, so might be total disaster
[14:36:05] <Jartza> but we'll see
[14:40:39] <thekindlyone> I am trying to test this ir remote decoder library on atmega 32A
http://extremeelectronics.co.in/code-libraries/using-ir-remote-with-avr-mcus/
[14:41:15] <thekindlyone> all I get is 119 on the LCD
[14:41:40] <thekindlyone> what could be the problem? I tried the same remote with a arduino and it worked
[14:45:51] <thekindlyone> I haven't put any capacitors in the external crystal part. could that be the reason?
[14:55:44] <theBear> do you get 119 regardless of the remote or what ?
[14:55:52] <thekindlyone> yea
[14:56:03] <theBear> heh, if you using a 2 wire/pin crystal, yeah, that'll do it almost every time
[14:56:07] <thekindlyone> the moment I turn it on, I get 119
[14:56:20] <thekindlyone> I am using a 2 pin crystal
[14:56:20] <theBear> also that yeah means that whatever the problem is, ir is irrelevent
[14:56:59] <thekindlyone> so..
[14:57:08] <thekindlyone> what do I use if not a 2 pin crystal
[14:57:08] <theBear> yeah, in rare cases there'll be a stray 20 or 30 pfs between tracks/pcb/leftover flux, but chuck in the 22uF's or whatever they recommend, and it'll be way more awesome, might even start working perfectly
[14:58:09] <theBear> well a "3 pin crystal" more accurately referred to as a little blue resonator whatsit, is BASICALLY a crystal AND caps in one package, tho from memory they drift a bit cos they don't use an actual crystal, but some resonant pfft it's been a long time
[14:59:23] <theBear> then there are also 4 pin crystal oscillator thingers that's basically a whole crystal AND oscillator/buffer (lookup ttl inverter crystal circuit for the rough idea) which has gnd/5v/output and somethign i forget
[15:01:06] <theBear> but you got a crystal, surely you can find some caps around, if you can't, you MIGHT have limited success touching the crystal pins with a finger, either from before power-on, or a moment later, it probly won't keep the crystal going like the right caps would, but is often enough to tickle it and make it flip a few times, and this usually shows as a lcd clearing or a led changing or something, suggesting that if you get the crystal going (with the right c
[15:01:06] <theBear> aps) that you are a big step in the right direction
[15:02:30] <theBear> i ain't got time to look thru that link, but you probly able to get away with using internal rc osc for remote codes, which would mean you could lose the crystal completely, program the internal-rc related fuses, and bing bang boom, or the page might mention somewhere you need to use a crystal cos internal rc isn't accurate enough for ir to be reliable
[15:06:29] <Lambda_Aurigae> internal RC should work fine for IR codes...would have to rework the code for the speed though.
[15:07:33] <Lambda_Aurigae> thekindlyone, if you get 119 displayed on the LCD then I'm guessing the microcontroller is running so there is likely something else wrong.
[15:08:10] <Lambda_Aurigae> that microcontroller has to be running to get the LCD to display anything.
[15:09:39] <Lambda_Aurigae> it looks like it should run on the 8MHz internal oscillator as the code appears to support multiple clock speeds.
[15:10:04] <Lambda_Aurigae> make sure you have set F_CPU to whatever your clock frequency is.
[15:10:40] <Lambda_Aurigae> won't be relevant to the LCD but will be very relevant to the IR decoding.
[15:11:38] <thekindlyone> okay I tried with 47 pF caps
[15:11:49] <thekindlyone> instead of 22pF
[15:11:58] <thekindlyone> and the code changed to 000
[15:12:06] <thekindlyone> but remote still not working
[15:12:24] <Lambda_Aurigae> what are your fuses set to?
[15:12:49] <thekindlyone> DE 99
[15:12:56] <Lambda_Aurigae> and, which is which?
[15:13:15] <Lambda_Aurigae> is that low high?
[15:13:17] <Lambda_Aurigae> should be.
[15:13:32] <thekindlyone> yea
[15:14:02] <Lambda_Aurigae> so, you have jtag enabled?
[15:14:08] <thekindlyone> http://pastie.org/9347858
[15:14:13] <Lambda_Aurigae> and are you using any of the jtag pins for anything?
[15:14:21] <thekindlyone> I didn;t change any of the default settings
[15:14:46] <thekindlyone> http://www.engbedded.com/fusecalc/
[15:14:58] <Lambda_Aurigae> and are you using any of the jtag pins for anything?
[15:15:07] <thekindlyone> selected atmega 32A, selected the required clock option that you suggested
[15:15:15] <Lambda_Aurigae> but
[15:15:16] <Lambda_Aurigae> but
[15:15:18] <Lambda_Aurigae> and are you using any of the jtag pins for anything?
[15:15:20] <thekindlyone> and the codes it said was DE 99
[15:15:32] <thekindlyone> which one are the jtag pins?
[15:16:05] <Lambda_Aurigae> PC5, PC3, PC2
[15:16:15] <thekindlyone> nope
[15:16:41] <Lambda_Aurigae> really?
[15:16:57] <Lambda_Aurigae> according to that page, PC2 and PC3 are used for the LCD
[15:17:22] <thekindlyone> that is for atmega 8
[15:17:28] <thekindlyone> I am using atmega 32
[15:17:35] <thekindlyone> the figure below it
[15:18:29] <Lambda_Aurigae> ok, then that is not the problem.
[15:19:00] <Lambda_Aurigae> not that they are used, but AVCC and AREF,,,are tied to VCC?
[15:19:13] <thekindlyone> no
[15:19:17] <Lambda_Aurigae> they should be.
[15:19:21] <thekindlyone> k
[15:19:28] <Lambda_Aurigae> and both GND pins should be tied to GND
[15:19:43] <Lambda_Aurigae> reset should be pulled high with a 10Kohm resistor.
[15:20:20] <myself> aww seroiusly? Here I thought the double-GND thing was a convenience passthrough so I could omit a trace on my board and connect all the components over there to that bridged-over ground! Saves jumpers on a single-sided..
[15:20:35] <Lambda_Aurigae> I always connect both of them.
[15:20:40] * myself scuttles back under his bridge
[15:22:22] <Lambda_Aurigae> thekindlyone, what is F_CPU set to in the code?
[15:22:31] <thekindlyone> nothing in the code
[15:22:36] <Lambda_Aurigae> thekindlyone, and, what speed crystal are you using?
[15:22:38] <thekindlyone> 8 mhz in makefile
[15:22:42] <thekindlyone> 8 mhz
[15:22:47] <thekindlyone> crystal
[15:24:31] <thekindlyone> how do you put a pull up resistor
[15:24:32] <thekindlyone> ?
[15:24:37] <Lambda_Aurigae> I don't see a link to the source anywhere.
[15:24:48] <Lambda_Aurigae> connect 10Kohm resistor from the pin to VCC..
[15:24:50] <Lambda_Aurigae> pull up to VCC.
[15:24:53] <Lambda_Aurigae> pull down to GND
[15:25:09] <thekindlyone> http://www.extremeelectronics.co.in/avrtutorials/download/IR.zip
[15:25:20] <thekindlyone> I thought so, just wanted to confirm
[15:35:32] <thekindlyone> okay, did all that
[15:35:34] <thekindlyone> code back to 119
[15:36:10] <Lambda_Aurigae> so time to start debugging.
[15:36:29] <Lambda_Aurigae> bypass the part of the code that reads the sensor and see if you can display something to the LCD
[15:37:56] <thekindlyone> it is working
[15:38:09] <thekindlyone> the lcd part is working fine
[15:39:08] <thekindlyone> I get
[15:39:08] <thekindlyone> IR Remote decoder
[15:39:09] <thekindlyone> Key Code: 119
[15:39:09] <thekindlyone> on the LCD
[15:39:37] <Lambda_Aurigae> so you have a hardware problem with the sensor connection?
[15:40:57] <thekindlyone> not one that I can see
[15:41:07] <thekindlyone> and the receivers work
[15:41:10] <thekindlyone> tested in arduino
[15:41:28] <Lambda_Aurigae> well, it'
[15:41:33] <Lambda_Aurigae> it's either hardware or software.
[15:41:42] <thekindlyone> yes
[15:42:06] <Lambda_Aurigae> time to start troubleshooting and eliminate things until you find the problem.
[15:42:40] <thekindlyone> there is nothing to eliminate
[15:42:47] <thekindlyone> the code is very straight forward
[15:42:52] <thekindlyone> if I trust in the library that is
[15:43:24] <Lambda_Aurigae> there is something wrong.
[15:43:40] <Lambda_Aurigae> and likely not the crystal.
[15:43:50] <thekindlyone> and not the lack of capacitors?
[15:43:54] <Lambda_Aurigae> no.
[15:44:03] <Lambda_Aurigae> the capacitors are basically to get the oscillator running.
[15:44:07] <thekindlyone> maybe lack of capactors in ir receiver?
[15:44:32] <Lambda_Aurigae> the page doesn't show any.
[15:44:45] <Lambda_Aurigae> without having the hardware here to test, no way for me to know.
[15:44:58] <thekindlyone> it says connect a 10uF capacitor between Vcc and GND of sensor close to it
[15:45:08] <thekindlyone> but I don't have 10uF caps
[15:45:39] <Lambda_Aurigae> do you have anything within 100uF of that?
[15:46:22] <thekindlyone> I have max 100nF
[15:47:04] <Lambda_Aurigae> then go rip apart your mom's radio for parts.
[15:47:46] <thekindlyone> hmm, maybe that is what I should do
[15:49:23] <Lambda_Aurigae> scavenging parts from dead electronics is how I got most of my stuff when I started.
[15:52:16] <thekindlyone> I do too, but my stuff
[15:52:18] <thekindlyone> :)
[15:52:41] <thekindlyone> I even break apart perfectly working stuff for parts. but mom is risky territory.
[17:23:13] <Jordan_U> For anyone wondering, we got DebugWIRE working. Our static shock protection was interfering.
[17:24:31] <Lambda_Aurigae> oops
[18:18:41] <AndreeeCZ> Hi
[18:19:10] <AndreeeCZ> Im trying to compile c++ for avr, I have added -lstdc++ to linker flags, but it says 'cannot find -lstdc++'
[18:19:14] <AndreeeCZ> what am i doing wrong?
[18:20:24] <AndreeeCZ> .. with gcc
[18:26:56] <timemage> AndreeeCZ, not sure there is a c++ standard library with avr gcc. in any case, usually when you're linking c++ with the standard library you'd let the g++ driver do it, rather than using gcc and supplying -l options.
[18:28:13] <timemage> AndreeeCZ,
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_cplusplus "However, there's currently no support for libstdc++, the standard support library needed for a complete C++ implementation"
[18:28:42] <Thrashbarg> that's a relief!
[18:28:50] <timemage> Thrashbarg, heh
[18:30:25] <Thrashbarg> you probably don't want my opinion on C++ generally anyway... I'll let myself out
[18:31:29] <timemage> Thrashbarg, i doubt i would mind, but yeah, it's probably not the first thing they'd want to hear. there are a few here that use c++ on avr though.
[18:33:48] <Thrashbarg> I'm not a fan of OOP because it lies outside my scope of things. I can however see it being extremely useful if it's implemented *properly* ...
[18:54:32] <Duality> shouldn't avr-gcc see see it's c++ and then just compile it like it's c++ ? i read that somewhere and correct me if i am wrong :)
[18:58:23] <timemage> Duality, iirc, the g++ driver will check the extension. the gcc driver will just treat it as c. foggy memory though.
[18:58:43] <Duality> or it was that
[19:20:40] <chickensk> hi. is there any way to address PORT, PIN and DDR registers by numbers as in datasheet ? attiny4313 has 0x10 PIND, 0x11 DDRD, 0x12 PORTD
[19:23:24] <timemage> chickensk, hmm, which numbers are you talking about, their SRAM addresses?
[19:24:11] <chickensk> in datasheet those numbers are calles address
[19:24:15] <chickensk> *called
[19:24:23] <Lambda_Aurigae> yup.
[19:24:58] <timemage> chickensk, well, you could set up a pointer to address zero in sram. say an unsigned char *, and just use the numbers as indices.
[19:25:10] <timemage> chickensk, umm, why though?
[19:25:33] <Lambda_Aurigae> you can access the registers directly.
[19:25:40] <chickensk> i am trying to use a constructor for pin setting
[19:26:20] <chickensk> i never used pointers/
[19:26:39] <timemage> chickensk, =), probably a good thing to look into before going much further.
[19:26:58] <Lambda_Aurigae> look at the register summary in the datasheet.
[19:27:04] <Lambda_Aurigae> it gives the addresses of all registers.
[19:28:23] <chickensk> yes i have those numbers.
[19:28:43] <chickensk> 0x10-0x12 for port pin ddr D
[19:29:28] <chickensk> i am trying to check pind: (!(PIND & (1 << bit)))
[19:29:30] <Lambda_Aurigae> just remember that every avr model set has registers in different places
[19:30:00] <chickensk> but replace PIND by number (or pointer)
[19:30:07] <Lambda_Aurigae> there is pind1, pind2, pind3, pind0
[19:30:12] <timemage> chickensk, the thing is, the way the gcc avr libs are set up, something like PORTB will resolve to a volatile unsigned char. you can just as easily use &PORTB to get the pointer to that volatile char back. you can then pass that pointer. no need to mess around with specific addresses.
[19:30:17] <Lambda_Aurigae> well,,, PIND0 PIND1 PIND2, ETC
[19:30:56] <chickensk> i will think of the & thing
[19:32:07] <timemage> chickensk, well, i suppose you could also use a reference, as long as you're using the ctor's initialization list. anyway, if you can avoid using the addresses directly, and i think you can, you're better off.
[19:32:28] <timemage> chickensk, by addresses, i mean the specific values from the datasheet. someone has already done that work.
[19:32:58] <Lambda_Aurigae> an array of pointers.
[19:33:57] <chickensk> ok, i will take a look at pointers tomorrow, too tired. thanks !
[21:13:29] <thekindlyone> Lambda_Aurigae, I tried with a 33 uF instead of a 10 uF. still 119 on lcd
[21:13:40] <thekindlyone> withthe sensor that is
