#avr Logs

Sep 30 2017

12:32 AM day__ is now known as daey
12:50 AM rue_: nick rue_house
12:53 AM rue_ is now known as rue_house
12:53 AM rue_house: I'll get it
01:08 AM Casper: rue_house: of course you will get it, as long as you have your irc cheats sheet with you
01:30 AM rue_shop3: ok I had supper
01:31 AM rue_shop3: now I just need to wake up
01:31 AM rue_shop3: hmm
01:32 AM rue_shop3: I wonder if I should try some ABS in my printer
01:32 AM rue_shop3: I dont have a heated bed
01:36 AM Casper: make one, duh
01:44 AM rue_shop3: I'v broken 3 peices of glass trying so far
01:49 AM Casper: don't let failure stop you
04:12 AM Cracki: ABS benefits from keeping the build volume warm
04:12 AM Cracki: afaik that's been patented by commercial FDM
04:13 AM Cracki: you'll want to control build volume temp very precisely. if it's above the glass transition temp, you'll have pudding
04:13 AM Cracki: so slightly under, but not room temp, that's too much tension in the material. let it cool in its entirety after the print is done.
04:14 AM Cracki: *slightly under, but enough (with circulation) that layers solidify quickly enough
04:52 AM dgriffi2: do any microcontrollers have FRAM yet?
04:52 AM polprog: no, but there are spi frams
04:52 AM polprog: easy to use, and compatible with spi flashes
04:53 AM polprog: why would you need fram in a micro
04:54 AM dgriffi2: polprog: frequently saving settings
04:55 AM polprog: ah
04:55 AM polprog: why did i think you wanna store program code in fram
04:55 AM polprog: so fram instead of eeprom?
04:55 AM dgriffi2: I need to get my hands on some of those spi ones
04:55 AM dgriffi2: exactly
04:56 AM dgriffi2: for my bluebox project, I'm looking at coming up with some sortbof round-robin scheme to impose wear-leveling
04:57 AM polprog: FM25V10
06:00 AM mmfood_: *REPOST* (paste expired) I am having issues with the set_mode variable being changed, seemingly arbitrarily at times (on button press). And not following the pattern 0 -> 1 - > 2 -> 0 ... And also the LED_min and LED_sec is not blinking consistently when in mode 1 vs mode 2 respectively. It is merely alternating between full brightness and a bit faded or sometimes from 0V to a little brighter. Then seemingly it starts to work as expected but after toggling and
06:00 AM mmfood_: returning to the same mode again it is acting up again. It might be a bit much to ask for a complete code review but maybe someone could notice something faulty. It doesn'seem to be a
06:00 AM mmfood_: hardware issue since bridging the pin to 5V gives full power.
06:00 AM mmfood_: I'm thinking that the LED_xxx ports are being set somewhere else in the code which would effectively act as pwm I guess. But I can't find a line where that would occur.
06:00 AM mmfood_: https://pastebin.com/C87r41A9
06:00 AM mmfood_: https://pastebin.com/X8bHg0W7
06:01 AM Cracki: nobody's gonna analyze 200+ lines of code
06:01 AM Cracki: please reduce
06:01 AM polprog: yeah, post the revelant part
06:02 AM Cracki: not just that, it must be complete and working, and have no irrelevant parts
06:02 AM mmfood_: sure
06:09 AM mmfood_: https://pastebin.com/C87r41A9
06:09 AM mmfood_: How about this?
06:10 AM Cracki: and what's wrong with it
06:10 AM Cracki: it appears you are doing a state machine of some kind
06:11 AM Cracki: and you might be missing a delay at around line 50
06:11 AM Cracki: uh 39
06:12 AM Cracki: also your main loop will run "hot"
06:12 AM Cracki: I suggest a sleep there
06:12 AM Cracki: sleep will awaken on any interrupt
06:13 AM mmfood_: well it is a timer watch, 4x 7 segment led for mm:ss where the colons are controlled by separate I/O pins
06:13 AM mmfood_: it has a set-mode button which toggles modes 0-2 where 0 is normal basically just a standby mode displaying the current time limit, 1-set min 2. set seconds. The colon LEDs should blink individually indicating set minute mode and set seconds mode respectively. The problem is with the LED flashing as mentioned above
06:14 AM mmfood_: what do you mean by "hot"
06:15 AM mmfood_: and what purpose would the delay serve?
06:16 AM Cracki: what purpose would the delay in the other if-branch serve?
06:16 AM Cracki: why one, but not the other?
06:16 AM Cracki: i expect symmetry
06:18 AM mmfood_: that delay on l34 is for blinking the entire screen att 00:00. I can't have such delay with the blinking of the colons, since the displays are multiplexed
06:22 AM mmfood_: I have to keep the delay time per loop iteration down so as not to flicker the display. Instead I use a variable (blink) which is flipped in the timer. THen the variable is checked in the loop to determine if the leds should be flipped.
06:35 AM Cracki: ah right
06:35 AM mmfood_: might be an issue with how the blink variable is handled. It is only flipped in the timer ISR and then the main loop is only checking if it is set. So when blink is 0 it won't flip the leds. Might have to clear blink after each loop and then set it in the ISR. Or maybe have a second variable for keeping track of it's previous state. Like if (tic != tac) { flip leds; tac == tic}
06:37 AM polprog: if you flip the blink var in the ISR, then you just need to check if it's true in the loop
06:37 AM Lambda_Aurigae: dgriffi2, use serial nvsram from microchip...spi interface, small battery for backup, no wear leveling needed as it is true sram.
06:38 AM mmfood_: polprog: wouldn't that make it flip every other second? If I don't clear it in the loop?
06:38 AM polprog: the problem is that you clear it in the loop then
06:39 AM polprog: i havent read the code, i have other things to do
06:39 AM mmfood_: right ^^
06:39 AM polprog: so i guess the blinking dots look steady of or very very faint, amirite?
06:40 AM mmfood_: but setting it in the ISR (every second) then checking it each loop iteration and if it is set then blink the leds and clear the var?
06:40 AM polprog: no idea.
06:40 AM polprog: basically, dont change a var both in the loop and in the ISR
06:41 AM polprog: do you multiplex the leds too or are they separate from the 7 segs?
06:41 AM mmfood_: they are separate
06:42 AM polprog: then you can switch them inisde the ISR as well. or do it in a loop, basically, if(blink) {ledsON(); } else { ledsOFF(); }
06:42 AM polprog: end of story
06:43 AM polprog: if you clear the blink variable every iteration, then the leds are on until you run the ckeck again , in your case at the next iteration of the loop
06:45 AM Lambda_Aurigae: you appear to have a variable that gets changed in an interrupt routine.
06:45 AM Lambda_Aurigae: I don't see that it is declared as volatile.
06:46 AM polprog: it should
06:46 AM Lambda_Aurigae: in fact, I see more than one variable changed inside interrupt routine.
06:46 AM Lambda_Aurigae: and don't see where they are defined at all.
06:46 AM Lambda_Aurigae: so there is a header file we are not seeing apparently.
06:47 AM Lambda_Aurigae: aahh..there is the header file.
06:47 AM polprog: why would you define a variable in a header file?
06:47 AM Lambda_Aurigae: aaaand
06:47 AM Lambda_Aurigae: blink is not defined as volatile..while the other appears to be.
06:47 AM Lambda_Aurigae: polprog, some people do that for global variables.
06:47 AM polprog: eww
06:48 AM polprog: you dont write the story in the header :P
06:48 AM Lambda_Aurigae: I don't know if this is the problem with the code, but blink, being changed inside the interrupt, should be declared volatile
06:49 AM Lambda_Aurigae: polprog, I've seen that promoted as a certain programming style in the past...probably not good practice as header files can be used in more than one C file.
06:49 AM polprog: include guards should have solved that anyway
06:50 AM Lambda_Aurigae: on the other paw, I've been told that one should NEVER use global variables...that's why they created C++
06:50 AM Lambda_Aurigae: hehe
06:50 AM Emil: Lambda_Aurigae: is register access always volatile btw?
06:50 AM Emil: I don't remember atm
06:50 AM Lambda_Aurigae: polprog, no ifdef guards in that code.
06:50 AM Lambda_Aurigae: Emil, no clue.
06:50 AM polprog: wow, that's bad
06:51 AM Emil: Lambda_Aurigae: "never use volatiles" is for actual computers and even there you _have_ to use them from time to time
06:51 AM Lambda_Aurigae: not volatiles...never use globals.
06:51 AM Emil: SORRY, GLOBAL
06:51 AM Emil: globals*
06:51 AM Lambda_Aurigae: but, yeah, I agree.
06:52 AM polprog: how else would i define a cross-file flag if not bloody global
06:52 AM Lambda_Aurigae: there are so many programming "standards" out there that have absolutes like that...it's horrid.
06:52 AM polprog: i love standards and i have at least two on every occasion :^)
06:52 AM Lambda_Aurigae: polprog, static inside a function?
06:52 AM polprog: makes sense
06:52 AM mmfood_: yes, I am not used to header files. Basically been using it for defines etc to clean up the .c file.
06:53 AM Lambda_Aurigae: makes the program much larger though.
06:53 AM Lambda_Aurigae: mmfood_, if you must, create a C file that is just variables declaration.
06:54 AM Lambda_Aurigae: not like, functionally, it really makes a difference.
06:54 AM Lambda_Aurigae: it's more of a programming faux-pas than a functional problem.
06:54 AM Lambda_Aurigae: but,,,back to your issue
06:55 AM Lambda_Aurigae: no clue why the code doesn't work but that blink variable gets changed in the interrupt so it should be declared volatile or it won't necessarily get updated properly.
06:55 AM Emil: mmfood_: so the issue with volatiles is this:
06:56 AM Emil: Compiler writers are a bunch of fucking retards idiots fucking assholes
06:56 AM Emil: If they can they will, even if your intent when writing the program is _100%_ clear
06:56 AM Lambda_Aurigae: tell us what you really think there Emil !
06:56 AM Emil: So if you have an ISR
06:57 AM Emil: From a compilers standpoint it's never called
06:57 AM Emil: So if you change something in the ISR the compiler says: well, hey, according to this structure I've generated, this code never actually affects anything
06:58 AM Emil: so I can just cache this variable to a register and be done with it
06:59 AM Cracki: no optimizations without assumptions
07:00 AM Cracki: that's life
07:00 AM Emil: So if you have a global var (but not volatile) that's initialised to some value at the beginning, use it only in main but change it only in an ISR, the compiler (probably) will generate code that caches the value to some register and then forget RAM access, because it's slower and takes space
07:01 AM Emil: Similarly but a bit less subtly
07:01 AM Emil: If you do multiple consequtive accesses to a variable
07:01 AM Emil: that's a global but not a volatile
07:01 AM Emil: the compiler might read from RAM at the beginning and then just cache that result to a register
07:01 AM Emil: instead of always fetching it from RAM
07:02 AM Emil: again, because performance
07:02 AM Emil: The takeaway here is that
07:02 AM Emil: Compiler writers are absolute faggots and fucking assholes
07:03 AM Emil: and to never trust the compiler to do what you ask it to do reasonably
07:03 AM Emil: Unless you very specifically tell it to do something
07:03 AM Lambda_Aurigae: always declare variables volatile if they are to be changed inside an isr.....
07:04 AM Lambda_Aurigae: and, yes Emil, from what I'm seeing, it pretty much ignores the volatile definition if the variable is declared as a register as well...although I could be mistaken here but that's what google is telling me.
07:04 AM Emil: And similarly, if you want the performance optimisations and know your code, read the global into a local which the compiler can optimise as it wishesh
07:05 AM Emil: wishes*
07:05 AM Emil: Lambda_Aurigae: ignores?
07:05 AM Emil: Lambda_Aurigae: I don't believe you
07:05 AM Emil: Aren't register's declared as something like
07:06 AM Lambda_Aurigae: Emil, it's just what I'm seeing...looks like a bug actually.
07:06 AM Emil: #define DDRB (volatile unsigned char *)number
07:06 AM polprog: the macro defs for register (like portd etc) are defined as a fixed pointer, like *(0x20)
07:07 AM Lambda_Aurigae: maybe the bug has been fixed as it first showed up,,in my searches anyhow,,in 3.2
07:07 AM polprog: iirc
07:07 AM polprog: that's what eclipse's macro expansion told me
07:08 AM Emil: polprog: you sure it doesn't contain (volatile unsigned char *)
07:08 AM polprog: not sure
07:08 AM polprog: im still not sure about the syntax of pointers, heard somewhere that 'a' is the same as *(&a)
07:09 AM polprog: but im still not sure how to read that.... pointer to adress of a ?
07:09 AM polprog: i should draw this out
07:09 AM polprog: whatever
07:11 AM Emil: eh?
07:11 AM Emil: You mean if I write 'a' in code
07:11 AM Emil: what does that mean?
07:13 AM antto: it'll turn to 97
07:13 AM polprog: this joke: https://i.redd.it/of5r7b49eroz.jpg
07:14 AM polprog: does that mean, a pointer to an adress evaluates as the value itself?
07:15 AM antto: look at the declaration of the said variable
07:16 AM mmfood_: weird, changed the blink function to this: https://pastebin.com/mhPGSnXY and now it won't even turn them off...also declared all variables that are changed in an ISR as volatile and put the definitions above main in .c
07:16 AM antto: aka look at its type
07:17 AM polprog: say a is an int. then *a is the pointer to that int. so if i take the pointer to the adress... that makes sense
07:17 AM Cracki: no, &a is the pointer. *a is a dereference
07:17 AM Cracki: also: int a; int *a;
07:17 AM Emil: wtf
07:17 AM Cracki: definition and use
07:17 AM Emil: The chain is like
07:17 AM antto: if a is an int - *a doesn't make much sense IMO
07:18 AM polprog: a method that has &a as a parameter expects *a as the value.
07:18 AM Cracki: you can cast a number to be an address/pointer, and deref that. that's ok
07:18 AM antto: ehm, no
07:18 AM antto: polprog a method that expects &a gets the argument by reference
07:18 AM Cracki: foo(type *a) {} foo(&a);
07:18 AM Cracki: that's ok
07:18 AM Cracki: or rather, if the outer a is of type 'type' :P
07:19 AM Cracki: "reference" is a c++ concept
07:19 AM Cracki: but yes, by reference/pointer
07:19 AM Cracki: and a "method" doesn't expect "&a", it expects a pointer maybe
07:19 AM Cracki: and if a isn't a pointer, &a will be a pointer to a
07:19 AM antto: otherwise you get a copy of the value
07:19 AM polprog: i have "the c programming language". i should read that
07:20 AM polprog: dont bother, ill look that up later
07:20 AM Cracki: what are y'all even arguing about?
07:20 AM Cracki: that meme?
07:21 AM Cracki: *(&a) is a dereference of the address of a
07:21 AM Cracki: so a no-op more or less
07:21 AM Emil: #define PINB _SFR_IO8(0x03) and then #define _SFR_IO8(io_addr) ((io_addr) + __SFR_OFFSET) but also #define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET)
07:21 AM Cracki: take the address, deref it. same as a.
07:22 AM Cracki: ah, yes, avr headers use cosntants and cast them to be addresses
07:22 AM Emil: __SFR_OFFSET is just a number
07:22 AM Cracki: that's ok
07:22 AM Cracki: does this bother or confuse?
07:22 AM Cracki: pointer arithmetic is a basic principle in C
07:23 AM Emil: #define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))
07:23 AM Cracki: yep
07:23 AM Emil: But there's that volatile unsigned char *)
07:23 AM Cracki: char and uint8_t are mroe or less the same
07:23 AM Emil: Yes we know
07:23 AM Emil: But it's interesting that there are double definitions for those _SFR_IO8
07:23 AM antto: Emil_ check out the xmega IO headers, they use structures, instances of which are declared at specific locations in memory
07:24 AM Cracki: so what is _MMIO_BYTE?
07:24 AM Cracki: nvm there it is
07:24 AM Emil: Cracki: I pasted it above
07:24 AM Cracki: so I'm guessing the plain definition expects io_addr to be a pointer already
07:25 AM antto: it looks like a cast
07:25 AM Cracki: and the one with mmio-byte does the cast in any case
07:25 AM Cracki: it is a cast
07:25 AM Cracki: cast and deref
07:25 AM Cracki: this can be a problem
07:26 AM Cracki: uh weird, this should not be like that
07:26 AM Cracki: where did you get #define _SFR_IO8(io_addr) _MMIO_BYTE((io_addr) + __SFR_OFFSET) from?
07:26 AM Cracki: the result of that is a "variable"
07:27 AM Cracki: the result of this is just an address: #define _SFR_IO8(io_addr) ((io_addr) + __SFR_OFFSET)
07:27 AM Cracki: difference is the deref
07:28 AM Cracki: those must be mixed definitions from unrelated headers
07:28 AM Emil: No
07:28 AM Emil: There's no issues
07:28 AM Cracki: there should be
07:28 AM Emil: And all from the same header
07:28 AM Cracki: in different ifdefd sections?
07:28 AM Emil: Cracki: or you are analysing it wrong
07:29 AM Cracki: you can't just redefine a macro, there is either an undef somewhere or the definitions are inside an #if
07:29 AM Emil: yes there's #if _SFR_ASM_COMPAT
07:29 AM Emil: and else for that
07:29 AM Cracki: aha!
07:29 AM antto: preprocessor dark magic
07:29 AM Cracki: could have said so sooner :)
07:30 AM Cracki: hardly dark magic
07:30 AM Cracki: can't know what hasn't been said
07:30 AM Emil: https://emil.fi/jako/koodi/avr_sfr_defs.h
07:31 AM Emil: from /usr/lib/avr/include/avr
07:31 AM Emil: I added avr_ to the filename when uploading to my server
07:31 AM Emil: from /usr/lib/avr/include/avr/sfr_defs.h
08:17 AM Cracki: Define \c _SFR_ASM_COMPAT as 1 to make these names work as simple constants
08:17 AM Cracki: nobody does that, I hope
10:34 AM mmfood: I found the issue! Embarissingly enough, I neglected to left shift the mask in the clear_pin() macro, duh!!
01:08 PM JanC is now known as Guest29974
01:08 PM JanC_ is now known as JanC
01:49 PM toddpratt: i used to have linux on my laptop and it was easy to get and use the avr toolchain. My new laptop doesn't work very well with linux, so I'm looking for a toolchain for windows.
01:54 PM mmfood: isn't avr studio a complete package with everything you need?
01:54 PM polprog: some poeple dont like it
01:54 PM polprog: there are avr toolchains for win
01:54 PM polprog: mostly on german sites
01:56 PM toddpratt: mmfood: that's what i needed to know. thanks.
01:56 PM toddpratt: i'll give it a try at least
02:10 PM Emil: I use the arduino ide as a toolchain
02:11 PM Emil: When on Winshiy
02:11 PM polprog: looks like you can use the gnu toolchain
02:12 PM polprog: with command prompt or powershell
02:12 PM polprog: hell, you can even install emacs or vim in windows
02:12 PM polprog: avrdude is probably ported too
02:12 PM polprog: the package is called WinAVR
02:13 PM polprog: this is what i use as an IDE on linux, and it should work on windows too: http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_GCC_Toolchain
02:18 PM Cracki: don't use winavr, it's ancient
02:18 PM Cracki: avrgcc is maintained by atmel/mcp
02:19 PM Cracki: there are builds of avrdude. arduino uses them.
02:19 PM Cracki: avr eclipse is well maintained too, afaik
02:22 PM Cracki: https://github.com/arduino/avrdude-build-script
02:24 PM Cracki: http://download.savannah.gnu.org/releases/avrdude/?C=M&O=D
02:24 PM Cracki: and here are binaries
04:02 PM cambazz: hello, i got my cheap usbasp programmer and an attiny connected to it, and i want to program it. i am getting error from avrdude: program enable: target doesn't answer. 1
04:02 PM cambazz: i double checked the connection that i did to my breadboard
04:02 PM cambazz: i am executing a makefile with make
04:03 PM cambazz: and at first it would not see the programmer and i found out i had to run the avrdude as root to talk to it.
04:04 PM cambazz: i am on ubuntu, so avrdude sees my programmer, bit either i have messed up connections or a bad attiny
04:06 PM polprog: is the target powered on?
04:06 PM polprog: also, what else does avrdude say?
04:09 PM cambazz: avrdude: warning: cannot set sck period. please check for usbasp firmware update
04:10 PM cambazz: avrdude: initialization failed, rc=-1
04:10 PM polprog: yes. this is bad
04:10 PM cambazz: Double check connections and try again, or use -F to override
04:10 PM polprog: this is the problem with usbasp
04:10 PM polprog: it just doesnt work
04:10 PM polprog: sorry mate, you have to get another programmer, which is NOT usbasp
04:10 PM cambazz: really?
04:10 PM polprog: yes
04:11 PM cambazz: there are jumpers on it maybe it is because 3.3/5V problem
04:11 PM cambazz: well the uspasp firmware update can be ignored
04:11 PM cambazz: it is a warning
04:11 PM polprog: if you set the jumpers properly (it means target's voltage)
04:11 PM polprog: it reports you an error
04:12 PM polprog: if you choose to ignore it, it will just crap out at another stage
04:13 PM Casper: Also, check the command line used for avrdude
04:13 PM Casper: you may not be using the right options
04:14 PM cambazz: i measured the voltaget and the target has 5V
04:14 PM cambazz: well there re some jumpers on the programmer i dont know what it is
04:14 PM cambazz: avrdude -p attiny85 -c usbasp -P usb -q -U flash:w:main.hex
04:14 PM Casper: do you happend to have a scope?
04:15 PM Casper: need to go, but check the voltage on reset while you attempt to flash, see if there is any change while the flashing happend... really, just to be sure that it does try to flash it..
04:15 PM cambazz: yes i do indeed. a logic analyzer as well
04:15 PM Casper: ... and check miso and mosi, might be inversed
04:16 PM Casper: gtg
04:16 PM polprog: thats very good
04:16 PM Casper: bbl in 3-4 hours
04:16 PM polprog: having those really helps
04:16 PM polprog: but still, i had no luck with usbasp. it's in the junk drawer for a year now
04:16 PM cambazz: oh have you seen this dude who hacked a soldering iron
04:16 PM cambazz: to make a scope
04:17 PM cambazz: it like the soldering iron has a screen on it with some mcu, and he reprogged it to get a dso
04:20 PM cambazz: ow i tried to erase the chip with avrdude
04:20 PM cambazz: and it says -p attiny85
04:21 PM cambazz: one sec
04:21 PM cambazz: avrdude: AVR device initialized and ready to accept instructions
04:21 PM cambazz: avrdude: Device signature = 0x88fb76
04:21 PM cambazz: avrdude: Expected signature for ATtiny85 is 1E 93 0B
04:21 PM polprog: dont try.
04:22 PM polprog: if it gets the signature wrong, it most likely is receiving garbage
04:23 PM cambazz: are we talking aboiut the same device
04:25 PM cambazz: i could have a bad attiny chip
04:30 PM polprog: not likely
04:30 PM polprog: if you have another micro feel free to try it
05:24 PM cambazz: hello again.
05:24 PM cambazz: i made the cheap usbasp work.
05:25 PM cambazz: there is a jumper near usb like not soldered in. it does not say anything, it says jp3 in mine.
05:26 PM cambazz: i was browsing google image search and in one of the pictures it said "SLOW SCK"
05:26 PM cambazz: so i shorted it, and voila it works :)
05:35 PM polprog: god job
05:35 PM polprog: maybr i can revive mine
05:39 PM Lambda_Aurigae: the usbasp needs a software update OR a jumper on the slow speed programming pins.
05:40 PM Lambda_Aurigae: your usbasp is running the programming interface too fast.
05:40 PM Lambda_Aurigae: the chip by default is running at 1MHz...8MHz internal RC oscillator with div8 fuse programmed
05:41 PM Lambda_Aurigae: the usbasp, by default, is too fast.
05:41 PM Lambda_Aurigae: it has to be slowed down.
05:41 PM Lambda_Aurigae: the usual default software on them is old and doesn't support the delay command from avrdude so it can't slow down.
05:41 PM Lambda_Aurigae: usually there is a jumper on the usbasp board to slow it down.
05:42 PM Lambda_Aurigae: where it is and how it is marked depends on the usbasp.
05:42 PM Lambda_Aurigae: not all usbasp boards have the jumper pins.
05:42 PM Lambda_Aurigae: I have seen this happen at least a dozen times in this channel in the last year.
05:42 PM Lambda_Aurigae: usbasp is cheap..and you get what you pay for.
07:42 PM avrdude: 20:49 < cambazz> avrdude: Expected signature for ATtiny85 is 1E 93 0B
07:42 PM avrdude: Uhm, ok.. cool story bro. Why do so many people highlight me to tell me random stuff itc :(
07:43 PM Lambda_Aurigae: avrdude, just for the fun of it.
07:46 PM antto: cuz this channel is about avr.. dude!
08:05 PM Casper: avrdude: might want to change your nick to something... better
10:39 PM aarcane: hallo folks, I had an odd issue with an ATmega 324PA where I couldn't bring pin PC3 high or low because it was controlled by JTAG/TMS. I disabled JTAG and it works... well, now I'm having a similar issue with PC0 which only shows SCL as an alternate function and the datasheet says I can do GPIO with it, but it's not really working. It works when I'm calling some initialization stuff, including UART and setting up a 6KHZ carrier signal
10:39 PM aarcane: on another port, but insofar as I can see, absolutely nothing else is touching portc except for three other GPIOs, and they're working fine.