Back
[01:13:18] <Levitator> Hey, to use a digital I/O, do you need to do any setup aside from setting the direction?
[01:13:56] <Levitator> Isn't it just update DDR to set direction, and then output with PORTxn? Or is there something else?
[01:24:52] <Casper> that's it
[01:29:40] <Levitator> Hrm.
[01:40:20] <Levitator> Ah. Just my lysdexia acting up again, I guess.
[05:05:20] <crabcake> Hi, I'm reading some AVR code in C and I'm new to AVR
[05:05:36] <crabcake> I see values like TC_CCBINTLVL_HI_gc but can't find any documentation for these
[05:07:06] <crabcake> should be related to avr-libc, but didn't find anything in the reference either
[05:07:11] <crabcake> any suggestions please?
[05:12:41] <crabcake> actually from what I see they *are* defined in the avr-libc header files
[05:37:35] <antto> crabcake those are for xmega
[05:38:05] <antto> _gc means group constant or something like that
[05:38:10] <crabcake> yeah, i just found out that the manual contains more info than the datasheet
[05:38:26] <crabcake> i think it's an avr understanding problem mainly and libc secondly
[05:41:41] <antto> crabcake there's one datasheet that describes the modules of the whole range of chips in detail, usart/spi/i2c/timers/adc/etc.. how to set them up and use them, and then there is another datasheet which covers your chip specifically and only explains the specific stuff (number of pins, which pin does what, how many usarts it has, how many adcs, how many spis, etc..)
[05:42:00] <crabcake> Ah, that's what I need then
[05:42:14] <antto> you should look into the first datasheet to see what that value means
[05:42:51] <antto> by its name, it looks like TC = timer/counter, CC probably means capture-compare, B is probably a port maybe, INTLVL is obviously the interrupt level
[05:42:55] <crabcake> i think that's the difference between the "manual" and the "datasheet"?
[05:43:10] <crabcake> yes, it's the capture-compare indeed
[05:43:16] <crabcake> i'm reading about it all now
[05:43:20] <antto> well, i don't know how to call them, both are PDFs as far as i care
[05:43:27] <crabcake> heheh
[05:43:39] <crabcake> i think i'm on the right track now
[05:43:42] <crabcake> thanks :-)
[05:43:45] <antto> what's your chip exactly?
[05:44:21] <crabcake> ATxmega128A4U-AU
[05:44:41] <antto> heh, i happen to know these
[05:45:21] <antto> but for some reason loading atmel.com takes ages o_O
[05:45:37] <crabcake> so i found out that the document referred to as the "xmega au manual" contains all the background info i need to read
[05:45:57] <crabcake> and then the datasheet for my device contains the values etc, as you said earlier
[05:46:10] <antto> you need the A4 or A4U document (that's what i wanted to check in the site)
[05:46:27] <antto> that explains in details all the modules for any of those chips
[05:47:02] <crabcake> yeah i think once i understand how it works, the libc directives are self-explanatory
[05:48:27] <antto> the specific datasheet for your chip will contain the pinout for the xmega128a4u, 64a4u, 32a4u, and 16a4u, it will tell you that these chips have 5 (iirc) USARTs, where are they located, offsets in memory for the different structures
[05:48:49] <antto> but it won't explain how to set up the USART, that's explained in the first datasheet
[05:49:22] <antto> ah, finally
[05:49:32] <antto> http://www.atmel.com/devices/atxmega128a4u.aspx?tab=documents
[05:50:03] <antto> so when you go to your chip's product page - it shows the two documents i was talking about at the top there
[05:50:20] <crabcake> ah, yes yes
[05:50:41] <crabcake> the "manual" and the product-specific "datasheet"
[05:50:42] <crabcake> we're talking about the same thing
[05:50:57] <crabcake> being a compleete noob to avr it took me a bit of googling to figure it out
[05:51:10] <antto> yeah, i'm not on my "work" computer so i was talking out of memory here
[05:51:25] <crabcake> wow, there's a lot of supplementary docs there too
[05:51:30] <antto> yeah
[05:51:34] <crabcake> cool
[05:52:36] <antto> with xmega, once you figure out how a given module works, and when you make yourself a "driver" for it (for which you gotta do some reading in the first document) - then you got it covered, because this code will work for any instance of that module in the chip
[05:53:52] <antto> in other words, all 5 USARTs are the same in terms of operation/initialization/usage .. the difference is where they are located in RAM and on which pins on the chip
[05:54:33] <crabcake> yeah i found that this is the way i generally understand complex systems. break down things into smaller components and write some test code for each, repeat for every component, then put the whole thing together
[05:55:04] <antto> i wish other chips did it this way too (atmega, pic..) but sadly, things are more messy there
[05:55:13] <crabcake> what you're saying makes sense, after all it's all about IC re-use inside
[05:55:19] <crabcake> oh really
[05:55:31] <crabcake> that's bad hahah
[05:55:45] <crabcake> s/IC/IP
[05:55:56] <antto> it's "normal" ... xmega is just "nicer"
[05:56:43] <antto> everybody is used to that mess, but xmega decided to waste a lot of ram in order to make all modules nicely organized in RAM as structures, so that you can code easier
[05:57:33] <crabcake> see i mostly work on SoCs so i take this for granted
[05:58:16] <crabcake> most of the time things are tidy
[05:58:33] <crabcake> at least for the ones i've worked with so far
[05:58:35] <crabcake> :-)
[05:58:49] <antto> no idea about that, but for example, with pic18, if the chip has two USARTs their configuration bits in RAM will be located in weird places, stuffed together with configuration bits of other modules (to pack everything tightly in RAM and not waste any bit)
[05:59:01] <antto> that's cool and all, but writing a driver for that is not so easy
[05:59:32] <crabcake> ah, so it's probably related to the limited nature of uCs
[05:59:37] <crabcake> makes sense
[05:59:56] <antto> while for xmega, if your driver takes a pointer to the USART_t struct, and if it works for USARTC0 - then you automatically know that it will work for USARTC1, D0, D1, E0... all of them
[06:00:30] <antto> just pass the right pointer, all configuration bits are contained in the struct
[06:01:47] <crabcake> my blissful ignorance, hahah. i thought that would be the norm
[06:02:11] <antto> nah, you'd get that impression if you pick xmegas first, that's why i mentioned it ;]
[06:02:29] <crabcake> better than none right
[06:02:32] <antto> i started with atmega, then went to pic x_x and recently to xmega \o/
[06:03:11] <crabcake> how's pic compared to avr
[06:03:34] <antto> i prefer avr
[06:03:48] <antto> the tools for pic are annoying
[06:05:14] <crabcake> my only experience with uC was some toy projects on the arduino level which abstracts everything
[06:05:39] <antto> btw, for the xmega - i write in C++ .. tho i don't actually use the fancy sides of the language, just structs with methods is good enough
[06:05:40] <crabcake> and some CTF / reversing
[06:05:49] <specing> PIC has a weird architecture
[06:05:50] <crabcake> which was different due to the harvard architecture
[06:05:58] <specing> as such, it is not supported by mainstream compilers
[06:06:09] <specing> as such, there is no support for the Ada programming language
[06:06:18] <crabcake> how about gcc?
[06:06:30] <antto> sdcc
[06:06:33] <specing> no support for PIC in gcc.
[06:06:44] <antto> afaik sdcc is based on gcc
[06:06:47] <specing> no
[06:06:52] <antto> hm?
[06:07:04] <specing> sdcc only does C and was quite weird when I used it
[06:07:09] <specing> it did work, however
[06:07:15] <specing> was 10 years ago
[06:07:43] <antto> i use sdcc for pic, because i can't stand the xc8 compiler and especially the mplab IDE
[06:07:51] <crabcake> i suspect that there must have been some progress since then
[06:07:54] <crabcake> ;-)
[06:08:02] <antto> sdcc almost works (pic14 support is kinda lacking)
[06:08:20] <antto> but for pic18 - i use entirely sdcc
[06:09:15] <antto> the situation with avr is miles better - avrgcc
[06:09:36] <antto> it just works
[06:09:47] <crabcake> http://stackoverflow.com/questions/16690635/does-gcc-support-pic-particularly-the-problematic-pic16-family
[06:09:53] <crabcake> :-/
[06:10:34] <specing> why :/?
[06:10:42] <specing> just use avr
[06:10:48] <specing> or some other 8 bit arch
[06:10:58] <specing> that is supported in gcc
[06:11:26] <crabcake> just surprised
[06:11:28] <antto> if you've seen how nice xmega is - i think you'll hardly go for anything else ;P~
[06:11:34] <crabcake> wasn't intending to use pic anyway
[06:11:45] <antto> ESPECIALLY pic >:/
[06:11:56] <crabcake> heheh, it just happens that the project i wanted to do some coding on uses xmega
[06:12:07] <crabcake> i wasn't intending to get involved into the uC part in the first place
[06:12:13] <crabcake> but you know how these things are...
[06:12:14] <antto> pic is nice if you don't have to write the code yerself
[06:13:33] <antto> i also got into microcontrollers by chance of fate, previously i had no idea about them, i was coding software stuff (dsp algos)
[06:14:28] <antto> then i bought an analog synthesizer controlled by an atmega162, and figured i can actually modify the firmware - downloaded the compiler and.. it just worked
[06:14:46] <antto> had no idea what i was doing tho ;P~
[06:15:35] <crabcake> good stuff
[06:16:23] <crabcake> once i bought a used microkorg, ended up spending way longer reading about how this stuff works than using it for music
[06:16:36] <crabcake> in the end i accepted my fate and sold it
[06:16:46] <crabcake> focused completely on computers
[06:18:56] <antto> yeah, korgs suck
[06:18:58] * antto runs
[06:19:46] <crabcake> lol
[06:19:52] <crabcake> maybe that's why i gave it all up
[09:43:53] <carabia> specing: you should write a book on using ada. Kind of like the propaganda-books that are released prior to presidential elections
[09:45:00] <Lambda_Aurigae> carabia, we had those in the military in the early 90s.
[09:45:15] <carabia> outdated
[09:45:26] <Lambda_Aurigae> yeah, but same concept.
[09:45:30] <Lambda_Aurigae> but moreso.
[09:45:40] <Lambda_Aurigae> not so much "You should use Ada because."
[09:45:49] <Lambda_Aurigae> more like, "You WILL use Ada because,,,"
[09:45:58] <Tom_L> Ada? who's she?
[09:46:05] <Lambda_Aurigae> Ada Lovelace!
[09:46:42] <Lambda_Aurigae> Charlie Babbage's assistant.
[09:47:30] <Lambda_Aurigae> apparently Ada was a popular name in the 1800s
[09:48:19] <Lambda_Aurigae> locally there are memorials and parks named for Ada Hayden, botanist and preservationist from the 1800s
[09:48:24] <Tom_L> my grandmother was Ada
[09:48:46] <Lambda_Aurigae> what, you want us to use your grandmother?
[09:48:56] <carabia> So actually I have come to undertand why the programming language is named Ada.
[09:50:01] <carabia> It's because it is as impractival as Miss Lovelace due to her apparent (and constant) absense from the kitchen
[09:50:27] <carabia> impractical, even
[09:52:38] <Lambda_Aurigae> apparently it was developed in the 70s
[09:53:00] <carabia> yes
[09:53:23] <Tom_L> by a bunch of drug crazed hippies?
[09:53:31] <Lambda_Aurigae> by the US military.
[09:53:42] <Lambda_Aurigae> worse than any drug crazed hippies.
[09:53:45] <Tom_L> oh they didn't burn their draft cards
[09:53:51] <carabia> hahaha
[13:15:07] <Levitator> Are there any indirect word-size RAM load/store instructions? Not finding any.
[13:23:45] <crazy_pete> you know i don't rememember but i don't think so Levitator
[13:24:27] <Levitator> Datasheet says to use cli for 16-bit data.
[13:25:25] <crazy_pete> clear interrupt?
[13:25:36] <Levitator> Yeah. So that it's atomic.
[13:26:21] <crazy_pete> http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_instructions.Data_Transfer_Instructions.html
[13:26:25] <crazy_pete> oh right
[13:26:36] <crazy_pete> yes cli if you want it to be atomic, sorry ;-)
[16:46:16] <Lambda_Aurigae> Levitator, ram is 8bits.
[16:46:31] <Lambda_Aurigae> now, there are some register pairs that can be worked together
[16:46:45] <Lambda_Aurigae> which are, technically, ram.
[16:47:03] <Lambda_Aurigae> but doing indirect like that,,,not really.
[23:43:21] <chendry> hey all! I'm doing: "PORTB ^= PB4" repetedly on my ATTiny85. I'm seeing the result, but on physical pin 7, not 3 as I expected from the datasheet. Am I using the macros incorrectly?
[23:43:54] <_ami_> chendry: on linux or windows?
[23:44:11] <_ami_> i meant where did you compile your code? linux or windows?
[23:44:12] <chendry> _ami_: I'm running Linux, using avr-gcc
[23:50:09] <carabia> chendry: it's been a while since i've done avrs, but afaik PB4 resolves to 4
[23:50:31] <chendry> yeah, it does -- and I just realized... I bet I need to pass it 1 << PB4 ?
[23:50:42] <carabia> so what you actually wanna do is a left shift by that to toggle it
[23:50:51] <chendry> or, rather, PORTB ^= (1 << PB4)
[23:50:54] <carabia> yes
[23:53:32] <carabia> but even then i'm not sure if 4 would correspond to pin 7...
[23:54:19] <carabia> I think it should be pin 5 but i don't know, i just woke up :)
[23:56:09] <chendry> aha! it works!
[23:56:46] <chendry> so, yeah -- 4 would be 0x100, so 1 << 2, and PB2 is 2, and the datasheet shows physical pin 7 being PB2, so I think everything is checking out
[23:57:37] <carabia> no, it would be 0b100
[23:58:28] <chendry> dah! yeah, 0b100
[23:58:58] <chendry> muscle memory... this 0b syntax is new to me :)