#avr Logs
Nov 23 2017
#avr Calendar
02:06 AM polprog: Ameisen: if you are into history, you'll like this documentary: http://www.imdb.com/title/tt4938484/
08:32 AM rue_bed: use the inta to control the power via a P channel mosfet
09:08 AM rue_mohr: then the pullup can be 10M if you want
09:09 AM rue_mohr: wakes up the avr by turning it on, it holds itself on, does its work, and turns its power off
11:29 AM polprog: https://puu.sh/ys5wE/bd30591805.png
11:29 AM polprog: this is crammed
11:31 AM nuxil: hi
11:31 AM nuxil: so youre done redesigning it ?
11:38 AM polprog: yeah
11:39 AM nuxil: so 2 new weeks wait time before you get it ? :p
11:39 AM polprog: i had to replace the 4x 0402 resistor packs with 0603 resistors and change via sizes
11:39 AM polprog: it was pretty demanding
11:40 AM polprog: my millhouse takes a week to make them
11:40 AM polprog: including postage if i select express shipping,
11:40 AM nuxil: how much do you pay for a pcb like that ?
11:40 AM nuxil: if i may ask
11:40 AM polprog: i will get 3 or 4 copies under 16 eur
11:41 AM polprog: 70 pln
11:41 AM nuxil: o.O thats not much
12:23 PM daey: if i have a pointer char *ptr = 0x00; does it point to the first address in the flash or to the first byte in the SRAM?
12:23 PM polprog: pointers point to ram
12:24 PM daey: ok thats what i thought. but what about function pointers?
12:24 PM polprog: hmm
12:24 PM daey: shouldnt the function be in the flash?
12:24 PM polprog: i forgot function ptrs exist
12:24 PM polprog: im hoining the question then ;)
12:24 PM polprog: joining*
12:25 PM daey: :3
12:25 PM daey: from my understanding flash and sram do not share the same address space on atmegas, correct?
12:26 PM polprog: yes they have separate opcodes to interface
01:14 PM fooman2011: Hello. I would like to connect my Attiny2313 to the DS1337 RTC. In the DS1337 datasheet (http://docs-europe.electrocomponents.com/webdocs/124d/0900766b8124d616.pdf) it says that INTA pin must be connected to the microcontroller pin thought a pullup resistor. Currently the whole circuit is consuming less than 500nA. Adding a pullup will consume at least 100µA. Is there a way to avoid this ?
01:15 PM polprog: no, it's open drain, there needs to be a pullup, you can use attinys internal pullup though
01:16 PM polprog: if you set DDR bit to 0 and PORT bit to 1 then you have an input with a pullup
01:16 PM fooman2011: eah ok but I have "a lot" of current consumption because of this pullup
01:17 PM polprog: do you know how open drain outputs work?
01:18 PM fooman2011: polprog: I'm not an expert, but floating line must be connected to pullup to set a defined logic state.
01:19 PM polprog: yes, that's right
01:19 PM polprog: you are already using the builtin pullup?
01:22 PM fooman2011: "builtin pullup", you mean the internal attiny pullup ?
01:22 PM daey: fooman2011: 100uA is too much? are you sure an attiny is up to the task at all? you could use an external pullup with a higher value
01:22 PM daey: yeah
01:22 PM polprog: yeah i mean the internal one
01:23 PM polprog: higher value pullup would work
01:23 PM fooman2011: currently all is only theory, I have nothing to test
01:23 PM polprog: i had some appnote on calculating the best pullup
01:23 PM fooman2011: I have computed that the max pullup value is 150K
01:23 PM daey: honestly if you care about the energy wasted by a pullup resistor then a uC isnt going to cut it
01:24 PM polprog: fooman2011: http://www.ti.com/lit/an/slva485/slva485.pdf
01:24 PM fooman2011: polprog: yeah I used this doc to calcul
01:24 PM polprog: and what did you calculate out
01:25 PM fooman2011: The pullup ill consumes current only when the DS1337 INTA is floating or only when the INTA is low ?
01:25 PM polprog: when it's low
01:25 PM fooman2011: ill => will
01:25 PM fooman2011: oh so I missed something
01:25 PM polprog: in fact when the line is leaking which is always
01:25 PM polprog: it's more complicated, let me explain
01:25 PM daey: when ever theres a voltage difference between V_cc and your pin
01:26 PM polprog: if the line is low (pulled by rtc) then the current is big (Vcc / R). if the line is not pulled low, then the current is the sum of all leakage currents
01:26 PM daey: you could also work with a pull down resistor. then you would lose energy whenever the line is high
01:27 PM polprog: it's open drain
01:27 PM polprog: so that would need to be some other rtc? i dunno
01:29 PM fooman2011: mmmh ok. I was thinking that pullup is "the way for the current when there is no other way to go"
01:30 PM polprog: if avrs line is input, and the open drain is not pulling down (ie. connecting one end of the line to ground) then the current really has no way to go. in theory with perfect elements theres zero current going there, IRL there's leakage
01:30 PM daey: lel. i just realized im using my atmegas totally wrong :D
01:30 PM polprog: and you cant fight the laws of physics
01:30 PM polprog: :D
01:30 PM daey: im driving my testing led through the internal pullup :D
01:30 PM fooman2011: polprog: yeah ok I undertand now. Thanks very much for the explanation :)
01:31 PM polprog: np ;)
01:40 PM daey: my god...bitcoin got nothign on ram prices O.O
01:41 PM daey: i should have invested in ddr4
01:42 PM polprog: daey: the internal pullups are meant for driving small loads like a led or logic pins
01:42 PM polprog: i think it's safe to say some older TTL logic input pin can take as much as a small led nowadays ?
01:42 PM daey: yeah its just i never thought of it. i thought high means 'power on' :P
01:43 PM polprog: halfbridge circuit (enableable pullup and pulldown) is standard in CMOS circuits
01:43 PM daey: always wondered why the current drain doesnt overload the pin though. but.. never question a working solution ^.^
01:44 PM polprog: http://modularcircuits.tantosonline.com/blog/wp-content/uploads/2011/11/image21.png
01:44 PM daey: yeah that was basically what i thought how it would work. *plus an additional pullup for when its working as input*
01:45 PM polprog: theres everything drawn out in the datsheet, it was an interesting read for me
01:45 PM polprog: learnt a lot about cmos
01:49 PM fooman2011: I have another question.
01:49 PM fooman2011: I have an attiny and a device connected to using i2c (SDA + SCL) and I use the internal attiny pullups for SDA and SCL. What is the best way to totally cut off the I2C and pullup consumption? Maybe set the SDA and SCL pins of the microcontroller to "input" and deactivate internal pullup ?
01:49 PM polprog: yeah, but that can cause noise to aggregate on the lines
01:49 PM polprog: and glitch the slave
01:50 PM polprog: i would cut power to the slave with a mosfet additionally to your idea so the slave wont get floating lines on it's bus
01:51 PM polprog: at some point you reach the situation where battery self discharge rate will make it drain faster than your thingy
01:51 PM fooman2011: Ok I thought about another solution. DOn't use internal pullup. Use another attiny pin as outpu HIGH and link it to SDA and SCL throught external pullups. So when I want to cut off I2C I put this pin to LOW
01:51 PM polprog: I2C is idle high
01:51 PM polprog: it's an open drain bus
01:52 PM fooman2011: yes
01:55 PM fooman2011: polprog: I mean something like this: https://pasteboard.co/GV1nvEF.png
01:56 PM polprog: yeah that makes sense
01:56 PM fooman2011: pin 17 and 19 pullup NOT activated. pin 16 output HIGH when I want to use I2C and LOW when I don't want
01:56 PM polprog: but as i said i dont know how will your slave react to LOW at both lines
01:56 PM polprog: it may lock up - worst case scenario
01:56 PM polprog: so id do
01:56 PM polprog: cut power to slave - i2c pullups off
01:57 PM polprog: and then first enable i2c pullups and the power the slave
01:58 PM polprog: also i can see you are using eagle ?
01:58 PM fooman2011: Yes I'm trying to learn
01:58 PM polprog: got the free edition?
01:58 PM fooman2011: yes
01:59 PM fooman2011: my pcb must be small :p
01:59 PM polprog: i started with it too but i got put off by the size limit
01:59 PM polprog: but it's good to know more than one tool
01:59 PM fooman2011: What tool are you using ?
01:59 PM polprog: i also watched altium tutorials but eventually used kicad at work cos they probably didnt have a spare licence. im using kicad now
02:00 PM polprog: i guess i can use altium
02:00 PM polprog: but goddamnit altium's schematics makey my eyes bleed
02:00 PM fooman2011: lol
02:00 PM polprog: the color scheme, the *serif* font, please no
02:02 PM fooman2011: :)
02:02 PM polprog: the best i found so far was to rip the eagle library converted to kicad
02:02 PM polprog: it's awesome
02:02 PM polprog: win-win situation :D
02:03 PM fooman2011: Kicad or Eagle or other tools I have tried. All have interface from another age...
02:03 PM fooman2011: egle lib to kicad ? intersting
02:04 PM fooman2011: Kicad has an good auto router ?
02:04 PM polprog: it does not
02:04 PM fooman2011: lol
02:04 PM polprog: but the more pcbs ive done the more an autorouter looks like a gimmick for me
02:04 PM polprog: kicad has push and shove router
02:05 PM fooman2011: well ok
02:05 PM polprog: which means that you tell the computer what route the trace should run and kicad moves all the other traces away and makes it
02:05 PM polprog: this is the best so far
02:05 PM polprog: it can be also set to different modes
02:06 PM polprog: if you really really want an autorouter it uses a 3rd part router
02:06 PM polprog: it exports a file for FreeRouting router, which used to be online, but it's down and since then available as a .jar program
02:07 PM polprog: but you will be really disappointed
02:07 PM polprog: never trust the autorouter
02:07 PM polprog: the pcb i posted earlier
02:07 PM polprog: was entirely routed by hand with push and shove router
02:07 PM polprog: that why it has those nice, clean and concise trace busses
02:08 PM polprog: autorouter generally makes the traces a huge mess, plus they dont work well on single sided boards
02:08 PM fooman2011: yeah sure it is better when it's manually done
02:08 PM polprog: all people i know do it manually
02:08 PM polprog: gtg, supper
02:08 PM polprog: /away supper
02:08 PM polprog: ...
02:09 PM fooman2011: ok thanks for your help
02:09 PM polprog: ;)
02:52 PM polprog: i set up a git repository in this project's root tree
02:53 PM polprog: so far it's working well and i have history tracking
02:53 PM polprog: and i learnt a bit of git on the way
03:05 PM nuxil: <daey> if i have a pointer char *ptr = 0x00 , i didnt see anyone mention this. but iirc you need to use PROGMEM to store in the flash.
03:06 PM hetii: Hi :)
03:06 PM nuxil: hello
03:07 PM nuxil: uint8_t foobar PROGMEM = 0;
03:07 PM hetii: I have a value like 0b1011, what Is the most efficient way to reverse bit so have a value 0b1101
03:09 PM nuxil: o.O
03:09 PM nuxil: xor
03:10 PM nuxil: i mean
03:10 PM nuxil: like var = ~var
03:12 PM hetii: hmm
03:12 PM hetii: wonder why python give me such output: bin(~0b1011) -> '-0b1100'
03:13 PM nuxil: wrong channnel :p
03:13 PM LeoNerd: Twos-complement
03:13 PM polprog: i remember in assembly theres com and neg
03:14 PM polprog: and i cant remember which is which ;)
03:14 PM nuxil: hetii, do you want to reverse the bin sting or flip bitvalues ?
03:14 PM polprog: lol for the past 3 or so hours someone on verilog channel is having a long political monologue
03:16 PM hetii: nuxil, I have 12bit value that I need to split it to get first 8 bits and store that in one of the port and the rest of the 4 bits reverse and store on other port.
03:16 PM LeoNerd: Bitshifts by 8 are efficient via gcc because they're just register accesses
03:17 PM polprog: PORTA = val >> 4; portb = val & 0b00001111;
03:17 PM nuxil: hetii, listen to that guy :D
03:17 PM Ameisen: mm
03:17 PM Ameisen: just a warning for y'all
03:17 PM polprog: bitshift by 4 was also easy iirc
03:17 PM Ameisen: bitshifting 8-bit values in g++ has a bug.
03:17 PM Ameisen: I reported it, hasn't been fixed.
03:17 PM nuxil: oh
03:17 PM nuxil: tell
03:17 PM polprog: Ameisen once posted a link to bitshifts
03:17 PM polprog: 4 bit was swap and and iirc
03:18 PM Ameisen: polprog - aye
03:18 PM Ameisen: I made a document with my best found shifts
03:18 PM Ameisen: they aren't all optimal
03:18 PM Ameisen: they were what was obvious to me
03:18 PM Ameisen: gcc has better ones in most cases
03:18 PM polprog: Ameisen: you looked at the documentary i sent you?
03:18 PM polprog: ;)
03:18 PM Ameisen: polprog - not yet
03:18 PM Ameisen: regive it
03:18 PM polprog: http://www.imdb.com/title/tt4938484/
03:18 PM Ameisen: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82658
03:19 PM Ameisen: there you go
03:19 PM Ameisen: the g++ has a universal bug where the integer promotion rules are being held too strongly, and not being reduced in the middle end
03:19 PM Ameisen: this causes really weird shift code (very suboptimal) for 8-bit values in g++
03:19 PM Ameisen: it's a universal bug, but only manifests as a problem in AVR
03:19 PM Ameisen: though it does change codegen in x86 (but not negatively)
03:19 PM hetii: nuxil, here is my circuit: https://snag.gy/6t0Dpo.jpg
03:19 PM nuxil: Ameisen, Oh its C++ issue.
03:20 PM nuxil: who cares :p
03:20 PM nuxil: just kidding :p
03:20 PM hetii: so as we can see after port PC7 the next one to address is PA7
03:20 PM Ameisen: I certainly care :|
03:20 PM Ameisen: if I get a chance, I will try to fix it
03:20 PM Ameisen: but my time is being spent on my firmware and avr-llvm
03:21 PM Ameisen: Actually spending the day (and after meeting up with family - I hate thanksgiving and all holidays) doing cleanup in my codebase
03:21 PM polprog: hetii: is it some kind of a dac?
03:21 PM Ameisen: finally wrote macros.hpp
03:21 PM hetii: polprog, yes
03:21 PM polprog: yay, i analyzed a circuit \o/
03:22 PM Ameisen: https://pastebin.com/PdFgvmjz
03:27 PM Ameisen: I don't think I perform many shifts on 8-bit values explicitly
03:27 PM Ameisen: most of my shifts are actually in the fixed-point lib, and I don't think I ever use 8-bit fixed point values
03:27 PM Ameisen: Any of you guys know of a good software floating-point library that provides float16/float24?
03:27 PM Ameisen: that's fast?
03:28 PM Ameisen: and, ideally, supports fast-math
03:28 PM daey: on a chip without hardware fp support?
03:29 PM Ameisen: yes
03:29 PM Ameisen: on a chip with it, no reason to bother
03:29 PM Ameisen: without it, fp16/24 would be smaller and faster
03:29 PM Ameisen: same reason I've been changing certain types in this codebase to __int24/__uint24
03:29 PM Ameisen: which gcc and g++ define for AVR, btw
03:29 PM Ameisen: if you weren't aware.
03:30 PM hetii: polprog, btw your idea with portb = val & 0b00001111; is wrong cause it return first lower bytes and I need address four upper bits so from Pa4 to PA7
03:30 PM Ameisen: no reason for it not to, if you think about it
03:30 PM Ameisen: I really wish it defined __int48/__uint48 as well
03:30 PM polprog: hetii: but the general idea is good i think
03:30 PM Ameisen: since there are a _few_ areas in this codebase that it defaults to 64-bit arithmetic (for some advanced motion derivation)
03:30 PM Ameisen: where 48-bit arithmetic would suffice
03:30 PM polprog: whatever
03:30 PM Ameisen: I might be able to get away with defining a bitfield type as something like int64_t val : 48
03:30 PM Ameisen: but need to find a way for it to think it only needs to be 48 bits wide
03:31 PM Ameisen: and not 64-bits
03:31 PM Ameisen: :|
03:31 PM Ameisen: since I build without strict aliasing rules... might be able to get away with some casts?
03:31 PM Ameisen: I always disable strict aliasing, and use __restrict__ judiciously
03:31 PM Ameisen: gives me more control over the code, and __restrict__ tends to produce better code anyways as it is more restrictive than strict aliasing
03:32 PM Ameisen: and lets me type pun when I want
03:34 PM hetii: polprog, general yes, I had the same but stock on changing it to upper part and reverse ordering
03:34 PM polprog: stock?
03:36 PM hetii: *stuck
03:36 PM hetii: gosh I`m tired probably should go to sleep..
03:37 PM polprog: write it out on paper
03:37 PM polprog: first 8 bits meaning the first 8 lsb?
03:38 PM polprog: if so then you should make porta = val & 0xFF; portb =(val >> 8) &0x0F;
03:38 PM Ameisen: is hetii doing something with shifting or something
03:38 PM Ameisen: don't forget that AVR also has instructions to clear/toggle/set bits in registers
03:38 PM Ameisen: though you cannot use them in certain cases (where a bit might be shared with another byte's address - described in the atmel datasheets)
03:39 PM Ameisen: AVR handles those situations very strangely.
03:39 PM Ameisen: I'm still not used to architectures where registers are reflected as addresses
03:42 PM daey: Ameisen: you mean the read the Lower byte first then the higher scenarios?
03:50 PM hetii: ok I end for today, will back tommorow with a fresh mind.
03:50 PM hetii: Best regards.
03:50 PM Ameisen: well
03:50 PM Ameisen: I'm unsure what you're doing
03:50 PM Ameisen: either way, need to shower and go to family thanksgiving thing
03:50 PM * Ameisen dislikes social gatherings
03:50 PM Ameisen: as most programmers, I'm asocial
03:51 PM daey: or maybe you simply dislike forced meetings with people who dont share your interests :P
03:52 PM daey: *like everyone else*
04:21 PM Ameisen: daey - high functionings tend to dislike social interaction overall
07:22 PM rue_mohr: there is nothing quite like sitting alone in the corner of a room of people having fun, trying to stay entertained.
07:28 PM Thrashbarg: yup...
11:39 PM day__ is now known as daey
11:41 PM kl0wn is now known as _kl0wn