#avr Logs
Jul 25 2017
#avr Calendar
12:15 AM _ami_: Casper, ok.
12:33 AM day is now known as daey
01:10 AM Emil: _ami_: why would it
01:10 AM Emil: _ami_: rather disable them
01:10 AM Emil: you save moar power
01:12 AM Emil: By disabling
01:12 AM Emil: I mean the pins
01:14 AM _ami_: Emil, disabling means? lowering the pin?
01:14 AM _ami_: Emil, i read at AVR DS that its better to enable internal pullups on unconnected pin to save power.
01:15 AM _ami_: although it says that have a definite value on unused pins to save more power.
01:16 AM _ami_: http://www.atmel.com/Images/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_Datasheet.pdf
01:16 AM _ami_: 18.2.6
01:18 AM Emil: yeah it's true
01:18 AM Emil: but you can save wven moar by disabling the pins
01:18 AM Emil: completely
01:19 AM Emil: DIDR iirc was the register name
01:19 AM Emil: But yeah if you dont want to disable them then pullups do save energy
01:20 AM Emil: because otherwise the pins float which might trigger other circuitey
01:25 AM _ami_: i think i would just enable internal pullups on unused pins when mcu starts.
01:25 AM _ami_: it would be interesting to actually do some case study on power consumption
01:29 AM polprog: thats a useful remark
01:29 AM polprog: i have to check that
01:31 AM _ami_: Emil, i was looking for AVR DS to have information on sleep modes + all peripherals enabled/disabled.
01:32 AM _ami_: polprog, i noticed that stm32f103 DS has clearly have detail information on current consumption in sleep modes + all peripherals enabled/disabled.
01:37 AM Emil: _ami_: you can disable pins
01:38 AM _ami_: Emil, whats the relative definition of a disabled pin? set PIN to OUTPUT and then set pin state to low? or enable input and set pin state to high (enabling internal pullup)?
01:40 AM Emil: DIDR
01:40 AM Emil: Oh it was just for ADC
01:42 AM _ami_: i have already disabled ADC at the beginning so DIDR does not matter to me
01:42 AM _ami_: power_adc_disable();
01:43 AM _ami_: basically i do in reverse. power_all_disable(); power_whatuneed_enable();
02:08 AM Emil: But iirc there's some register to disable gpio on other pins, too
02:11 AM _ami_: https://electronics.stackexchange.com/questions/43460/how-should-unused-i-o-pins-be-configured-on-atmega328p-for-lowest-power-consumpt
02:13 AM _ami_: i think it would be better to take atmel device and enable internal pullups on unused pins.
02:20 AM Emil: Apprently not
02:20 AM Emil: _ami_: yes
02:20 AM Emil: enabling internal pullups is the best if you have nothing connected to those pins
02:20 AM Emil: _ami_: but you can actually also have external pulldowns
02:20 AM Emil: and whatnot
02:21 AM Emil: as long as the voltage on the pins is not close to vcc/2
02:22 AM Haohmaru: on xmega you can do a bunch of more stuff.. like set the pin to output 0 without actually being able to sink much current
02:22 AM Haohmaru: or output high without being able to drain much
02:26 AM Haohmaru: speaking of pins.. after a reset, the pins are usually all set to a hi-z state afaik, and you should initialize them in main() soon-ish
02:27 AM Haohmaru: however, if you have a bootloader, then when the bootloader decides to stick around for a significantly longer time - it either has to do that initialization, or you may get some weird behaviour with the whole device
02:28 AM Haohmaru: but i don't really want my bootloader to have to be modified for each device type
02:28 AM Haohmaru: so i'm thinking.. could the bootloader.. call a function from the firmware, which just does the initial pin initialization?
02:47 AM Casper: now.... avr or esp...
02:48 AM Emil: Casper: for what
02:48 AM Casper: the esp have wifi... the avr may be more reliable...
02:48 AM Emil: Casper: the avr is absolutely more reliable
02:48 AM Casper: fridge thermostat and fan control, need 1 analog input for the ntc
02:48 AM Emil: Casper: But if you need wifi and not a lot of pins
02:48 AM Haohmaru: doesn't the esp still have binary blobs?
02:48 AM Casper: the mechanic thermostat half failed
02:48 AM Emil: Casper: then you need an avr
02:48 AM Emil: Casper: the esp analog is like 6 bits
02:49 AM Casper: seriously????
02:49 AM Casper: wow, ok, avr it will be
02:49 AM Casper: beside, it will be damn simple for the code...
02:49 AM Emil: Oh wait
02:49 AM Emil: I was wrong
02:50 AM Emil: It's 10 bits
02:50 AM Emil: but it's only 0-1v
02:50 AM Casper: if temp > 4°C then turn on compressor. If temp < 2°C turn off compressor. If temp < 1°C turn off fan .... or something like that, not sure if I keep the useless freezer...
02:50 AM Casper: the voltage range is not important
02:50 AM Emil: Dunno where I got that shit resolution thing
02:51 AM Casper: I'll put a cap at the input anyway to kill all noise
02:51 AM * Haohmaru throws a bag of comparators at Casper
02:51 AM Casper: Haohmaru: I tought about it, but I will do it 'proprelly'
02:51 AM Casper: with the 3 minutes delay
02:51 AM Casper: if I can figure out how to do it of course :D
02:51 AM Casper: brb
02:52 AM Emil: Haohmaru: it has binary blobs
02:52 AM Emil: and you can't work around them
02:58 AM Casper: back
02:58 AM Casper: what I wonder is how I can make a power out delay of 3-4 minutes
02:59 AM _ami_: its just 0 to 1v for esp analogi
02:59 AM _ami_: analog*
02:59 AM Haohmaru: analog(ue)
02:59 AM Casper: 0-1V is just as good as 0-5V when you use ntc
03:00 AM * Haohmaru injects 1Vpp pink noise into Casper's circuit
03:01 AM Casper: symetrical around 0? or with DC offset?
03:02 AM Emil: Hm?
03:02 AM Emil: DC offset
03:02 AM Emil: If it was plus minus 1v
03:02 AM Emil: that'd be godsend
03:02 AM Haohmaru: do i look like a guy who has a nice source of symmetrical pink noise? ;P~
03:03 AM Emil: Pink Guy
03:12 AM Casper: I'm tempted to use an esp, because lua is easy
03:12 AM Emil: >lua
03:12 AM Emil: pls no
03:12 AM Casper: and could be fun to have wifi
03:12 AM Emil: Program it using the sharduino ide
03:12 AM Emil: You get a lot more frodoms
03:12 AM Casper: I know
03:13 AM Haohmaru: you are tempted to use an esp?
03:13 AM Haohmaru: don't do it, it's a sin
03:14 AM Haohmaru: don't listen to the devil!
03:15 AM Casper: I'm actually thinking to mix both instead
03:15 AM Casper: use an avr as the brain, and the esp as a simple relay
03:18 AM Emil: Casper: I do that all the time
03:18 AM Snert_ is now known as Snert
03:18 AM Casper: I'm just trying to figure out if I use 1 or 2 fans... :D
03:26 AM Casper: I'll go avr...
03:26 AM Casper: if I can fix my system...
05:36 AM day is now known as daey
06:45 AM Thrashbarg_ is now known as Thrashbarg
08:19 AM day is now known as daey
08:38 AM day is now known as daey
10:47 AM enhering: Emil?
10:47 AM enhering: cehteh: ?
10:47 AM enhering: Are you around?
10:47 AM enhering: What do you think about these connectors to join modules and backplane?
10:47 AM enhering: https://www.aliexpress.com/item/100pcs-2x8-P-16-Pin-2-0-mm-Pin-Header-Female-Dual-row-SMT-PCB-surface/32731095848.html?spm=2114.search0104.3.17.yBSVSo&ws_ab_test=searchweb0_0,searchweb201602_1_10152_10065_10151_10068_10173_10084_10083_10080_10082_10081_10110_10137_10111_10060_10112_10113_10155_10114_10154_438_10056_10055_10054_10310_10182_10059_100031_10099_10078_10079_10103_10073_10102_10052_10053_10142_10107_10050_10051-10050,searchweb201603_5,
10:47 AM enhering: ppcSwitch_5&btsid=d67955d1-3715-4082-99fc-efc7460bce55&algo_expid=504fd572-2aa7-4175-a218-02822e17962c-2&algo_pvid=504fd572-2aa7-4175-a218-02822e17962c
10:48 AM enhering: Ops
10:48 AM enhering: https://www.aliexpress.com/item/100pcs-2x8-P-16-Pin-2-0-mm-Pin-Header-Female-Dual-row-SMT-PCB-surface/32731095848.html
10:50 AM Emil: enhering: matey
10:50 AM Emil: enhering: I'm always here
10:50 AM enhering: :)
10:50 AM Emil: enhering: ask your question instead if we are here
10:50 AM enhering: Sorry for my ignorance, Emil. What does matey mean?
10:51 AM Emil: mate
10:51 AM Emil: friendo
10:51 AM Emil: friend
10:51 AM Emil: pal
10:51 AM enhering: hum.
10:51 AM Emil: buddy
10:51 AM enhering: Thanks!
10:51 AM polprog: enhering is just asking in TCP
10:51 AM Emil: np
10:51 AM Emil: polprog: lol
10:51 AM Emil: I would not use pin headers myseld
10:51 AM enhering: Thanks a lot for all your patience with my dumb questions
10:51 AM Emil: but those look di e
10:52 AM Emil: fine*
10:52 AM enhering: Those seem small enough. What would you use?
10:54 AM enhering: I selected these for the module side: https://www.aliexpress.com/item/100pcs-2x8-P-16-Pin-2-0-mm-Pin-Header-male-Dual-row-Straight-PCB-180/32718811539.html
10:54 AM enhering: one row on each pcb side.
10:57 AM enhering: This is the setup: https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller
11:36 AM Trieste_ is now known as Trieste
12:21 PM _abc_: Hello. I have C trouble with avr-libc: uint8_t i = X; eeprom_write_byte( (uint8_t *)(void *)(int)(i++), 0x12 ); <- without the ugly cast string I get errors from the compiler, specifically:
12:21 PM _abc_: passing argument 1 of '__eewr_byte_m328p' makes pointer from integer without a cast
12:22 PM _abc_: Is there a less evil way to write that? Afair (void *) casting is a magic catch all in C, it is the "common denominator" type.
12:23 PM Emil: Eh?
12:23 PM _abc_: If I leave out (void *) I get the same error as before, makes pointer from integer without a cast
12:24 PM _abc_: avr-libc says void eeprom_write_byte ( uint8_t ? __p, uint8_t __value );
12:24 PM _abc_: this is the proto. I have a uint8_t address in i, I need to call the function.
12:25 PM Emil: why not eeprom_write_byte((uint8_t *)i, value); i++;
12:29 PM _abc_: because that is precisely what fails with the error above, (i++) or i give the same error
12:29 PM _abc_: *the warning above. I have -Werror in CFLAGS so it's an error too. Not relevant.
12:47 PM antto: _abc_ static_cast<>()
01:00 PM _abc_: antto: hmm?
01:03 PM antto: that's what i do
01:04 PM antto: why do you have some many casts btw?
01:04 PM antto: * so many
01:05 PM antto: are you trying to write the value of X (uint8_t) onto address 0x12 in the eeprom?
01:11 PM _abc_: nope, other way around.
01:12 PM _abc_: __p is the pointer (address) __value is the value
01:12 PM _abc_: antto: If I omit any casts, the code does not compile without warnings
01:12 PM _abc_: <break>
01:13 PM antto: you want to write 0x12 to some address in the eeprom?
01:14 PM antto: i really don't understand why you need any casts
01:14 PM antto: eeprom_write_byte(32, 0x12);
01:15 PM antto: my nose tells me this would write 0x12 to the eeprom at offset 32
01:15 PM antto: uint8_t offset = 32; eeprom_write_byte(offset, 0x12);
01:20 PM _abc_: Try that with -Werror and see
01:21 PM _abc_: I would not be asking it it would work. It does not.
01:21 PM _abc_: 1) the offset must be an int not an int8_t since eeprom space is larger than 256 bytes on many devices
01:21 PM _abc_: 2) the 1st argument must be a pointer to an eeprom data type specified by avr-libc
01:22 PM _abc_: void eeprom_write_byte ( uint8_t ? __p, uint8_t __value ) this is the proto
01:22 PM _abc_: the '?' is a '*'
01:22 PM antto: okay, so it must be a uint8_t* then
01:22 PM _abc_: So to make a linear address into a pointer one should: (uint8_t *)32
01:23 PM _abc_: And THAT gives the error 'making a pointer out of an integer without a cast'
01:23 PM _abc_: Which is the question I actually asked.
01:23 PM antto: try uint8_t *ptr = 32;
01:23 PM _abc_: Please do not guess, say if you know how it works.
01:24 PM antto: can't help you then
01:24 PM _abc_: That would work probably but why does the other way not work?
01:24 PM _abc_: I tried to indirect it with *, not good
01:24 PM _abc_: <break 2> be back in a few
01:25 PM antto: with all your casts, i think you were getting an address from a temporary int
01:25 PM antto: if you have to combine more than one cast it smells wrong to me
01:26 PM _abc_: I agree. brb
01:26 PM antto: i use static_cast<>() to make things clearer
01:26 PM _abc_: static_cast<>() is a c++ construct?
01:26 PM antto: i write in C++
01:26 PM antto: but i think i've used it in C too
01:26 PM _abc_: I do not. This is C.
01:27 PM antto: gcc may forgive you ;P~
01:29 PM antto: uint8_t *ptr = (uint8_t*)(32); func(ptr, value);
01:30 PM antto: this works in gcc for linux in C++ mode
01:34 PM _abc_: http://www.avrfreaks.net/forum/eepromreadbyte-warning-cast-pointer-integer answer.
01:36 PM antto: i still would avoid writing like that at all costs
01:36 PM antto: because it looks weird
01:46 PM _abc_: I will not mix C and C++. Ever. Not in embedded for sure. Damn duino pest causing such habits.
02:13 PM JanC_ is now known as JanC
02:37 PM Emil_ is now known as Guest99166
02:57 PM antto: meh
03:09 PM Emil: Mixin C/++ is a) blasphemy b) insane c) retarded
03:09 PM Emil: pick three
03:10 PM Emil: Also lol at "duino past"
03:10 PM Emil: "I have but one weakness"
03:10 PM Emil: "My history with..."
03:10 PM Emil: "ARDUINOS!"
03:10 PM Emil: Cue anime shouting
03:12 PM antto: what i proposed was actually a C cast
03:12 PM antto: according to my knowlage
03:51 PM xentrac: I mix C and C++ regularly
03:51 PM Tom_L: does it come out as C# ?
03:52 PM * antto zaps Tom_L with alternating 5V
03:53 PM xentrac: I think _abc_'s line of code is the least evil way to do it
03:54 PM xentrac: antto: don't try to fix C programs with C++; the C compiler won't accept it
04:12 PM enhering: Just write your code in C++ with C aditions. When it works, make it better, less complex. It will be natural to convert all your code to either side later.
04:13 PM enhering: I have to mix the two languages. I can put classes in an AVR, but string usually do not fit.
04:15 PM Emil: polprog:
04:15 PM Emil: https://i.redd.it/ak5smmpwjrbz.jpg
04:16 PM enhering: Anybody knows if this brand is good? https://www.aliexpress.com/item/1-Set-Professional-3-5X-90X-Trinocular-Stereo-Zoom-Vertical-Zoom-Microscope-0-5X-2X-Auxiliary/32821294551.html
04:22 PM polprog: Emil: ha ha ha
04:36 PM R0b0t1`: Lambda_Aurigae: xentrac: I mean, I wouldn't be making this up because I realize how intractable it makes troubleshooting. However I've never had problems with USART usage with the RC oscillator.
04:36 PM R0b0t1`: Lambda_Aurigae: xentrac: In the interest of avoiding Arduino software I asked for a bootloader recommendation, because that may solve my problem
04:38 PM xentrac: ah, cool
04:38 PM xentrac: I wish I knew enough to make a useful comment :)
04:38 PM xentrac: enhering: why do you need to mix the two?
04:38 PM polprog: R0b0t1`: curious, how fast did you transfer with that?
04:38 PM polprog: uart needs stable oscillators
04:39 PM polprog: RC can have a big temperature drift
04:50 PM R0b0t1`: polprog: 57600
04:50 PM xentrac: quite impressive
04:51 PM polprog: that's 100khz signal...
04:51 PM R0b0t1`: I would be able to accept that maybe I need to do something different if I couldn't get it to upload at all, but in an air conditioned office I am able to upload once and then never again
04:51 PM polprog: ok
04:51 PM xentrac: I don't think there's anything wrong with the Arduino bootloader, except that maybe a serial bootloader might be unreliable on the RC clock
04:51 PM polprog: if in doubt, test
04:52 PM xentrac: well, I think R0b0t1` did test and is trying to figure out why the bootloader isn't working :)
04:52 PM R0b0t1`: I very much don't want to sound like I don't need help but based on my personal experience using serial on the internal oscillators I suspect most people who say serial communication needs a crystal simply haven't tried to do it without one
04:52 PM polprog: i heard about an EE prof back then who was testing temp drift endurance by walking around with a hairdyer and blowing at students' constructions
04:53 PM polprog: to see if they fail
04:53 PM polprog: :P
04:53 PM R0b0t1`: I can't find the writeup but I'm basing my conclusion on a guy who did the math based on the acceptable jitter that the USART can compensate for
04:53 PM R0b0t1`: The conclusion was it will be fine at lower speeds
04:54 PM polprog: 9600 is enough most cases
04:54 PM R0b0t1`: polprog, heh
04:54 PM R0b0t1`: at the hair dryer
04:54 PM polprog: unless you want to xfer pictures or anything
04:55 PM polprog: but please, how much flash do the biggest avrs have? m128 has 128k flash... that would take ~15 secs to transfer
04:55 PM polprog: no big deal
04:56 PM xentrac: R0b0t1`: it might also be that those people are looking for higher levels of reliability than "I haven't seen it fail yet" :)
04:57 PM polprog: you can always check it on a scope
05:05 PM R0b0t1`: Turns out that I didn't have the BOOTRST fuse set
05:05 PM R0b0t1`: xentrac: Okay, but "I haven't seen it fail yet" still applies to your crystal-based USART
05:13 PM Lambda_Aurigae: I've gotten avr to run reliably on internal RC oscillator for USART comms at 9600bps and below with newer chips....atmega1284p specifically...
05:14 PM Lambda_Aurigae: on the older ones, like the atmega32, atmega16, and atmega8515 the RC oscillator was much less stable.
05:15 PM Lambda_Aurigae: but even with the newer chips I wouldn't rely on it being stable at 57.6K or above...that's just me though.
05:20 PM Lambda_Aurigae: as for serial bootloaders....google is your friend....I've found half a dozen and modded them to my purposes over the years.
05:20 PM xentrac: R0b0t1`: right, but we have stronger reasons to expect crystal-timed RS-232 communciations to work than just that one person hasn't seen it fail yet
05:21 PM xentrac: yay BOOTRST
05:21 PM xentrac: so now it works all the time?
05:21 PM xentrac: congratulations!
05:21 PM R0b0t1`: Yep
05:21 PM xentrac: the ATMegas have their RC oscillator specced at ±1%, while the ATtinies have it specced at ±2%
05:22 PM xentrac: including the 32(8)
05:22 PM R0b0t1`: I am about 90% sure that that tolerance keeps you within what the USART expects, maybe even for very high baudrates
05:22 PM R0b0t1`: Also I apologize that I keep plugging my topics, but this one (http://www.avrfreaks.net/forum/unable-use-avrdude-avr-isp-mk-ii) about being unable to use the AVR ISP Mk II sans Atmel Studio has been plaguing me for years
05:23 PM R0b0t1`: Probably the last time I will post it
05:23 PM Lambda_Aurigae: no input on that one as I don't have such a piece of hardware.
05:24 PM Lambda_Aurigae: avrdude and 15ish year old stk200 clone work great for me for programming and old school debugging methods without debugging hardware beyond some LEDs and maybe serial port connection.
05:26 PM Lambda_Aurigae: my most advanced debugging hardware was 8 LEDs on a GPIO port and a 556 timer setup for 1-shot and adjustable speed free running mode for clock source.
05:26 PM Lambda_Aurigae: one button push for one clock pulse is fun.
05:27 PM R0b0t1`: I typically do something like that and tend to not make use of the in-circuit debugging functionality
06:48 PM R0b0t1`: My apologies, one more issue with asynchronous timer 2 operation: http://www.avrfreaks.net/forum/timer-2-asynchronous-mode-not-active.
09:27 PM enhering: xentrac: Sorry for the late answer. I use C++ for most of the code, i.e. I divide the problem into classes that are simple enough. But if I need to deal with strings, I fallback to C. The C++ string class consumes a lot of program space.
09:43 PM xentrac: couldn't you jsut use C strings in C++?
09:43 PM enhering: you mean char *?
10:01 PM day is now known as daey
10:49 PM xentrac: wel, char* pointing to NUL-terminated arrays of bytes
10:49 PM xentrac: I mean you can still manipulate those in C++
11:36 PM enhering: xentrac: That is what I do. Null terminated arrays of chars and very basic string manipulation functions like strlen, strcat, strncpy etc. If I try to include a <string> c++ class, my code does not fit into the ATMega328p anymore.
11:37 PM xentrac: I see. So you don't actually have to compile code as C
11:38 PM enhering: nope
11:38 PM enhering: But using those functions is not C++...
11:39 PM xentrac: you can use them in C++ code; you just have to #include <cstring>
11:39 PM enhering: most C++ programmers just include and use <string>. Much easier. When it fits in
11:39 PM enhering: I do not even include <cstring>
11:39 PM enhering: avr-gcc recognizes them
11:40 PM xentrac: interesting, I'd think that in C++ you would get an error from trying to call an undeclared function
11:40 PM xentrac: (even though of course you would want avr-gcc to inline them)
11:41 PM enhering: http://www.atmel.com/webdoc/avrlibcreferencemanual/group__avr__string.html
11:42 PM enhering: I do not include those, but they are available
11:48 PM xentrac: I wonder if you're including some header file that includes them
11:51 PM xentrac: if at some point you get curious, you can pass -M to avr-gcc to find out
11:51 PM day is now known as daey