Back
[02:53:20] <skz81> crap, it seems I need more buffer to log this chan... someone spoke to me but, bzzzz too late
[02:53:57] <Casper> that'S why I set mine to 10k
[03:30:54] <rue_shop3> zlog
[06:33:41] <Tom_itx> anonnumberanon, here's my example using interrupts:
http://tom-itx.no-ip.biz:81/~webpage/how_to/atmega168/mega168_led_blink_int_index.php
[08:00:13] <skz81> rue_shop3, thanks
[08:00:50] <skz81> I guess it was another highlighting, related to work, that triggered
[08:10:41] <skz81> <eszett> What is the differente between a "evaluation board" and a "development board"? >> Marketing teams
[08:15:17] <skz81> <anonnumberanon> Would making a function "static" make it a lot faster to call it? Right now as a regular function it takes ages to get into it before the stuff inside is even executed. >> Nope. In plain C it just make it "local" to your module (.c file) and in C++ it has a a special meaning for class/struct members (they are shared by all instances). Does not change anything on exec speed (unless optimisation is on and uses this info for some trick).
[08:16:52] <skz81> anonnumberanon, rather check your optim flag -Ox it sound like your compiling with -O0 which means "no optim". avr-gcc is used to produce big function prolog with useless register load/saves.
[13:33:12] <eszett> hi
[13:33:17] <eszett> I have a question.
[13:33:29] <bss36504> Shoot
[13:34:15] <eszett> I have written a simple code which turns a LED on or off depending on whether a toggle switch is in left position (then its "high") or in right position (then its "low). The code works, but when i try to toggle the LED, it needs almost 2 seconds to turn on, why is that?
[13:34:45] <eszett> Is that the LED that needs time to "warm up"? or is it the microcontroller? or is it my code?
[13:35:05] <bss36504> Can you share your code?
[13:35:08] <bss36504> I would assume code.
[13:35:08] <eszett> sure thing
[13:35:55] <eszett> http://pastebin.com/qE4bZwHR
[13:36:32] <eszett> The code is a keyboard firmware framework, that a very experienced guy has written, I just added those 3 lines of codes to turn the LED on and off
[13:36:51] <Lambda_Aurigae> how fast is your chip running?
[13:37:03] <eszett> it's 16Mhz, which is standard..
[13:37:09] <Lambda_Aurigae> standard?
[13:37:11] <bss36504> what calls matrix_scan_kb?
[13:37:17] <eszett> A simple Atmega32u4 with external 16Mhz clock
[13:37:21] <Lambda_Aurigae> you have a 16MHz crystal attached and the fuses are set correctly?
[13:37:29] <eszett> ye
[13:37:48] <eszett> bss: there are other files which are linked to that framework
[13:38:02] <eszett> bss: but the cycles are blazingly fast
[13:38:21] <eszett> a keypress registers immediately
[13:38:30] <eszett> just the LED is sluggish when i turn it on
[13:38:32] <Lambda_Aurigae> I also don't see a main()
[13:38:35] <bss36504> What would happen if you remove the button check code, and just toggle an led each time that function gets called
[13:38:36] <bss36504> ?
[13:38:46] <eszett> bss: good idea
[13:38:56] <bss36504> also protip: you dont need the do...while, you can just use braces.
[13:39:08] <eszett> bss: but that would be too fast for the LED ill add a WaitMS procedure
[13:39:11] <bss36504> I mean, it's probably optimized away anyway, but just saying
[13:39:21] <eszett> bss: ok
[13:39:25] <bss36504> eszett: well if it's too fast then I guess that code is called quickly.
[13:39:35] <bss36504> I was trying to test if it really is getting called as quickly as you think
[13:40:06] <bss36504> either because the fuses are setup wrong and your chip is running at 2MHz instead of 16, or because there is some other code trickery happening in the framework that makes it not work the way you think it should
[13:40:32] <bss36504> if you can see the led flashing visibly while doing the toggle, then something outside your domain is causing it to be slow.
[13:40:43] <bss36504> and by outside your domain, i mean in the framework or the fuse settings
[14:00:15] <eszett> sorry I got a disconnect!
[14:07:26] <pwillard> we don't mind... ;-P
[14:07:50] <pwillard> Its a matter of what you missed
[14:08:58] <pwillard> IE; at the most, you missed this much:
http://hastebin.com/duzulukaco.vbs
[14:09:07] <eszett> ye what did i miss..
[14:09:14] <eszett> the last line i've read was <bss36504> and by outside your domain, i mean in the framework or the fuse settings
[14:09:37] <pwillard> then, nothing
[14:15:35] <carabia> oh gawd dayumn, that's so nice of you pwillard
[14:16:57] <pwillard> one is glad to be of service
[14:18:59] <bss36504> Hey look, I found a picture of carabia:
http://i.imgur.com/mzfz7vf.jpg
[14:19:02] <bss36504> :P
[14:19:14] <carabia> :D
[14:20:30] <Lambda_Aurigae> don't forget to pinch him and throw him over your shoulder.
[14:20:31] <carabia> i haven't been feeling too sodious lately :)
[15:11:36] <eszett> back..
[15:11:44] <bss36504> howdy
[15:11:48] <eszett> hi bss!
[15:11:53] <eszett> I hope now i can stay online
[15:12:05] <eszett> bss: I could figure something out
[15:12:12] <bss36504> Whats up?
[15:12:36] <eszett> bss: I can turn the LED with the toggle off immediately, but when i want to turn it on its delayed 2 seconds almost
[15:12:44] <eszett> so it doesnt have to do with cycle/clock speed
[15:13:50] <eszett> I wonder if the current does make a break on its journey to the pin.
[15:15:49] <eszett> with a different line of code, i can let the LED blink really fast
[15:16:41] <eszett> So the practically the LED *can* turn on quickly. Its just sluggish in my lines of code, where i combine it with the toggle.
[15:23:06] <bss36504> Your LED_TGL macro is wrong. Should be PORTB^=(1<<7)
[15:23:10] <anonnumberanon> skz81, yes I use -O2 for optimization. I was debugging a lot and researching all my options and now I'm fighting a bit with avrdude cause I switched to bareboard AVR.
[15:23:19] <bss36504> writing to PINB on an input pin enables the internal pullup
[15:23:33] <bss36504> that is not true at all
[15:23:43] <bss36504> dunno why I said that. My brain shut off for a moment
[15:23:54] <anonnumberanon> skz81, well not avrdude, but I think one of my fuses might be wrong, having been fused with an Arduino bootloader before.
[15:23:56] <bss36504> If youre trying to assert the state of a pin, write to the PORTx register
[15:24:08] <anonnumberanon> skz81, thanks for your reply
[15:24:16] <bss36504> eszett: Why are you trying to set the pin direction every time?
[15:24:37] <bss36504> What happens if you just write the code directly, instead of using macros? does the two second delay persist?
[15:30:04] <eszett> bss: yes thats what im trying to do now, directly without macros
[15:31:30] <eszett> without the macros, its still the same:
http://hastebin.com/obekugekaj.cpp
[15:32:27] <eszett> so the macros are not causing the delay.. hm
[15:32:48] <bss36504> Not that it's causing the problem, but why do you write to DDRB every time? Most everyone sets that up at the beginning and that's it.
[15:33:57] <eszett> that correct, i should write this only once in the "init function" not in the "cycle function"
[15:34:18] <eszett> but still, this isnt the problem ;-)
[15:35:04] <bss36504> What is your optimization set to?
[15:35:41] <eszett> optimaztion? hmm gotta look
[16:09:17] <anonnumberanon> Tom_itx, yep that's nothing new to me. Just gotta play with the fuses tonight as the only source of potential problems. I think the CKSEL fuses are okay since this is the same setup as what I had for the Arduino Uno clone. But the boot sectors fuses may need to be changed. The datasheet was complicated about this stuff when I read it last night. It didn't give an option to not have a boot sector. It got me wondering if I had to
[16:09:18] <anonnumberanon> allocate the most minimal size for boot which is 256 for a fuse bits value for BOOTSZ of 11 (unprogrammed).
[16:11:33] <eszett> finally got it solved, the LED turned on sluggish, because I forgot to set the internal pullup on the toggle pin. So the MCU interpreted the toggle pin, which was Tristate, as "yea, maybe on, maybe not, well, let me think 2 second about it, ah ok i interprete it as HIGH"
[16:12:56] <bss36504> Oh, weird that it would even read high at all.
[16:13:08] <bss36504> Must have just enough capacitance and leakage on that pin
[16:13:28] <bss36504> cap charges up slowly over 2s with a couple uA or nA of leakage
[16:16:01] <eszett> jeez
[16:16:08] <Lambda_Aurigae> eszett, so, you left an input floating.
[16:16:14] <eszett> yes
[16:17:27] <eszett> such a simple mistake, but I forgot it
[16:17:48] <Lambda_Aurigae> I don't rely on the internal resistors. I always use external.
[16:18:26] <eszett> And while debugging and I didnt expect that "a sluggish turn on" behaviour could be due to a Tristate
[16:18:26] <eszett> Well, it works well with the internals for me, so why not?
[16:21:16] <bss36504> Lambda_Aurigae: Why dont you use the internal pullups?
[16:21:30] <Lambda_Aurigae> because they get forgotten.
[16:21:54] <bss36504> haha ok fair enough
[16:22:07] <Lambda_Aurigae> if I can see a resistor there I know it's there.
[16:22:09] <bss36504> I'm always trying to reduce BOM and board space
[16:22:22] <Lambda_Aurigae> I don't make things commercially so not a big deal for me.
[16:22:34] <Lambda_Aurigae> and mostly do stuff on breadboards.
[16:22:39] <bss36504> Me neither, but resistors arent free and PCB space certainly isnt either
[16:23:01] <bss36504> I dont bother with breadboards most of the time
[16:23:10] <bss36504> simply because all the cool chips are SMD
[16:23:18] <Lambda_Aurigae> not really.
[16:23:24] <Lambda_Aurigae> most usb chips are, but,,,
[16:23:29] <bss36504> so why bother making a breakout, just to eventually roll it into a PCB in the end, which is my preference.
[16:23:30] <Lambda_Aurigae> there are kewl chips in dip.
[16:23:36] <bss36504> I guess
[16:23:43] <bss36504> I should have put quotes around cool
[16:23:57] <eszett> I have to consent with bss, I always try to keep things as minimal as possible, reducing BOM and solder effort.
[16:24:49] <Lambda_Aurigae> to each their own.
[16:24:56] <bss36504> I also dont care to only ever use ATTiny or a 328 for every project. Some of the neato AVRs are SMD, and a lot of the stuff they interface with is SMD, at least in my applications. And, you can litter your board with .1uF caps a lot easier in 0805 SMD rather than through hole
[16:25:03] <bss36504> totally personal preference and need though
[16:25:10] <Lambda_Aurigae> seems the internal pullup has caused someone some hours of "why don't this work?" though
[16:25:17] <bss36504> Very true
[16:25:25] <bss36504> but these headdesk moments are good for learning
[16:25:31] <Lambda_Aurigae> yup.
[16:25:53] <anonnumberanon> Lambda_Aurigae, are you talking about me?
[16:26:04] <Lambda_Aurigae> no...about eszett
[16:26:08] <anonnumberanon> ah
[16:26:11] <Lambda_Aurigae> choo
[16:26:30] <anonnumberanon> damn, i though figuring out internal pullups would solve all my problems :)
[16:26:37] <Lambda_Aurigae> hehe..
[16:26:40] <Lambda_Aurigae> probably will.
[16:26:44] <bss36504> Are you still working on that abomination of a PWM driver?
[16:26:47] <Lambda_Aurigae> until you run into something totally different.
[16:26:48] <anonnumberanon> stop trolling
[16:26:48] <bss36504> anonnumberanon ^
[16:27:01] <carabia> anonnumberanon: ^
[16:27:42] <bss36504> carabia
https://i.imgur.com/QQfshkI.jpg
[16:27:45] <bss36504> lol
[16:27:48] <carabia> not the salt again
[16:27:49] <anonnumberanon> bss36504, I wanted to definitely get off of the Arduino bootloader so I'm still doing that. The PWM stuff has to wait until "my tools are ready".
[16:28:16] <bss36504> anonnumberanon what are you programming it with if not the bootloader?
[16:28:22] <Lambda_Aurigae> anonnumberanon, you change the bootrst fuse to turn off the bootloader.
[16:28:26] <bss36504> carabia, I'm just joshin' ya
[16:28:40] <bss36504> though this one is a block of salt, not just a shaker
[16:28:57] <carabia> you still have a few different forms of salt to go
[16:29:00] <carabia> so i'll be ready
[16:29:02] <carabia> >:)
[16:29:27] <anonnumberanon> Lambda_Aurigae, ah. That could be it.
[16:29:34] <Lambda_Aurigae> it could.
[16:29:44] <Lambda_Aurigae> with that off then the bootloader size really is meaningless.
[16:30:04] <Lambda_Aurigae> except for the flash write commands that can only run from the bootloader section.
[16:30:35] <Lambda_Aurigae> bootrst fuse tells the chip to start at 0x0000 or at the beginning of the bootloader section which is defined by bootsize configuration.
[16:31:30] <anonnumberanon> bss36504, with a usbasp
[16:32:03] <anonnumberanon> or i can also use my Arduino UNO flashed with ISP programmer
[16:32:16] <carabia> can i also use your Arduino UNO?
[16:32:23] <anonnumberanon> no you can't
[16:32:33] <carabia> (??)
[16:32:37] <anonnumberanon> shipping to you would be more expensive than its value
[16:32:42] <anonnumberanon> stupid question
[16:32:45] <anonnumberanon> :3
[16:33:04] <carabia> I live across the road. Take a look out the window i'll wave
[16:33:21] <anonnumberanon> Look behind you before it's too late.
[16:33:38] <carabia> in fact -- we all live in theBear's LSD (and ac-braindamage, amongst other things) induced dream
[16:40:09] <anonnumberanon> Lambda_Aurigae, "The lowest addresses in the program memory space are by default defined as the Reset and Interrupt Vectors."
[16:40:25] <Lambda_Aurigae> yup
[16:40:41] <Lambda_Aurigae> which are duplicated in the bootloader section if you set the bootrst fuse
[16:40:43] <anonnumberanon> This is why any of my interrupt .hex would not work. But other programs would like, just toggle pin, no interrupts involved.
[16:41:11] <anonnumberanon> so a set bootrst is value 0 for it, right? sanity check
[16:41:22] <anonnumberanon> and with that the other boot pins don't matter.
[16:41:26] <eszett> jeez, why is the "make clean" not automatically done when i type "make".. This would save me alot of typing all the time
[16:41:27] <eszett> ye the vector points to the application code in memory
[16:45:46] <hetii> Hi :)
[16:45:52] <hetii> q: With one of those GPS module will be better for car navigation (android) GYGPSV3-M8N from
http://tinyurl.com/jxxq5w9 or
http://tinyurl.com/jmmo5vx ?
[16:49:04] <carabia> I'm pretty sure hetii is a bot
[16:49:21] <hetii> hmm :)
[16:49:29] <carabia> kurwa
[16:49:32] <hetii> why you assume that ?
[16:49:46] <Tom_itx> anonnumberanon i thought we went over the bootrst last night
[16:50:14] <hetii> carabia: nie przeklinaj :P
[16:50:15] <carabia> you pop out of nowhere on various channels on freenode, throw a random question and leave a few minutes afterwards before anyone even answers
[16:50:43] <carabia> often containing a link, i'm not opening them!
[16:50:57] <carabia> poland smells of aids.
[16:52:41] <anonnumberanon> Tom_itx, I am mapping out my fuses to see everything that is going on. That will also let me recheck the changes that we made last night and whether or not that should have been enough.
[16:52:59] <hetii> carabia: gosh ... you are a very sad person if you think like that ...
[16:55:53] <anonnumberanon> What happens if there is a brownout detection?
[16:56:14] <anonnumberanon> Micro stops running until vcc comes back up?
[16:56:18] <carabia> no, not sad, just a dick, but what gives...
[16:56:37] <bss36504> I dont trust tinyurl links.
[16:56:41] <anonnumberanon> hetii, you're not doing it right
[16:56:46] <bss36504> goo.gl
[16:56:52] <bss36504> anyway, gotta go.
[16:57:22] <carabia> anonnumberanon: it keeps it in reset when it's below the threshold
[16:57:33] <anonnumberanon> thanks
[16:57:44] <carabia> bss36504: have a good one!
[17:12:14] <Lambda_Aurigae> anonnumberanon, you know of avr fuse calculators online, yes?
[17:13:32] <anonnumberanon> Yes. I have almost all my fuses mapped on paper, only need to understand BOOTSZ 1-0 and BOOTRST
[17:17:00] <anonnumberanon> "When the BOOTRST Fuse is programmed, the device will jump to the Boot Loader address at reset"
[17:17:12] <anonnumberanon> So I DONT want to program it, right?
[17:20:16] <carabia> anonnumberanon: how much clearer can that line get?
[17:21:09] <anonnumberanon> Nah it's very clear I'm just subconsciously showing I suck at the memory mapping of the boot stuff.
[17:23:00] <carabia> really has nothing to do with memory mapping anything
[17:23:12] <carabia> and has everything to do with you knowing what you want
[17:24:43] <anonnumberanon> Well so far I understand it as: "program BOOTRST and that puts the interrupts vectors at the beginning of the addresses, don't program it and that puts the vectors at the beginning of the beginning address of the bootloader".
[17:32:56] <anonnumberanon> So final question, if I'm not a boot-loader, should I set boot size to the minimal 256 words?
[17:37:12] <Lambda_Aurigae> remember, programmed fuses are 0...
[17:37:52] <Lambda_Aurigae> anonnumberanon, boot size is irrelevant if you are not using bootloader..set it to whatever.
[17:38:07] <Lambda_Aurigae> unless you are using the SPM command for some reason.
[17:38:11] <anonnumberanon> I will load L:0xF7 H:0xDF E:0xFD after I'm done reading and understanding the fuses that are currently set on the chip right nowl
[17:38:29] <Lambda_Aurigae> anonnumberanon, have you fed those into the online fuse calc?
[17:38:46] <anonnumberanon> Will now.
[17:38:51] <Lambda_Aurigae> http://www.engbedded.com/fusecalc/
[17:40:07] <anonnumberanon> Yeah when I check the boxes it checks out.
[17:41:54] <anonnumberanon> This is what I have:
http://www.pastefile.com/Qmg8th
[17:43:05] <carabia> seems alright
[17:43:13] <carabia> also, back. what did i miss?
[17:44:33] <anonnumberanon> I created a sentient AI on a atmega8 but then my computer crashed carabia .
[17:49:17] <carabia> well good thing the mega8 doesn't really give two shits whether your computer crashes or not
[17:50:04] <carabia> but i call bullshit. avrs don't have enough ram in them. Therefore sentient AI is only possible with pics.
[17:53:41] <anonnumberanon> yeah okay i see what i had for fuses yesterday, so i changed high fuse to 0xde but that wasn't enough, i needed 0xdf
[17:54:04] <anonnumberanon> the clocking fuses should now also be better
[17:54:10] <anonnumberanon> (slightly)
[17:54:32] <anonnumberanon> gonna upload and test an interrupt .hex, brb
[17:57:32] <eszett> I have a question, does the statement have to be "if (LED_is_on = 1) ..." or "if (LED_is_on == 1) ..."?
[17:59:31] <Lambda_Aurigae> eszett, the second if you are doing a comparison
[17:59:46] <Lambda_Aurigae> the first assigns 1 to LED_is_on
[18:00:15] <Tom_itx> but you still know it's 1 :)
[18:00:28] <Lambda_Aurigae> true...guaranteed to be so even.
[18:02:27] <Tom_itx> sry if i'm crabby... i just did a windows downgrade from 10 to 8
[18:02:55] <Tom_itx> enough to make a saint curse
[18:03:16] <Lambda_Aurigae> did it cost you a large amount of cash?
[18:03:33] <Tom_itx> none
[18:03:40] <Tom_itx> for a friend
[18:04:43] <Lambda_Aurigae> I had a customer who upgraded all their computers over christmas holiday last year.
[18:05:02] <Lambda_Aurigae> then they tried to run their tax software....it wouldn't run..kept crashing when they logged into it.
[18:05:16] <Lambda_Aurigae> is a law firm that does tax law.
[18:05:33] <Lambda_Aurigae> they had years of tax info for many customers...and had a court case they needed data for.
[18:05:48] <Lambda_Aurigae> so they had to reformat one of the machines to win7 because the downgrade horked hairballs.
[18:05:56] <Lambda_Aurigae> then went to reinstall the software...couldn't find the disks.
[18:06:13] <Lambda_Aurigae> had to go back and buy 7 years of software...at $10K per year.
[18:07:29] <Lambda_Aurigae> a 70 thousand dollar free upgrade.
[18:10:32] <Tom_itx> i'm guessin they've come across their share of law suits
[18:10:37] <Tom_itx> ms that is
[18:10:38] <Lambda_Aurigae> yup.
[18:10:51] <Lambda_Aurigae> there are several still pending over the automated upgrades.
[18:11:22] <Tom_itx> this 10 thing is the shittiest they've ever been so far
[18:11:30] <Lambda_Aurigae> yup.
[18:12:24] <Lambda_Aurigae> that last round of updates where it told you it was ready to update but then when you closed the window it updated anyhow if you didn't scroll down and tell it not to..that was just low.
[18:12:30] <Tom_itx> the laptop i was working on wouldn't even perform a task due to all the crap they install along with the os
[18:12:41] <Lambda_Aurigae> I caught the wife's computer doing that and pulled the plug in the middle of the update..it reverted on its own.
[18:13:05] <Tom_itx> i removed all the update warnings from mine
[18:13:15] <Lambda_Aurigae> I just run linux
[18:13:22] <Lambda_Aurigae> no windows update warnings.
[18:13:26] <Tom_itx> i need both
[18:13:40] <Lambda_Aurigae> I use windows for work only.
[18:13:51] <Lambda_Aurigae> for home I have no need for windows.
[18:31:32] <eszett> test123
[18:31:53] <Lambda_Aurigae> fail
[18:33:32] <eszett> something is weird with my IRC connection, I have to check that
[18:50:54] <anonnumberanon> Interrupt-driven code does not work. Other codes do. :(
[18:53:09] <anonnumberanon> Maybe the BOOTSZ fuses did count?
[18:54:53] <Tom_itx> i don't think so
[18:57:57] <anonnumberanon> CLKDIV8 ?
[18:58:48] <Tom_itx> that just makes things run in slo mo
[18:59:44] <Tom_itx> basically just a 'preset' prescalar divisor
[19:11:52] <anonnumberanon> I think I'm having a toolchain problem.
[19:13:09] <anonnumberanon> I'm sending avr code to the arduino uno and all code always works.
[21:15:32] <Evidlo> Is it possible to overclock internal RC oscillators?
[21:31:54] <cehteh> Evidlo: yes, with the OSCCAL register
[21:34:10] <Evidlo> so would it be reasonable to bump the internal 8MHz oscillator of the attiny85 up to 16MHz?
[21:34:57] <Evidlo> the chip is rated up to 20MHz, so if anything went wrong it would be the oscillator
[21:39:55] <cehteh> will only work when you are lucky, the RC osc has a lot jitter and drift
[21:40:21] <cehteh> but also look into the PLL config
[21:43:46] <cehteh> that can generate 16mhz within spec out of the 8mhz RC osc
[21:44:37] <cehteh> (and some people overclock it like crazy :D up to 32Mhz)
[21:46:08] <cehteh> https://spritesmods.com/?art=avrfmtx
[22:00:51] <_ami_> Evidlo:
http://amitesh-singh.github.io/avr/2016/09/04/use-ext-clock-as-hearbeat-to-avr.html :D
[22:02:08] <eszett> test 1 2 3
[22:02:36] <cehteh> works
[22:03:04] <eszett> My inet connection seems to be repaired now
[22:29:00] <anonnumberanon> well this was an exercise in futility
