#avr Logs

Nov 12 2017

01:11 AM polprog: Ameisen: that's interesting what you said about gcc regressing
01:14 AM polprog: Ameisen: ill take a look at llvm
05:54 AM Jan-: hihi :)
05:55 AM Jan-: is there any reason this TCXO would not be suitable to run an atmega328p (it's part of an arduino board, we're going to hack it)
05:55 AM Jan-: https://www.ebay.co.uk/itm/122215167725
05:55 AM Jan-: I'm not sure if it's sine wave or square wave or if that matters.
06:02 AM Emil: Jan-: mate
06:02 AM Emil: buy from digikey/mouser/farnell/arrow
06:04 AM Jan-: It's a long story.
06:04 AM Jan-: if they do a dip one I've yet to find it
06:14 AM Jan-: so the question stands, I guess
06:26 AM nuxil: no idea. how you suppose to wire it up? just hook it up to xtal1, and ignore the xtal2 output ?
06:31 AM nuxil: Jan-, it should be doable
06:31 AM nuxil: look at datasheet
06:31 AM nuxil: external clock part
06:32 AM nuxil: around page 31
06:35 AM nuxil: but. why use a tcxo ?
06:36 AM Jan-: I'm aware you *can* theoretically use a tcxo with an avr
06:37 AM Jan-: I'm just asking if anyone can see any reason why that would wouldn't be the right one to use
06:37 AM Jan-: as to why nuxil it's a long story but yes, we do actually need that degree of precision.
06:39 AM nuxil: hmm. i mean i dont see the point. unless you have more components that is of same type. resistant to temperature changes. because even if you got a good crystal. other stuff might start to slew out of specs at low/high temps. just encapulate the hole device thats temp resistant :p
06:39 AM nuxil: *in a box thats temp resistant :p
06:43 AM Jan-: it's a precision timing application
06:44 AM nuxil: anywho. seems like you can use it. on xtal1 or on xck, not sure how that will work tho.
06:45 AM Jan-: yes I think I have to reset the avr to expect an external clock
06:45 AM Jan-: I'm not sure the arduino software can do that
06:47 AM nuxil: cant tell.. i one have one, and dont want one :p
06:47 AM nuxil: *i dont
06:50 AM Jan-: I just use them as cheap, easy avr dev boards.
06:50 AM Jan-: it's not like writing avr C is so hard that it's worth the arduino overhead, usually
06:51 AM Jan-: though I have done quick hacky things with it, it's fine enough
06:53 AM Jan-: my concern is more whether that particular tcxo I mentioned is electrically compatible with an avr.
06:53 AM Jan-: I don't know.
07:01 AM nuxil: i think it is.
07:01 AM nuxil: but check with the others :p
07:02 AM nuxil: it has +5 VDC / +3.3 VDC (+/-5%), Waveform: TTL/CMOS, Duty cycle: 40/60%, Phase noise: -125dBc/1KHz
07:05 AM nuxil: i see why not.
07:05 AM nuxil: its expencive tho.
07:47 AM twnqx: Ameisen: i suppose the 2KiB are strippable anyway? i mean, I got C to generate code in the size of <100 byte by killing all system and library code
07:51 AM Ameisen: doubtful
07:51 AM Ameisen: codegen issue, mainly
08:19 AM Jan-: oh thanks nuxil
08:19 AM Jan-: sorry, I was eating lunch
08:19 AM * Jan- belch
08:29 AM Tom_L: pheq
08:29 AM Tom_L: w
08:52 AM day is now known as daey
08:52 AM Jan-: hey its Tom_L
08:52 AM Jan-: we still have your programmer :D
08:55 AM Jan-: hey, I wonder if that programmer could be used to reprogram an AVR that's on an arduino board.
08:55 AM * Jan- headscratch
08:56 AM Tom_L: sure can
09:33 AM Jan-: Could we use that to tell the AVR to expect an external clock
09:33 AM Jan-: or would that get reset every time we flashed it with the arduino software?
09:33 AM tpw_rules: that's in the fuse config
09:34 AM tpw_rules: it won't get reset by the arduino bootloader
09:34 AM Jan-: okay.
09:34 AM tpw_rules: but it's possible to configure the clock fuses so that a mere programmer can't fix it
09:34 AM tpw_rules: i did that once
09:34 AM Jan-: so it looks like the procedure would be: 1) connect up Tom_L's programmer to the ICSP header on the arduino, 2) use AVR studio to set the AVR to expect an external clock, 3) remove crystal and attach TCXO appropriately.
09:34 AM Jan-: that syould be good, right?
09:35 AM Tom_L: as long as you pick the right fuses yes
09:35 AM Jan-: Now all I need is a five volt, through-hole, 16MHz, square wave output TCXO.
09:35 AM Jan-: Which is hard.
09:35 AM Tom_L: nope
09:36 AM Tom_L: there's on on the programmer :)
09:36 AM Tom_L: unless yours is really old
09:36 AM * Jan- gets down to the sugary chocolatey sludge at the bottom of her cocoa
09:36 AM Jan-: Mmmm.
09:36 AM Jan-: ...but I can't find one to buy.
09:37 AM Tom_L: http://tom-itx.no-ip.biz:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
09:37 AM Tom_L: the first pic
09:37 AM Tom_L: see at the top where it says clk?
09:37 AM Jan-: I found this one, but it's sine wave: https://www.ebay.co.uk/itm/1PCS-TCXO-0-3PPM-16MHz-16-000MHz-Sine-wave-Ultra-precision-Oscillator/332222860777?epid=560673124&hash=item4d5a068de9:g:oMsAAOSwYlRZGqgL
09:37 AM Tom_L: hmmmmm i wonder wtf that's for
09:37 AM Jan-: err no I can't see pics. but I get the idea.
09:37 AM Tom_L: ahh yeah i forgot. sry
09:38 AM Jan-: I read that the avr doesn't like sine wave clocks.
09:38 AM Jan-: aha: https://www.ebay.co.uk/itm/1PCS-TCXO-0-3PPM-16MHz-16-000MHz-Square-wave-Ultra-precision-Oscillator/332222668415?hash=item4d5a039e7f:g:hCAAAOSwuMZZGm3R
09:38 AM Tom_L: i put that there for those noobs that set the fuses to external clock and are trying to recover from it
09:39 AM Jan-: doesn't that just read one side of the crystal then
09:39 AM Tom_L: that pin puts out a square wave
09:39 AM Jan-: oh hm
09:39 AM Tom_L: i forget the freq though
09:39 AM Jan-: not tcxo precision though.
09:39 AM Tom_L: tom's programmer precision :)
09:40 AM tpw_rules: Jan-: what do you need tcxo precision for
09:40 AM Jan-: it's an audio synchronisation device for film and TV work
09:40 AM Jan-: it's not so much frequency precision as long term stability over temperature changes.
09:40 AM tpw_rules: you could use a gps with PPS to correct the internal RC oscillator
09:41 AM Jan-: that's probably how we'll calibrate them but they need to work well in various environments, when there might not be GPS
09:41 AM tpw_rules: are the audio inputs digital?
09:41 AM Jan-: it's been thought through - we really do need this. I wrote it on an arduino nano which has a ceramic resonator and it's all over the place.
09:41 AM Jan-: you can literally make it change its perception of what the input frame rate is by blowing warm air on the board
09:41 AM tpw_rules: are you sure you're just not respecting interrupt latency? :P
09:42 AM Jan-: Yes, very, very sure.
09:42 AM Jan-: This has been thought about a lot, planned, and tried.
09:42 AM Jan-: If I want to make something that will independently maintain audio synchronisation to a single digit number of frames at 60 frames per second in 24 hours, I need a tcxo.
09:44 AM Jan-: one of the hardest things about this is figuring out what the interrupt latency is
09:45 AM Jan-: the only way we have of doing that is to put a scope on the input signal and a scope on the output latch line, and observe the phase error.
09:45 AM Jan-: Which we can do, and which we will have to do.
09:45 AM tpw_rules: i think it's almost constant for AVR parts though?
09:45 AM Jan-: I'd imagine so.
09:45 AM Jan-: basically we're using a timer/counter with the input comparator to read some serial data.
09:46 AM tpw_rules: like it has to wait for the end of the current instruction so there's 1/2 cycles of jitter, but not really
09:46 AM tpw_rules: but then it's constant
09:46 AM tpw_rules: what protocol are the inputs and outputs speaking?
09:46 AM Jan-: it's about the time taken for the interrupt to detect the edge, our code to process it, realise it has a complete frame of data, act on that, and flip the latch.
09:46 AM Jan-: that should be consistent
09:46 AM tpw_rules: oh, yeah
09:47 AM Jan-: input is SMPTE-12M linear timecode, which is biphase mark encoded serial data at about 2400-3000bps
09:47 AM Jan-: output is we're driving an 8 digit, 7 segment display via shift registers, which we can pre-fill with the right numerals then just flip their combined latch line to update the display.
09:47 AM Jan-: we should be able to hold that to a pretty decent error
09:48 AM tpw_rules: ok i don't understand where the drift can appear?
09:48 AM tpw_rules: that there's not exactly and precisely 1/60th of a second between latch triggers?
09:48 AM Jan-: Ah. Well, the drift happens when we do "jam sync" where the device has to listen to the smpte-12m for a while, get in sync, then remain in sync when the input signal goes away.
09:48 AM Jan-: the better the clock, the longer it will stay in sync.
09:48 AM tpw_rules: oh ok
09:48 AM Jan-: a conventional crystal will not maintain sync for a useful period of time.
09:48 AM Jan-: a tcxo can
09:49 AM tpw_rules: so you prime it with some SMPTE timecodes, then it runs on its own even as the timecodes are no longer presejt
09:49 AM Jan-: Precisely.
09:49 AM Jan-: By the way, you have won a prize as person 1,000,000 to whom I have had to explain this before they will accept my need for a tcxo is actually valid :)
09:49 AM tpw_rules: yay!
09:50 AM tpw_rules: is it a new car
09:50 AM Jan-: It's a cookie.
09:50 AM Jan-: Enjoy.
09:50 AM * Jan- stuffs large chocolate cookie into tpw's mouth
09:51 AM Jan-: So will this do? https://www.ebay.co.uk/itm/1PCS-TCXO-0-3PPM-16MHz-16-000MHz-Square-wave-Ultra-precision-Oscillator/332222668415?hash=item4d5a039e7f:g:hCAAAOSwuMZZGm3R
09:51 AM Jan-: I mean it's chinesium so I guess it isn't really 0.3ppm
09:52 AM tpw_rules: should do
09:53 AM tpw_rules: it's 5V
09:53 AM Jan-: can I blame you if it doesn't work?
09:53 AM Jan-: or Tom_L
09:53 AM tpw_rules: def him
10:00 AM tpw_rules: so is this thing like a stationary clapper board?
10:00 AM Jan-: no, it's an actual clapper board :)
10:01 AM tpw_rules: oh
10:01 AM tpw_rules: so you plug it in at the beginning of the day then it's ready for the whole day
10:01 AM tpw_rules: neat
10:01 AM Jan-: well, resync at lunch often
10:01 AM Jan-: but yes.
10:01 AM Jan-: it's a clone of a device that totally exists, I just thought it'd be a good beginner project
10:01 AM Jan-: actually it's sort of a PITA
10:01 AM Jan-: but I think I can do it
10:01 AM tpw_rules: sounds it
10:02 AM Jan-: I already wrote the SMPTE-12M decoder and display stuff, we have a breadboard version that will drive a big display with the timecode digits.
10:05 AM Jan-: the next thing we want to do is a remote focus controller for lenses
10:05 AM Jan-: which is sort of easier as it's just a giant radio control servo with some scaling stuff
10:06 AM tpw_rules: have you actually looked up gps pps specs?
10:06 AM tpw_rules: like if it loses lock, what's the drift on that
10:07 AM Jan-: I uhoh
10:07 AM Jan-: we did think that theoretically we could use GPS to calibrate these things
10:07 AM Jan-: there's almost no better clock
10:08 AM tpw_rules: so yeah, can you dump all the hard part of clocking into a gps module?
10:09 AM tpw_rules: http://blog.dan.drown.org/gps-pps-drift-when-it-has-no-signal/
10:12 AM Jan-: Maybe, but it seems easier to just hack the TCXO in and have a base clock we can rely on.
10:12 AM tpw_rules: idk
10:12 AM Jan-: at some point we will have to cal these things
10:13 AM tpw_rules: idk order a few and see what happens
10:13 AM Jan-: and for that we will need a really good clock, to characterise how near to 16 million hits a second we're *really* getting.
10:13 AM tpw_rules: why will you have to cal them? can't you do it based oon the timecode?
10:13 AM Jan-: well they also have a mode where they generate timecode
10:13 AM Jan-: (which is easy to program, but anyway)
10:13 AM Jan-: and that needs to be... um. *right*
10:13 AM tpw_rules: sure, but you can just ask the user to plug it in to an existing timecode source?
10:14 AM Jan-: Yes, but then we're only as good as that source, and that source may be BS.
10:14 AM Jan-: Frankly that's likely to be good enough for most people
10:14 AM tpw_rules: ah
10:14 AM Jan-: but sure yes
10:15 AM tpw_rules: well there's another reason to get a gps in there :P
10:15 AM Jan-: well we did think hmm, we could include a GPS module
10:15 AM Jan-: then put a "calibrate" mode in the menus
10:15 AM Jan-: and it could sit there in a gps-available place for a while and sort itself out
10:16 AM Jan-: the thing that worries me about that most is actually the code space, it's only an atmega328 and the ram is already half used
10:16 AM tpw_rules: do you mean ROM?
10:16 AM Jan-: both
10:16 AM Jan-: it's shit out of resources
10:16 AM tpw_rules: are you doing it all in C
10:17 AM Jan-: yes.
10:17 AM tpw_rules: hm
10:17 AM Jan-: there's some debug I can chop out but it's not going to be night and day
10:17 AM Jan-: 2k of ram is not heaps
10:17 AM tpw_rules: no but like how are you planning on cycle counting in C
10:18 AM tpw_rules: what does this thing even need ram for
10:19 AM tpw_rules: -Os -ffunction-sections -fdata-sections -Wl,--gc-sections -mcall-prologues
10:19 AM tpw_rules: maybe -mstrict-X too
10:19 AM Jan-: we're using the analog comparator to read the smpte-12m
10:20 AM Jan-: and an input capture interrupt
10:20 AM Jan-: and a timer.
10:22 AM Jan-: then in the ISR for TIMER1_CAPT_vect we have if(ICR1>ltc_bitperiod_threshold) ...
10:22 AM Jan-: works fine
10:24 AM tpw_rules: are you using floating point?
10:25 AM Jan-: None so far I think
10:26 AM tpw_rules: i'm just not sure what you would be using code space on
10:26 AM Jan-: I will eventually have to as there will be one large long division in the "listen for a while and then synchronise do it" code
10:26 AM tpw_rules: yeah but why do you need floats?
10:26 AM Jan-: well, I'll listen for 10 seconds say
10:26 AM Jan-: listen for how many clock periods there are per frame
10:27 AM Jan-: total it all up, divide by framerate * 10
10:27 AM Jan-: that's your clocks per frame, the last frame in the window period will be odd length to make up any difference.
10:29 AM Jan-: so yeah. one large, ugly division
10:30 AM tpw_rules: yeah but you don't need floats for that
10:30 AM Jan-: as long as it aims low no.
10:30 AM Jan-: say I have 250,001 counts per 10 second period, then the answer I need is that it's 249 frames of 1000 clocks, and one frame of 1001 clocks.
10:33 AM Jan-: if that makes sense
10:34 AM tpw_rules: div and mod?
10:36 AM * Jan- blinks in the same manner as a cow that's just chewed a particularly tasty bit of grass
10:36 AM Jan-: ....moo?
10:41 AM Jan-: what does that mean tpw_rules
10:42 AM tpw_rules: the modulus operator
10:43 AM Jan-: so I have my total sample count which will be some large number
10:43 AM Jan-: roughly 10*16million if I count in single clocks
10:43 AM Jan-: and I need to divide that into 250
10:44 AM tpw_rules: well floats will not give you that much precision
10:44 AM tpw_rules: oh i read that wrong
10:44 AM tpw_rules: they should. but it's ill-advised
10:46 AM Jan-: I need two numbers.
10:46 AM Jan-: How many clocks per frame, and how many left over.
10:47 AM Jan-: the left over, yes, is a modulo thing.
10:47 AM Jan-: how many per frame could be an integer thing since we don't worry too much about the precision.
10:47 AM tpw_rules: both are integer operations
10:48 AM Jan-: will it round down or up, if I go int x, int y, z = x/y
10:48 AM tpw_rules: down
10:48 AM Jan-: well that works then
10:49 AM Jan-: so the calculation is ticksPerFrame = totalTicks / (sampleTime * frameRate)
10:49 AM Jan-: then remainingTicks = totalTicks % ticksPerFrame
10:49 AM tpw_rules: yes??
10:49 AM Jan-: of course frameRate may be non-integer :/
10:49 AM tpw_rules: idk
10:49 AM tpw_rules: you could express it all in terms of 16MHz clock units
10:50 AM Jan-: frame rates may be 24000/1001 or 30000/1001
10:50 AM Jan-: you could, you would need to know precisely what the clock was
10:50 AM tpw_rules: ahhh, ntsc
10:50 AM Jan-: yes. Fuck NTSC and the horse it rose in on. It is a nightmare.
10:50 AM tpw_rules: well don't you anyway for your task
10:51 AM Jan-: possibly.
10:51 AM Jan-: the problem is that it then needs to calculate that stuff at runtime based on a (not very round) actual clock speed, and the 30000/1001 frame rates
10:51 AM Jan-: for which it then needs the floating point library
10:52 AM Jan-: Although to be fair (sampleTime * frameRate) is fixed.
10:52 AM Jan-: It's just a long float.
10:52 AM tpw_rules: also remember arduino doesn't have doubles
10:53 AM tpw_rules: so you only get ~ 7 sig figs
10:53 AM Jan-: actually this is wrong anyway
10:53 AM Jan-: because we don't know sampleTime
10:53 AM Jan-: what we're actually doing is waiting until we have 10 seconds worth of frames, we're not actually attempting to wait 10 seconds.
10:54 AM Jan-: we don't care how long it actually takes, we're just waiting for the "seconds" digits in the incoming timecode to tick up 10 times.
10:54 AM Jan-: in some sense it doesn't matter what our native clock is as long as it is stable, we just care how many ticks of it there are per incoming frame.
10:55 AM Jan-: am I making any sense
10:55 AM tpw_rules: maybe, i'm not paying that much attention
10:56 AM * Jan- scratches head
10:56 AM Jan-: good thing one of us is :/
10:56 AM tpw_rules: i'm mildly busy, sorry
10:56 AM tpw_rules: but yeah that does make sense actually
10:56 AM tpw_rules: i looked this time
10:57 AM Jan-: s'OK
10:58 AM Jan-: I'm thinking aloud really
10:58 AM Jan-: ultimately we don't *care* what the frame rate is. We just care how many ticks per frame.
11:00 AM Jan-: the number of frames we sample will always be a whole number because that's the only way we can actually count frames, so it is doable integer.
12:12 PM Jan-: well, I ordered the TCXO
12:41 PM nuxil: Have fun with it :p
01:09 PM nuxil: PROGMEM
01:12 PM nuxil: who want to explain it to me :p
01:12 PM nuxil: what is it good for? im not sure i understand the difference between it and global variables?
01:12 PM nuxil: i mean. i sais it puts the data in the Program Space.. but what does that actually mean.
01:12 PM cehteh: flash
01:12 PM cehteh: AVR's have quite little ram
01:12 PM cehteh: so you may offload some static data to flash
01:12 PM nuxil: so you turn part of the flash into ram ? so to speak ?
01:13 PM cehteh: no
01:13 PM rue_mohr: yea they aren't likea an arm processor or a desktop PC, so you dont have much memory to work with, dont multitask and done use c++
01:13 PM cehteh: you just put static things into flash, you can change them there and reading from flash needs special instructions
01:14 PM nuxil: aha
01:14 PM nuxil: i get it.
01:14 PM cehteh: google "Harvard Architecture" .. avr's are such beasts where code and data reside in different address spaces
01:14 PM rue_mohr: they are for realtime, dedicated tasks
01:14 PM rue_mohr: like controlling the current on my servo motor
01:14 PM nuxil: http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
01:14 PM nuxil: :D
01:15 PM cehteh: from normal PC's you are more likely used to 'Von Neumann' architectures where data and code is share in one address space
01:15 PM nuxil: yea all modern pc's are von neumann
01:16 PM cehteh: all common, doesnt depend on new
01:16 PM cehteh: as everything each has its advantages and disadvantages
02:00 PM NoHitWonder: <cehteh>from normal PC's you are more likely used to 'Von Neumann' architectures where data and code is share in one address space
02:00 PM NoHitWonder: harvard can also share same address space
02:01 PM NoHitWonder: memory map of stm32f4 https://note_embedded2016.hackpad.com/ep/pad/static/Q1oJ3O7AHoB
02:02 PM NoHitWonder: https://hackpad-attachments.s3.amazonaws.com/note_embedded2016.hackpad.com_Q1oJ3O7AHoB_p.577035_1461657410656_undefined
02:03 PM NoHitWonder: more info about it http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3839.html
02:20 PM NoHitWonder: its the separate busses for data and instructions that make the distinction, not the address space
03:21 PM polprog: basically you keep the stuff that is not changing (for example a lookup table or message strings) in PROGMEM so they sit in big flash instead of taking up ram, which can be used for things which actually change during execution
04:09 PM hetii: Hi
04:09 PM hetii: :)
04:12 PM Emil: Hi
04:35 PM polprog: hi
04:35 PM polprog: got a new toy today
04:35 PM polprog: a dell
05:08 PM hetii: polprog, hi :) good for you :)
05:12 PM hetii: polprog, I also got new toy: https://obrazki.elektroda.pl/5374988400_1510489608.jpg
05:12 PM hetii: https://obrazki.elektroda.pl/1954944700_1510489607.jpg
05:13 PM hetii: its Nokia FPS-21 programmer that is based on 32bit cpu and FPGA.
05:13 PM hetii: Just wonder if there is a chance to put some own firmware on it and use it for eg as a NAS or some other device...
05:14 PM hetii: as I check sdcards there are partitions formated as linux-raid so maybe there is some sort of linux already :)
05:24 PM hetii: Time for me, see you next time :)
08:00 PM nuxil: so im trying to make sense of PROGMEM and all that.. but i get tonz of warning when i try to use it :\
08:01 PM nuxil: im not sure what im doing wrong.. can anyone take a look at ThaArray and Test() and the output.. ???
08:01 PM nuxil: https://pastebin.com/R3xFC4KV
08:10 PM nuxil: ffs.
08:10 PM nuxil: im blind
08:11 PM _ami_: nuxil, well.. its array size issue
08:11 PM nuxil: ThaArray[3][3][2]
08:11 PM nuxil: lol
08:11 PM nuxil: yea
08:11 PM _ami_: should be [9][2]
08:11 PM nuxil: just saw it
08:12 PM _ami_: damn. i am scared of my korean language class teacher. :P
08:13 PM _ami_: learning a new language is so HARD
08:13 PM nuxil: o.O korean ?
08:13 PM _ami_: and its became harder when you don't really put more efforts. :P
08:13 PM * _ami_ lives in S. korea
08:14 PM nuxil: ahh that explains it. thought you where preparing yourself for Kim Jong-un to take over the world :p
08:14 PM _ami_: lol
08:14 PM _ami_: americans are crazy abt him. especially the president.
08:16 PM nuxil: how is the food down there ?
08:18 PM _ami_: i like food here
08:18 PM _ami_: i like spicy foods.
08:18 PM nuxil: what do they eat ? nudels and stuff ?
08:18 PM _ami_: well, all indians like spicy food so yeah!
08:19 PM _ami_: the korean fried chicken is way better than those KFC etcs
08:20 PM nuxil: im not a big fan of spicy food. you taste nothing. it only burns in your mouth. :p
08:20 PM _ami_: :)
11:14 PM Ameisen: I think I finally got my heater manager code somewhat useful
11:14 PM Ameisen: https://i.imgur.com/h6BERJl.png
11:19 PM nuxil: explain more..
11:20 PM Ameisen: trying to eliminate temperature fluctuations in 3d printer
11:21 PM nuxil: oki.
11:21 PM Ameisen: so wrote a custom, non-PID temperature controller
11:21 PM nuxil: looks loke yout heater is pwm'ing :p
11:21 PM Ameisen: well, yes
11:21 PM Ameisen: it's a controller to control the PWM value of the heater
11:25 PM day__ is now known as daey
11:26 PM cehteh: Ameisen: for non 3d printer i have good experiences with cascaded pid and feed forward
11:27 PM cehteh: would prolly apply to 3d printer as well, dunno if cascading makes sense but you can use feed rate and ambient for a feedforward
11:28 PM Ameisen: certainly
11:28 PM Ameisen: I just wanted to try something that wasn't PID
11:28 PM Ameisen: also easier to implement in AVR where there's no floats
11:29 PM cehteh: you can do pid on integer
11:53 PM _ami_: Ameisen, why not just use ints?