Back
[10:51:30] <carabia> sup avr people
[10:51:37] <carabia> what's cooking
[11:07:31] <gjm> amphetamine
[11:14:24] <carabia> a bit early for that, or have you lost track when you last slept?
[11:20:33] <Casper> cooking? in my field... most likelly a cpu somewhere...
[13:40:08] <carabia> Casper: don't do that
[15:58:02] <moondeck> hi
[15:59:26] <moondeck> so, just wanna know if avr-gcc has the kind of thing PICs have, that you can address individual bits in a SFR, like PORTCbits.PORTC7?
[16:00:21] <Tom_itx> yes
[16:00:27] <bss36504> That's merely syntactic sugar
[16:00:42] <bss36504> Tom_itx: Does that API exist for megaAVR though?
[16:00:50] <Tom_itx> look in the header files and see
[16:01:04] <Tom_itx> i think most of them are defined
[16:01:30] <bss36504> I'm pretty sure it's a union of the SFR with a struct that has bitfields. I don't know that they did that for the current version of the megaAVR headers
[16:01:34] <bss36504> but check and see
[16:01:44] <bss36504> if not you can just write it yourself, moondeck
[16:01:44] <moondeck> yeah, i know i can set them like PORTC = (1 << PORTC6) but i could not just do PORTC6 = 1
[16:01:54] <Tom_itx> i don't generally use them so i'm not real familiar with em but i'm pretty sure they're defined
[16:02:05] <bss36504> well no, PORTC6 is different than what you asked for
[16:02:24] <bss36504> sorry, PORTC6 = 1 is different
[16:02:50] <moondeck> yeah, but what should i use then?
[16:03:01] <moondeck> if i wanna set a certain bit in a register, to a certain state?
[16:03:22] <Tom_itx> what chip are you working with?
[16:03:30] <moondeck> atmega 32u4
[16:03:33] <bss36504> Well, I know for a fact that (1<<[the bit number]) is a very portable and, IMO, very readable format
[16:04:07] <Tom_itx> PIND1 is defined
[16:04:17] <bss36504> right, they are defined, but PIND1 is just 1
[16:04:22] <bss36504> it's a #define
[16:04:32] <carabia> y
[16:04:48] <carabia> you could make your own port struct if you wanted to
[16:04:49] <moondeck> bss36504 i cant do that, as i need to have some pins defined like D1 PORTC5 and then i need to set it to a state. any other way i could do it?
[16:04:56] <bss36504> PORTDn is also defined, but saying PORTDn = y won't do anything
[16:05:16] <carabia> but there's little to no sense in doing that
[16:05:34] <bss36504> if you want to *set* bit n in a PORT register, do something like this: PORTx|=(1<<n);
[16:05:53] <bss36504> to *clear* you'd do PORTx&=~(1<<n);
[16:06:03] <bss36504> toggle is PORTx^=(1<<n)
[16:06:07] <carabia> and reset PORTx &= ~(1 << n);
[16:06:12] <carabia> oh you're faster
[16:06:16] <bss36504> :)
[16:06:35] <bss36504> if you dont like that format, make an inline function or a macro or something
[16:06:39] <carabia> very readable. You can define your pins with logical names
[16:06:44] <moondeck> just got enlightened
[16:06:46] <moondeck> thanks guys
[16:06:50] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/avr/c_bits/bits_index.php
[16:07:00] <Tom_itx> there's the whole gammit of bitsets
[16:07:32] <bss36504> Now, what you were doing earlier with the dot-syntax can be constructed, but it's probably more work than you want to do. It's only helpful, IMO, for special peripheral registers where the bits are mnemonic.
[16:07:33] <Tom_itx> #define bit_get(p,m) ((p) & (m))
[16:07:33] <Tom_itx> #define bit_set(p,m) ((p) |= (m))
[16:07:33] <Tom_itx> #define bit_clear(p,m) ((p) &= ~(m))
[16:07:33] <Tom_itx> #define bit_flip(p,m) ((p) ^= (m))
[16:07:33] <Tom_itx> #define bit_write(c,p,m) (c ? bit_set(p,m) : bit_clear(p,m))
[16:07:34] <Tom_itx> #define BIT(x) (0x01 << (x))
[16:07:34] <Tom_itx> #define LONGBIT(x) ((unsigned long)0x00000001 << (x))
[16:08:32] <bss36504> basically you create a union of the SFR for the register, and a struct that has bit fields with the names of the fields in the register, and call that struct "bits" or something.
[16:08:53] <Tom_itx> yeah but that's silly and alot of extra work
[16:09:00] <moondeck> alright, thanks
[16:09:21] <bss36504> Tom_itx: Oh yes, it's silly unless atmel does it for you, like they do for the ARM and Xmega APIs
[16:09:24] <bss36504> Then it's pretty neat
[16:09:40] <Tom_itx> yeah i've seen it done
[16:10:34] <Tom_itx> i've done unions before but not normally
[16:11:16] <bss36504> Well, they have a very limited use case. this is one spot where they excell
[16:11:56] <bss36504> Though, now that I think of it, I guess you'd have to place the union at the location of the SFR in memory, and i'm not sure how to do that.
[16:12:07] <bss36504> I imagine there is some attribute you can toss on it.
[16:14:52] <Tom_itx> was he messin with portc on the u4?
[16:15:01] <Tom_itx> iirc that port has reset on it
[16:15:12] <Tom_itx> if he toggles that he'll be surprised
[16:16:23] <bss36504> I thought when the RSTEN fuse was set you couldnt use that as an IO?
[16:16:38] <Tom_itx> try it sometime :D
[16:16:54] <bss36504> Well that's actually kind of cool, you could do a self reset
[16:16:58] <bss36504> on putpose
[16:17:01] <bss36504> purpose*
[16:18:38] <Tom_itx> it's on the U2
[16:18:41] <Tom_itx> PC1
[18:00:41] <foob_> Hello, I am having a strange issue with the attiny1634. I am trying to read the built-in temperature sensor with the ADC. This works fine. However, if pin PA2 goes low, the temperature reading changes from 408 to 283. This seems to be related to the internal 1.1V reference (which is used when measuring the temperature sensor. If I measure the reference with respect to VCC, PA2 affects the value I get as well, 336 (seems sensible since VCC is 3.3
[18:00:41] <foob_> V) vs 1004.
[18:01:28] <foob_> somehow the state of PA2 is affecting my temperature reading
[18:09:26] <Lambda_Aurigae> I would attempt to help
[18:09:27] <Lambda_Aurigae> but
[18:09:32] <Lambda_Aurigae> can't get a datasheet for the chip.
[18:09:36] <Lambda_Aurigae> atmel site is being a bitch.
[18:09:44] <foob_> :)
[18:09:51] <LeoNerd> PA2 is AREF?
[18:10:08] <LeoNerd> Oh, no.. that's PA0
[18:11:04] <foob_> page 181 is the place where I see PA2 might somehow disturb the ADC
[18:11:12] <foob_> figure 18-1
[18:11:41] <foob_> PA2 is referred to AIN1 there, and the ADC multiplexer is right there as well
[18:12:35] <foob_> so maybe the voltage at PA2 (AIN1) somehow affects the ADC through the ADC MUX
[18:12:51] <Lambda_Aurigae> yeah...looks like ain1 will not play nice with adc multiplexer output.
[18:14:32] <foob_> that seems a bit broken to me, unless I can configure them not to interact
[18:14:49] <Lambda_Aurigae> well, they both feed the same input on the comparator.
[18:15:07] <Lambda_Aurigae> but ACME and ADEN should be able to configure which one gets fed in.
[18:15:21] <foob_> my issue is not at the comparator
[18:15:28] <foob_> which I don't even use
[18:15:45] <foob_> the problem is that the temperature reading gets affected by the comparator input
[18:16:04] <foob_> and the temperature sensor is one of the inputs to the ADC mux
[18:16:11] <Lambda_Aurigae> too bad I don't have a chip to play with.
[18:17:28] <foob_> I'm not sure how to read those triangly things in the figure
[18:18:14] <foob_> not the comparator, but the switching elements