Back
[09:39:28] <illumer> Hello dears
[09:39:50] <illumer> learath
[09:43:31] <illumer> Learath
[11:41:36] <Malinus> Hey guys. I've always programmed my AVR's from windows, using the wonderful automagic of Atmel Studio. I'm trying for the first time to do it from linux, and avrdude can't even seem to find the programmer. Giving me the "avrdude: Error: Could not find USBtiny device (0x1781/0xc9f)". Yes I'm running as root, and the programmer is connected ("Bus 002 Device 006: ID 03eb:2104 Atmel Corp. AVR ISP mkII" -it's Tom_itx's programmer).
[11:45:39] <Tom_itx> avrdude -c avrisp2 -p t10 -P usb -C "C:\WinAVR\bin\avrdude.conf" -e
[11:46:05] <Tom_itx> to erase
[11:46:24] <Tom_itx> avrdude -c avrisp2 -P usb -p t10 -v -U flash:w:C:\avrtest\Tiny10_asm\t10blink.hex:i
[11:46:31] <Tom_itx> you probably don't need the -v
[11:48:04] <Malinus> Tom_itx, it might not have came trough clear enough, sorry about that - but I'm on linux :)
[11:48:29] <Tom_itx> yeah, hang on
[11:48:42] <balrog-k2n> hi, is there any relatively unique serial id that can be read from a register on an atmega328?
[11:49:16] <Tom_itx> avrdude -c avrisp2 -p m328 -P usb -U flash:w:"/usr/local/avr/test.hex":a
[11:50:55] <atom1> avrdude -c avrisp2 -P usb -p m128 -v -U flash:w:/home/tom/avrtest/atmega128/blink_led.hex:i
[11:51:02] <atom1> right off my linux box
[11:53:20] <Malinus> yeah, the thing was, it's -c avrisp2 and not -c tinyusb
[11:53:58] <Lambda_Aurigae> balrog-k2n, there is the device-id but that is not unique to each chip, only to chip type.
[11:54:51] <Malinus> nope that wasn't it Tom_itx... I'm getting avrdude: stk500v2_ReceiveMessage(): timeout using "avrdude -c avrisp2 -p t85"
[11:55:00] <balrog-k2n> Lambda_Aurigae: ah :/ looking for something to use as a network address
[11:55:06] <balrog-k2n> the radio chip has no serial id register either
[11:55:45] <balrog-k2n> guess i'll need to generate one to sit in the eeprom
[11:58:14] <Lambda_Aurigae> eeprom is probably easiest unless you want to recompile for each device and put it in flash.
[11:59:20] <Lambda_Aurigae> I did a wireless mesh once and the devices all started with the same address and I used something like a dhcp server...if they chimed in with the default address it would assign the next on the list and the devices would then program that as their "permanent" address.
[11:59:41] <Lambda_Aurigae> so you power them on one at a time and give them a few seconds till the OK light blinks then on to the next one.
[12:00:57] <Tom_itx> Malinus, did you swap firmware on the programmer at any time?
[12:02:50] <Tom_itx> you might wanna load the 131027 windows_studio version here:
http://tom-itx.dyndns.org:81/~webpage/boards/USBTiny_Mkii/USBTiny_Mkii_index.php
[12:03:08] <Tom_itx> it works with avrdude under linux but not avrdude under windows
[12:03:41] <Tom_itx> the whole libusb / jungo driver thing
[12:03:49] <balrog-k2n> Lambda_Aurigae: hmm that would work too, but I was also thinking of modifying the bootloader to be able to reflash over radio so it shouldn't be too complex of a mechanism
[12:04:10] <phinxy> Can i have two different timer interrupts on OCR2A and one on OCR2B?
[12:04:20] <Tom_itx> i doubt it
[12:04:37] <Tom_itx> look at your io.h file
[12:06:09] <Lambda_Aurigae> balrog-k2n, the bootloader can reload the flash without overwriting the eeprom so storing it in there should be fine...
[12:10:31] <ambro718> phinxy: yes you can
[12:11:10] <ambro718> ISR(TIMER1_COMPA_vect) and ISR(TIMER1_COMPB_vect)
[12:11:22] <ambro718> *TIMER2
[12:11:32] <phinxy> using 2 timers you mean?
[12:11:53] <ambro718> no, they will both compare against TCNT2
[12:12:09] <ambro718> then OCR2A==TCNT2, TIMER2_COMPA_vect fires
[12:12:36] <ambro718> some devices even have comparator C (atmega2560)
[12:12:45] <phinxy> i tought it worked like that but they interrupt at the same time. prob my configuration that is wrong then
[12:12:54] <Malinus> Tom_itx, no I've never changed the firmware. and I have the rev 1.1c version.
[12:12:58] <ambro718> it does work like that
[12:13:25] <phinxy> ambro718, is it better practive to use ocr comparitors than count a variable in C?
[12:13:34] <ambro718> what?
[12:13:45] <ambro718> what is "counting a variable"
[12:14:16] <ambro718> but yes, I do believe that comparators are the best way to generate interrupts at desired times
[12:14:23] <ambro718> as long as you have enough of them
[12:14:34] <phinxy> Well im making a clock and i would like to use one ocr interrupt for the seconds and the other for minutes.
[12:14:53] <ambro718> just use one for seconds
[12:15:47] <ambro718> seconds++; if (seconds == 60) { seconds = 0; minutes++; if (minutes == 60; minutes = 0; ... } }
[12:16:18] <Malinus> Tom_itx, but you think I should update?
[12:16:29] <learath> illumer: ?
[12:17:13] <ambro718> phinxy: first calculate exactly how many timer ticks (T) correspond to one second. Then initialize with: OCR1A = TCNT1 + T; and enable the ISR, forgot how you do that.
[12:17:36] <ambro718> phinxy: then in the isr, above^^, plus, OCR1A += T;
[12:18:14] <ambro718> of course if T is not a whole number of ticks, you have a problem, and your clock will drift
[12:18:59] <phinxy> ambro718, counter is counting fine with an external watch crystal.. but ive messed up the settings somehow cause if i dont set ocr2b, which i dont even use the controller restarts randomly afer a couple seconds
[12:18:59] <ambro718> * this is assuming you're running the TC in normal mode, as opposed to CTC mode
[12:19:07] <phinxy> im using CTC
[12:19:42] <ambro718> well that is an option too, but if you do that, you effectively make that TC not useful for other purposes
[12:20:16] <ambro718> in normal mode and incrementing like I suggested, you can use the other comparator for an unrelated task
[12:21:06] <Tom_itx> Malinus, it should be ok if you haven't changed it
[12:21:11] <Tom_itx> unless you want the updates
[12:21:44] <lionrouge> hi :)
[12:22:22] <Tom_itx> Malinus, also you need avrdude 5.10 or later
[12:23:31] <lionrouge> how can i flash an avr MCU under Linux with a USB-UART board (FT232)?
[12:23:46] <Tom_itx> maybe avrdude
[12:23:57] <Tom_itx> check the device settings in avrdude.conf
[12:24:29] <lionrouge> ok, thanks
[12:24:41] <Malinus> Tom_itx, sorry my bad. I think that particular uC was dead.
[12:24:55] <Malinus> Tom_itx, I've tried another one and it works just fine
[12:25:03] <Tom_itx> oh, great!
[12:25:12] <Malinus> Tom_itx, thanks for the help though.
[12:25:29] <Tom_itx> np
[12:27:07] <Tom_itx> Malinus, the update gives you faster xmega programming
[12:27:23] <phinxy> ambro718, in non-ctc i would have to reset the timer manually tough so when it reaches its max 16-bit value it doesnt screw up the time?
[12:27:30] <Malinus> Tom_itx, I don't own a xmega, but that's nice to know
[12:27:34] <ambro718> phinxy: NO!!
[12:27:45] <ambro718> phinxy: that's the whole beauty of modular arithmetic
[12:28:03] <ambro718> phinxy: passing through the max value is irrelevant,
[12:28:30] <Tom_itx> Malinus, depending when you got yours there could be other things but nothing major
[12:29:20] <Tom_itx> mostly studio 6.1 updates
[12:29:28] <ambro718> phinxy: imagine a ring with the numbers from 0 to 2^16-1 laid out. The next number of 2^16-1 is simply 0. There's nothing special about it, the addition of T will wrap around, and the comparator will catch it at the right time.
[12:29:28] <Tom_itx> (version control)
[12:29:49] <ambro718> (or 2^8 if you have a 8-bit timer here)
[12:33:03] <_abc_> Does anyone know if newer versions of gpasm pic sim correctly simulate interrupt on gpio port change in p12f675 and 629? Mine does not. The code works right in a real device. This is a little off topic here but still relevantish. Hoping someone knows...
[12:33:03] <ambro718> phinxy: in this case the actual value of TCNT does not have much meaning to you, you'd only use it to get the ISRs firing at regular times. Each time the ISR fires increment your seconds, that's what you care about.
[12:33:22] <ambro718> phinxy: you could start with TCNT at a random number and it would work equally well...
[12:34:28] <phinxy> alright i guess all that math is done in hardware somehow. anyhows, excellent info
[12:35:24] <ambro718> phinxy: there's nothing special about it. (uint16_t)(65535+4) = 3. The C standard guarantees it and all.
[12:36:06] <ambro718> *well that particular expression, not, you'd need to make sure both your operands are uint16.
[12:36:51] <ambro718> phinxy: the behavior arises naturally once you simply forget about the carry when adding the bits
[12:37:07] <ambro718> *the final carry in case there's an overflow
[12:39:08] <DanFrederiksen> what's the name for a chip that does frequency counting? either digital or converts to a voltage
[12:41:17] <_abc_> frequency to voltage converters exist
[12:41:28] <_abc_> otherwise, frequency counter or period measurement
[13:09:30] <phinxy> Why does my interrupts blink the led every second but on different times? ist this code supposed to blink one led each 3rd second and the other every 300 seconds?
http://pastebin.com/cHmfMqWT
[13:10:08] <phinxy> ignore the custom delay function
[13:17:27] <illumer> learath
[13:21:47] <illumer> what are you people doing?
[13:21:58] <illumer> please tell me so I can do the same
[13:25:46] <Casper> illumer: watching youtube
[13:27:22] <illumer> :)
[13:27:58] <illumer> I like your spirit
[13:28:07] <illumer> won't you share some info
[13:28:10] <illumer> ?
[13:28:13] <phinxy> My timer is overflowing every second, shouldnt it increase by 1 each second on 1Hz?
[13:28:24] <illumer> I came here yesterday and had a great help
[13:29:46] <illumer> 16 bit timer?
[13:30:03] <phinxy> yeah its on a watch crystal
[13:30:27] <illumer> crystal oscillator you mean?
[13:30:36] <phinxy> its just a crystal
[13:30:44] <phinxy> well
[13:30:53] <phinxy> the built in oscillator uses it
[13:31:28] <illumer> you are talking about the oscillator not the counter right?
[13:31:59] <illumer> or I missed understand?
[13:32:22] <illumer> misunderstood*
[13:32:33] <phinxy> im talking about the counter but i tought it would increase OCRnx by 1 each second but its overflowing each second which means i got waay to high resolution
[13:32:43] <phinxy> i need like 1/4 of a second max
[13:33:13] <illumer> 16 bit counter right?
[13:33:16] <phinxy> yes
[13:33:57] <illumer> it gives 0-65535
[13:34:16] <illumer> then you can prescale
[13:34:35] <illumer> to 64
[13:34:39] <illumer> 1000000/64
[13:34:48] <illumer> 15625
[13:34:50] <phinxy> im using 128 and im getting 1Hz
[13:34:59] <illumer> yes
[13:35:04] <phinxy> 1024 is max
[13:35:17] <phinxy> that would be 1/10 of a second, right?
[13:36:04] <illumer> 1 MHz prescaled to 64 shall give you 15625
[13:36:17] <illumer> then put the top as 15625
[13:36:27] <illumer> it will interrupt each 15625
[13:36:29] <phinxy> im not using CTC
[13:36:44] <illumer> which will be like 1/4 of the prescaled 1 MHz
[13:37:08] <ambro718> phinxy: *you* need to increase the OCR
[13:37:47] <ambro718> inside the ISR, increment it by the number of ticks in one second (or minute)
[13:38:04] <ambro718> minute might not work, depending on your F_CPU and prescaler
[13:38:49] <phinxy> ambro718, yeah im gonna do that but it would be nice to have longer interrupt limit (less resolution). i guess the prescaler is the limiter?
[13:38:57] <ambro718> phinxy: why do you think the chip will magically guess how much you want it to increment??
[13:39:49] <ambro718> phinxy: once you get it working I can show you how to increase the timer to 32 bits
[13:39:53] <illumer> I think you will need to define a variable
[13:40:07] <ambro718> I don't think so, OCR doesn't change by itself
[13:40:11] <illumer> in case you dont want to prescale
[13:41:22] <phinxy> just to clarify; with prescaler 128 i get overflow every second. so with prescaler 256 i should get an overflow every other second(2)?
[13:41:25] <ambro718> illumer: without a prescaler the timer will increase at a rate of 32000 per second (you say so in the code). Which is sufficient for second counting, and not at all for minute counting.
[13:42:08] <ambro718> phinxy: the overflows are irrelevant, as long as you're not trying to increase the width to 32bits with software (you are not)
[13:42:53] <ambro718> phinxy: give me a minute I'll write the correct code...
[13:43:09] <phinxy> ambro718, Sure as you explained before but in order to count longer than 1 second
[13:43:14] <phinxy> no need dude ive got it
[13:43:18] <phinxy> i got it*
[13:43:43] <ambro718> phinxy: do you have the seconds counter working with OCR incrementing?
[13:43:54] <phinxy> yeah
[13:43:58] <ambro718> good :)
[13:44:15] <ambro718> phinxy: now don't bother with the minutes with another ISR.
[13:44:38] <ambro718> increment the minutes every 60 seconds from the seconds ISR. It's that simple.
[13:44:52] <ambro718> phinxy: do you want to keep counting the seconds ad infinitum or wrap at 60?
[13:45:07] <ambro718> i.e. you want a nice clock minutes seconds
[13:45:30] <phinxy> ill wrap it around. is there a clever way to store everything in one 8bit integer maybe?
[13:45:47] <phinxy> including hours
[13:46:04] <ambro718> phinxy: in the seconds ISR: clockseconds++; if (clockseconds == 60) { clockseconds = 0; clockminutes++; }
[13:46:18] <ambro718> phinxy: that extra piece of code is all you need
[13:46:24] <phinxy> thanks
[13:46:31] <illumer> so you are designing a watch?
[13:47:23] <ambro718> phinxy: be careful though, when you want to read the current clock from the main loop, you'll need to disable interrupts, read the seconds and minutes, and re-enable interrupts
[13:47:28] <ambro718> to get a consistent reading
[13:47:57] <phinxy> ambro718, i dont see any use of the other OCR2B tough.
[13:48:08] <ambro718> phinxy: that is good
[13:48:13] <ambro718> why do you want to use it?
[13:48:52] <phinxy> true, true.
[13:49:10] <ambro718> make it play a tune or something that makes you happy ;)
[13:50:17] <illumer> let us share my yesterday experience then
[13:50:41] <phinxy> Is it possible to get something to happend every 1/4 second? or do i need to change the prescaler?
[13:50:42] <illumer> I was working on SPI
[13:52:24] <illumer> the Master micro was using a spi function while the Slave was using interrupt
[13:52:44] <ambro718> phinxy: well you can use the other comparator for that
[13:53:00] <ambro718> phinxy: it's all about how much you increment the OCR each time
[13:53:12] <illumer> it worked well in the begining but when I added a global variable in the Master it didn't
[13:53:13] <phinxy> ambro718, yeah i can use one overflow, and two of the OCR's? for 1/3 second
[13:54:08] <ambro718> phinxy: if you're running the timer in normal mode overflow is not normally useful
[13:54:20] <ambro718> *you don't normally care about it
[13:54:38] <ambro718> phinxy: what you need to consider is whether 1/3 of a second is a whole number of ticks
[13:54:51] <ambro718> phinxy: is it?
[13:55:12] <illumer> are you following @ambro71 and @phinxy
[13:55:12] <illumer> ?
[13:55:31] <phinxy> ambro718, yeah
[13:56:01] <ambro718> phinxy: if it is a whole number, there's nothing special about it, just use another OCR and increment it by that amount each time
[13:56:20] <ambro718> phinxy: if it is not a whole number, that approach will lead to progressive accumulation of errors
[13:56:37] <ambro718> (and I can show you how to fix it with a little more code)
[13:59:34] <phinxy> alright, so if i use OCIE2A and B i dont need to care about accuracy over time but when using overflow i could get wrong time over time ..?
[14:00:27] <ambro718> no, it doesn't matter what mode you're using, only whether your desired interval is a whole number of ticks
[14:01:23] <ambro718> ticks = interval_in_seconds * timer_frequency_in_hz
[14:01:24] <phinxy> ok! so currently MAX is the desired interval.
[14:02:01] <ambro718> so if your timer frequency is 32kHz, and you want 1/3 second interval, ticks=32/3=10.6666
[14:02:08] <ambro718> so, you have a problem
[14:02:20] <ambro718> * wait I made a mistake...
[14:02:29] <phinxy> ah ok now i understand
[14:02:39] <ambro718> 32000/3 = 10666.66666
[14:03:30] <ambro718> is't not a whole number, so if you set up your interrupt to fire every 10666 ticks (whether you do it with CTC or normal mode and OCR incrementing), you'll be ticking at slower than 3 times per second
[14:03:54] <ambro718> gimme your current code, I can show you how to resolve that issue
[14:04:26] <phinxy> wait a second. do you know anything about music?
[14:04:38] <ambro718> nope, why do you ask
[14:05:13] <phinxy> i dont, but i would like to make a kind of music machine. do i choose between 1/4 bps and 1/3 or do i need both?
[14:05:41] <ambro718> I have no idea, but I can help you get 1/3 ticking right, without accumulating errors
[14:05:47] <phinxy> sure
[14:06:03] <phinxy> 32768 / 3 = 10922,6666
[14:06:08] <ambro718> so show your current code that ticks once per second or approximately once every 1/3 second
[14:09:47] <phinxy> ambro718, The closest prescaler to 1/3 of a second (128/3=42) is 32, is this close enough?
[14:10:21] <ambro718> phinxy: increasing the prescaler will only make it worse
[14:10:49] <phinxy> ambro, so i gotta use CTC?
[14:11:20] <ambro718> phinxy: your non-prescaled allows you to observe time with a certain resolution. If you prescale it by a power of two, you most definitely lose resolution.
[14:11:36] <ambro718> phinxy: you can deal with it in software. Let me explain...
[14:12:27] <ambro718> phinxy: so in general your problem is you want to fire the ISR in interval A/B, both A and B being a whole number of ticks
[14:13:03] <ambro718> sorry, A is an interval you can express as a whole number of ticks (1 second), and B is a positive integer
[14:13:07] <ambro718> get it?
[14:13:32] <ambro718> the key here is that you can express A as a whole number of ticks
[14:14:39] <ambro718> what you do is you set up your isr to fire with the period A/B, rounded to whole ticks. Now, every time you do a B ticks, you correct for the accumulated errors.
[14:14:54] <phinxy> so without a prescaler i get the resolution 38,768 each second and i need to pick a integer for OCRnA which is what?
[14:15:34] <ambro718> forget about the prescaler, let me show you...
[14:15:45] <ambro718> prescaling only makes the problem worse
[14:16:12] <ambro718> I'll just write it in code
[14:16:19] <phinxy> yes, please
[14:17:12] <phinxy> is that what _num does?
[14:26:06] <phinxy> i dont see how i could get an interrupt each 1/3 of a second with only OCR1A and B.
[14:26:21] <phinxy> without changing prescaler
[14:26:26] <ambro718> ok something like this
http://ideone.com/NTKGxT
[14:26:37] <ambro718> haven't tested it, might have a bug
[14:28:37] <ambro718> the catch here is that you keep a reference seconds_time, and every time you finish 3 (imprecise) 1/3rd second intervals, you increment your seconds_time by one second, and set OCR based on that
[14:29:12] <ambro718> so every time you finish the 3 1/3 second intervals, you fix the accumulated error
[14:29:35] <ambro718> and yes, there is a bug. Line 34 needs to be deleted ;)
[14:30:42] <ambro718> can you test if it works?
[14:31:20] <phinxy> Sure thing
[14:31:40] <phinxy> thanks ill try to understand this thing. i know whats the problem and solution is now tough
[14:32:09] <ambro718> yeah correct code is not always simple
[14:32:54] <phinxy> so i guess this will always be a very very small amount of time out of the right time but then again, always correct itself?
[14:34:18] <ambro718> yes, the worst case error will be twice the roundoff error in third_second_ticks, I believe
[14:34:24] <ambro718> (because 2 = 3 - 1)
[14:35:05] <phinxy> Ok. so this is all good. no prescaler needed, nice
[14:35:14] <ambro718> but because third_second_ticks is pretty large in the first place, it's not noticable
[14:36:12] <ambro718> now if your used a prescaler, the roundoff error could have been much larger.
[14:36:38] <ambro718> does it work?
[14:38:06] <Fleck> ambro718: btw, can you tell bootsz1:0 and bootrst fuse state?
[14:39:07] <phinxy> ambro718, does it matter how high float the microcontroller can handle?
[14:40:29] <ambro718> phinxy: best to add a const to those calculations above
[14:40:37] <ambro718> static uint16_t const second_ticks = ...;
[14:40:54] <ambro718> the compiler will most likely compute it at compile time
[14:41:14] <ambro718> (given reasonable optimization like -O2 or -Os)
[14:41:53] <ambro718> phinxy: the important thing to know about floats and AVR is to not use them in ISRs.
[14:42:21] <ambro718> In main, it's okay (unless your application has some very specific requirements)
[14:42:21] <rue_house> abc's usb code seems to be giving way for other usb code, whats the deal? I thought his usb stuff was in the lead there
[14:44:14] <ambro718> phinxy: there's nothing inherently broken with floats and AVR. They're just slow. Doing slow things in ISRs tends to break other ISRs which have certain expectations of how long it takes from interrupt being flagged to executing.
[14:46:13] <ambro718> phinxy: an important case here is the USART RX interrupt. The AVR hardware has a 2-byte buffer here, and if three bytes are received in succession while a very long ISR is being executed, the third one will be lost.
[14:48:04] <ambro718> Fleck: I don't know, surely the datasheet has something...
[14:52:56] <phinxy> ambro718, it blinks once! :D
[14:53:15] <Fleck> ambro718: thought you run that pasted code...
[14:55:02] <ambro718> phinxy: what do you mean once
[14:55:11] <ambro718> phinxy: it should toggle once per second
[14:55:31] <Fleck> phinxy: what chip btw?
[14:55:57] <phinxy> sorry my fault. i changed the int16 to floats
[14:56:33] <phinxy> 1284p
[14:57:20] <phinxy> didnt know a int could hold decimals.. :S
[14:57:24] <ambro718> phinxy: it's very important that they're uint16_t
[14:57:30] <ambro718> unsigned, 16-bit
[14:57:58] <ambro718> you did remove the incorrect counter++ in the else part right?
[14:59:03] <ambro718> phinxy: integer types hold integers, the range they can handle depends on the particular kind of integer type (unsigned/signed, bit width)
[14:59:39] <ambro718> phinxy: if you assign a float to an integer, it's rounded towards zero (except if it's out of range, that is undefined)
[14:59:45] <phinxy> ambro718, no i didnt. clockseconds looks fine tough
[14:59:59] <phinxy> i see.
[15:00:00] <ambro718> phinxy: so what's happening now?
[15:00:37] <phinxy> clockseconds is increasing on my LCD
[15:00:49] <phinxy> and it looks like seconds * 100
[15:00:56] <phinxy> * 1000
[15:01:26] <ambro718> so it's printing milliseconds or what?
[15:02:12] <ambro718> well also I'm an idiot, static uint16_t third_second_ticks = 0.3 * second_ticks;
[15:02:19] <ambro718> obviously incorrect
[15:02:41] <ambro718> 0.3 != 1/3
[15:02:47] <phinxy> i changed it to the value
[15:02:58] <phinxy> right!
[15:03:02] <ambro718> but not to 1/3, that's still zero ;)
[15:03:39] <ambro718> just set it to second_ticks/3, you don't really need float ops for this one
[15:04:56] <ambro718> if you paste the code you got I can take a look
[15:06:43] <phinxy> ambro now the time is too slow. ill paste it
http://pastebin.com/XihbyYVv hope u dont mind the LCD stuffs
[15:11:51] <phinxy> doesnt seconds_time overflow at some point?
[15:12:59] <phinxy> Doh
[15:13:29] <phinxy> i suppose you expected the interrupt to happen every second ambro718?
[15:14:02] <ambro718> phinxy: the interrupt should happen every 1/3rd second, but the led will toggle every second. What is it doing?
[15:15:10] <rigid> ambro718: do you know the difference between integer and float?
[15:15:11] <phinxy> the interrupt is happening 100 times more often or so
[15:15:32] <ambro718> rigid: I do.
[15:15:37] <rigid> also, 0.3 ~= 1/3
[15:16:03] <rigid> ambro718: and still you try to multiplicate 0.3 to an int? your compiler should go havoc on this
[15:16:16] <phinxy> rigid, yes but would make sense to use that in a watch program tough if it isnt accurate?
[15:16:25] <ambro718> rigid: it's a perfectly defined thing to multiply an integer and a float
[15:16:31] <rigid> phinxy: no, not a t all
[15:16:43] <rigid> ambro718: in C? no it's not
[15:16:51] <ambro718> then you don't know C
[15:17:22] <ambro718> rigid: can you paste your code
[15:17:33] <rigid> my code?
[15:18:04] <ambro718> sorry I mean phinxy's code
[15:18:32] <ambro718> rigid: (float * int) will first convert the int to a float, multiply the floats and return a float result...
[15:18:37] <phinxy> ambro718, i assume hes right? i mean the uint_16 cant hold any decimals
[15:18:44] <rigid> ambro718: also, only because it's defined doesn't mean it gives you the expected result
[15:19:56] <phinxy> float third_second_ticks = 10922.6666666667 would make sense
[15:20:01] <ambro718> rigid: that statement doesn't mean anything
[15:20:57] <rigid> ambro718: which statement?
[15:21:05] <ambro718> converting a float to an integer will first round down the float towards zero, and the result of the conversion will be that value, if it's within the range of the type you're converting to
[15:21:14] <ambro718> If you don't believe me, go read C standard.
[15:21:20] <ambro718> rigid: "only because it's defined doesn't mean it gives you the expected result"
[15:21:33] <rigid> ambro718: what would you expect here?: "int foo=1; foo *= 0.5; printf("%d\n", foo);"
[15:22:10] <ambro718> rigid: I don't expect anything, but I can tell you what the result will be.
[15:22:29] <ambro718> (it's zero)
[15:22:43] <rigid> if you don't expect anything, how doesn't my statement make sense?
[15:22:50] <rigid> "go read the C standard" ... lol
[15:23:02] <rigid> yes... but no one would expect 1*0.5=0
[15:23:14] <rigid> if you don't understand that statement, please stop "helping" people
[15:23:34] <ambro718> please stop pretending like you know everything about programming
[15:23:49] <ambro718> if certain C languge features were never useful, they certainly would not exist
[15:24:02] <illumer> take easy
[15:24:12] <illumer> you can all verify with the system
[15:24:21] <illumer> take it*
[15:24:34] <rigid> i'm not gonna feed the troll
[15:25:07] <rigid> phinxy: did you paste your code somewhere? i didn't read everything about your problem *scrollback*
[15:25:33] <phinxy> rigid, ya i did.
http://pastebin.com/XihbyYVv
[15:25:49] <phinxy> ive changed the int to float
[15:26:01] <phinxy> float third_second_ticks = 10922.6666666667;
[15:26:25] <phinxy> dont know if that 7 is rounded by the calculator in windows 7
[15:26:48] <rigid> phinxy: floats are also not accurate, since the timers use integers.
[15:27:47] <ambro718> phinxy: it's a bad idea to turn the third_second_ticks into a float
[15:27:59] <rigid> phinxy: how accurate do you need to be? i mean, you can never _exactly_ trigger an interrupt every 1/3rd second. Even with the most accurate clock.
[15:28:02] <Malinus> I could look into the datasheet, but maybe somebody happens to know whatever both GND are to go to ground, on a atmega328p?
[15:28:15] <ambro718> rigid: stop listening to him, he has no idea what he's doing
[15:28:19] <ambro718> phinxy: I mena
[15:28:37] <phinxy> rigid, as long as it doesnt drift more than the oscillator itself
[15:28:41] <ambro718> phinxy: if the ISR is going too fast I suggest you check if the clock is set up right
[15:28:54] <rigid> ambro718: i guess he's a beginner and we already know how your "help" looks like.
[15:29:08] <phinxy> lol rigid have u even looked at the code`
[15:29:08] <rigid> /topic only come here if you know everything about programming
[15:29:37] <phinxy> i dont know it made sense the way ambro explained it
[15:30:03] <rigid> phinxy: surely i did.
[15:30:44] <rigid> phinxy: just look at the "Hits" counter on that pastebin
[15:31:51] <rigid> i can see from the code, that you don't own a scope :-P
[15:32:05] <ambro718> phinxy: your problem is surely that you wrongly think TC2 is a 16-bit timer
[15:33:13] <ambro718> rigid: try with TC1 for now
[15:33:17] <ambro718> phinxy:
[15:33:30] <ambro718> that is drive TC1 on the internal clock
[15:33:35] <ambro718> which is 16-bit
[15:34:47] <ambro718> possibly prescale it so that its range is more than a second
[15:35:22] * rigid is off to #stm32 again ;)
[15:35:26] <rigid> farewell o/
[15:35:58] <illumer> ambro
[15:36:23] <phinxy> ambro718 i need the watch crystal between xtal1 and xtal2 ,
[15:36:54] <phinxy> i think its 16bit still
[15:36:59] <ambro718> phinxy: it's not
[15:37:19] <ambro718> usually it helps to have the datasheet close by
[15:38:30] <ambro718> phinxy: so if you want to stay with TC2 you can do the artificial bitness enhancement
[15:39:03] <ambro718> phinxy: I can tell how how do to that too, but still, I think you should at least test the existing code with TC1 to see the logic is right.
[15:40:45] <phinxy> 10-BIT T/C PRESCALER
[15:40:55] <phinxy> nevermind
[15:41:02] <phinxy> i really cant find if its 8 or 16 bit
[15:41:32] <ambro718> phinxy: the whole title of the section is "8-bit Timer/Counter2 with PWM and asynchronous operation"
[15:42:30] <phinxy> ambro, ill just prescale it..
[15:43:52] <phinxy> snap
[15:45:18] <ambro718> phinxy: yeah
[15:46:12] <ambro718> phinxy: still, when you absolutely need to have more bits, you can do it with a little help from the overflow ISR (but you need to be very careful, it's easy to make a racy clock reading procedure than)
[16:27:16] <phinxy> ambro718, somehow when i uncomment LCD init and draw functions everything behaves as expected but if i include them none of the timer2 function works as expected (random flashing of led and lcd is weird)
[16:27:29] <phinxy> does this mean my lcd library is using the timer too?
[16:27:52] <ambro718> phinxy: I don't know, check it.
[16:33:50] <Fleck> so, who can help me? :)
[16:58:11] <Tom_itx> not me
[17:01:17] <Fleck> :D
[17:38:17] <Fleck> uhh, where are you Tom_itx? :D
[17:38:39] <Tom_itx> i reset the router
[17:40:29] <Fleck> ohh, ok, so, what time is it there Tom_itx?
[17:40:52] <Tom_itx> 5:24pm
[17:51:17] <carabia> werebutt... is that like a werewolf but with ass?
[17:51:27] <carabia> like every now and then he turns into a huge ass?
[18:04:04] <Fleck> /kick carabia off-topic!
[18:15:33] <Lambda_Aurigae> Fleck, you seem to have a question so ask it and maybe someone will be able to help.
[18:16:16] <Fleck> I have... many times :D
[18:16:35] <Lambda_Aurigae> and not everybody has a large scrollback buffer.
[18:17:10] <Fleck> http://paste.opensuse.org/14210608 << vector function is never called, when bootsz1:0 and bootrst fuses are programmed, and there is NO bootloader, atmega2560
[18:17:56] <Fleck> working good when bootrst, or bootsz fuses are unprogrammed
[18:19:01] <Lambda_Aurigae> let me grab the datasheet.
[18:19:34] <PoppaVic> of course, '1' is "unprogrammed"
[18:19:43] <Lambda_Aurigae> with bootrst fuse programmed then the chip jumps to the bootloader section.
[18:19:48] <Lambda_Aurigae> I think.
[18:19:51] <Lambda_Aurigae> PoppaVic, ayup.
[18:20:09] <Fleck> PoppaVic: yes, bootsz0:1 and bootrst are 0
[18:21:23] <Lambda_Aurigae> Fleck, with bootrst programmed then it jumps to the bootloader section..if there is no bootloader then the chip is likely going to reset.
[18:21:40] <Lambda_Aurigae> with it unprogrammed, it should work fine.
[18:21:46] <Lambda_Aurigae> that's what it is supposed to do.
[18:22:09] <Fleck> Lambda_Aurigae: well, timer works ok, OC1A toggles...
[18:22:22] <Fleck> just vector function is not called!
[18:23:26] <Lambda_Aurigae> something is getting hosed with it having the bootrst fuse programmed...it should be unprogrammed unless you have a bootloader there.
[18:24:50] <Lambda_Aurigae> oh...duh!
[18:24:57] <Lambda_Aurigae> it's obvious when I read the datasheet.
[18:25:26] <Lambda_Aurigae> with bootrst fuse programmed the bootloader interrupt vectors are active, not the main interrupt vectors!
[18:25:36] <Lambda_Aurigae> so, of course, it won't get called.
[18:26:41] <Fleck> ok, and with MCUCR I should be able to run them anyway, no?
[18:27:02] <Fleck> how does arduino bootloader works then? What's the trick?
[18:28:23] <Lambda_Aurigae> clear IVSEL bit in the MCUCR
[18:28:29] <Lambda_Aurigae> before enabling interrupts.
[18:28:32] <Fleck> tried that, not helping!
[18:29:50] <Lambda_Aurigae> datasheet page 107
[18:30:17] <Fleck> yes?
[18:31:36] <Lambda_Aurigae> actually, look at page 110
[18:31:43] <Lambda_Aurigae> you have to do two things to get it to change.
[18:32:12] <Lambda_Aurigae> clear IVCE bit then clear IVSEL bit
[18:32:23] <Fleck> yep
[18:32:26] <Fleck> I did that!
[18:32:34] <Fleck> and it is not helping!
[18:34:19] <Fleck> afaik there should be new vector number, but I don't understand, what should it be, tried many different, no luck so far!
[18:34:36] <Lambda_Aurigae> new vector number?
[18:35:24] <Fleck> yes, _VECTOR(<NUMBER>)
[18:35:55] <Lambda_Aurigae> have you read the bootloader part of the avr-libc manual?
[18:37:35] <Fleck> yes and not only that! :D
[18:38:40] <Lambda_Aurigae> I have a feeling that you have to be in bootloader section to make the change over to main interrupt vector...not seeing it anywhere but for some reason that's ringing a tiny bell in the back of my mind.
[18:39:47] <Fleck> well, that would make sence!
[18:40:02] <Lambda_Aurigae> which is the behavior you are seeing.
[18:40:13] <Fleck> and explain why it's not working, but, arduino bootloader doesn't change MCUCR
[18:40:26] <Fleck> still, we can use ISR there
[18:41:58] <Lambda_Aurigae> you would have to load the interrupt vectors in the bootloader section...your coded loads your interrupt vector into the main section.
[18:42:13] <Fleck> nope
[18:42:20] <Fleck> check this for example:
http://playground.arduino.cc/Code/PCMAudio
[18:42:32] <Lambda_Aurigae> I'm not looking at ardweeny code.
[18:42:42] <Fleck> :D
[18:42:49] <Fleck> more like AVR :D
[18:44:11] <Lambda_Aurigae> nope. ardweeny
[18:44:11] <Lambda_Aurigae> no main()
[18:46:07] <balrog-k2n> no main no gain
[18:46:20] <balrog-k2n> there
[18:46:21] <Lambda_Aurigae> which means other things are going on there in the ardweeny libs that are automagically linked in.
[19:07:43] <Fleck> http://paste.opensuse.org/2794602 << Lambda_Aurigae working just fine! bootsz and bootrst fuses are 0!
[19:08:32] <Fleck> so the secret MUST be in bootloader :/
[19:09:31] <Lambda_Aurigae> I suspect that's not all the code as there are no includes there.
[19:12:10] <Fleck> all that I see in arduino editor :D
[19:12:18] <Lambda_Aurigae> fucking ardweeny
[19:12:33] <Lambda_Aurigae> I told you there is more going on in the background with ardweeny crap that you don't see.
[19:12:53] <Lambda_Aurigae> automatically included libs that change the behavior of the program.
[19:13:22] <Lambda_Aurigae> one should take arduino questions to arduino channel methinks.
[19:15:10] <PoppaVic> darn those weenies
[19:16:20] <Tom_itx> it's the main reason i try to discourage noobs to use them
[19:16:28] <Lambda_Aurigae> me too.
[19:16:45] <Lambda_Aurigae> causes too many issues in the long run.
[19:16:45] <Tom_itx> they don't have a clue wtf is going on with them
[19:16:55] <Lambda_Aurigae> if you are gonna do ardweeny, then stick with what the ardweeny can do.
[19:17:33] <PoppaVic> <shrug> Sounds to me like idiotic expectations
[19:17:36] <Fleck> poor guys :D
[19:17:51] <Tom_itx> i got an ardweenie 2560 but i got it for the board and nothing else
[19:18:11] * PoppaVic wants to see assembler, he uses -S
[19:18:12] <carabia> i have a noobdweeny altar in the living room
[19:18:18] <carabia> i sacrifice avrs to it nightly
[19:18:35] <Lambda_Aurigae> Fleck, what? the arduino software has a lot of background crap that abstracts you from the chip's hardware.
[19:18:42] <carabia> so they can avoid the fate of being slammed some god damn ardoono bootloaders
[19:18:51] <PoppaVic> Lambda_Aurigae: Just blame the italians - the french are busy
[19:19:05] <Fleck> Lambda_Aurigae: thats not the point though! :D
[19:19:55] <Lambda_Aurigae> Fleck, then what is the point?
[19:20:12] <Fleck> as you can see - there are cases where #avr can't help, but easly done with arduino, still, I will find whats going on...
[19:20:53] <Tom_itx> it's not rocket science, it's just hidden
[19:21:24] <Lambda_Aurigae> lots of hidden code in the arduino system...have fun digging it out..
[19:22:17] <Fleck> Lambda_Aurigae: and my initial q. was not about arduino...
[19:22:37] <Lambda_Aurigae> wel
[19:22:44] <Lambda_Aurigae> well, it seems you are using arduino.
[19:23:15] <Fleck> just tried with arduino bootloader :D
[19:23:29] <Fleck> so - no, I am not!
[19:26:32] <Lambda_Aurigae> what optimizations do you have on compile?
[19:26:36] <Fleck> or is it a sin to try? :D
[19:27:20] <Fleck> Lambda_Aurigae:
http://im9.eu/picture/bf2544
[19:28:07] <Lambda_Aurigae> look at the assembly source on that...I bet it's optimizing something stupid...maybe more than 4 cycles between setting the two bits.
[19:28:30] <Lambda_Aurigae> and the re
[19:29:20] <Lambda_Aurigae> and the reason it works with the arduino bootloader loaded on the machine is that the bootloader switches the interrupts from bootloader to main then it jumps to the main program.
[19:30:38] <Fleck> how?
[19:30:42] <Fleck> with IVSEL?
[19:31:05] <Lambda_Aurigae> only way to do it.
[19:32:22] <Fleck> searching arduino source code, can't find that to be the case!
[19:32:36] <Lambda_Aurigae> I don't even see the bootloader in the ardweeny source tree.
[19:33:04] <Fleck> https://github.com/arduino/Arduino
[19:45:26] <Lambda_Aurigae> try changing optimization to -Os instead of -O1
[19:47:38] <Fleck> nope, still the same!
[19:48:01] <Lambda_Aurigae> that is with setting the IVSEL etc?
[19:48:21] <Lambda_Aurigae> have you looked at the assembly output to see if it is within the 4 cycles for those 2 bit sets?
[19:51:10] <Fleck> Lambda_Aurigae:
http://paste.opensuse.org/45768277
[19:52:16] <Fleck> was taking effect when tried with bootrst unprogrammed, with 0 - working ok, with 1 did not, so, I guess IVSEL is ok!
[19:52:42] <Lambda_Aurigae> I'm off to bed...have fun.
[19:53:10] <Fleck> Lambda_Aurigae: ok, thank you for your time! Good night!