Back
[05:03:27] <Elec_A> Hello , I am using Codevision. I have a strange problem , Whenever I use lcd_init() after adc initialization , ADC won't work. I use ADC autotrigger, freerunning mode .
[05:04:58] <Elec_A> this is my code :
http://paste.opensuse.org/27930933
[05:10:38] <Elec_A> anybody can help me ?
[05:12:54] <specing> wtf is codevision
[05:12:58] <specing> Install avr-gcc
[05:13:16] <specing> and avarice and gdb
[05:13:46] <Elec_A> specing: is the problem related to codevision ?
[05:14:15] <specing> I don't know but nobody uses that here
[05:15:20] <specing> did you check that lcd init and ADC don't fight for the same pin?
[05:18:02] <Elec_A> specing: yes,
[05:18:08] <Elec_A> lcd_init(16) ; ADCSRA = ADCSRA | 0x40; will work
[05:18:21] <Elec_A> but ADCSRA = ADCSRA | 0x40; lcd_init(16) ; do not
[05:19:47] <specing> it could be an "optional" lcd pin
[05:21:34] <Elec_A> with AVR studio debugger "ADCSRA=ADCSRA|0x40" , Converts 10101011 to 11101011 (sets ADSC)
[05:50:02] <Jartza> I guess specing is right, lcd_init() must do something to ADC pin
[05:50:13] <Jartza> maybe it uses the same pin for some purpose
[05:54:08] <specing> LCD is mostly output while ADC is input, so it could be one DDR toggled
[05:54:44] <Jartza> yep
[05:54:45] <specing> or maybe the lcd code blanket-toggles all pins in an i/o bank while using only a few
[05:55:08] <Jartza> that would be stupid lcd code, but might be
[05:55:26] <specing> C makes it very easy to write stupid code
[05:55:41] <specing> trivial even
[06:00:31] <Elec_A> If i initialize lcd after setting ADSC , ADC converts only 1 time ! it means it converts the first value in ADC pin and then ADC Trigger turns off :\ but before setting ADSC , everything works .
[06:01:06] <Elec_A> *initializing lcd before ADSC , everything works
[06:02:34] <specing> Elec_A: avr-gcc+avarice+gdb
[06:02:50] <Elec_A> specing: OK OK ! :D
[06:03:19] <Elec_A> is there any library for LCD in avr-gcc ?
[06:06:28] <Jartza> what lcd?
[06:06:47] <Elec_A> Alphabetical or Graphical, any driver !
[06:06:50] <Elec_A> :)
[06:06:55] <Jartza> plenty of them
[06:08:39] <Jartza> http://homepage.hispeed.ch/peterfleury/avr-software.html
[06:23:07] <Elec_a> Jartza: Thanks , is there any AVR simulator for linux ?
[06:25:08] <specing> Elec_a: why do you need that?
[06:32:40] <Jartza> Elec_a:
https://gitorious.org/simavr
[06:57:16] <Elec_a> Jartza: thanks
[08:00:56] <new_bie> Hi guys I'm testing some code for the ATTiny85. First of all let me quote you something from the chip's datasheet. "The COM1A1 and COM1A0 control bits determine any output pin action following a compare match with compare register A in Timer/Counter1. Since the output pin action is an alternative function to an I/O port, the corresponding direction control bit must be set (one) in order to control an output pin.".
[08:01:11] <new_bie> The code sets COM1A0 in TCCR1, for use in timer1. Thus OC1A toggles on every compare. The funny thing is that the compare register A for timer 1 is never written to, only OCR1C. Is the value in OCR1C coppied in some way in CTC mode?
[08:02:18] <new_bie> TCCR1 = (1 << CTC1) | prescalerBits;
[08:02:24] <new_bie> GTCCR = 0;
[08:02:33] <new_bie> OCR1C = top;
[08:02:51] <new_bie> TCCR1 |= (1 << COM1A0);
[08:03:06] <new_bie> OCR1A is never written to
[08:03:12] <new_bie> But yet this works
[08:05:20] <new_bie> What significance does OCR1A have when OCR1C is used for timer 1 for the attiny85, especially with the COM1A0 flag set in TCCR1?
[09:51:16] <Guest74251> Hi!
[09:51:32] <Guest74251> I got problem with ADC interrupt
[09:51:57] <Guest74251> I have connected nrL transmitter to ADC
[09:52:23] <Guest74251> and it sends signal with frequency of ADC
[09:53:07] <Guest74251> when ADC works on 4 kHz, it sends without probems
[09:53:30] <Guest74251> but when ADC works on 8kHz, it don't even send first time
[09:54:08] <Guest74251> so when there is ADC conversion completed interrupt, it sends byte
[09:54:36] <Guest74251> so I think that transmitter just can't work so fast with its setings
[09:55:32] <Guest74251> i added command lines in ADC completed int which drive transmitter only on each secound ADC convertion complete int
[09:56:01] <Guest74251> so it skips one int and there should be 4kHz speed to transmitter
[09:56:14] <Guest74251> but it doesn't work that way :(
[09:56:27] <Guest74251> it doesn't send even 1. signal
[09:56:46] <Guest74251> I don't get what can be wrong
[09:57:49] <Guest74251> that every secound ADC int what only compares is that odd or even doesn't use any common registers
[09:58:39] <Guest74251> how can it stop sending of signal?
[10:00:18] <Guest74251> as I understand on every int handling there is global interrupt disabled so next ADC conversion just changes it's own interrupt flag
[10:00:49] <Guest74251> even if that interrupt handling already running
[10:01:55] <Guest74251> so if there would be some code, which doesn't fit in time between ADC int, it would fully finished and next ADC int handling will start after reti instruction
[10:04:52] <Guest74251> am I right?
[10:06:00] <Guest74251> it seems to me that next ADCint in some way don't let the previous ADCint code to complete..
[10:06:51] <Guest74251> but it is not logical if next ADCint is not handled and only change status bits and wait for previous int to be completed
[10:09:21] <twnqx> i am not sure if all parts handle interrupts like that
[10:10:27] <Guest74251> which parts do you mean?
[10:10:39] <twnqx> interrupt sources
[10:11:39] <Guest74251> so there is a chance that if new interrupt arrives when handling of old interrupt is not completed, then that new interrupt stops old interrupt code?
[10:11:51] <twnqx> stops? no
[10:11:58] <twnqx> but the second might be lost
[10:12:38] <Guest74251> ok that is not problem because even if first interrupt code is completed, thet it sends first byte
[10:12:46] <Guest74251> tranmitter sends..
[10:12:57] <Guest74251> but it doesn't send first byte
[10:13:23] <Guest74251> it sucesfully send when adc works on single cycle mode not freerun
[10:14:30] <twnqx> mh
[10:14:48] <twnqx> i had some problem with irqs in freerunning mode too
[10:14:56] <twnqx> but can't remember details :(
[10:15:29] <Guest74251> O I remembered
[10:16:05] <Guest74251> problem was gone when I put that every 3. ADC int must be handled (transmitter sends byte)
[10:16:35] <Guest74251> but every 3. is 4000kHz/3 = 1.x kHz
[10:17:19] <Guest74251> but when I change ADC clock to 2kHz then all runs perfect without compare procedure
[10:18:10] <Guest74251> it is not logical because if I divide increased CLK 2kHz in two parts it is 4kHz each part
[10:18:16] <Guest74251> +my compare code
[10:19:02] <Guest74251> so with compare code and 2kHz divided in 2 parts, it could not work faster than....fuk.. I mess with f
[10:19:53] <Guest74251> 4kHz divided in 2 parts + code it in no way can work faster than 2kHz without compare code..
[10:20:49] <Guest74251> I use internal RC oscillator
[10:21:27] <Guest74251> maybe if I divide it's f then it doesn't mean that f will be divided in 2...
[10:22:01] <Guest74251> but if division is completed in logic way not in f change way then it is not logical what happens :(
[10:23:53] <Guest74251> so hard to explain.. :/
[11:56:40] <aczid> anybody here have experience with Atmel's programmable LF-RFID transponders?
[11:57:08] <aczid> my device sample is meant for the automotive industry and I don't have all the datasheets
[16:39:52] <milosz96> hi, i'm trying to compile very, very simple program for my attiny13a. My command: avr-gcc -DF_CPU=1000000UL -mmcu=attiny13a -L/opt/cross/avr/avr/lib/avr25 -g -Os -Wall -std=c99 -lprintf_flt -lm -u vfprintf test.o -o test.out -lm And i get this error: /usr/bin/avr-ld: cannot find crttn13a.o. This file is in path specified by -L parameter, so what's wrong?
[16:45:04] <timemage> milosz96, odd. it compiles here, with the exception that i'm using main.c containing int main() { return 0; } and i don't have the -L directory you mention.
[16:45:31] <milosz96> without -L i have the same error
[16:45:55] <timemage> milosz96, right, you shouldn't need to be explicit about where to find the runtime objects.
[16:46:42] <timemage> milosz96, you've confirmed that you have that file on your system, right?
[16:46:54] <milosz96> timemage: can you tell me where you have your crttn13a.o?
[16:47:12] <timemage> milosz96, yes, though i'm not sure that will help you...
[16:47:20] <milosz96> yes, i've launched find -name "crttn13a.o" and it found one file
[16:47:44] <timemage> /usr/lib/avr/lib/avr25/crttn13a.o
[16:48:55] <milosz96> hmm i don't have even /usr/lib/avr :D
[16:49:12] <milosz96> i'm on suse 13.2
[16:50:22] <timemage> milosz96, that's the sort of reason why i said i may not help. not surprisingly, i'm not on suse.
[16:51:59] <milosz96> timemage: any idea for workaround?
[16:52:48] <timemage> milosz96, thinking. though, i should probably warn you, the tiny13 isn't exactly a c-friendly mcu.
[16:53:22] <timemage> milosz96, are you able to compile for any other avr? the 45 or 328 or ?
[16:54:02] <timemage> milosz96, oh, nevermind, i thought you were using one of the 6pin variants.
[16:55:09] <timemage> milosz96, see if you get any interesting output when you add -v to your command-line.
[16:56:38] <milosz96> timemage: i can even compile my program for attiny13
[16:57:20] <milosz96> timemage: what is that mean that it isn't c-friendly?
[16:59:56] <milosz96> timemage: that might be a problem
[16:59:57] <milosz96> LIBRARY_PATH=/opt/cross/avr/lib/gcc/avr/4.8.3/avr25/tiny-stack/
[17:02:46] <timemage> milosz96, "i thought you were using one of the 6pin variants"
[17:05:16] <timemage> milosz96, tha path doesn't mean anything to me. do you not have that directory or what?
[17:08:47] <milosz96> timemage: hmm, it compile now :) But... I can't flash because avrdude don't have attiny13a in config
[17:09:18] <milosz96> i just moved that file to LIBRARY_PATH
[17:09:35] <milosz96> but what can i do with avrdude?
[17:10:29] <timemage> milosz96, see what t13 gets you.
[17:11:27] <milosz96> id mismatch
[17:13:03] <timemage> milosz96, near as i know it's meant to be a drop in replacement. you may be able to get avrdude to ignore the deviceid.
[17:16:37] <hetii> twnqx: hi, Do i need wipe flash if I want to replace bytes on some page?
[17:16:58] <twnqx> you can erase just the page
[17:17:14] <twnqx> there's chip erase, sector erase, page erase
[17:17:30] <hetii> but I just wonder why cannot just write new byte at some position ?
[17:17:48] <timemage> milosz96, what id is it reporting?
[17:18:09] <milosz96> timemage: without signature check avrdude cant initialize attiny, while with signature check it initialize correctly
[17:18:16] <twnqx> hetii: that's how flash works
[17:18:33] <timemage> milosz96, it should tell what what it read for an id.
[17:18:34] <hetii> hmm
[17:18:39] <twnqx> having single cell erase logic is what makes eeproms so small in comparison to flash capacity
[17:18:44] <hetii> odd a bit
[17:18:54] <twnqx> you can alwqys move more bits from 1 to 0
[17:18:57] <hetii> when its clear it know how to store byte
[17:19:13] <twnqx> just getting them back to 1 requires erase :P
[17:19:21] <timemage> milosz96, if it's the ID of the 13a and your questioning the ID of the 13, then -F will probably work. if it's reporting something random or all zeros you probably have a wiring or clock issue.
[17:19:58] <milosz96> timemage:
[17:20:00] <milosz96> avrdude: Device signature = 0x8846e3
[17:20:01] <milosz96> avrdude: Expected signature for ATtiny13 is 1E 90 07
[17:20:56] <milosz96> without signature check (without -F) i only get: avrdude: initialization failed, rc=-1
[17:22:06] <timemage> milosz96, looks like junk. is this a new wiring attempt?
[17:24:33] <milosz96> timemage: oh well it looks that it might be a problem because id is totally random
[17:32:57] <milosz96> timemage: ok fixed :) One more problem, see here:
http://pastebin.com/kqnvRePE
[17:34:19] <timemage> milosz96, you seem to be attempting to fill flash with the data intended for eprom.
[17:35:13] <timemage> milosz96, if you're trying to your code into flash, avr-objcopy would need the program text section.
[17:37:18] <timemage> milosz96, avr-objcopy -j .text -j .data -O ihex test.out test.hex #maybe
[17:41:15] <timemage> milosz96, what did you do to fix your device id problem?
[17:41:36] <milosz96> timemage: fixed wire connection :)
[17:41:47] <timemage> milosz96, okay.
[17:42:34] <milosz96> timemage: still the same:
http://pastebin.com/j77LtvLk
[17:45:01] <timemage> milosz96, any chance you just have too much code?
[17:46:35] <milosz96> timemage: in previous paste there is whole code
[17:48:58] <timemage> milosz96, run avr-size on it. look at the .text column.
[17:48:58] <milosz96> timemage: that;s weird because .hex have over 8KB of size
[17:49:31] <milosz96> text data bss dec hex filename
[17:49:33] <milosz96> 0 3086 0 3086 c0e test.hex
[17:50:09] <timemage> milosz96, well, i suppose that does it too ,but i meant on the elf file.
[17:50:17] <milosz96> thats my actual code:
http://pastebin.com/1255HGhu
[17:50:42] <milosz96> i don't have any elf file
[17:51:43] <timemage> milosz96, yes you do. test.out
[17:52:51] <milosz96> 3086 0 0 3086 c0e test.out
[17:54:43] <timemage> milosz96, right. how much flash do you have?
[17:55:58] <milosz96> timemage: fixed ^^
[17:56:13] <milosz96> the problem was parameter in gcc options
[17:56:27] <milosz96> i deleted it and now i use only 72b
[17:56:32] <milosz96> thank you a lot
[17:56:52] <timemage> milosz96, i was trying to lead you that way. anyway, you get the idea.
[17:57:48] <timemage> milosz96, you may want to look at -Os -fdata-sections -ffunction-sections and -Wl,--gc-sections
[17:58:19] <TechChristoph_> hi
[17:58:55] <timemage> milosz96, am i correct in guessing you took out the -u vfprintf ?
[17:59:08] <milosz96> timemage: exactly
[18:00:38] <timemage> milosz96, printf is a beast.
[19:18:25] <LeoNerd> Woo. Just finished making the first board I can sell :)
[19:25:42] <xpoqp> congratulations :)
[19:26:52] * LeoNerd writing tindie page now
[19:27:03] <xpoqp> that is some achievment
[19:43:01] <Jartza> LeoNerd: cool! congrats!