Back
[00:24:10] <Casper> vectory_: even worse, many don't even talk about the dependency required...
[03:22:06] <Sinestro> I'm trying to write my first buffered serial driver, but I'm just getting gibberish. Just hoping to get an extra set of eyes on it.
https://gist.github.com/SASinestro/6102794
[04:21:30] <OndraSter_> http://www.ti.com/lsds/ti/arm/keystone/overview.page?paramCriteria=no
[04:21:38] <OndraSter_> "KeyStone platform provides up to 5.6GHz of ARM - and 9.6GHz of DSP processing "
[04:21:40] <OndraSter_> wait what
[04:21:52] <OndraSter_> did they add 4*1.4GHz or what?
[04:23:56] <specing> OndraSter_: Yep, thats marketing
[04:24:28] <specing> OndraSter_: common cheap chinese tablet: 1.4 GHz (1 Ghz CPU + 400 MHz GPU) :)
[04:24:46] <OndraSter_> haha
[04:24:51] <OndraSter_> but TI did it!
[04:24:52] <OndraSter_> why!
[04:25:48] <specing> they can, so why not
[04:26:00] <OndraSter_> that is like if I told "I WILL BE USING LINUX FROM NOW ON! WINDOWS SUCKS!"
[04:26:11] <OndraSter_> just a joke
[04:26:43] <specing> you can, so why not?
[04:26:50] <OndraSter_> I can? :o
[04:30:03] <specing> http://www.arso.si/ :/ so hot
[04:33:34] <OndraSter_> are ou in si?
[04:33:49] <OndraSter_> you*
[04:34:05] <OndraSter_> it is not as hot here as yesterday, but the air is much ... harder to breathe
[04:35:10] <specing> yes
[04:35:21] <specing> .si == slovenia
[04:35:49] <OndraSter_> yes, I thought you were German though? :o o:
[04:36:49] <specing> 0.o
[04:41:59] <OndraSter_> hmm I wish somebody was selling broken Logitech G27
[04:42:06] <OndraSter_> because I want to get one to try some modding on
[04:42:10] <OndraSter_> and reverse engineering
[04:42:18] <OndraSter_> and working ones are too expensive :D
[04:42:34] <OndraSter_> 200€+
[04:42:39] <OndraSter_> (but it is well worth it)
[04:42:54] <OndraSter_> the idiots at logitech thought it would be nice to have 4 wires coming to the wheel itself
[04:43:13] <OndraSter_> why can't we AT LEAST plug the power cord to the pedals! I am sure they are not using all 9 pins anyway on the connector
[04:43:17] <OndraSter_> they are after all 3 analog pots
[04:47:09] <specing> 4 wires to the wheel == rotary encoder?
[04:47:56] <OndraSter_> 4 cables*
[04:48:30] <OndraSter_> USB wheel -> PC, DB9 gearbox -> wheel, DB9 pedals -> wheel, 3.5mm barrel power adaptor -> wheel
[04:48:57] <specing> Ah, I thougt it was a mouse
[04:48:59] <specing> lol
[04:49:04] <OndraSter_> lol
[04:50:07] * specing swaps chairs due to the one he was sitting on becoming too hot.
[04:50:32] <OndraSter_> I bought a big fan last year
[04:50:35] <OndraSter_> for these heats
[04:51:28] <specing> I need something to push air over my keyboard
[04:51:43] <specing> damn southbridge is fucking hot
[05:42:21] <vectory_> specing: i hope you dont worry about the keyboard, but the southbridge
[05:48:26] <specing> its operating within design limits
[05:48:32] <specing> too bad that is 80'C
[05:50:00] <specing> also waiting for intel to release cheapo mobile haswell stuff (pentium, celeron) -- I hope they will be haswell, some talks we on about moving atom to those two lines
[07:28:06] <Volis> Should I get an arduino board(costs me $10 including the USB cable) or a programmer?
[07:28:30] <Amadiro> Volis, er... why are those the alternatives?
[07:28:32] <Volis> I already have two Atmel lying around
[07:28:40] <Amadiro> "should I get a car or a banana?"
[07:28:54] <Volis> Amadiro: Sorry, blame my low wpm.
[07:29:09] <Amadiro> if you are planning to use the arduino as a programmer, don't bother
[07:29:14] <Amadiro> just get a proper programmer
[07:30:00] <Volis> Yeah, thats the choises I have. To use arduino as programmer or get a different programmer(cost ~$5) and make the rest of circuit myself.
[07:30:16] <specing> Volis: try to get something that can debug as well
[07:30:19] <Volis> I guess I don't have to buy a solder just yet, since i have a breadboard.
[07:30:28] <Amadiro> Volis, the arduino is fine if you just want to program the arduino
[07:30:37] <specing> blinking leds and printing to console can only get you as far...
[07:30:39] <Amadiro> Volis, but don't bother using the arduino to program other chips
[07:30:44] <Amadiro> if you want to program other chips, get a programmer
[07:31:08] <Volis> specing: debug as in?
[07:31:16] <Volis> I can't debug arduino?
[07:31:18] <Amadiro> no.
[07:31:25] <twnqx> specing: did you ever get debugging with avarice to work?
[07:31:36] <specing> twnqx: I never got a hardware debugger unit
[07:31:43] <twnqx> ah
[07:31:55] <specing> but being able to manipulate memory on the fly on my stellaris launchpad is motherfukcing epic
[07:32:00] <theBear> mine only works with extreme pregidous
[07:32:00] <twnqx> <specing> blinking leds and printing to console can only get you as far... <- then those were always sufficient? :P
[07:32:12] <specing> twnqx: I didn't get far
[07:32:23] <twnqx> i have to say, works for me
[07:32:34] <twnqx> but i am only in smallish projects with a few k lines
[07:32:41] <Volis> so is debugging necessary if you go for better projects?
[07:32:48] <twnqx> it canhelp
[07:32:55] <specing> Volis: it helpts immensely
[07:33:03] <Amadiro> Volis, you can get pretty far without, but if you run into some serious issue, you can be pretty dead in the water without
[07:33:06] <specing> you can test the code before actually writing it
[07:33:16] <Amadiro> Volis, it also helps you a lot to learn about the CPU architecture, if you can single-step it, dump the registers, etc
[07:33:55] <specing> twnqx: are there any cheapo AVR debuggers? Im kinda out of this ...
[07:34:05] <Amadiro> So if you're just looking to get your feet wet, the arduino is fine, but if you want to get a little more serious about things, maybe go for something that can debug
[07:34:12] <specing> twnqx: cheapo as in homemade
[07:34:21] <twnqx> my jtag mark I was 20€
[07:34:36] <specing> problem is that many AVRs don't have JTAG
[07:34:42] <twnqx> and i think that one is available as REd schematic
[07:35:09] <specing> including pretty much any AVR I have
[07:35:34] <Volis> I guess since I have two atmega and one Toshiba microcontroller lying around with a couple of LEDs, photoresistors, and various stuff. I'll go with getting a programmer
[07:35:48] <twnqx> are there any on-jtag debug protocols in AVR?
[07:35:51] <twnqx> non-jtag*
[07:36:04] <MrM0bius> Volis, what toshiba microcontroller?
[07:36:14] <specing> twnqx: dW?
[07:36:21] <OndraSter_> doesn't dW unpack into jtag?
[07:36:38] <specing> Isn't JTAG only the electrical/interface?
[07:36:43] <OndraSter_> it is
[07:36:48] <OndraSter_> but there are some basic instructions
[07:36:48] <Volis> wait, i'll link to alldatasheets MrM0bius
[07:36:50] <OndraSter_> like device ID
[07:36:51] <specing> everything beyond is custom protocol
[07:36:57] <specing> ah okay
[07:37:01] <OndraSter_> basic commands should be universal AFAIK
[07:37:11] <OndraSter_> the ones you can read about in atmel's datasheets ;D
[07:38:39] <Volis> MrM0bius: It is W78E052
[07:39:52] <Volis> I found the result for this winbond one, I think I saw the manufacturer as Toshiba somewhere
[07:40:04] <Volis> http://www.alldatasheet.com/datasheet-pdf/pdf/236771/WINBOND/W78E052C.html
[07:40:49] <Volis> Ok, Nuvoton, not Toshiba
http://www.keil.com/dd/chip/4641.htm
[07:45:01] <twnqx> beware that you wither need specific debug controller for each stuff, or some universal and expensive stuff like that from keil
[07:45:02] <twnqx> either*
[09:37:07] <cart_man> RikusW: hi Rikus
[10:05:23] <RikusW> hi cart_man
[10:30:23] <ambro718> If I want to use more than one ADC pins, I have to manually switch channels, is that so?
[10:31:43] <specing> yeah
[10:32:45] <ambro718> wouldn't that be a big cpu load if I want to sample it as often as possible?
[10:33:35] <ambro718> so in the ADC interrupt, I read the current result, switch channel, and start another conversion
[10:44:20] <specing> ambro718: yes
[10:44:26] <specing> its only 10 cycles or so
[10:44:59] <specing> I think xmegas can do this automatically with the event system or whatever
[10:45:05] <specing> same with ARMs
[10:45:30] <ambro718> ok I'll do that, thanks
[12:09:47] <ambro718> how do I select the operation mode for the ADC (Free Running or Single Conversion)?
[12:14:00] <RikusW> probably a bit in the ADC config registers
[12:16:47] <ambro718> ADATE in ADCSRA?
[12:16:56] <ambro718> i.e. auto triggering enable
[12:17:43] <ambro718> ok so it seems I just set that to zero and I'm in single conversion mode
[12:58:07] <megal0maniac> Hi RikusW :)
[13:03:20] <megal0maniac> Gaanit?
[13:15:57] <RikusW> Hi megal0maniac
[13:16:46] <RikusW> All is well thanks, just got back from a weekend on the farm. :)
[13:16:59] <RikusW> What are you up to ?
[13:17:20] * RikusW has been watching Dexter 805
[13:20:03] * twnqx wtched top gear 20x05
[13:39:09] <megal0maniac> Episode 5 is out? I'm behind...
[13:40:29] <megal0maniac> RikusW: I got tired of Dexter. I'm playing with networking stuff. Uni started today
[13:41:10] <RikusW> Apart from Dexter I'm also watching White Collar
[13:41:18] <RikusW> currently busy with S3
[13:41:42] * RikusW remembers a time when a season lasted only 3 days :-P
[13:42:02] <RikusW> Can't do that anymore...
[13:42:24] <RikusW> or even 2 days :-D
[13:50:42] <megal0maniac> White collar was good. I'm watching Breakout Kings :)
[13:50:52] * megal0maniac should get white collar
[14:00:23] <RikusW> How about Chuck ? ;)
[16:36:20] <braincracker> h
[16:38:54] <Roklobsta> h
[16:40:31] <specing> h
[16:42:22] <Roklobsta> w a y d?
[16:48:55] <specing> C-C-C-COMBO BREAKER
[17:26:58] <Sinestro> I'm trying to write my first buffered serial driver, but I'm just getting gibberish. Just hoping to get an extra set of eyes on it.
https://gist.github.com/SASinestro/6102794
[17:27:31] <Casper> first, do you use the RC oscillator or an external crystal?
[17:28:32] <Roklobsta> Sinestro: use a LILO
[17:29:50] <Sinestro> Casper: External crystal.
[17:29:55] <Sinestro> 16MHz.
[17:30:08] <specing> templates in a C file? whats up?
[17:30:52] <Sinestro> C++
[17:30:58] <Casper> ... arduino junk...
[17:31:12] <Sinestro> I'm just using them as a cheap dev board
[17:31:29] <Casper> drop the arduino libs, code in pure C
[17:31:45] <Sinestro> I'm not using the arduino libraries
[17:31:50] <Sinestro> I fucking hate them
[17:32:07] <Sinestro> I'm just using C++
[17:32:26] <Casper> woops, yeah that's not arduino... should have looked better :D
[17:32:51] <Casper> so... you appear to NOT check if the tx was completed
[17:33:23] <Casper> so probably corrupt the data... or just drop all unsent data...
[17:33:38] <Roklobsta> hhhm, in the init do a "char sreg= SREG; cli(); foo()....; SREG=sreg;
[17:33:51] <specing> Sinestro: the first thing you are doing wrong is making those ring buffers operate on strings
[17:34:01] <specing> you are overcomplicating
[17:34:23] <Casper> you may want to look at peter fleury's lib to see how he do it
[17:34:39] <Roklobsta> i made my own FIFO's which are optionally blocking.
[17:34:47] <Roklobsta> they work damned well
[17:35:19] <Sinestro> specing: They are just chars, the pointer is just used in pop so that NULL can signal empty
[17:35:45] <specing> ah okay
[17:36:27] <Casper> that dosen't look like a ring buffer at all
[17:36:35] <specing> though what you are doing is a bit inefficient
[17:36:42] <specing> passing pointers around
[17:36:54] <specing> you should use an uint16_t instead
[17:37:06] <Sinestro> I've been poisoned by too much time using big computers
[17:37:09] <Roklobsta> Sinestro:
http://pastebin.com/w6X8qEsh
[17:37:51] <Sinestro> https://gist.github.com/SASinestro/6108450 is my ring buffer
[17:38:01] <Sinestro> Casper
[17:38:20] <specing> Sinestro: uint16_t ubrr = (F_CPU / (16 * baud)) - 1;
[17:38:38] <specing> use a right shift by 4 instead of division by 16
[17:38:52] <specing> its around 300 cycles faster
[17:39:17] <Roklobsta> won't the compiler be smart enough to infer a shift where a div is a power of 2?
[17:39:23] <specing> not avr-gcc
[17:39:29] <Roklobsta> WTF
[17:39:30] <Roklobsta> no way
[17:39:33] <twnqx`> Sinestro: are you sure that pop returns a char pointer... and not a char?
[17:39:38] <specing> TIAS
[17:39:47] <Roklobsta> i did check that once on taskings 8051 compiler, it did do that
[17:40:04] <specing> this is avr-gcc, it features dumbness
[17:40:08] <twnqx`> err
[17:40:15] <twnqx`> that is a generic gcc optimization
[17:40:37] <twnqx`> now you have me worried
[17:40:43] <specing> Im still sceptical of it being done
[17:41:39] <Sinestro> twnqx`: I've tested the ring buffer pretty thoroughly, it is correct
[17:41:43] <Sinestro> ish
[17:42:01] <twnqx`> still, you should make it return the value, like you push it, and not a pointer on it
[17:42:03] <twnqx`> will be expensive
[17:42:16] <twnqx`> at least for char :P
[17:42:47] <LoRez> if you're optimizing a baud rate calculation for cycles, you're probably doing something wrong.
[17:44:08] <Roklobsta> careful too, your trick of "head++ & (SIZE - 1)" will only work with SIZE that is powers of 2
[17:44:51] <twnqx`> #define IN_USE (head - tail) has me wondering too, what happens with tail > head?
[17:45:13] <Roklobsta> i have done somethine like "if (++head >= SIZE) head = 0;
[17:45:43] <twnqx`> anyway
[17:45:50] <twnqx`> the code should, in principle, work
[17:45:59] <twnqx`> except that inuse thing
[17:47:07] <specing> uint16_t ubrr = (baud / 16); //* baud)) - 1;
[17:47:08] <specing> 32: 24 e0 ldi r18, 0x04 ; 4
[17:47:08] <specing> 34: 96 95 lsr r25
[17:47:08] <specing> 36: 87 95 ror r24
[17:47:08] <specing> 38: 2a 95 dec r18
[17:47:09] <specing> 3a: e1 f7 brne .-8 ; 0x34 <main+0xa>
[17:47:14] <specing> theres your shift
[17:47:19] <specing> in a loop
[17:47:24] <specing> avr-gcc style.
[17:47:44] <Roklobsta> -O?
[17:47:50] <twnqx`> -O3 i hope
[17:48:01] <specing> -g -ggdb -Os -Wall
[17:48:08] <twnqx`> try -O3
[17:48:11] <twnqx`> to my amusement
[17:48:29] <twnqx`> i found two divisions in all my code
[17:48:42] <twnqx`> og 4.5k lines
[17:49:25] <Roklobsta> here's my FIFO.
http://pastebin.com/2V21mxmD
[17:50:06] <twnqx`> both of them are ARRAY_SIZE style and should be compile time resolved
[17:50:47] <specing> Ah, with -O3 it actually produces reasonable code
[17:50:48] <ambro718> templates!
[17:50:49] <specing> my bad
[17:51:01] <twnqx`> uint16_t ubrr = (F_CPU / (16 * baud)) - 1; <- shouldn't that be problematic anyway
[17:51:10] <twnqx`> with F_CPU being 32bit
[17:51:24] <twnqx`> baud being 16bit only even
[17:51:27] <ambro718> if baud is constant avr-gcc should precompute it anyway
[17:51:33] <ambro718> floats included
[17:51:40] <Sinestro> AVR-GCC precomputes it, I think.
[17:51:48] <twnqx`> only if the function is inlined
[17:52:42] <twnqx`> tried replacing ubrr, for testing, with a contant that matches your baud rate?
[17:53:27] <twnqx`> volatile char *p = write_buffer_0.pop(); <- that var isn't volatile, and you break optimizing it into a register
[17:54:14] <twnqx`> also, that code might never trigger
[17:54:33] <twnqx`> if your rxint triggers once with no data
[17:54:42] <twnqx`> ready to be sent out
[17:54:45] <twnqx`> it will never trigger again, ever
[17:55:07] <twnqx`> you'd need some manual way of triggering queue flush, from a timer or somethign
[17:55:38] <ambro718> my serial implementation, for those with an abstraction fetish,
https://github.com/ambrop72/aprinter/blob/master/aprinter/system/AvrSerial.h
[17:56:06] <twnqx`> if it doesn't compile with gcc (the binary), it doesn't exist
[17:56:34] <twnqx`> and that looks like overhead, more overhead, a few doses of overhead, and then some overhead
[17:57:07] <twnqx`> probably depends on how much is inlined away though
[17:57:11] <Sinestro> I think I should just give up and stop trying
[17:57:25] <twnqx`> no
[17:57:28] <twnqx`> you should learn
[17:57:45] <twnqx`> i chased a bug in my serial for 6 months or so
[17:57:47] <Sinestro> Replacing the UBBR with precalculated values makes it work, except it drops the first two characters of each string I write.
[17:58:08] <Sinestro> dafuq.
[17:58:30] <twnqx`> so, that values that looked to large for the variable types were actually too large :P
[17:58:43] <Sinestro> Amazing, rihgt
[17:59:44] <twnqx`> the one thing i don't see
[17:59:53] <twnqx`> is how that thing ever sends anything back to you :P
[18:00:39] <Sinestro> What do you mean?
[18:01:19] <twnqx`> a) you are using two unrelated ringbuffers
[18:01:27] <Sinestro> Over time it slowly grows more characters
[18:01:48] <twnqx`> b) ISR(USART_UDRE_vect) should never trigger again, once it triggered with no data available
[18:02:40] <twnqx`> so if the write queue ran empty, i don't see how you restart processing
[18:02:49] <Sinestro> serial_write_0 reenables the interrupt.
[18:02:58] <Sinestro> That line just got deleted
[18:03:05] <Roklobsta> i have a timer interrupt that gets serial ISRs moving again
[18:03:07] <twnqx`> so?
[18:03:15] <twnqx`> it's not like the interrupt is disables
[18:03:18] <twnqx`> it is not generated
[18:03:31] <twnqx`> because it is generted when the hardware pulls the byte from UDR
[18:03:35] <Roklobsta> oh i soud qualify that, i am using RTS/CTS handshake too
[18:03:45] <Roklobsta> yes
[18:03:51] <twnqx`> if you never put a new one in, it should never generate the interrupt again
[18:04:13] <Roklobsta> ok, my timer checks CTS and gets the TX IRQ going again if it's deasserted
[18:05:29] <Sinestro> https://gist.github.com/SASinestro/6108590
[18:05:43] <Sinestro> That is the code that this macro makes
[18:06:08] <Sinestro> the earlier stuff
[18:06:19] <twnqx`> http://pastebin.com/FES96rtT i wonder how many people reinvented the "i needa buffering uart" wheel on avr already :P
[18:07:36] <braincracker> http://www.electronics-lab.com/blog/?p=7471
[18:07:37] <braincracker> ^^
[18:07:50] <braincracker> DIY Spectrophotometer
[18:08:01] <ambro718> Sinestro: your UDRE ISR is very strange. Where do you disable the UDRE interrupt when you run out of write buffer and re-enable it when you get more?
[18:09:09] <Sinestro> good point
[18:09:33] <ambro718> that's how I do it and it works with no problems.
https://github.com/ambrop72/aprinter/blob/master/aprinter/system/AvrSerial.h#L257
[18:09:54] <ambro718> and see sendProvide which enables the UDRE interrupt
[18:10:17] <Sinestro> We're quickly proving that there are roughly as many buffered serial port implementations are there are AVR users.
[18:10:19] <ambro718> also, I never enable the interrupt when I have nothing to send, so there's no need to check in the interrupt if there is anything to send at all, there always is
[18:10:49] <twnqx`> hm
[18:11:18] <twnqx`> ambro718: that works? disabling the interrupt delays it triggering?
[18:12:22] <ambro718> twnqx`: the udre basically has assert(buffer not empty);. It grabs a byte, writes it to UDR0. It then checks if there are any more bytes to send, if yes, it returns, if no, it first disables itself.
[18:12:43] <twnqx`> no i mean in the hardware
[18:12:46] <ambro718> when more bytes come into the buffer the UDRE interrupt is enabled again to start feeding bytes to the hardware
[18:13:05] <twnqx`> like, interrupt triggered, pull last byte, disable interrupt
[18:13:11] <ambro718> twnqx`: what do you think disabling the interrupt does?
[18:13:44] <twnqx`> i kind of thought the last byte is pulled, no interrupt is generated, and the interrupt "is lost"
[18:13:50] <ambro718> afaik when you disable an interrupt, it won't trigger from that moment on, until it is re-enabled
[18:13:53] <twnqx`> and when you reenable it it won't trigger
[18:14:07] <ambro718> twnqx`: nope, I believe this is not the case
[18:14:13] <twnqx`> hmmmmm
[18:14:33] <ambro718> twnqx`: the interrupt triggers as long as it's enabled and the hardware send buffer is not full
[18:14:38] * twnqx` types "git branch uartirq; git checkout uartirq"
[18:14:45] <twnqx`> yes
[18:14:54] <twnqx`> but if it is not ebanled, that triggering is delayed?
[18:15:04] <twnqx`> until, maybe minutes later, it is reenabled?
[18:15:10] <ambro718> yes (since I have no bytes to give it)
[18:15:16] <ambro718> until I have more bytes to send, yes...
[18:15:25] <twnqx`> not your code
[18:15:30] <twnqx`> is that how the hardware works
[18:15:43] <ambro718> what would you do? leave it triggering in a busy loop?
[18:15:46] <twnqx`> ...
[18:15:49] <twnqx`> my question is
[18:15:58] <twnqx`> will purely enabling the interrupt after a minute
[18:16:03] <twnqx`> automatically trigger it immediately
[18:16:14] <twnqx`> when minutes ago the last byte was pulled from udr0
[18:16:17] <ambro718> no, the hardware send buffer must also not be full
[18:16:30] <twnqx`> well, obviously
[18:16:35] <twnqx`> it was emptied minutes ago
[18:16:44] <twnqx`> guess i'll just try it
[18:16:47] <ambro718> but otherwise yes, it doesn't matter what the past was
[18:16:47] <Sinestro> There needs to be a good collection of libraries as a common core for AVR.
[18:16:54] <Sinestro> Like Arduino sort of, only not shit,.
[18:19:20] <twnqx`> ambro718: and you use TXCIE, not UDRE, too :)
[18:20:19] <ambro718> me? no, I use UDRE
[18:20:19] <ambro718> I don't have any use for TXCIE
[18:20:30] <ambro718> UDRE lets me know when I can feed more bytes to the hardware, that's all I need
[18:21:25] <Roklobsta> Sinestro: here's my RX and TX ISR's.
http://pastebin.com/bV6Piciw
[18:21:37] <Roklobsta> note that SerPort0 is a volatile strcuture.
[18:22:04] <ambro718> don't call the UDRE the TX ISR. They're different things...
[18:22:50] <twnqx`> indeed
[18:23:08] <twnqx`> i think my rts/cts broke with using UDR, though
[18:27:03] <Sinestro> I'm gonna take a break
[18:55:37] <twnqx`> hm
[18:55:38] <twnqx`> wow.
[18:56:21] <twnqx`> except some weird misdetection of buffer overflow it seems to work
[18:59:15] <braincracker> avr forever!
[19:00:11] <ambro718> twnqx`: I wonder, what were you doing before that? Did you just leave the UDRE enabled and triggering all the time?
[19:00:25] <twnqx`> sure
[19:00:28] <twnqx`> why "all the time"
[19:00:33] <twnqx`> it triggers *once*
[19:00:39] <twnqx`> when the byte is taken from UDR
[19:00:52] <twnqx`> also, i used txcomplete interrupt
[19:01:22] <twnqx`> and no, doesn't 100% work, apaprently the queue fills completely
[19:02:02] <Roklobsta> one needs some volatiles and atomicity
[19:02:04] <ambro718> No, you're wrong.
[19:02:05] <ambro718> When interrupt-driven data
[19:02:07] <ambro718> transmission is used, the Data Register Empty interrupt routine must either write new data to
[19:02:08] <ambro718> 182
[19:02:10] <ambro718> 8272D–AVR–05/12ATmega164A/PA/324A/PA/644A/PA/1284/P
[19:02:11] <ambro718> UDRn in order to clear UDREn or disable the Data Register Empty interrupt, otherwise a new
[19:02:13] <ambro718> interrupt will occur once the interrupt routine terminates.
[19:02:21] <ambro718> sorry wait
[19:02:33] <twnqx`> like i said
[19:02:42] <twnqx`> i did not use UDR
[19:02:46] <twnqx`> i used TXC
[19:03:05] <ambro718> ahh
[19:04:53] <ambro718> I wonder why both TXC and UDRE exist
[19:05:19] <twnqx`> TXC triggers exactly once
[19:05:26] <ambro718> yep, I get it
[19:05:34] <twnqx`> UDRE triggers until you stop it
[19:05:51] <ambro718> but use of either is sufficient to send stuff, right?
[19:06:04] <twnqx`> yes
[19:06:14] <twnqx`> but with UDRR you get an extra byte of buffering
[19:06:27] <twnqx`> you then have one in the shift register, and one in UDR
[19:06:33] <twnqx`> sometimes you might not want that
[19:07:04] <ambro718> why, how could a buffer hurt?
[19:07:14] <twnqx`> you might overrun your receiver, i guess
[19:07:34] <twnqx`> if you need veryprecise cts/rts reaction, maybe
[19:09:37] * twnqx` wonders if i am misreading the LED
[19:10:34] <twnqx`> no way that is enough data to even fill the buffer
[19:11:59] <twnqx`> ... it was too long i used the hardware
[19:12:09] <twnqx`> that LED indicates something completely different.
[19:14:28] <twnqx`> AND
[19:14:43] <twnqx`> i understand the issues i had using UDR int before :P thank you.
[19:14:57] <ambro718> np ;)
[19:20:00] <twnqx`> grumble, why does the compile not complain about unused variables with -Wall -Werror
[19:24:35] * twnqx` tries to make up scenarios where unlucky timing can braek the code
[19:28:26] <ambro718> when you get more bytes in your send buffer be sure to cli/sei between the section that increments the end pointer, and enabled UDRE
[19:28:43] <twnqx`> nah, can't cli/sei :P
[19:28:50] <ambro718> huh?
[19:28:53] <twnqx`> can only cli/restore to whatever before :P
[19:29:01] <ambro718> ah, whatever
[19:29:17] <twnqx`> might be called from interrupt handlers, you know
[19:29:20] <ambro718> also, updating UCSR0B is not atomic, check for conflicts between sending and receiving code
[19:29:30] <twnqx`> i... have no receiving code.
[19:30:02] <twnqx`> why would the receiving code ever meddle with UCSR0B, anyway?
[19:30:24] <ambro718> I use C++ templates so a function knows at compile time whether it's in "interrupt context", that is, either it's in an interrupt or interrupts have been cli'd
[19:30:36] <twnqx`> how so?
[19:30:45] <twnqx`> the same function could be called from both with my code
[19:30:55] <ambro718> then I have a macro into which I put the critical code and it knows whether to do cli/sei or not
[19:31:05] <ambro718> it's a template taking a Context parameter
[19:31:17] <twnqx`> so what does it do
[19:31:30] <ambro718> wait a min I'll make a simple example how to do it
[19:31:36] <twnqx`> if the function is called from 10, 12 function deep nestings from an interrupt handler?
[19:31:53] <twnqx`> via indirect function pointers
[19:32:40] <twnqx`> mind you, my mainloop is roughly while (1) sleep ();
[19:32:51] <ambro718> well the function pointers won't work
[19:33:09] <twnqx`> so ~95% of my code is run inside interrupt handlers
[19:33:18] <twnqx`> regardsless how deep the nesting levels
[19:34:07] <twnqx`> surprisingly still works with 4mbit/s rs232
[19:34:19] <twnqx`> or is it 2
[19:34:24] <twnqx`> whatever the max speed is
[19:35:29] <twnqx`> 2mbit.
[19:42:07] <twnqx`> i wish there was a counter in avr counting how many cycles the cpu spent in sleep mode
[19:44:10] <Valen> which sleep mode?
[19:44:24] <ambro718> twnqx`:
http://ideone.com/Yk4iys
[19:44:33] <twnqx`> idle
[19:44:39] <Valen> use one of the timers
[19:45:17] <twnqx`> how?
[19:45:28] <Valen> fire up say a 16 bit timer
[19:45:33] <Valen> it'll keep running in idle
[19:45:35] <twnqx`> far too slow
[19:45:43] <Valen> how is it too slow?
[19:45:46] <ambro718> twnqx`: the information on whether interrupts are enabled or not is transferred with function calls at compile time as the type of the Context arguments
[19:46:05] <twnqx`> also, can't tell cycles burnt in interrupt handlers apart from cycles spent in sleep, from mainloop point of view
[19:46:31] <Valen> the timer will keep running, you can read out the value of the timer however you choose
[19:46:36] <twnqx`> ambro718: the easy way uint8_t sreg = SREG; cli(); ...; SREG = sreg;
[19:46:37] <Valen> you don't need to wait for the overflow
[19:46:42] <twnqx`> yes, so?
[19:46:51] <ambro718> twnqx`: I know :P
[19:46:58] <Valen> so it will perfectly count the number of cycles you have spent in "sleep"
[19:47:05] <twnqx`> so i can read a 16bit timer
[19:47:21] <twnqx`> and in interrupt
[19:47:24] <Sinestro> I'm pretty sure that I have a cursed UART.
[19:47:44] <twnqx`> my mainloop wakes up from sleep only after the interrupt handler
[19:47:45] <Valen> Sinestro: I once put 9V into a uart, it flipped the tx and rx pins around
[19:47:49] <Valen> kept working ;->
[19:47:52] <Sinestro> lol
[19:48:02] <twnqx`> Sinestro: i thought that for a long time, too
[19:48:06] <twnqx`> it was all PEBCAK
[19:48:12] <Valen> so read the timer as the first thing in your interrupt handler
[19:48:21] <twnqx`> which of the many?
[19:48:24] <twnqx`> :P
[19:48:28] <Valen> all of them
[19:48:49] <Sinestro> I'm using Tim Sharpe's modified version of Fluery's library, with the simplest possible code, and it doesn't work.
[19:48:54] <twnqx`> some of them tick at 125khz while active
[19:49:01] <twnqx`> some at 1k
[19:49:25] <twnqx`> they might fire back to back, without running mainloop, given the length of the interrupt handling code
[19:49:25] <Valen> its one if statement then like 4 instructions
[19:50:40] <Valen> if WasIdle == 0 {somevar = timer1;WasIdle = 1}
[19:50:48] <twnqx`> hm, the 1khz interrupt always runs, which is 16000 clocks @ 16mhz
[19:51:09] <twnqx`> umm, wait
[19:51:13] <twnqx`> do i even have a 16bit timer left
[19:51:55] <twnqx`> 0,1,3 are used
[19:52:18] <ambro718> 1 and 3 each have 2 output compare units if that's what you need
[19:52:51] <twnqx`> i guess they run at bad prescalers :X
[19:53:27] <twnqx`> also CTC mode so they reset early, damn
[19:53:48] <Sinestro> https://gist.github.com/SASinestro/6109148 isn't working.
[19:53:50] <Sinestro> WHAT
[19:53:52] <Sinestro> THE
[19:53:53] <Sinestro> FUCK
[19:54:28] <twnqx`> heh
[19:54:31] <ambro718> I use normal mode with timers, CTC is confusing if you need to use timers generally, as in, "I need the interrupt to trigger at that time".
[19:54:42] <twnqx`> umm
[19:54:48] <twnqx`> that is exactly what i use CTC for :S
[19:55:00] <ambro718> but it's relative
[19:55:21] <twnqx`> no? it causes a perfect 1khz interrupt rate
[19:55:32] <ambro718> yes, if that's what you're after
[19:55:49] <ambro718> but I compute the times of the timer events at runtime
[19:56:13] <ambro718> basically it boils down to "OCR1A = time_you_want_it_to_happen"
[19:56:41] <twnqx`> the 1khz timer just feeds into a timer interrupt distributor... decrementing in 1ms intervals, function pointer called when 0
[19:56:43] <ambro718> with care taken to make sure you don't set it in the past
[19:56:57] <twnqx`> (like i said, all of my code runs *in* interrupt :P)
[19:57:16] <ambro718> right, but sometimes you need more complex timing than constant rate
[19:57:18] <twnqx`> using events or the like has too high latency
[19:57:24] <twnqx`> yeah, all the time
[19:57:37] <twnqx`> register a callback, tell the code "call me in 150ms"
[19:58:05] <twnqx`> 150ms later the bin is empty, callback triggered
[19:58:12] <ambro718> but you can do it efficiently with timer running in normal mode, including setting it up at absolute time
[19:58:14] <Roklobsta> Sinestro: look at my putc getc
http://pastebin.com/CSQKiQc7
[19:58:23] <ambro718> to avoid any drift
[19:58:25] <twnqx`> depends how many such callbacks you need
[19:58:53] <twnqx`> i have far more than timers, might be running with 12 active at peak so far
[19:59:13] <ambro718> 12 what?
[19:59:21] <twnqx`> active "call me in" callbacks
[19:59:49] <twnqx`> session timers, packet timers, large interval periodic variable updates, ADC updates, LED updates, ...
[19:59:54] <ambro718> ah right, my code has lots of callbacks too
[20:00:26] <ambro718> though I do most of the stuff from the main loop
[20:00:41] <ambro718> with an event queue, and ISRS often post events to the event queue
[20:00:57] <twnqx`> too much overhead
[20:01:09] <ambro718> yep, it's a doubly linked list
[20:01:26] <ambro718> time critical stuff stays in the ISRs though
[20:01:29] <twnqx`> in some situations i have 500µs to receive a packet, parse it, and relay it
[20:01:45] <twnqx`> if it is for me i have more time
[20:01:53] <twnqx`> like, 15ms
[20:02:52] <twnqx`> hm, i could free timer 1 i think
[20:03:03] <twnqx`> ADC updates happen at 80hz
[20:03:52] <twnqx`> no idea why i used a dedicated timer for that...
[20:06:14] <ambro718> couldn't you reuse the internal ADC prescaler and ADC interrupt
[20:06:53] <twnqx`> nope
[20:07:08] <twnqx`> conversions triggers as soon as i enter sleep .P
[20:07:36] <twnqx`> so i have to use the timer to start conversion, and the adc interrupt to finishit up
[20:08:11] <ambro718> wouldn't the ADC interrupt wake it up?
[20:08:55] <twnqx`> the problem with automatic conversion is that once you enable it, it triggers every time you enter sleep
[20:09:01] <ambro718> well I've never really done sleeping so I don't know yet
[20:09:11] <ambro718> then don't enable automatic conversion
[20:09:18] <twnqx`> yes
[20:09:23] <twnqx`> then you can't have automatic
[20:09:31] <twnqx`> at least on my chip :P
[20:09:50] <twnqx`> as in, timed
[20:10:20] <ambro718> why not just use the ADC in normal mode, that is, from the ADC interrupt start the next conversion? Does it interfere with sleep?
[20:10:28] <twnqx`> too fast
[20:10:48] <ambro718> you can ignore most conversions heh
[20:11:09] <ambro718> well it does waste power and cycles
[20:11:26] <twnqx`> and i don't even know how many i have left :P
[20:11:29] <Valen> adc conversion clock has a prescaler
[20:11:49] <twnqx`> yeah, but like i just said, it doesn't work together with sleeping.
[20:12:45] <ambro718> how do you need it to behave with sleeping?
[20:13:19] <twnqx`> well, guess i could run it like while (1) {} ;
[20:13:24] <twnqx`> insteadof
[20:13:33] <twnqx`> while (1) { sleep () } ;
[20:16:04] <twnqx`> waaait
[20:16:18] <TechIsCool> so I am running into an issue with this change and how it works can someone give me a little help?
http://www.nongnu.org/avr-libc/changes-1.8.html
[20:16:24] <twnqx`> ok, i use timer 1 for time triggered ADC conversion, and switching the input multiplexer
[20:17:10] <twnqx`> no idea how it worked before, gcc didn't support that
[20:17:11] <TechIsCool> it was originally extern const TC2_t* timer_to_tc2_PGM[] PROGMEM; and I changed it to extern const TC2_t* const timer_to_tc2_PGM[] PROGMEM;
[20:17:37] <TechIsCool> but when I add the extra const I get assignment of member 'CTRLB' in read-only object
[20:18:19] <twnqx`> so umm.. don't add it?
[20:18:59] <TechIsCool> but then it says variable 'timer_to_tc1_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
[20:19:01] <twnqx`> and that's not related to the change you inked anyway
[20:19:22] <twnqx`> note the difference of tc1 vs. tc2?
[20:19:31] <TechIsCool> there are thre of them all the same error
[20:19:39] <TechIsCool> I just modified one back so I could copy the error
[20:20:29] <twnqx`> so those are really arrays TC2_t pointers?
[20:20:35] <twnqx`> araays of*
[20:21:06] <TechIsCool> correct line 82 down
https://github.com/akafugu/Xmegaduino/blob/xmegaduino/hardware/xmegaduino/variants/akafuino/pins_arduino.h
[20:21:19] <TechIsCool> 180 not 82
[20:22:47] <twnqx`> yeah, the attribute needs to go in front
[20:23:10] <TechIsCool> what you mean?
[20:23:37] <ambro718> __attribute__(...) void func() {}
[20:23:50] <twnqx`> wait, you mean it does not compile?
[20:23:56] <TechIsCool> correct
[20:24:03] <twnqx`> const PROGMEM TC0_t* timer_to_tc0_PGM[] = {
[20:24:38] <ambro718> gcc will proudly tell you that you can't add attributes to function definitions if you put it just before {, even though you can put it in front
[20:25:32] <twnqx`> oh god
[20:25:33] <twnqx`> 3am
[20:25:35] <twnqx`> :X
[20:25:54] <TechIsCool> Error 3 variable 'timer_to_tc1_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
[20:26:06] <TechIsCool> woops I edited 1 not 0
[20:26:10] <TechIsCool> same thing
[20:26:30] <ambro718> const TC1_t* const PROGMEM timer_to_tc1_PGM[] = {
[20:26:39] <ambro718> I think it's trying to tell you to make it const
[20:27:21] <twnqx`> if anything
[20:27:34] <ambro718> well it does say "must be const", so why not make it const?
[20:27:41] <TechIsCool> ambro718: I think so as well. But then I get Erro rassignment of member 'CTRLB' in read-only object
[20:27:42] <twnqx`> const PROGMEM TC1_t const *
[20:27:59] <twnqx`> i would say
[20:28:24] <ambro718> you just said twice that it points to something const
[20:28:31] <twnqx`> no
[20:28:39] <ambro718> yep, you did
[20:28:48] <twnqx`> i said that the array is constant, and the pointers inside the array are too
[20:28:56] <TechIsCool> its listed at line 84
https://github.com/akafugu/Xmegaduino/blob/xmegaduino/hardware/xmegaduino/cores/xmega/wiring_digital.c
[20:29:38] <ambro718> theBear: consider that "const int x;" is the same as "int const x;", and the former form is an exceptional syntax that works anyway
[20:29:44] <ambro718> I mean twnqx`
[20:30:25] <twnqx`> TechIsCool: which file throws the error
[20:30:35] <twnqx`> the one with the declaration, or the one with the assignment
[20:30:36] <TechIsCool> wiring_digital.c
[20:30:36] <ambro718> similarly, "const int *ptr", "int const *ptr" amd "const int const *ptr" are all the same
[20:30:53] <TechIsCool> twnqx`: the assignment
[20:31:17] <ambro718> TechIsCool: you can't store it to program memory and then modify
[20:31:48] <twnqx`> i think
[20:31:54] <twnqx`> what he actually wants to do
[20:32:05] <twnqx`> is something that is neither
[20:32:09] <ambro718> TechIsCool: program memory is flash
[20:32:17] <TechIsCool> which is read-only
[20:32:23] <ambro718> yes!!
[20:32:31] <ambro718> "But then I get Erro rassignment of member 'CTRLB' in read-only object"
[20:32:39] <ambro718> of course you do
[20:32:46] <TechIsCool> the thing I don't understnad is how it was being set before I started tinkering with it
[20:32:53] <twnqx`> TechIsCool: first of all, you need to access it through the programspace reading helper functions
[20:33:05] <twnqx`> you can't read it the way you do.
[20:34:25] <twnqx`> once you do that, you will realise that you need to read the value from tc0->CTRLB, which is the address of the thing you want
[20:34:48] <twnqx`> into a temporary variable, which will be either a uint8_t or uint16_t, not sure
[20:35:06] <twnqx`> and then you have to deference the resulting variable to write to the register
[20:35:18] <ambro718> I don't see how this line has anything to do with the timer_to_tc1_PGM array
[20:35:28] <twnqx`> tc1->CTRLB &= ~(TC1_CCAEN_bm << channel); then
[20:35:35] <twnqx`> via
[20:35:37] <twnqx`> TC1_t* tc1 = (TC1_t*)timerToTC1(timer);
[20:36:03] <ambro718> but once the pointer was grabbed and cast to non-const this has nothing more to do with the array
[20:36:42] <twnqx`> that is something i was wondering about, too
[20:36:44] <ambro718> maybe TCC1 itself is read-only? where is it declared?
[20:37:23] <TechIsCool> #define TCC1 (*(TC1_t *) 0x0840) /* 16-bit Timer/Counter 1 */
[20:37:34] <Roklobsta> 1101001 101010001 10101001 10001 0101010101 1
[20:37:42] <TechIsCool> its defined in the chip manifest
[20:38:36] <ambro718> TechIsCool: what if you make the array elements point to non-const?
[20:38:56] <ambro718> TC1_t* const PROGMEM timer_to_tc1_PGM[] = {
[20:39:00] <ambro718> no const in front
[20:39:16] <twnqx`> nonconst... in progmem...
[20:39:33] <ambro718> no, the array is still const
[20:39:49] <ambro718> I've just changed the type of the array elements to "pointer to TC1_t"
[20:39:54] <twnqx`> ah, right
[20:40:20] <TechIsCool> it returns with the same error but nothing different Error 4 assignment of member 'CTRLB' in read-only object
[20:40:27] <twnqx`> static const __ATTR_PROGMEM__ char rsomtr_01[] = { 0x01, 0x83, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
[20:40:29] <twnqx`> so tell me
[20:40:33] <twnqx`> what is const here?
[20:40:59] <ambro718> twnqx`: it's an array of const char
[20:41:23] <twnqx`> which makes it completely const, or am i wrong?
[20:41:25] <ambro718> twnqx`: be aware that you can't really make a const array, only an array of const elements
[20:41:30] <ambro718> you are correct
[20:41:39] <twnqx`> good
[20:42:13] <ambro718> but: int * const arr[]; it's an array of const pointers to int
[20:42:23] <ambro718> int const * const arr[]; it's an array of const pointers to *const* int
[20:42:35] <ambro718> both are completely const and suitable for going in progmem
[20:44:13] <ambro718> don't write "const int ...", it's confusing syntax, use "int const ..." :D
[20:45:06] * twnqx` just switches to const int const * const
[20:45:25] <ambro718> duplicate const, the horror!
[20:46:40] <ambro718> void func (int arr[static const 7]);
[20:46:53] <twnqx`> static const __ATTR_PROGMEM__ struct uartconf speeds[] = { and like that? an array of const structs?
[20:47:57] <ambro718> yep, and you put the const in front, again ;)
[20:48:41] <ambro718> but really, void func (int arr[static const 7]); compiles and does something useful, try it!
[20:50:08] <ambro718> TechIsCool: I susppect a compiler bug in your case, which compiler is that?
[20:50:56] <twnqx`> ambro718: i suspect a lack of pgm_read_byte/pgm_read_word
[20:51:33] <twnqx`> he takes the address of somethng in flash, then tries to access it via ram. can
[20:51:39] <twnqx`> 't work either way
[20:52:15] <twnqx`> i bet as soon as he introduces a temporary pointer variable it will go away
[20:52:20] <ambro718> I can't tell, I'd need to see what timerToTC0 does
[20:52:42] <Roklobsta> oh bollox, sinestro lefty
[20:52:49] <twnqx`> i maps timer registers for indirect access into an array, if i get the tables correctly.
[20:53:29] <ambro718> as long as you use the progmem array directly (not via pointer) wouldn't the compiler generate the flash reads?
[20:53:37] <twnqx`> no
[20:53:53] <twnqx`> it did with the old structure, as long as you didn't use avr-gcc
[20:54:34] <Roklobsta> hmm, my inderstanding was iwth gcc you need to use the builtins for reading and writing flash
[20:54:54] <twnqx`> if my understanding is correct. nevergot it to work without explicit reading.
[20:55:04] <twnqx`> anyway, alarm goes off in 5.5h
[20:55:06] <twnqx`> good night
[20:55:07] <Roklobsta> simply because gcc, unlike other compilers, is general an assumes certain things about hwo the memory is organised
[20:55:56] <ambro718> hm stupid, the compiler knows enough to be able to handle it
[20:56:08] <ambro718> specifically, it knows the progmem attribute
[20:57:37] <ambro718> in fact, it does something very much like what would be needed here, on ARM, when you pack a struct with __attribute__((packed)), and as long as you access the members via the struct (not via pointers to them), it will specifically generate special code to not trigger alignment trapc
[20:57:40] <ambro718> *traps
[20:58:03] <ambro718> so, I doubt the "gcc assumptions" thing
[21:04:39] <TechIsCool> back sorry ab out that
[21:04:52] <Roklobsta> i mean i don't think gcc/libc are generally clever enough to automatically generate the right opcodes for flash memory space versus ram memory space.
[21:04:55] <TechIsCool> ambro718: What do you need to see on my side
[21:05:25] <ambro718> oh wait I'm stupid
[21:05:27] <Roklobsta> for example all the prinf stuff has a version for aruments to be const in flash and arguments to be const in ram
[21:05:51] <ambro718> no, never mind...
[21:06:21] <Roklobsta> maybe c++ would be easier in that case with overloadig
[21:06:43] <ambro718> TechIsCool: try this TC1_t* const timer_to_tc1_PGM[PROGMEM] = {
[21:06:48] <Roklobsta> and just hide the decidsion to use the flash or the ram version
[21:07:25] <TechIsCool> ambro718: Error 2 expected ']' before '__attribute__'
[21:07:30] <ambro718> meh
[21:08:25] <TechIsCool> I hate fixing other things I have minimal information or understanding
[21:09:20] <ambro718> TechIsCool: can you find the definition of timerToTC0
[21:09:41] <Roklobsta> ambro718: re arm: well AFAIK ARM is 32bit aligned memory ops (I am no arm expert) so yes, it'd have to do things like make sure the start of the structure was on a 32bit boundary to ensure unaligned byte reads were consistent.
[21:09:56] <TechIsCool> line 149
https://github.com/akafugu/Xmegaduino/blob/xmegaduino/hardware/xmegaduino/cores/xmega/Arduino.h
[21:10:05] <TechIsCool> #define timerToTC0(T) ( (volatile TC0_t *)( pgm_read_word( timer_to_tc0_PGM + (T))) )
[21:10:13] <Roklobsta> does AMR have misaflined read and writes like the MIPS?
[21:10:27] <ambro718> Roklobsta: if you directly access a packed structure, gcc will generate special read/write code to work even when the structure and its members are not aligned
[21:10:46] <ambro718> I've seen it, you can try it for yourself.
[21:11:11] <Roklobsta> i am familair with my wee time with MIPS
[21:11:37] <ambro718> Roklobsta: ARM traps on unaligned access, except some new versions
[21:11:46] <Roklobsta> as once upon a time the blasted misaligned load and store opcodes were patented by MIPS and gcc needed a software workaround
[21:13:17] <ambro718> I'm just saying that the compiler can use information in the attributes of types to change the way read/writes are done, so as far as I see, the same could be done for avr progmem
[21:13:26] <Roklobsta> no correction, MIPS clones didn't have the misaligned instructions bevcause of patents so gcc had to work around the missing opcodes
[21:13:55] <Roklobsta> probably.
[21:14:00] <ambro718> they patented memory load/store instructions, lol?
[21:14:04] <Roklobsta> yes
[21:14:13] <ambro718> but then x86 violates it too
[21:14:17] <Roklobsta> patent 4,814,976
[21:14:28] <ambro718> since x86 load/store allow unaligned
[21:14:33] <Roklobsta> Intel is a big Gorilla
[21:14:38] <Roklobsta> dare you mess with them
[21:15:18] <Roklobsta> http://www.google.com/patents/US4814976
[21:15:24] <Roklobsta> it's expired now
[21:15:35] <Roklobsta> it was an issue for Lexra (MIPS clone) cores
[21:15:39] <Roklobsta> and gcc
[21:15:50] <Roklobsta> MIPS absorbed lexra in the end
[21:16:02] <ambro718> I see, funny...
[21:16:08] <Roklobsta> but many cheap linux based wifi routers with realtek chips in them have the lexra core still
[21:17:01] <Roklobsta> hmmm, i would imagine at worst avr is 16 bit aligned
[21:17:15] <Roklobsta> i am still anoob with AVR ISA
[21:17:30] <Roklobsta> only look at it when i need to, which isn't much so far.
[21:18:59] <ambro718> Roklobsta: avr is mostly 8-bit
[21:19:12] <ambro718> and memory access is all 8-bit afaik
[21:19:27] <ambro718> so alignment problems can't exist by definition
[21:22:27] <Roklobsta> isn't the load word (16 bits) aligned?
[21:23:34] <ambro718> which instruction are you talking about
[21:23:53] <ambro718> I only see 8-bit loads in the ISA manual
[21:26:40] <ambro718> maybe you were confuse by "LDS (16-bit)" which is still an 8-bit load
[21:39:15] <TechIsCool> any idea on my problem or are we at at dead end
[22:01:06] <ambro718> I don't know, have you tried not putting the array in progmem?
[22:01:47] <ambro718> if you do that be sure to change timerToTC0(timer) to timer_to_tc0_PGM[timer] etc
[22:02:27] <ambro718> TC1_t* const timer_to_tc1_PGM[] = {
[22:02:37] <ambro718> need to change all 3 of course
[22:03:41] <ambro718> TechIsCool: ^^
[22:07:52] <TechIsCool> trying now
[22:08:55] <TechIsCool> ambro718: still the same error damnit
[22:09:04] <TechIsCool> Error 3 assignment of member 'CTRLB' in read-only object
[22:21:41] <Roklobsta> hey I just noticed DES in the ISA
[22:21:56] <Roklobsta> ah poo XMEGA only
[22:29:07] <Roklobsta> ambro718: aha i was thinking of the movw opcode
[22:31:35] <ambro718> yes it works on even registers only
[22:31:56] <ambro718> TechIsCool: if you directly access TCC0->CTRLB is there still an error?
[22:32:26] <ambro718> I think the problem may be the pointer is cast to non-volatile
[22:34:56] <ambro718> if this is the case, that should fix it: volatile TC0_t* const PROGMEM timer_to_tc0_PGM[] = { and volatile TC0_t* tc0 = timerToTC0(timer);
[22:35:19] <ambro718> the declaration of the array also needs to be changed
[22:35:24] <TechIsCool> ok
[22:35:26] <TechIsCool> let me try
[22:35:36] <ambro718> (in addition to the definition...)
[22:35:54] <Roklobsta> TechIsCool: have a good read of:
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
[22:36:24] <ambro718> Roklobsta: I think the problem has nothing to do with program space though
[22:36:39] <ambro718> since it's present even if program space is not used
[22:36:59] <TechIsCool> so here it the prototype correct extern volatile TC0_t* const PROGMEM timer_to_tc0_PGM[];
[22:37:11] <ambro718> yes
[22:39:19] <TechIsCool> this is the define TC0_t* const PROGMEM timer_to_tc0_PGM[] = {
[22:39:32] <TechIsCool> this is the function call const TC0_t* tc0 = (volatile TC0_t*)timerToTC0(timer);
[22:39:41] <ambro718> change both as I suggested
[22:39:47] <TechIsCool> I think I did
[22:39:54] <ambro718> no you didnt
[22:40:13] <TechIsCool> the define needs volatile also
[22:40:41] <ambro718> try exactly as I suggested, I suppose you can read ;)
[22:40:48] <TechIsCool> :)
[22:42:28] <ambro718> just copy-paste if you can't see the difference....
[22:44:26] <ambro718> so what, does it still fail?
[22:44:33] <TechIsCool> no I don't think it does
[22:44:49] <ambro718> whats the error
[22:44:51] <TechIsCool> but its throwing a Error 2 undefined reference to `timer_to_tc2_PGM'
[22:45:00] <ambro718> so it compiled
[22:45:09] <TechIsCool> that was the error so no compile
[22:45:09] <ambro718> check if the declaration matches definition
[22:45:25] <ambro718> it failed later in the link stage
[22:45:31] <ambro718> it's a good sign ;)
[22:46:49] <TechIsCool> this is very true
[22:47:45] <ambro718> where can I find the definition?
[22:48:04] <ambro718> I checked all the .c and .cpp files, it must be somewhere else
[22:48:29] <TechIsCool> looking
[22:48:53] <TechIsCool> https://github.com/pkarc/USB-XMEGA/blob/c6cd82991fd2630191d14d6fbc0350e4aedbd3f8/iox32a4u.h
[22:48:55] <TechIsCool> it is there
[22:49:12] <TechIsCool> line 2303
[22:49:14] <TechIsCool> I think
[22:49:35] <TechIsCool> 2547
[22:49:42] <TechIsCool> if you are looking for tc2_t
[22:50:01] <ambro718> no I mean the definition of timer_to_tc2_PGM
[22:50:03] <ambro718> should be in
https://github.com/akafugu/Xmegaduino/blob/xmegaduino/hardware/xmegaduino/variants/akafuino/pins_arduino.h
[22:50:18] <ambro718> the timer_to_tc0_PGM and 1 are there, 2 is missing
[22:50:27] <ambro718> hence the link error
[22:50:34] <TechIsCool> I see
[22:50:37] <TechIsCool> hmm
[22:50:48] <ambro718> so it seems like that code wasn't tested for your MCU
[22:51:10] <ambro718> try removing/out-defing all the TC2 code if you don't need it
[22:51:15] <TechIsCool> maybe but it speced the none u version the and only thing that changed was usb support
[22:52:26] <ambro718> which MCU you using?
[22:52:55] <ambro718> it would be a good idea to check the issue tracker
[22:53:07] <TechIsCool> xmega32a4u
[22:53:41] <TechIsCool> I commentted them out and I make it all the way through the compile now it says multiple definitions of main but I think I broke that not anyone else
[22:53:44] <ambro718> there's an issue for ATXMega256A3U, you can take it as inspiration to get it working
[22:53:58] <ambro718> I don't think I can help any more here
[22:54:13] <TechIsCool> ambro718: so what was the issue that we solved using volitile
[22:54:20] <TechIsCool> volatile
[22:54:32] <ambro718> yep
[22:55:17] <TechIsCool> ambro718: Thank you so much for spending the time helping through this. You Rock
[22:55:50] <ambro718> np
[22:56:29] <TechIsCool> it compiled no way
[22:57:53] <Roklobsta> i think i havw missed the gist of what it is you are trying to do.
[22:58:00] <Roklobsta> put a structure in progmem?
[22:59:29] <vectory_> Roklobsta: i am not sure if he knows, he's just porting a lib to a new libc-avr/gcc-avr combo, afaik from yesterday
[22:59:50] <Roklobsta> oh and it's choking
[23:00:51] <vectory_> < TechIsCool> it was originally extern const TC2_t* timer_to_tc2_PGM[] PROGMEM; and I changed it to extern const TC2_t* const timer_to_tc2_PGM[] PROGMEM;
[23:01:19] <vectory_> just grepped the backlog, did this fix it?
[23:04:41] <TechIsCool> correct
[23:04:50] <vectory_> appearantly the extra const doesnt fix it
[23:05:02] <TechIsCool> vectory_: [20:20] <ambro718> if this is the case, that should fix it: volatile TC0_t* const PROGMEM timer_to_tc0_PGM[] = { and volatile TC0_t* tc0 = timerToTC0(timer);
[23:05:05] <TechIsCool> that was the fix
[23:06:17] <TechIsCool> vectory_: Roklobsta I was porting the xmegaduino to atmelstudio6 and it was having an issue caused by
http://www.nongnu.org/avr-libc/changes-1.8.html
[23:07:14] <Roklobsta> ok
[23:09:11] <vectory_> TechIsCool: it seems to me, that change only concerns deprecating types like prog_char, which i dont see in your line. if that makes a difference to you
[23:10:09] <TechIsCool> I understand but that is the was the cause of the originating error if that make sense the const was not originally in the code
[23:10:34] <TechIsCool> I might be totally wrong though have been before
[23:22:49] <N1njaneer> Anyone awake in here? :)
[23:23:37] <N1njaneer> Found an oddity between .hex and .elf generation, wondering if anyone has experience with this.
[23:24:48] <Casper> .hex and .elf ain't really the same
[23:25:02] <N1njaneer> Hooray, someone awake
[23:25:14] <N1njaneer> Here's what I'm seeing.
[23:25:20] <Casper> oh? someone is awake? who??
[23:25:33] <N1njaneer> I have a bootloader compiling and working great on ATMEGA128.
[23:25:45] <N1njaneer> gcc dumps the .elf and .hex as expected
[23:26:01] <N1njaneer> Both will program and run fine
[23:26:13] <N1njaneer> Bootloader is at 0x1E000
[23:26:57] <N1njaneer> When I program the .hex, everything is exactly as I expected it when reading the device flash back out and examining. Everything is 0xFF all the way up to bootloader start at 0x1E000 and the vector table
[23:28:01] <N1njaneer> When I program the .elf and read back, there is a chunk of data from 0x1DF000 immediately proceeding the 0x1E000 vector table, and I have no idea what it is.
[23:28:24] <N1njaneer> the .map file shows everything starting to map at 0x1E000 as expected. It's very strange.
[23:28:51] <Casper> the .elf contain debug data
[23:28:56] <Casper> which the .hex strip
[23:29:03] <Casper> and contain other useless info
[23:29:33] <N1njaneer> That's what I was thinking it might be, but it's strange that it places it BEFORE the bootloader instead of somewhere in a spare section OF the bootloader.
[23:30:38] <Casper> afaik, it's actually before the main program
[23:30:39] <N1njaneer> It doesn't seem to affect operation in normal run, but was peculiar and was out of place when debugging this bootloader, because I was seeing a chunk of data in my application section that should not have been there!
[23:30:49] <Casper> and the address space in the .elf isn't the same as in the .hex
[23:31:14] <N1njaneer> Well, this is showing up in the actual micro when I read the flash out and look at the resulting .hex
[23:31:47] <N1njaneer> I'm curious as to where that debug data goes when doing a standard application build, since the vector table then goes at 0x00000
[23:31:57] <Casper> are you sure that it isn't the standard vector table and some stub code?
[23:32:14] <Casper> the debug data is stripped when the .hex is generated
[23:34:01] <N1njaneer> Nope, the vector table only has one interrupt present in my bootloader for UART-RX at interrupt 18, and that's the only place that has a valid jump instruction. And my vector table is at 0x1E000 exactly where it should be and working correctly.
[23:34:15] <Roklobsta> elf can program the fuses too which hex can't
[23:34:28] <N1njaneer> So I'm guessing this IS the debug data, but it's odd that it just shows up in the micro's application flash memory when doing the readback.
[23:34:43] <Casper> there is 2 vector tables
[23:34:54] <Casper> one at 0x0000 and one at your bootloader address
[23:35:11] <N1njaneer> Correct. I am speaking strictly about the bootloader's at 0x1E000
[23:35:56] <N1njaneer> The entire application section is 100% blank between 0x00000 and 0x1DFFF when I program the .hex in, but there's just a bit of stuff right before 0x1E000 when the .elf goes in.
[23:36:34] <N1njaneer> So I guessing it is debug data of some sort. Everything works correctly, it was just very odd to see the discrepancy.
[23:36:41] <N1njaneer> +I'm
[23:36:50] <Casper> weird
[23:37:06] <Casper> maybe a bug somewhere
[23:37:45] <N1njaneer> I'm going to ask my Atmel FAE if he can fire the question up the chain. Generally they're really great about getting quick answers back :)
[23:40:08] <Casper> do you use gcc / avrdude? if so, I don't think they can answer, they don'T maintain it
[23:42:24] <N1njaneer> I'm programming from inside AVRStudio with the JTAG MKII, which AFAIK is their own tool interface since they haven't published the JTAG device specs to port with.
[23:44:42] <Casper> ah yeah... ask them
[23:44:44] <N1njaneer> Firing off an email now. :)
[23:45:23] <N1njaneer> Local FAE is great on pushing my technical quandries up the chain.
[23:48:12] <N1njaneer> Thanks for the suggestions. I really need to hang around here again more - was around a year or so for a few weeks, then IRC kind of got lost in the shuffle.
[23:50:15] <Roklobsta> don't worry, we are good at red herrings.
[23:52:41] <N1njaneer> Happy to help contribute back as well where possible - been doing AVR stuff for about 11 years now so I've seen my share of oddball problems. :)
[23:53:18] <N1njaneer> Glad gcc is pretty well established. Not like the fun old days using ICC-AVR's toolchain and having the compiler spit out incorrect code.