Back
[00:52:10] <Casper> ah great... more data error... grrrr
[01:36:32] <LOMAS> rue_shop3, hello, u there ?
[01:59:12] <rue_shop3> yea
[01:59:31] <rue_shop3> just closing up the shop, give me another 15 mins or so
[02:02:50] * Casper blocks rue's shop door from the outside
[02:05:43] <rue_house> LOMAS, ok,
[02:06:08] <rue_house> your goal is to delay for 1us right?
[02:06:16] <rue_house> er, 50ms
[02:07:00] <LOMAS> rue_bed, 50 ms
[02:07:03] <rue_house> LOMAS, how are you measuring the timing of the code?
[02:07:10] <rue_house> by output freq?
[02:08:05] <LOMAS> with a oscilloscope.
[02:08:21] <rue_house> ok, your delay isn't working cause its comming out to slightly more than 50ms?
[02:08:25] <rue_house> or its not working at all
[02:09:05] <LOMAS> it is not working at all. It shows same delay If I change the TCON register too
[02:09:33] <rue_house> your aware that you set it up for a 1024 clock divider?
[02:09:49] <rue_house> and then your comment says 'no divider'
[02:10:32] <rue_house> 0x01 is no division of clock rate
[02:11:23] <LOMAS> no no I think I have divided the clk
[02:12:10] <LOMAS> rue_house, look at line 27
[02:12:40] <rue_house> comment says 'no prescaler' and you program it to a prescaler of 1024
[02:12:42] <LOMAS> rue_house, there I have TCCR0 = 0x05; i.e. clk/1024
[02:12:45] <rue_house> what do you want
[02:12:50] <rue_house> what is your cpu clock?
[02:12:55] <LOMAS> 4MHz
[02:13:04] <rue_house> ok
[02:13:08] <LOMAS> That was previous comment I forget to change, sorry
[02:13:22] <nuxil__> LOMAS, why have you made your own delay function. and not just included the delay header and use delay_ms(50) in your main loop?
[02:13:43] <rue_house> so with no divider you would want 12500 cycles
[02:13:43] <nuxil__> im a noob so i got to ask :p
[02:14:01] <LOMAS> nuxil__, it is not independent from interrupt. Is it ?
[02:14:15] <rue_house> LOMAS, ok, so lets try a divide of 1024
[02:14:35] <nuxil__> LOMAS, idk
[02:14:38] <LOMAS> rue_house, okay lets try out
[02:14:46] <LOMAS> rue_house, idk ??
[02:14:54] <rue_house> LOMAS, with a divide of 1024, you would want 12.207 counts, which I dont suggest
[02:15:11] <LOMAS> rue_house, then ?
[02:15:16] <rue_house> options are /1 /8 /64 /256 and /1024
[02:15:27] <LOMAS> rue_house, yse
[02:15:39] <rue_house> with /8 you would want 1562.5
[02:15:57] <rue_house> with /64 you would want 195.313
[02:16:04] <rue_house> which can be done
[02:16:17] <LOMAS> rue_house, do you mean, the higher pre-scaler disturbes the delay ?
[02:16:22] <rue_house> with /256 you would be 48.828
[02:16:44] <LOMAS> rue_house, /256 suits more I guess
[02:16:50] <rue_house> the system takes the 4Mhz, divides it by the prescalar, and then uses that as the counter clock
[02:16:55] <rue_house> no
[02:17:03] <rue_house> you will get more accuracy with the .64
[02:17:09] <LOMAS> oh
[02:17:16] <rue_house> you want to use the largest number you can fit in the 8 bit register
[02:17:26] <rue_house> 195 wil fit
[02:17:44] <rue_house> if we round to 195, we get a delay of
[02:18:04] <LOMAS> okay
[02:18:09] <LOMAS> lets try it then ?
[02:18:20] <LOMAS> lets try it then
[02:18:28] <rue_house> calc "((4/1000000)*64)*195"
[02:18:29] <rue_house> ((4/1000000)*64)*195 -->> 0.04992
[02:18:39] <rue_house> you get .4992 seconds, almost 50ms
[02:18:47] <rue_house> but hold on, lets keep fixing
[02:18:50] <rue_house> brb
[02:19:11] <Casper> c'mon rue_house you can do it! 50.00000ms!
[02:19:15] <rue_house> actaully, change that ^^ and repost i'll be back in a min
[02:21:07] <LOMAS> okay, thanks rue_house
[02:21:15] <LOMAS> I'll try and let you know
[02:21:33] <rue_house> no
[02:21:34] <rue_house> wait
[02:21:37] <rue_house> LOMAS, dont do
[02:21:40] <rue_house> its not gonna work
[02:21:43] <rue_house> we have to fix other tings
[02:21:55] <rue_house> you there?
[02:23:15] <rue_house> dont go...
[02:23:33] <rue_house> arg
[02:23:52] <nuxil> heh
[02:24:00] <nuxil> bet he will be back soon :p
[02:24:35] <rue_house> odd
[02:24:52] <rue_house> at a divide of 64, 3d is the right pre-load for the counter
[02:26:37] <nuxil> i still dont get it why he cant use the delay_ms() fnc.
[02:26:56] <rue_house> he didnt reset it right
[02:31:12] <nuxil> altho. on the subject of delay_ms. why does it need a constant. example i cant use it in a fnc like. void mydelay(t) { delay_ms(t);}
[02:31:24] <nuxil> any reasons to why?
[02:31:42] <rue_house> arduino sucks?
[02:31:53] <nuxil> idk. dont have one
[02:32:06] <rue_house> oh is it in an avr library?
[02:32:10] <nuxil> yea
[02:32:20] <rue_house> technically the loop throws out the timing
[02:32:29] <rue_house> its another problem with LOMASs code
[02:32:47] <nuxil> yea.
[02:33:00] <rue_house> the delay is good between the start and end of him using the timer, but when he puts it in a loop, it will be thrown out by the loop overhead
[02:33:12] <rue_house> GOOD coders can make delay functions that account for it,
[02:33:22] <rue_house> I'm gonna guess he dosn't even need it that accurate
[02:33:32] <rue_house> just calling a function is a reasonable delay
[02:34:24] <rue_house> http://hastebin.com/ubumemiquk.coffee
[02:34:29] <nuxil> should he not be use a ISR_blah fnc to reset blink the light instead
[02:34:30] <rue_house> does that link work to the code I modified?
[02:34:35] <nuxil> to avoid the while loop
[02:34:46] <rue_house> it really depends what he's trying to do
[02:35:30] * Casper thinks he might have to seriously consider a total rewrite once this code hit the avr...
[02:35:31] <rue_house> if you want to make an led flash really accuratly, then yea, or make an interrupt routine that has latency, but not added delay
[02:35:39] <Casper> switch are expensive on avr
[02:35:58] <rue_house> Casper, did you try if-else?
[02:36:12] <rue_house> how ugly is the switch?
[02:36:20] <Casper> last time I did, it was way cheaper to use if else
[02:36:34] <Casper> rue_house:
https://bpaste.net/show/e060d32af152
[02:37:03] * rue_house mumbles a question about just how many code paste sites are out there
[02:37:30] <rue_house> why the hell are you buffering on a microcontroller!?
[02:37:38] * nuxil sips some tea
[02:37:41] <rue_house> state machine, deal with charactesr when they come in
[02:37:43] <Casper> this code is not µC yet
[02:37:58] <Casper> so I can afford to not optimise fully
[02:38:29] <rue_house> ... LUT?
[02:39:29] <rue_house> your function is waaaay too long...
[02:40:00] * rue_house hands casper a state machine
[02:40:07] * rue_house hands casper a few more
[02:40:52] <rue_house> packets are ugly as all sin aren't they?
[02:41:23] <rue_house> are you decoding manchester?
[02:42:39] <rue_house> Casper, I hurt my brain
[02:42:50] <rue_house> I'm glad this is your challange and not mine :)
[02:42:58] <rue_house> damnit, its tommorow
[02:43:19] <rue_house> :( I have to go to work
[02:43:22] <rue_house> too soon
[02:45:10] <Casper> rue_house: no... a monky protocol that appear to have been badly tought...
[02:45:42] <rue_house> immediatly apparent when a variables bit are spead over 3 bit groups
[02:45:49] <rue_house> bits
[02:45:50] <Casper> most use a least significant bit first, the checksum use MSB
[02:46:27] <Casper> rue_house: oh you don't have the data...
[02:46:40] <Casper> rue_house:
https://bpaste.net/show/ed1b9b6a0939
[02:47:02] <rue_house> are the packets nativly 64 bit?
[02:47:12] <Casper> 36 and 32 bits
[02:48:04] <nuxil> 36?
[02:48:06] <Casper> it look like I could cut the last nibble of the packet 0 and 3
[02:48:13] <rue_house> data logger?
[02:48:18] <Casper> yup, 36 + 32 + 36 + 32
[02:48:41] <Casper> most bits in the first half are repeated in the second half...
[02:48:44] <rue_house> 36 bits is just to screw up anyone who thought they could deal with it in 32 bits
[02:48:56] <cehteh> hehe wtf
[02:48:58] <Casper> rue_house: heat pump remote control
[02:49:52] <Casper> for now, it will stay in 64 bits, but if no test case show the last nibble from being used it WILL go 32 bits
[02:50:04] <Casper> up to now, the last nibble is always 0010
[02:52:02] <Casper> it's funny
[02:52:27] <Casper> fan speed in packet 0 is: auto 1 2 3 3 3 but in packet 2 you have auto 1 2 3 4 5
[02:52:53] <Casper> I feels like the first 2 packets are for some older model, that they kept it for backward compatibility
[02:53:38] <nuxil> that might be it
[02:54:54] <nuxil> so will the heatpump accept only 36+32 instead of 36+32+36+32 ?
[02:54:54] <Casper> hmmm finally it's the last 7 bits that always stay the same... device ID?
[02:55:19] <Casper> nuxil: didn't tried yet, but if it does, then I miss some functions
[02:55:35] <Casper> like fan speed 4-5
[02:56:58] <Casper> bed time, nite
[02:57:06] <nuxil> nite
[02:58:07] <rue_house> gnight
[03:03:55] <rue_bed> gnight
[06:57:55] <Lambda_Aurigae> Jartza,
http://feedproxy.google.com/~r/hackaday/LgoM/~3/mh91CdriA5M/
[06:58:01] <Lambda_Aurigae> hmm.
[06:58:03] <Lambda_Aurigae> that don't work.
[06:58:19] <Lambda_Aurigae> Jartza,
http://hackaday.com/2016/01/04/driving-ws2811-leds-with-vga/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29
[06:58:21] <Lambda_Aurigae> there.
[06:58:48] <Lambda_Aurigae> instead of using a microcontroller to drive vga....use vga output to communicate with a microcontroller...or an led thingie.
[08:09:15] <Jartza> Lambda_Aurigae: hehe, cool!
[08:35:55] <Knaldgas> Anyone know of a really small AVR-based board with RS485 or CANBus drivers, and wide-range input on-board voltage regulator (6-16V'ish)?
[08:36:17] <Knaldgas> Ahh, and transient protection on-board
[08:39:08] * LeoNerd doesn't really /know/ boards; having a tendency to make them instead :)
[10:07:07] <LeoNerd> When assigning timers on chips, do Atmel just roll dice or something?
[10:07:33] <LeoNerd> Given a chip of, say, 4 timers, it seems arbitrary which ones they've chosen to be 8 or 16bit, which ones might be async-capable, how many compare outputs they have, ...
[10:07:58] <LeoNerd> I thought I'd seen a general pattern that timer 0 is 8bit, timers 1 and 2 are 16bit, timer 2 can do async, ... but then the ATmega128(A) breaks that entirely
[10:20:10] <cehteh> how does atmel design chips anyway? i always feel its on *big* customer demand, and only then put into market
[13:24:38] <nuxil> im a bit confused about the PB5 pin on the ATtiny85, is this pin by default a reset pin?
[13:40:51] <ali1234> nuxil: it depends on the fuse setting
[13:44:35] <nuxil> ali1234, ok. will check it out later, busy soldering now :)
[13:48:02] <cehteh> nuxil: usually if you didnt refuse it, tinys shipped with reset enabled and clkdiv/8 enabled
[13:48:30] <cehteh> aka .. the way you can easily reprogram them from a nomal ISP
[13:49:23] <nuxil> i havent refused it
[13:50:07] <nuxil> but i dont want to use it as a /reset button , but rather a PCINT
[14:04:17] <Tom_itx> don't you need that pin for programming?
[14:25:28] <cehteh> nuxil: do you have a high voltage programmer?
[14:26:30] <cehteh> if not, you can disable the reset by a fuse once ... use it as I/O .. but never again :)
[14:28:15] <cehteh> used reset as is for input, just detect at startup if we got a reset, and build the program with all variables which contain state in the noinit segment
[14:29:09] <cehteh> that way you can use the reset line for very simple things (here its a user interface to change modes by a button)
[14:51:11] <nuxil> oh
[14:51:52] <nuxil> got and example :p
[14:54:58] <cehteh> link?
[14:55:56] <cehteh> ah .. another thing, with bootloader you can disable the reset line and still reprogramm the chip
[15:00:37] <nuxil__> cehteh no.. sorry. it was a question,, forgot the to include the ? :p
[15:01:23] <cehteh> :D
[15:01:29] <cehteh> moment
[15:02:07] <cehteh> http://git.pipapo.org/?p=battswitch.git;a=blob;f=src/battswitch.c
[15:02:24] <cehteh> using the reset to click through the calibration
[15:04:31] <cehteh> important part is to have a lot variables defined __attribute__((section (".noinit"))) ... then the Clib startup will not reinitialize them
[15:05:27] <cehteh> and that you safe the MCUSR into a backup variable early (some do that in .init sections as well)
[15:06:16] <cehteh> later it checks if it got started from a reset condition and eventually interates a reset counter which toggles through different calibration steps
[15:07:14] <nuxil> nice.. thats like a hole program.. not and example :p my mind is about to blow up trying to figure out what going on all over the place :D
[15:08:09] <cehteh> well i wont make you an example from that :D .. but i gave you an description things are relative easy to figure out
[15:08:30] <nuxil> thx
[15:09:53] <cehteh> MCUSR holds some bits telling why the device booted (power on, reset, watchdog, brownout ...)
[15:11:25] <cehteh> the sram will not be cleared on reset, its the nasty C lib which does that. but the mpu registers get reset and you have to initialize everything
[15:12:10] <cehteh> well you may also forget about what i saied now and see my remark that you can disable reset when you have a bootloader to flash the program
[15:12:28] <cehteh> https://github.com/micronucleus/micronucleus
[15:47:03] <cehteh> duh .... 150Baud is too slow prescaler overflow
[17:22:08] <MarkX> i made this macro "(DDRF |= (0 << DDRF0)", i see DDRF has been defined before but there is no definition for DDRF0....but i don't get any warnings or errors in atmel studio
[17:22:15] <MarkX> am i missing something?
[17:48:37] <Tom_itx> it's not defined in the part header file?