Back
[01:03:06] <tavish> Hi, does anyone know if atmel lists how much extra current an mega1280 chip will consume with JTAGEN/OCDEN enabled in deep sleep mode. I can't find it anywhere, apaprt from 'significantly contributes to sleep current'
[01:04:23] <Chillum> I would guess at least an order of magnitude
[01:04:40] <tavish> mA?
[01:05:07] <tavish> i guess i'll just have to test it
[01:05:19] <Chillum> I don't know, you may be the first to publish such data
[01:07:01] <Casper> jtag is normally not left enabled once the product is done manufacturing, so not an important factor to consider
[01:08:46] <Chillum> I can see debugging ruining power saving optimizations
[01:42:51] <tavish> something around 3mA it seems
[02:21:28] <daey> looking through the gcc avr headerfiles, what exactly does _SFR_IO8 mean? #define GPIOR2 _SFR_IO8(0x1A)
[02:27:26] <tavish> 8 bit register maybe, #define _SFR_IO8(io_addr) ((io_addr) + __SFR_OFFSET)
[02:34:15] <daey> tavish: but a DDRX = 0x00; translates to something like *uint8pointer = 0x00 ? right?
[02:40:09] <jsoft> So where are the things witht he stuff
[02:40:56] <_ami_> daey: better to learn ASM though. it gives you clearer picture.
[02:41:19] <_ami_> btw, to your question:
[02:41:50] <_ami_> .equ DDRB = 0x1a
[02:41:59] <_ami_> ldi r16, 0x01
[02:42:09] <_ami_> out DDRB, r16
[02:42:38] <_ami_> in AVR, DDR*/PORT*/SPL/SPH are treated like port
[02:43:52] <_ami_> ports*
[02:52:06] <daey> _ami_: but a port is just a register, isnt it?
[02:52:29] <_ami_> it is a register which addressed is mapped.
[02:52:33] <daey> y
[02:52:44] <_ami_> its a DMA
[02:52:56] <_ami_> you get direct access which is a nice thing IMHO
[02:53:19] <_ami_> daey: i was talkign abt how its done in AVR asm.
[02:53:37] <daey> and something like this should work then: uint_8t *addresspointer; addresspointer = 'mapped register address 0x1234'; *addresspointer = 0xff;
[02:53:40] <_ami_> in C, its just a ptr which value can be changed,
[02:53:56] <_ami_> yeah, indeed. it should work.
[03:16:54] <daey> tavish: how does this define make any sense? #define _SFR_MEM8(mem_addr) (mem_addr).
[03:17:44] <daey> or is it supposed to be a readability thing?
[03:32:43] <Jartza> hello
[03:44:19] <_ami_> Jartza: yo
[03:45:12] <_ami_> daey: no
[03:45:37] <Jartza> yo yo
[03:45:40] <Jartza> sup?
[03:46:04] <_ami_> __SFR_OFFSET is required for compiler to know that its a register I/O so that it will generate out 0x11, r16
[03:46:36] <_ami_> if you don't add __SFR_OFFSET, compiler will think as data section memory
[03:46:42] <_ami_> so it will add sts
[03:46:46] <_ami_> there is a difference.
[03:47:04] <_ami_> Jartza: not much, whats up with you? long time, no see.!
[03:47:36] <_ami_> daey: that is why i said initially, you do OUT on registers
[03:48:26] <_ami_> C is just a high level language over asm. its compiler job to generate correct code.
[03:48:34] <_ami_> one example.
[03:49:37] <_ami_> #define MEM(io_addr) (*(volatile uint8_t *)(io_addr))
[03:49:38] <_ami_> #define MY_IO8(io_addr) MEM((io_addr) + __SFR_OFFSET )
[03:49:38] <_ami_> #define MY_DDRD MY_IO8(0x11)
[03:49:38] <_ami_> int main(void)
[03:49:38] <_ami_> {
[03:49:38] <_ami_> DDRD = 1;
[03:49:38] <_ami_> MY_DDRD = 2;
[03:49:39] <_ami_> return 0;
[03:49:39] <_ami_> }
[03:49:57] <_ami_> 0x00000066 <+0>: ldi r24, 0x01 ; 1
[03:49:58] <_ami_> 0x00000068 <+2>: out 0x11, r24 ; 17
[03:49:58] <_ami_> 0x0000006a <+4>: ldi r24, 0x02 ; 2
[03:49:58] <_ami_> 0x0000006c <+6>: out 0x11, r24 ; 17
[03:50:15] <_ami_> you can see same instruction code in both cases.
[03:50:46] <_ami_> so you need to have __SFR_OFFSET to ask compiler to generate register memory related code.
[03:51:16] <_ami_> basically (mem_addr + __SFR_OFFSET) ---> register memory --> OUT
[03:54:53] <Jartza> _ami_: I've been assembling my second 3D-printer :)
[03:54:57] <Jartza> it's gonna be HUGE
[03:55:03] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxSjNhNktDcW9HMEk/view
[03:55:30] <_ami_> Jartza: wow! man.
[03:55:49] <Jartza> the heatbed is like 400x250mm :D
[03:56:03] <Jartza> my first printer is 200x200x200mm
[03:56:22] <_ami_> Jartza: you should write a blog on ' how to make 3d printers' :) making 3d printers is my ultimate goal.. i think it will take more learning for me to achieve that.
[03:57:00] <Jartza> well this is just a kit
[03:57:01] <_ami_> Jartza: can u share that link on github? can't access google drive from work.
[03:57:28] <Jartza> but I'm also at the same time being part of the manufacturer's betatest/protoyping team
[03:58:06] <Jartza> _ami_:
https://i.imgur.com/MMyNHOs.png
[03:58:08] <Jartza> can you open that?
[03:58:21] <_ami_> yeah.
[03:59:21] <_ami_> so is it ready to use? looks like lots of other parts to assemble.
[04:00:40] <_ami_> daey: did my explanation make sense? MEM vs REG?
[04:01:21] <Jartza> hehe, nope, not ready yet
[04:04:06] <_ami_> daey:
http://www.nongnu.org/avr-libc/user-manual/group__avr__sfr__notes.html more details abt what i said.
[04:06:20] <_ami_> Macros starts with __ are actually for compilers.
[04:06:42] <_ami_> actually __ should be at both ends.
[04:06:58] <_ami_> although its different in case of avr-gcc.
[04:08:19] <_ami_> Jartza: you worked on CAN buses before?
[04:08:45] <_ami_> ODB2 port in vehicles
[04:23:39] <Jartza> I've worked with ALDL, lol :)
[04:23:47] <Jartza> and well. yea, CAN, but about 10 years ago
[04:23:49] <Jartza> and LonWorks
[04:27:15] <daey> _ami_: im just wondering why not #define MY_IO8(io_addr) MEM((*(volatile uint8_t*)(io_addr))+__SFR_OFFSET)
[04:27:44] <daey> MEM(io_addr) looks to me like it converts a long phrase into its own argument
[04:28:25] <daey> kind of like #define hello hello
[04:28:57] <_ami_> daey: As i said, out asm instruction is used to access i/o registers so for accessing IO, you need to add some hints to compiler to know abt it.
[04:29:05] <_ami_> that is why __SFR_OFFSET
[04:29:22] <daey> iv no problem with the SFR_OFFSET
[04:29:52] <_ami_> volatile uint8_t *x = 0x11; *(x + __SFR_OFFSET) = 1; === DDRB = 1;
[04:29:59] <daey> the( io_addr) voodoo is what i dont get. the whole MEM(io_addr) define looks useless to me
[04:30:22] <_ami_> MEM(io_addr) --> sts
[04:30:28] <daey> sts?
[04:30:29] <_ami_> IO(io_addr) --> out
[04:30:44] <_ami_> daey: sts is an avr asm instruction
[04:30:47] <_ami_> google abt it.
[04:31:51] <daey> ok
[04:34:15] <daey> _ami_: 'macros that start with __ are for compilers' arent all #defines resolved by the preprocessor? i thought you need typedef for that?
[04:34:48] <_ami_> daey: ?
[04:36:01] <daey> ?
[04:36:53] <Jartza> how about just using good assembler instead of gnu? ;)
[04:36:55] <Jartza> like, avra
[04:40:52] <_ami_> daey: ok, i might be wrong abt this hint thing.
[04:41:15] <_ami_> int8_t *x = 0x11;
[04:41:15] <_ami_> *(x + 0x20) = 3;
[04:41:28] <_ami_> 0x0000006e <+8>: ldi r24, 0x03 ; 3
[04:41:28] <_ami_> 0x00000070 <+10>: out 0x11, r24 ; 17
[04:41:37] <_ami_> so the correct offset is important.
[04:42:14] <_ami_> like for m16a, avr-gcc magically knows to create out instruction.
[04:43:01] <_ami_> For, int8_t *x = 0x11;
[04:43:01] <_ami_> *(x + 0x00) = 3;
[04:43:10] <_ami_> 0x0000006e <+8>: ldi r24, 0x03 ; 3
[04:43:11] <_ami_> 0x00000070 <+10>: sts 0x0011, r24
[04:44:14] <_ami_> so compiler know the I/O address location. so whenever someone wrote code to access that memory region, it does generate OUT.
[04:45:08] <_ami_> indeed, it is the case.
[04:46:15] <_ami_> int8_t *x = 0x11;
[04:46:16] <_ami_> x+= 0x19;
[04:46:16] <_ami_> *(x + 0x1) = 3;
[04:46:32] <_ami_> 0x0000006e <+8>: ldi r24, 0x03 ; 3
[04:46:33] <_ami_> 0x00000070 <+10>: out 0x0b, r24 ; 11
[11:30:56] <_ami_> just wondering how we enable pullup resistor in rpi2 GPIOs? Is it similar to AVR? gpio_direction_input(pin); gpio_set_value(pin, 1);
[11:33:19] <bss36504> _ami_:
http://raspi.tv/2013/rpi-gpio-basics-6-using-inputs-and-outputs-together-with-rpi-gpio-pull-ups-and-pull-downs
[11:35:31] <_ami_> bss36504: i am writing a gpio linux kerne module.. so i probably need to check python code for GPIO.setup(25, GPIO.IN, pull_up_down=GPIO.PUD_DOWN)
[11:35:45] <_ami_> i am thinking it should be similar to AVR
[11:36:51] <bss36504> Why would you think that?
[11:37:01] <_ami_> i am not sure.. actually.
[11:37:08] <_ami_> it just a guess
[11:37:09] <bss36504> I'm not saying it's right or wrong, it just doesnt make sense to assume that
[11:37:23] <sabor> _ami_: or look what is creating these gpio file sin /proc
[11:37:55] <bss36504> Even the xmega has a different scheme, the AVR is just another unique processor in an ocean of GPIO strategies
[11:38:28] <_ami_> ah,
[11:38:35] <_ami_> did not know that.
[11:39:11] <_ami_> i get it.. its chip dependent
[11:39:14] <_ami_> hmm
[11:40:07] <bss36504> I haven't messed with the RPi enough to even have used GPIO, so unfortunately I can't help more. I would hope it's officially documented somewhere, but who knows
[11:44:40] <_ami_> bss36504: i am guessing that its chip dependent and driver should expose it. there should be some sys fs file in /sys/class/gpio/gpio<N>/<pulldown>
[11:45:06] <bss36504> Wait, don't they all use the same basic SoC?
[11:45:16] <_ami_> need to boot rpi
[11:45:31] <_ami_> bss36504: no,
[11:45:34] <_ami_> linux-4.4.0/drivers/gpio/
[11:45:34] <bss36504> Not that it really matters, there is a low level driver in place for you somewhere that controls the hardware, it's not like you're going to be writing to actual registers.
[11:46:35] <_ami_> bss36504: there is a uniformity in exposing the interface to user like value, direction.. etcs
[11:46:50] <_ami_> but i did not see pulldown and pullups file yet..
[11:46:54] <_ami_> need to verify..
[11:46:56] <_ami_> one min.
[11:47:04] <bss36504> Hmm, that is perplexing if it's not there
[11:53:30] <Plugh> I popped in here thinking to ask a question while I'm developing a program for an AVR but my question was really a Pi related one. Interesting to see someone else discussing something that appears Pi related.
[11:53:53] <bss36504> yeah, it's not a very strict channel
[11:54:08] <Plugh> yea, happens with IRC channels.
[11:54:54] <Plugh> I'm using my Pi as a platform for doing development for AVR microcontrollers.
[11:55:55] <_ami_> Plugh: good to know that.
[11:56:10] <_ami_> bss36504: i checked and find none of file related to pullup/down
[11:56:19] <bss36504> Hmm, interesting.
[11:56:47] <Plugh> _ami_: I just got here a few minutes ago. Not sure if I can help but I didn't see the original question.
[11:57:12] <_ami_> although searching "pulldown" in drivers/gpio/* results some results.
[11:57:26] <_ami_> seems like few chips support it
[11:57:38] <_ami_> gpio-twl4030.c: ret = gpio_twl4030_pulls(pdata->pullups, pdata->pulldowns);
[11:58:33] <_ami_> Plugh: i was wondering how we enable pullups in rpi2 gpio pins
[11:58:50] <Plugh> ok.
[11:58:52] <_ami_> Plugh: i was more interested in knowing how we do that in drivers
[12:00:47] <Plugh> _ami_: What programming language are you using?
[12:00:54] <_ami_> Plugh: C
[12:00:58] <_ami_> linux kernel module.
[12:01:02] <_ami_> for arm.
[12:01:12] <Plugh> ok. I just saw the info on using pullups for Python using Pi.GPIO
[12:01:28] <_ami_> yeah, bss36504 already told me abt that.
[12:01:44] <_ami_> but i was more interested in knowing how it is done.
[12:02:09] <_ami_> its kind of more of setting a pin pullup high via shell.
[12:02:36] <_ami_> there should be some sysfs file in /sys/class/gpio/gpio<N>/ for doing it.
[12:02:56] <Plugh> hm... I found a page about doing it in C but it uses wiringPi so that may not help ->
https://learn.sparkfun.com/tutorials/raspberry-gpio
[12:03:24] <_ami_> http://raspberrypi.stackexchange.com/questions/36580/set-pullup-from-command-line
[12:03:51] <_ami_> there is nothing like doing pullups via sysfs
[12:04:01] <_ami_> so there is no generic interface for doing it.
[12:05:34] <_ami_> i just wonder how could linux kernel miss that.. pullups are like basic thing. why do they left it unimplemented? must be a reason.
[12:05:45] <Plugh> I wonder if there might be an ioctl for it.
[12:06:59] <_ami_> Plugh: yes. it should be. may be py libs are using it.
[12:07:12] <_ami_> need to read the py lib code then.
[12:07:16] <_ami_> although i am reading
https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
[12:07:29] <_ami_> check page 101
[12:08:01] <Plugh> You could also ask on #raspberrypi or #raspberrypi-dev channels. :) They might have a better idea. I could keep looking. I don't need to know but I would also be interested to know.
[12:10:29] <Plugh> I just downloaded the source for wiringPi. I'll do some more digging later. Right now I need to break for lunch.
[12:11:15] <_ami_> Plugh: ok, i will also check it after dinner. :)
[12:11:23] <Plugh> :)
[12:11:24] <Plugh> bbl
[12:57:57] <Plugh> _ami_: I haven't followed the code fully but in wiringPi you can look at gpio/gpio.c and wiringPi/wiringPi.c to see see how they pull ups/downs are handled. wiringPi.c is the key file as it references the PUDCLK* stuff mentioned on page 101 of that PDF.
[13:11:54] <_ami_> Plugh: yeah
[13:12:02] <_ami_> i read the code of wiringPi
[13:12:07] <_ami_> and understood.
[13:50:40] <Plugh> eszett: Hm... are you following me? ;)
[14:29:03] <twnqx> eszett: i didn't know you named yourself after some sweets
[14:52:24] <Plugh> it is a sweet? When I look up the name I find it is the German letter ß
[15:24:48] <carabia> I think it's the hitl... I mean german double-s
[15:26:07] <Plugh> :)
[15:26:34] <carabia> ...rather than candy
[15:27:39] <carabia> I studied hitler-sprechen in grade school for a few years, nothing really stuck though.
[15:28:23] <carabia> Apart from developing the concept that the only possible use-case for said language was to command troops and drive tanks. I wonder how they managed to lose two times...
[15:28:47] <carabia> I mean, it excelled in that.
[22:50:20] <owl-v-> can I use USART as a SPI ?
[22:59:15] <carabia> owl-v-: yeah, there's an application note also, not sure if this is true for all devices
[22:59:56] <carabia> i've done it on a few different ones.
