#avr Logs

Nov 13 2017

01:51 AM nuxil: avrdude: 666 bytes of flash verified
01:54 AM nuxil: i make evil code :D
03:16 AM Ameisen: _ami_ - having difficulty figuring out doing the algorithm with ints. Even with fixed it has issues.
03:16 AM Ameisen: every version I've seen uses floats
03:17 AM Ameisen: though even my current version gives similar results to using PID
03:17 AM Ameisen: hrmm...
03:17 AM Ameisen: atmega2560 has 4 KiB of EEPROM
03:18 AM Ameisen: I presume no printers use the smaller ones since even Marlin's settings wouldn't fit
03:18 AM nuxil: silly question by.. how can i create a custom sleep function where i can dynamicly set the time? like. void mysleep(uint16_t time) {_delay_ms(time);} ?
03:19 AM Ameisen: Is there an advantage to using EEPROM vs flash for settings?
03:19 AM Ameisen: why not just use spm?
03:19 AM Ameisen: other than the fact that EEPROM has more write/erase cycles
03:24 AM nuxil: should i just do it something like, void mysleep(uint16_t time) { int i; for (i = 0; i<=time; i++) {_delay_us(1);};} ??
03:25 AM nuxil: i know its not perfect. but.. are there other ways?
03:32 AM Ameisen: why not just loop on enough cycles
03:33 AM * Ameisen isn't fond of delays in the first place
03:41 AM nuxil: oki! then 2 questions. 1. how do i count the cycles. 2. how do i find out the time and cycles 1, "loop" or a NOP cmd uses ??
03:42 AM nuxil: * to clear it up: ... the time & cycles one loop or nop uses
03:42 AM Ameisen: I mean... counting cycles isn't that hard... you know what the code is putting out.
03:42 AM Ameisen: and AVR instructions have a fixed cycle count
03:43 AM nuxil: that what i mean. where do i find out example how many cycles a asm("nop") does.
03:43 AM Ameisen: http://www.atmel.com/webdoc/avrassembler/avrassembler.wb_instruction_list.html
03:43 AM nuxil: thanks :D
07:25 AM noHitW_work: but why would you do that kind of function? its just a delay, not sleep
09:37 AM tpw_rules: i seem to somehow have broken inlining with avr-gcc?
09:37 AM tpw_rules: all my inline functions are showing "undefined reference to" when linking
09:50 AM thardin: pull-ups are 10k on ATmega128, right?
09:51 AM thardin: getting crap MISO waveforms despite pull-up
10:00 AM thardin: hrm, crappy supplies
10:01 AM JanC_ is now known as JanC
10:59 AM Emil: nuxil: what kind of sleep you want?
10:59 AM Emil: nuxil: busy looping?
10:59 AM Emil: well, that's bad, imho
11:00 AM Emil: anycase, you can't give a variable as an argument to those _delay_ms macros
11:00 AM Emil: you have to do it as a loop
11:16 AM learath: the sleep of the dead or the sleep of the just? :P
11:49 AM daey: im trying to use the atmega328p internal temp sensor, which should be pretty simple, in theory.
11:49 AM LeoNerd: I believe it appears as ADC8
11:50 AM daey: the code i came up with equals the code i found in github account. therefore i assume it should be pretty close. http://dpaste.com/3JZQF06
11:50 AM daey: the problem is the function exists (which tells me that the ADC conversion actually completes, but it returns a zero instead of the proper value
11:50 AM LeoNerd: Why aren't you just reading ADC ?
11:50 AM LeoNerd: There's no need to fiddle with ADCL and ADCH
11:51 AM daey: didnt know that. but that shouldnt affect the outcome, does it?
11:54 AM LeoNerd: I do'nt know what order gcc will emit your code into; if it reads the two halfs it will get the wrong number
11:54 AM LeoNerd: whereas gcc knows how to read from ADC just fine
11:54 AM daey: well im getting a straight zero
11:57 AM daey: i was thinking that maybe something with the internal 1.1V ref is wrong
11:57 AM LeoNerd: I would bet your bit-twiddling is wrong
11:58 AM LeoNerd: It's realyl hard to see what that is right now because you've got lots o fhardcoded numbers
11:58 AM daey: LeoNerd: the return thing?
11:58 AM LeoNerd: I suggest do'nt do that
11:58 AM daey: LeoNerd: ah thats the github code
11:58 AM LeoNerd: Instead, actually use the named constants for what they're supposed to be for
11:58 AM LeoNerd: Yes well people on github can be wrong
11:58 AM daey: no i mean mine doesnt do that
11:58 AM daey: but the hardcoded numbers are correct (at least match with mine)
11:58 AM LeoNerd: OK, well *shrug*
11:59 AM daey: http://dpaste.com/2628661
11:59 AM LeoNerd: I can't verify that easily so we'll have to take it on blind faith for now
11:59 AM daey: thats mine
11:59 AM LeoNerd: But also I don't think you've set enough of them
11:59 AM LeoNerd: there's more registers than that
12:05 PM daey: would you agree that the following means: "set the right bits in ADMUX and you can measure the internal reference on the AREF pin'?
12:05 PM daey: Optionally, AVCC or an internal 1.1V reference voltage may be connected to the AREF pin by writing to the REFSn bits in the ADMUX Register.
12:05 PM LeoNerd: ?
12:06 PM LeoNerd: I don't understand the question
12:06 PM daey: how is that not understandable o.o
12:06 PM daey: the 2nd line is from the datasheet
12:07 PM daey: the 1st the question
12:07 PM LeoNerd: "Would you agree that the following means: [statement]"
12:07 PM LeoNerd: There's notihng to comapre it to
12:07 PM LeoNerd: You made a statement quoting the data sheet
12:07 PM LeoNerd: Obviously the data sheet means what the data sheet means
12:07 PM LeoNerd: Anyhow, did you set the overall clock for the ADC?
12:07 PM LeoNerd: Did you make sure it's powered up (ie. poke the PRR)
12:08 PM LeoNerd: I forget what other steps are required because I wrote myself a HAL to ensure I dont have to tihnk about that ever agian
12:08 PM LeoNerd: So I set ADMUX _and_ ADCSRA on setup
12:09 PM daey: well one thing that confused me is that setting ADCSRA |= (1<<ADEN) makes the function get stuck in the while loop.
12:10 PM LeoNerd: ...
12:10 PM LeoNerd: If you don't turn on the ADC then it won't work ;)
12:10 PM LeoNerd: So you'd best remember to do that yes
12:11 PM LeoNerd: Is this really just "ADC 101" ?
12:11 PM daey: yeah i did that initially. but it didnt work. so i removed it. i assumed that it might only be necessary for it if you run it permanently as opposed to running it in single conversion mode
12:12 PM LeoNerd: Are you even reading the data sheet at all?
12:12 PM LeoNerd: The ADEN bit turns on the ADC at all
12:12 PM daey: ?
12:13 PM LeoNerd: If you actually read it then you don't need to randomly guess what lines of code do and therefore delete them as a random stab-in-the-dark
12:25 PM polprog: im setting up a debian server at home
12:25 PM polprog: how can i name it (it's the 2nd one)
12:25 PM LeoNerd: ?
12:29 PM daey: LeoNerd: so everything i wrote was basically correct.
12:29 PM daey: the adc does not need to be turned on
12:29 PM daey: the issue was a single &
12:53 PM rue_bed: #define LAND &&
12:53 PM rue_bed: #define BWAND &
02:30 PM Ameisen: Hey
02:30 PM Ameisen: two questions
02:30 PM Ameisen: 1. I have a 3d printer with an Atmega2560 board. When I either connect/disconnect USB, _or_ use arduino sdk or something else to monitor USB (that's already connected) for debug data, the board resets
02:30 PM Ameisen: any idea why?
02:31 PM Ameisen: 2. Is there a way to find out how much space the current bootloader is taking? I'm wondering if I should build a new firmware and flash it.
02:32 PM LeoNerd: Because it's Ardunino
02:32 PM LeoNerd: That's a feature to reset on USB. It's the DSR-RST connection
02:34 PM cehteh: Ameisen: thats a common misfeature from arduino compatible things
02:35 PM cehteh: just remove the cap or cut the trace going to from dtr-reset
02:36 PM Ameisen: all right
02:36 PM Ameisen: the 'feature' has been confusing me, as I can't comprehend why you'd ever want it
02:36 PM cehteh: bootloader size, for whats reserved can be figured out by the fuses, the actual size might be smaller but you can only figure that out when you dump the image and look at it
02:36 PM cehteh: its meant to enter the bootloader when one connects USB
02:36 PM cehteh: noob friendly flashing
02:37 PM cehteh: i hate that too, at least they should have made a jumper on the board for that
02:37 PM LeoNerd: Ameisen: it's for reseting the chip so the bootloader can talk over UART
02:37 PM Ameisen: ah
02:37 PM LeoNerd: Before that, users had to press the RESET button manually at the right time
02:37 PM Ameisen: Is there any benefit to flashing a newer bootloader onto it?
02:38 PM Ameisen: I have no idea what's in it right now
02:38 PM Ameisen: it's whatever came with this printer
02:38 PM cehteh: only when it offers some fatures you need
02:38 PM Ameisen: I just know it's an atmega2560
02:38 PM LeoNerd: I don't think the Arduino bootloader can update itself can it?
02:38 PM Ameisen: the arduino SDK has an 'update bootloader' feature
02:38 PM cehteh: no
02:38 PM Ameisen: what I _want_ is the ability to keep the 'spm' instruction on
02:38 PM cehteh: yes but you need an ISP for that
02:38 PM Ameisen: I don't want the bootloader to disable it
02:39 PM cehteh: when you have an ISP in the first place you may go without bootloader altogether when you need the program space
02:39 PM cehteh: and be carful about bootloaders and watchdog
02:39 PM LeoNerd: Yah I don't usually bother; I put ISP directly onto the chip
02:40 PM cehteh: resetting does not disable the watchdog, you cant get into a reboot loop when the bootloader doesnt care
02:40 PM cehteh: you may get some cheap usbasp and integrate it directly on your printer
02:40 PM LeoNerd: Huh, I hadn't thought of directly embedding the USB ISP device. I usually just make the 2x3 header accessible somehow
02:41 PM LeoNerd: I have a standard wiring pinout over DE9 connectors for it also
02:41 PM cehteh: i know lots people doing that, it cheap and convinient
02:41 PM cehteh: even in RC transmitters and other devices using AVR's but lack direct usb ports
02:42 PM cehteh: usually you can just keep it wired, depending on the IO usage
02:42 PM LeoNerd: I find that an unpowered USBASP upsets other SPI transactions on the bus, because of its ESD protection diodes
02:43 PM cehteh: i mean ISP means In System Programming :D
02:43 PM cehteh: yes may happen just check how its connected, maybe put 5K resistors on the data lines
02:44 PM cehteh: i once had a small tiny with a beeper directly soldered to the pins (deadbug battery watchdog) and even with the beeper it was programmable, just sounded a bit strange :D
02:53 PM Ameisen: what is the watchdog for, exactly
02:53 PM Ameisen: I see the reset watchdog command sometimes
02:55 PM cehteh: some timer which needs a ping from your code once every while, else it resets the chip
02:55 PM cehteh: in case your program locks up because of a bug ...
02:56 PM cehteh: better do not enable it unless you really know what you are doing
03:06 PM Ameisen: this firmware has it enabled, which is annoying sometimes
03:06 PM Ameisen: I've been questoining if I should disable it
03:06 PM Ameisen: if the program locks up, I'd know and I'd just reset the printer manually
03:06 PM Ameisen: otherwise it's just another thing
03:07 PM cehteh: there are rare cases where they are really useful
03:08 PM cehteh: you need your program to be audited anyway when it is critical, it wont help when help when the program stucks in a loop, petting the watchdog
03:11 PM Ameisen: either the printer is stuck in a loop doing nothing (though I suppose interrupts would keep the heater on), or it's reset
03:11 PM Ameisen: so, not a _huge_ difference to me
03:11 PM Ameisen: I did notice that this firmware only resets the watchdog once the main loop successfully gets a temperature read from a thermistor via an interrupt
03:12 PM Ameisen: I'm guessing they wanted it to reset if there was a problem reading temperature?
03:12 PM Ameisen: seems like that'd be trivial to implement anyways just using a counte.
03:12 PM Ameisen: counter*
03:13 PM Ameisen: That, and I can't think of a reason it'd ever fail to read the thermistor. Even if the thermistor is broken, it would still get data from ADC (which is what it does), it just wouldn't be valid data
03:13 PM Ameisen: and it doesn't check for that
03:13 PM Ameisen: so... the entire premise they use is flawed
03:14 PM Ameisen: the only way they'd ever trigger the watchdog is if somehow the interrupts were slower than expected, and that's a far more important issue to correct
03:14 PM cehteh: i just add some validty check, like if the ADC reads the same value few times in a row
03:14 PM cehteh: or unplausible jumps
03:14 PM Ameisen: well, I need to rewrite their ISRs anyways
03:14 PM Ameisen: they did it stupidly
03:14 PM Ameisen: they have three or so critical ISRs that execute at roughly the same rate
03:14 PM Ameisen: each one also only executes certain bits of the ISR 'sometimes'. However, they also each re-enable interrupts _for the other ISRs_
03:14 PM Ameisen: which... is sorta silly
03:15 PM Ameisen: makes me think that what they really want at that point is _one_ ISR that does these things
03:15 PM Ameisen: rather than interrupting one another.
03:15 PM Ameisen: as they are now adding the overhead of the interrupt, logic to handle non-reentrant interrupts and reenabling certain interrupts, etc
03:15 PM cehteh: unplausible like 20�C temperature difference between readings .. throw away first 1-3 unplausible reads, error out after that
03:16 PM Ameisen: Just not sure what they were trying to accomplish
03:16 PM Ameisen: what this firmware does (and I maintain) is basically...
03:16 PM Ameisen: presuming every # is the 'next' ISR
03:16 PM cehteh: well i am afk bbl
03:16 PM Ameisen: #ADC Start Extruder #ADC Sample Extruder, #ADC Start Bed, #ADC Sample Bed #{loop 16 times} #set values to volatile memory
03:16 PM Ameisen: so the sampled values are *16
03:17 PM Ameisen: which averages them but also gives some semblance of decimal precision to temperatures
03:17 PM Ameisen: takes a long time though
03:17 PM Ameisen: especially since it alternates between two different pins to sample from
03:17 PM Ameisen: but since the atmega2560 only has one ADC, not sure of a better way to do that
03:17 PM Ameisen: I don't think that they can be done in parallel
04:24 PM * nuxil yawns and take a sip from his coffee
04:28 PM nuxil: Emil, i just wanted something that would waste time. im makeing my atiny85 play music. so i wanted something that would "pause" between notes. anywho i need to redo my code since i want to use the pll insted.
05:20 PM Emil: the pll?
05:20 PM Emil: mate
05:20 PM Emil: the PLL is just a higher clock source
05:21 PM Emil: Or that's what you get if you tweak OSCCAL
05:21 PM Emil: if you want to play something on an attiny85 and want pauses
05:21 PM Emil: or in any case
05:21 PM Emil: you do it with hardware pwm and timers
05:34 PM cehteh: pause is as simple as turing the output off ...
05:36 PM cehteh: and you could use the PLL 64mhz clock for making some class-1 like waveform generation, but i dont know if the tiny85 can cope with it fastz enough
05:37 PM cehteh: using square wave output and switching some filter banks might be easier
05:42 PM cehteh: class-d im meant
05:48 PM NoHitWonder: nuxil do you mean like synthezising notes or playing recorded audio with the help of pwm output used as a dac?
05:48 PM NoHitWonder: the first i would assume
05:49 PM NoHitWonder: then you should timers
05:49 PM cehteh: it has been done, but its not trivial, because of speed and space limitations, nothing for a beginner, but give it Jartza and he makes a polyphonic synth from it :D
06:07 PM Emil: cehteh: no
06:07 PM Emil: cehteh: the PLL is divided down by a factor of 8
06:07 PM Emil: you _cannot_ change that
06:07 PM cehteh: huh?
06:08 PM cehteh: what has that to do with the pll dividing?
06:08 PM Emil: The PLL operates at a maximum of around 64MHz
06:08 PM cehteh: yes
06:08 PM Emil: Or was it actually divided by 2
06:08 PM cehteh: and you can run counter 1 at that frequency
06:08 PM Emil: anycase
06:08 PM Emil: cehteh: you can't
06:08 PM cehteh: yes you can
06:08 PM Emil: No
06:08 PM Emil: you can't
06:09 PM cehteh: that divider applies when you want to run the MPU from the PLL
06:09 PM Emil: cehteh: maximum clock output is 32MHz, but in reality it is around 28MHz
06:09 PM Emil: I have tested this
06:09 PM cehteh: 64/4 -> 16mhz on chip 8mhz lifted to 64mhz by the pll and divided by 4
06:10 PM Emil: cehteh: point is: no output frequency beyond 16MHz is available
06:10 PM cehteh: 32mhz is correct yes because you can only generate half as fast waveform as the clock is running
06:11 PM cehteh: at best
06:11 PM Emil: cehteh: and then that is divided further for the pwm,
06:11 PM cehteh: ine clock cycle to turn the output on, one to turn it off
06:11 PM Emil: not to mention you can't change the duty cycle
06:12 PM cehteh: i havent done the math, but some hundred khz shold be ok for crappy waveform generation
06:12 PM Emil: Of course
06:13 PM Emil: My point is, the system clock wont exceed 32 (~28) MHz and that'
06:13 PM Emil: and from that you get 16MHz as best possible output frequency
06:14 PM cehteh: system clock will be 16Mhz when you go within specs
06:14 PM cehteh: thats still plenty
06:14 PM cehteh: but you need some tight realtime loop to form the waveform within that
06:15 PM Emil: Yes
06:15 PM cehteh: (ISR's would prolly be too much already)
06:15 PM Emil: Not entirely
06:16 PM cehteh: i havent tried, depends on what level of crappiness you want to accept it may do,
06:16 PM Emil: exactly
06:17 PM Emil: 4 bits does require real time but even 6 bits and the cycles are enough for ISRs
06:17 PM Emil: Though, given the generation, it
06:17 PM Emil: 's a one trick pony pretty muc
06:17 PM Emil: h so ISRs are not rea§ly that useful anyways
06:19 PM cehteh: just some constant-time loop should be simple
06:19 PM Emil: yeah
06:19 PM cehteh: iterating along a table with increment/repeat tuples
06:20 PM cehteh: that way you can approximate a sine or other waveform with little data
06:21 PM Emil: well
06:21 PM Emil: I would actually use CVSDM
06:22 PM Emil: In which case we sidestep the actual frequency generation and drive the output almost like I2S
08:12 PM nuxil: so i was googeling a bit. seems like there is tonz of people done this before and there are even lib i can use :D
08:13 PM nuxil: found this https://github.com/blakelivingston/avr_tinytune and this https://github.com/blakelivingston/DuinoTune on github :D
11:24 PM day_ is now known as daey