Back
[01:46:38] <anonnumberanon> Arch-TK, are you talking about the question I asked yesterday?
[02:54:54] <Haohmaru> turboslow muhaha ;]
[03:26:09] <Haohmaru> yey, got this w5500+xmega finally receiving udp and tcp data \o/
[03:27:38] <Haohmaru> ethurrnet, here i come
[03:35:02] <Jartza> yay
[04:02:11] <Haohmaru> either i'm doing something wrong, or there's a problem with util/delay.h and _delay_ms() on this xmega
[04:03:17] <Haohmaru> _delay_ms(20) takes roughly a second
[04:04:39] <Haohmaru> the USART works at the expected bitrate, F_CPU is defined as compiler argument..
[04:16:34] <Xark> Hmm, that seems very FUBAR...
[04:16:52] <Haohmaru> yupz
[04:17:21] <Xark> Maybe some crazy interrupt overhead or something?
[04:17:36] <Haohmaru> no way
[04:18:18] <Haohmaru> i only have a tx and rx interrupt for one of the usarts and there's almost no data most of the time
[04:18:56] <Xark> Perhaps disassembly _delay_ms, but something is weird.
[04:19:06] <Xark> disassemble*
[04:19:46] <Jartza> Haohmaru: and your chip is really running at speed defined for F_CPU ? :)
[04:19:53] <Jartza> and not like with watchdog oscillator :D
[04:20:35] <Haohmaru> according to my calculations, BSEL=16 would give ~57600 bitrate for the USART.. that's surely working
[04:20:49] <Haohmaru> with 16MHz clock
[04:21:01] <Haohmaru> and i'm using a 16MHz external xtal
[04:21:52] <Haohmaru> i also tried "delay_x.h" from avrfreaks, i still get long time
[04:22:41] <Haohmaru> is the xmega "the same enough" for these delay functions to be identical for atmega/atxmega?
[04:24:51] <Xark> Well, it is sounding like perhaps not...but seems a huge discrepancy.
[04:26:02] * Xark has one Xmega board but has not done a whole lot with it in a few years (http://www.batsocks.co.uk/products/BreadMate/XMega%20PDI%20AV.htm)
[04:28:00] <Haohmaru> mine is 32a4u
[04:31:57] <Jartza> Haohmaru: have you set the chip to use external xtal?
[04:32:05] <Jartza> by default it runs with internal 2MHz clock
[04:32:16] <Jartza> try setting F_CPU to 2000000 and see if the delay is correct :)
[04:35:00] <Haohmaru> yes, i initialize the clock
[04:35:13] <Haohmaru> otherwise the USART's gonna break
[04:36:56] <Haohmaru> i'm looking in the .lss but i can't figure out what is supposed to be the delay code
[04:37:00] <Haohmaru> x_x
[04:42:45] <apo_> Haohmaru: try reducing to a main() that only loops sleep; toggle_led;, then you'll see it easily enough
[04:52:21] <Jartza> Haohmaru: just for test, do as apo said, and maybe like led on -> 500ms -> led off -> 500ms so you can easily see if your led blinks about once a second with F_CPU 2000000
[04:53:16] <Haohmaru> in the very beginning, it is actually working
[04:54:12] <Haohmaru> it becomes slow later, somewhere after i do w5500_software_reset() which turns a pin low, calls _delay_ms(100) twice and turns the pin high again
[04:54:29] <Haohmaru> then _delay_ms(20) takes like a second long o_O
[04:55:34] <Haohmaru> i'm inserting this to test it: while (1) { PORTB.OUTTGL = PIN3_bm; _delay_ms(20); }
[04:55:38] <Haohmaru> which is a LED
[04:56:10] <Haohmaru> i'm inserting that at different points in main() and in the beginning it does appear to work properly
[05:25:10] <Jartza> hmmh
[05:25:19] <Jartza> does the w5500_software_reset enable interrupts?
[05:25:41] <Jartza> maybe it's hogging up interrupts
[05:42:41] <Haohmaru> Jartza nope
[05:43:42] <Haohmaru> it's supposed to cause a 2ms low impulse on a pin, and then turn that pin high again, and wait for 200ms till the w5500 module resets
[05:44:46] <Haohmaru> actually it's just w5500_reset, not software reset..
[05:53:18] <Haohmaru> could it be the watchdog doing somethin?
[06:16:57] <Jartza> sounds very strange
[06:42:21] <Haohmaru> ah, it's not because of the w5500_reset function
[06:43:16] <Haohmaru> it has to do with the interrupts i think, at some point, something happens, and if i call cli() - the _delay_ms() function runs properly again
[06:46:51] <Jartza> Haohmaru: yeah, so your interrupts take so much time to handle that the delay gets longer, it's completely normal
[06:49:52] <Haohmaru> i did not expect that
[06:50:05] <Haohmaru> so.. what could be wrong with my interrupts :/
[06:54:31] <Haohmaru> hm.. i think it's the USART DRE interrupt /o\
[06:59:54] <Haohmaru> yes, when my transmit FIFO runs out of data, it disables the DRE interrupt.. but.. that doesn't actually stop it from repeating afterwards
[06:59:56] <Haohmaru> dafuq
[07:09:19] <Haohmaru> weirdly i can't seem to effectively cli() from within an interrupt
[07:09:43] <LeoNerd> ISRs run with interrupts disabled
[07:09:51] <LeoNerd> So cli() will have no effect there
[07:11:31] <Haohmaru> okay.. that's not important.. what's important is that i can disable the DRE interrupt while i'm inside the DRE interrupt
[07:11:46] <Haohmaru> and it kinda looks like that's not quite working
[07:26:47] <Haohmaru> found it
[07:27:30] <LeoNerd> Interrupts can't fire inside interrupt handlers unless you specifically ask for it to be so
[07:27:37] <Haohmaru> used the wrong group mask on the interrupt
[07:27:40] <LeoNerd> Normally interrupts are disabled so they don't recurse
[07:28:01] <Haohmaru> DRE fires all the time
[07:28:24] <Haohmaru> that's also the same on pic18, so i've had this sort of issue there too
[07:28:57] <Haohmaru> thus, when the TX fifo transmits the last char - disable the DRE
[07:29:16] <Haohmaru> pls DRE, no more beats
[09:09:30] <viikk> Hi! I get this link error "cannot find crtatmega32u4.o: No such file or directory" and what I can see I only have a "crtm32u4.o". Any help would be appreciated as I dont even know where to start solving it.(Maybe not an AVR problem but more with the OS?)
[09:10:40] <apo_> viikk: What are your compiler arguments?
[09:11:57] <viikk> apo_: -Os -g -std=gnu99 -Wall -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -ffunction-sections -fdata-sections (and some more looking through the Makefile)
[09:12:16] <apo_> 'some more'
[09:12:32] <viikk> apo_: -DF_CPU=$(F_CPU) -DBAUD=$(BAUD) -I. -I$(LIBDIR) -mmcu=$(MCU)
[09:13:26] <viikk> Yes, those are the compiler arguments
[09:14:19] <viikk> Ah, maybe this makes more sense "avr-gcc -Os -g -std=gnu99 -Wall -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -DF_CPU=1000000UL -DBAUD=9600UL -I. -I../../AVR-Programming-Library -mmcu=atmega32u4 -c -o blinkLED.o blinkLED.c"
[09:17:21] <apo_> hm
[09:17:31] <apo_> that actually looks fine at a first glance
[09:18:06] <viikk> Yes, the arguments to the linker is "avr-gcc -Wl,-Map,blinkLED.map -Wl,--gc-sections -mmcu=atmega32u4 blinkLED.o ../../AVR-Programming-Library/USART.o -o blinkLED.elf"
[09:18:59] <viikk> So I do not quite understand why it is wanting "crtatmega32u4" instead of only "crtm32u4.o" (which I have)
[09:24:35] <apo_> yeah
[09:24:38] <apo_> it's a bit weird
[09:25:28] <apo_> well
[09:25:32] <apo_> just make a symlink for now
[09:25:49] <apo_> (or try using -mmcu=m32u4)
[09:27:22] <viikk> If I use mmcu=m32u4 for the compiler it complains that that is not supported, but the idea with the symlink I will try
[09:31:29] <viikk> Oh, it worked now it only complains on "cannot find -latmega32u4". Down the rabbit hole... :)
[09:31:34] <viikk> Thanks for the help though.
[09:44:01] <viikk> So(if you are following along), apparently there is afile "specs-atmega32u4" which is autogenerated and in it references are made to crtatmega32u4.o(which should be to crtm32u4.o) and also this -latmega32u4. I guess there is where the problem originates.
[09:47:22] <apo_> viikk: Which gcc is this?
[09:47:30] <viikk> apo_: avr-gcc
[09:47:35] <apo_> Yeah, but which version
[09:47:40] <apo_> I know it's for avr ;)
[09:47:43] <viikk> 4.9.2
[09:47:46] <apo_> Huh
[09:47:58] <apo_> I have that version
[09:48:01] <apo_> lemme take a look
[09:48:33] <viikk> Then it might be Debian, (or more likely I) who made a "woopise"
[09:49:09] <apo_> I don't have the specs file anywhere
[09:49:57] <viikk> /usr/lib/gcc/avr/4.9.2/device-specs/specs-atmega32u4
[09:50:28] <apo_> nope
[09:51:09] <viikk> hmm, then it is even more likely I who made something silly along the way
[09:51:33] <apo_> If that specs file is installed by your .deb, probably no
[09:51:47] <apo_> Take a look at that, and if yes poke your maintainer
[09:52:43] <viikk> Ill have a go and finding out who put those files there.
[10:18:54] <t4nk170> I need some advice for making a delay with timers. I want to call a function in my main who can play some different sounds. I guess I need to use timers as delays because there are other things going on in my main which cannot be delayed.
[14:39:42] <Lambda_Aurigae> I would setup a timer to trigger an interrupt routine after a certain amount of time then start it.
[15:47:56] <DKordic`> t4nk649: Make a paste with problem statement and pseudocode.
[16:40:52] <Casper> Lambda_Aurigae: sound like an alarm clock
[19:12:43] <Lambda_Aurigae> hey rue_house, rue_bed, rue_xxxx,,,time for random code post-o-the-day
[19:12:50] <Lambda_Aurigae> number ^= (-x ^ number) & (1 << n);
[19:12:50] <Lambda_Aurigae> Bit n will be set if x is 1, and cleared if x is 0.
[19:13:40] <Lambda_Aurigae> bit = (number >> x) & 1;
[19:13:58] <Lambda_Aurigae> will put the value of the required bit x in the variable bit.
[19:14:20] <Lambda_Aurigae> easy enough to make a macro out of either I suppose.
[21:30:54] <rue_house> ah, hmm
[21:52:17] <Casper> utoa(i, buffer, 10); uart_puts(buffer);