#avr Logs

Nov 05 2018

01:19 AM * rue_bed tries to get to sleep
06:39 AM kakimir: what does A mean in name of AVR chip?
06:39 AM kakimir: and what if it has 1 instead of A
06:41 AM polprog: never saw "1VR"
06:42 AM polprog: The AVR architecture was conceived by two students at the Norwegian Institute of Technology (NTH),[1] Alf-Egil Bogen[2] and Vegard Wollan.[3]
06:43 AM polprog: it doesnt have any official meaning but it could mean "alf's and vegard's risc"
06:52 AM wondiws: https://pastebin.com/HrSbU3QP
06:52 AM wondiws: could anyone look at this?
06:52 AM wondiws: why do I have to reset to get a new analog read?
06:52 AM wondiws: I was expecting it to do a new analog read every iteration in the while loop
06:56 AM LeoNerd: (ugh pastebin.com)
06:56 AM Thrashbarg: should be able to set it to free running mode and trigger it once outside the loop
06:57 AM wondiws: Thrashbarg, but I should not need free running mode
06:57 AM wondiws: I want to work to something different
06:57 AM wondiws: this is a first test
06:57 AM LeoNerd: for (volatile uint16_t i = 0; i < 0xffff; i++); <== that won't ever stop
06:57 AM LeoNerd: ... ohwait maybe it wil.l. But either way it's weird and ugly
06:57 AM LeoNerd: Use a _usleep()
06:58 AM wondiws: LeoNerd, yes, it's a replacement of that, I didn't want to include util
06:58 AM LeoNerd: Also on a purely stylistic note, it's nice to put the empty ';' of a busywait loop on its own line, to really emphasise " Imean this"
06:58 AM wondiws: LeoNerd, usually I do that, but this is just an experiment so far
06:59 AM LeoNerd: But so far nothing obvious jumps out. Admittedly I haven't stared in detail at the bitconstants because I usually wrap them up in HAL functions
06:59 AM LeoNerd: So I don't have the whole lot committed to memory ;)
07:02 AM Thrashbarg: wondiws: hrm I would have thought you'd get a different value for each cycle, unless you've got the analog input on the wrong pin.... it's PORTC it's connected to right?
07:02 AM Thrashbarg: Try setting all bits in DIDR
07:02 AM Thrashbarg: to disable digital inputs
07:02 AM LeoNerd: DIDR is just about power management
07:03 AM Thrashbarg: yeah
07:03 AM wondiws: Thrashbarg, it's the right pin, because if I move the joystick, and press reset, I get a different reading
07:03 AM LeoNerd: Do you still get one complete report, including the CR-LF result?
07:03 AM wondiws: yes
07:03 AM Thrashbarg: what's declaring true and what's it set to?
07:03 AM LeoNerd: I'd suggest replacing that for loop with a proper _delay_us()
07:04 AM wondiws: LeoNerd, but that's not the problem
07:04 AM LeoNerd: wondiws: isn't it?
07:04 AM LeoNerd: You say you get one report then it stops working
07:04 AM LeoNerd: Maybe it infinite-spins at that point, never getting past it?
07:04 AM wondiws: LeoNerd, no, I get the same report over and over again
07:04 AM wondiws: until I reset
07:04 AM LeoNerd: Oh.. right
07:04 AM LeoNerd: OK, so I misunderstood the problem
07:06 AM LeoNerd: Also, any reason you're using ADCH and ADCL directly, rather than the ADC pseudoregister?
07:06 AM LeoNerd: I'd have done uint16_t adc = ADC; then send the four nibbles of that
07:07 AM wondiws: LeoNerd, I didn't know the pseudoregister, but could remember ADCH and ADCL
07:08 AM LeoNerd: gcc implements it to behave properly
07:08 AM LeoNerd: in a way that your direct accesses of the two halfs might not
07:08 AM wondiws: alright
07:09 AM wondiws: LeoNerd, you're right, when I read out ADCW something different happens, then it works :S
07:10 AM LeoNerd: 🙌
07:10 AM LeoNerd: "... In which we discover that HALs are a Good Thing" :)
07:18 AM wondiws: LeoNerd, I used to use ADCH and ADCL on the atmega32
07:18 AM wondiws: I'm not sure that one had that pseudo register
07:32 AM nabil_ is now known as nabil
08:07 AM kakimir: do I need to measure bandgap with noise-reduction on?
08:08 AM kakimir: weird stuff happening
08:09 AM kakimir: first measurement in function results in decimal value 55
08:09 AM kakimir: second measurement results in decimal value 72
08:09 AM kakimir: it seems to follow this pattern
08:14 AM kakimir: there is slight variations
08:24 AM kakimir: added more delay after switching channel
08:24 AM kakimir: now it's 55
08:24 AM kakimir: both
08:25 AM kakimir: between switching channel and conversion
08:25 AM kakimir: *delay
08:27 AM LeoNerd: Onboard ADCs are generally terrible; you have to throw away the first sample after a MUX change because it's still noisy
08:27 AM LeoNerd: I usually throw away the first, the average the next four
08:31 AM kakimir: why not just wait?
08:32 AM kakimir: 100us wait was not enough
08:32 AM kakimir: changed it to 500 and it did the trick
08:32 AM kakimir: does sampling make the voltage level stabilize faster?
08:37 AM LeoNerd: Ah, maybe. I'm not sure. I just found it easier to read then throw away one result, then implement some sort of delay
08:56 AM kakimir: what the... my readout from ADC channel doesn't change
08:59 AM kakimir: 192
08:59 AM kakimir: I remove voltage source from ADC pin
08:59 AM kakimir: still reads 192
09:05 AM rue_mohr: kakimir, what is your adc clock freq
09:08 AM rue_mohr: "By default, the successive approximation circuitry requires an input clock frequency
09:08 AM rue_mohr: between 50 kHz and 200 kHz to get maximum resolution. If a lower resolution than 10
09:08 AM rue_mohr: bits is needed, the input clock frequency to the ADC can be higher than 200 kHz to get a
09:08 AM rue_mohr: higher sample rate."
09:11 AM rue_mohr: for (volatile uint16_t i = 0; i < 0xffff; i++);
09:11 AM rue_mohr: ^^ any optimization setting will remove that
09:11 AM rue_mohr: when you make a delay, put a NOP(); instruction in it
09:13 AM rue_mohr: ADCH >> 4 & 0xf
09:13 AM rue_mohr: order of ops, best to use brackets
09:13 AM rue_mohr: and like, no
09:14 AM kakimir: wait.. I think I was just confused
09:14 AM rue_mohr: each of adcH and adcL are 8 bits...
09:14 AM skz81: <wondiws> https://pastebin.com/HrSbU3QP >> Either I am blind, or idx is never incremented
09:14 AM kakimir: I mixed adc value and converted value
09:14 AM wondiws: skz, correct, that's code from a previous experiment
09:14 AM rue_mohr: there is that too
09:15 AM wondiws: rue_mohr, but ADCW makes all the difference
09:16 AM rue_mohr: http://ruemohr.org/~ircjunk/avr/mega8/usart.c
09:16 AM rue_mohr: http://ruemohr.org/~ircjunk/avr/mega8/usart.c
09:16 AM rue_mohr: http://ruemohr.org/~ircjunk/avr/mega8/usart.h
09:16 AM rue_mohr: http://ruemohr.org/~ircjunk/avr/mega8/usart.h
09:16 AM rue_mohr: ^^ those are two files
09:16 AM rue_mohr: for you
09:16 AM rue_mohr: look at printhex
09:17 AM rue_mohr: it sends an 8 bit hex value string
09:17 AM rue_mohr: as ascii
09:19 AM rue_mohr: tho I think I see what your up to
09:19 AM rue_mohr: but, no
09:20 AM rue_mohr: oof, anyhow
09:22 AM rue_mohr: my code comes from the apple IIe rom, its proven :)
09:22 AM kakimir: I had 3 variable overflows
09:22 AM kakimir: I need ICE soon
09:22 AM kakimir: atmel ice worth the moneys?
09:22 AM vmt: for what purpose do you need the ice
09:23 AM vmt: if debugging, then trash your silly ass avrs and get arm
09:23 AM rue_mohr: if your going to get good at coding, you need to learn to make things in small pieces that you test, and then put tested peices togethor in a progressive manner
09:23 AM skz81: colding mojitos :]
09:23 AM skz81: cooling *
09:23 AM vmt: mojitos yuck.
09:23 AM rue_mohr: bad coders need complex debuggers
09:23 AM vmt: it's the one with sugar and mint yes?
09:23 AM kakimir: rue_mohr: I already installed visual studio
09:23 AM kakimir: tracked down 2 variable overflows
09:24 AM vmt: rue_mohr: wrong
09:24 AM rue_mohr: no its true
09:24 AM vmt: it's true as long as you write trivial programs
09:24 AM skz81: <vmt> it's the one with sugar and mint yes? >> yup. You can cool your own cocktail if you'd like rather :P
09:24 AM rue_mohr: I do almost no debugging at all, cause my stuff works
09:24 AM rue_mohr: casue I build it out of known-good modules
09:24 AM vmt: avr code in general will not be very complicated.
09:24 AM rue_mohr: BAD CODERS NEED FULL FEATURED DEBUGGERS
09:25 AM vmt: ...no
09:25 AM rue_mohr: all the problems I get I can work out with 1 output port and an led
09:25 AM vmt: because avr programs are very simple.
09:26 AM rue_mohr: how many years ahve people brought in code that they wrote all at once, and then tried to compile and run
09:27 AM rue_mohr: and surprise, it didn't work
09:27 AM vmt: you think that's how people do it in general?
09:27 AM vmt: these "bad coders"?
09:27 AM vmt: anyone with that approach to software is nothing but a mere hobbyist, and a bad one at that
09:28 AM rue_mohr: they end up with 15 things at once that dont work, and they cant pin them down because nothing works
09:28 AM rue_mohr: I'm a recreational coder too, not the point
09:28 AM rue_mohr: I break my stuff down into modules, build each, test it, and assemble them
09:29 AM rue_mohr: after a while, you get a collection of stuff you already know works
09:29 AM rue_mohr: and you know if its giving you trouble, its SOMETHING ELSE
09:29 AM rue_mohr: gtg work
09:30 AM vmt: bad coders need this kind of useless borderline unit testing
09:31 AM vmt: this approach you are describing works well for near-trivial programs, such as those which avr programs tend to be.
09:31 AM vmt: i.e. the lack of debugging in general
09:32 AM vmt: once you get to more complicated programs, you are bound to hit a snag at some point which you can't debug with uart or toggling a pin.
09:32 AM rue_mohr: not in 20 years
09:33 AM vmt: and this snag might be in one of your "modules", too. and finding it is just that much easier using a debugger
09:33 AM LeoNerd: Honestly, I find about 90% of my debugging works fine with the "well-placed print statement"- from the largest systems to the smallest microcontroller... albeit in that case a "print statement" might be toggling a spare pin
09:34 AM vmt: obviously you can pin-point the problem by sprinkling print statements all over the place
09:34 AM vmt: but with a debugger you have no need for this.
09:35 AM LeoNerd: I generally find they get in the way more than anything, honestly
09:35 AM vmt: in the way, in what exact sense?
09:35 AM LeoNerd: A placed print statement has a tiny side-effect on the overall running of the program, but the code generally runs and does its thing around it
09:35 AM LeoNerd: Whereas a debugger gets very invasive.. you stop the thing, fiddle with it under the hood, keep going... you need to run it *in* that debugger,...
09:36 AM vmt: well, it's kind of the point of a debugger.
09:37 AM vmt: i still fail to see how does it "get in the way"
09:37 AM LeoNerd: Indeed so - I'm not faulting the tool for its very nature; I'm saying I've never really felt a need for such a tool
09:37 AM kakimir: return (( adc_value * debug_bandgap_x1000 ) / (bandgap_adc_value * 10)); //Calculate X100 format voltage for parameter adc_value //TODO
09:37 AM kakimir: bandgap is intepolated value
09:38 AM kakimir: this works but I would wish to optimize it
09:39 AM kakimir: now there is something like 1062 1074 and so on values for bandgap
09:39 AM kakimir: that are used for interpolation
09:39 AM kakimir: actually I thing I will just change to x1000 voltage format
09:39 AM kakimir: think
09:41 AM LeoNerd: Also I guess, a lot with AVR and electronics generally, I find that the program code inside the MCU is only half of the story. Sometimes not even that
09:41 AM LeoNerd: A lot of more fun problems have been e.g. signal reflection down the SCK line causing phantom clocking of an SPI ROM chip
09:41 AM LeoNerd: No code debugger could have told me that
09:41 AM vmt: LeoNerd: yeah, but i was talking on a much more general level than that
09:42 AM LeoNerd: Well how general are we getting here? ;)
09:42 AM LeoNerd: Is an oscillopscope a "circuit debugger"?
09:42 AM vmt: i was saying, (specifically) avr programs are simple, and they really don't require a debugger
09:42 AM vmt: we were talking software debuggers here
09:42 AM vmt: and on a general level, refer to the "bad coders need full fledged debuggers" -argument
09:42 AM LeoNerd: Righty; but I was extending that further into *any* size of software code. It's really vanishingly-rare cases I've ever -wanted- to stop, single-step, inspect variables, setc...
09:43 AM LeoNerd: *Almost* almost always a wellplaced print, or other similar technique, has found what I've been after
09:43 AM LeoNerd: Even on hugely large distributed server systems or whatever
09:43 AM vmt: yet you referred to a mcu software later on
09:43 AM vmt: -a
09:43 AM kakimir: I use offset system to store voltages in x100 format
09:43 AM kakimir: what do you think about that?
09:44 AM kakimir: so it only stores relevant voltage range
09:46 AM LeoNerd: I find the print is also quite useful to just general underrstanding of existing code someone else wrote, as well
09:46 AM LeoNerd: So it's a quite extensible technique you can use in a variety of situations
09:47 AM kakimir: I wonder if I should go to uint16_t format for voltages and x1000 format
09:47 AM kakimir: at least it found make it a bit easier to handle
09:49 AM LeoNerd: kakimir: For scaled values I usually find it best to work with engineering-scales; i.e. powers of 1000, yes.
09:49 AM LeoNerd: Then you can conveniently remark that it stores milivolts, microamps, whatever...
09:49 AM LeoNerd: Otherwise it gets trickier to remember that "this is in units of 100nV"
10:01 AM kakimir: I think only the mem consumption
10:10 AM kakimir: wow
10:10 AM kakimir: badgap interpolation works
10:10 AM kakimir: but around 4.8v there is something weird happening
10:17 AM kakimir: bandgap apparently drops sligthly more there
10:17 AM kakimir: voltage readings rise 1% there
10:30 AM kakimir: After switching to internal voltage reference the ADC requires a settling time of 1ms before measurements
10:30 AM kakimir: are stable. Conversions starting before this may not be reliable. The ADC must be enabled during the set-
10:30 AM kakimir: tling time.
12:30 PM kakimir: there is attiny44, attiny441 and attiny44a
12:31 PM kakimir: really similar chips
12:31 PM kakimir: also to confuse more there is attiny48/88
12:34 PM kakimir: to confuse with attiny24/44/84
12:35 PM kakimir: probs you can program one like nothing while thinking you have another chip in use
01:03 PM LeoNerd: I suspect most people can distinguish that 48 and 84 are different numbers ;)
01:03 PM LeoNerd: Though yes I'll accept the trailing A or B or P or whatever suffixes can be annoying
01:32 PM kakimir: what does those even mean?
01:38 PM kakimir: if I run ADC in single conversion mode
01:38 PM LeoNerd: ?
01:38 PM kakimir: do I need to read registers in right order in order to release shadow register
01:39 PM kakimir: datasheet says something like "read this first and after that another register is held until read is performed on it"
01:41 PM LeoNerd: Are you talking about ADCL and ADCH? Just use the gcc-generated code for a 16bit read of ADC itself
01:41 PM kakimir: what register name?
01:41 PM LeoNerd: uint16_t result = ADC; will do the right thing
01:41 PM kakimir: just ADC :I
01:41 PM kakimir: i will
01:46 PM nohit: <rue_mohr>BAD CODERS NEED FULL FEATURED DEBUGGERS
01:46 PM thardin: also good coders
01:47 PM thardin: everyone should have a good debugger
01:47 PM nohit: <rue_mohr>not in 20 years
01:49 PM kakimir: hmm
01:50 PM kakimir: after I got over all 4 variable overflow bugs today I feel like SPI debug data is enough
01:50 PM kakimir: very similar macro constant names and overflow was once such that result was almost correct
02:53 PM hjf: hi guys. i was wondering, the datasheet for the ATMEGA328PB says it supports up to 144 mutual capacitance channels. i tried to configure a project with atmel start, but it will only let me add up to 55 mutual capacitance buttons
02:53 PM hjf: is this a limitation of the tool? or the IC?
02:54 PM hjf: i need 64 buttons for this project
04:10 PM kakimir: 861 looks promising
04:10 PM kakimir: 816*
04:10 PM kakimir: but it scares me
04:14 PM kakimir: it's a beast
04:14 PM kakimir: not sure if major rework of code is needed
04:40 PM [1]MrMobius is now known as MrMobius
06:58 PM aidanh010: the Atmega datasheet for the UART says "The receive buffer consists of a two level FIFO," where can I find how big this is exactly on the 328?
07:24 PM rue_mohr: its 1 byte
07:41 PM eadthem: hey
07:42 PM eadthem: In a mega164, ive not had much exprence with interups, but can i assign a couple pins , where if for any moment they go high or change state, that state is heald until cleared?
07:42 PM eadthem: same applys to mega16
07:43 PM eadthem: i have a bunch of both
07:45 PM eadthem: I guess what i would prob be doing is using the external interupt or pin change interups
07:45 PM eadthem: i just wanted to be sure that if i was in a non interuptable section of code i would get the interupt on leaving that section.
08:00 PM McDonaldsWiFi: Anyone ever had an issue uploading with USBasp and it still wants a port?
08:01 PM McDonaldsWiFi: I think it might be a windows 10 thing -.-
11:51 PM day__ is now known as day