#avr Logs
May 10 2018
#avr Calendar
01:09 AM Jartza: morning
01:12 AM Haohmaru: hm, so the data SRAM is *never* cleared by the mcu itself, right?
01:12 AM Haohmaru: Jartza will know
01:12 AM Jartza: you mean without running code?
01:12 AM Haohmaru: yez
01:12 AM Jartza: new AVRs seem to have all sram set to 0 in boot
01:12 AM Jartza: but reset doesn't change sram
01:12 AM Haohmaru: the lower 0x2000 bytes (so called IO memory) is reset to the default values, but the upper part (.data section) appears to be left
01:12 AM Jartza: yes
01:12 AM Haohmaru: "set to 0 in boot" <- hm?
01:12 AM Jartza: IO-ports have reset defaults, but rest of the sram needs to be initialized by user
01:12 AM Haohmaru: wut ya mean
01:12 AM Jartza: in power-up, I mean
01:12 AM Jartza: but after power up, in reset (user reset, watchdog, brown-out, external reset) it's not cleared
01:12 AM Haohmaru: only on power-on-reset but not in other kinds of reset?
01:12 AM Jartza: unless of course, code clears it
01:12 AM Jartza: yes
01:12 AM Haohmaru: good, purfect!
01:12 AM Haohmaru: muh plan might work
01:12 AM Jartza: that's pretty much how arm mcus work too
01:12 AM Haohmaru: xmega seems to make it even easier cuz the datasheet says that data SRAM always starts at 0x2000, no matter which chip
01:13 AM Jartza: I've taken advantage of that many times
01:13 AM Jartza: I have set certain area in SRAM to "non initialized" in my linker script and use that to store information over boot
01:13 AM Haohmaru: i am doing a fancy bootloader, and i need to pass some data around between the firmware and bootloader
01:13 AM Jartza: exactly
01:13 AM Jartza: that's the way
01:14 AM Haohmaru: yeah, except, i don't want to modify the linker script
01:15 AM Haohmaru: i'll have to check the function that clears the ram :~(
01:17 AM Haohmaru: i see __do_copy_data, __do_clear_bss, __do_global_ctors
01:17 AM Haohmaru: i guess, it must be the first one that deals with the very first bytes in the .data section?
01:19 AM Haohmaru: but.. i guess, i don't need to worry about that
01:21 AM Jartza: the SRAM clearing code is usually done by compiler automatically
01:22 AM Jartza: in AVR it's usually in __ctors_end
01:23 AM Jartza: uhh, not in, after
01:24 AM Jartza: something like do_clear_bss or similar, can't remember
01:24 AM Jartza: and running irc in phone right now :)
01:25 AM Haohmaru: well, my plan is basically, moving the .data section up by a few bytes (say, at 0x802008), and slapping a lil static structure at 0x802000
01:26 AM Jartza: probably linker script needs to be modified
01:26 AM Haohmaru: why?
01:26 AM Haohmaru: that's the thing i want to avoid
01:29 AM Haohmaru: hm, because this structure will be static, i guess it will need to be "initialized" according to the language.. so i guess that means that its initial values will go somewhere in the .text section and then be copied to the .data section by the startup code
01:29 AM Haohmaru: so it's a little unclear what's gonna happen
01:29 AM Haohmaru: given that the address of the struct in ram is *before* the .data section
01:31 AM Jartza: because compiler generates the code that clears SRAM?
01:34 AM Haohmaru: i don't know how that shizzle works in details, but i would think that the initialized variables are sorted like a big structure in RAM, and then that same structure is put in the .text section (the actual initial values), then the startup code will just use two pointers, one pointing at the beginning of that structure in flash, and another pointer pointing at __data_start maybe? and loop
01:34 AM Haohmaru: read-from-flash write-to-ram
01:55 AM Haohmaru: hm
01:56 AM rue_bed: olfs
01:56 AM Haohmaru: or maybe, i should just declare a pointer to that structure, similarly to how the peripherals are declared, so that gcc is fully unaware of its existance, allocation, initialization, etc..
02:32 AM Haohmaru: it seems on first sight that this should work:
02:32 AM Haohmaru: BOOTLOADER_SHARED_RAM_DATA_t &xbsh = *reinterpret_cast<BOOTLOADER_SHARED_RAM_DATA_t*>(0x2000);
02:32 AM Haohmaru: my test board is gone tho, i can't actually test it :~(
03:40 AM Jartza: Haohmaru: you probably want to use .noinit -section at least
03:40 AM Jartza: looks like the default linker scripts have one
03:40 AM Haohmaru: but where is that gonna be located?
03:42 AM Jartza: where you tell it to locate
03:42 AM Jartza: int foo __attribute__ ((section (".noinit")));
03:42 AM Jartza: avr-gcc ... -Wl,--section-start=.noinit=0x802000 ...
03:43 AM Haohmaru: sure, that's one of the first things i thought
03:43 AM Haohmaru: but then i cannot use that section for anything else
03:43 AM Haohmaru: cuz if i do, my uber-special-structure can be before some stuff, after some stuff, or in the middle of some stuff
03:44 AM Jartza: why?
03:44 AM Jartza: why it can't be in the beginning of SRAM?
03:44 AM Jartza: as you know (?), stack "grows" backwards from the end of SRAM
03:45 AM Haohmaru: say i do that, in the bootloader, i only have this special structure in .noinit, i set the section to 0x802000 - the structure goes right in the beginning of RAM
03:45 AM Haohmaru: then i write some firmware, do the same thing there
03:45 AM Haohmaru: now, some time later, i decide to use some variable (buffer maybe) in .noinit too, for legit reasons
03:46 AM Haohmaru: now the special structure in the firmware might happen to be placed *after* the buffer
03:46 AM Jartza: uhh. why?
03:46 AM Haohmaru: coz the compiler (or linker) can put it anywhere
03:46 AM Jartza: you might need to draw a picture because I don't know why your special structure needs to move at all
03:47 AM Haohmaru: okay, to say it another way..
03:47 AM Haohmaru: if you have a structure and a uint8_t in .noinit - which of those two will be placed first?
03:48 AM Haohmaru: what if you have another uint8_t too?
03:49 AM Jartza: define everything inside .noinit in struct?
03:49 AM Jartza: then they will be where you define
03:49 AM Jartza: every time, all the time
03:49 AM Haohmaru: that would work, but is inconvenient
03:50 AM Haohmaru: if i need a big buffer in .noinit which is an object member
03:50 AM Haohmaru: or something like that
03:51 AM Haohmaru: i think what i did now should work, i'm almost fully confident that the struct won't be "initialized" by the startup code
03:52 AM Haohmaru: because, afaict, the SFRs and peripheral structures are defined the same way
03:52 AM Haohmaru: i just made a "gap" of a few bytes between the IO memory and .data memory
03:54 AM Jartza: if you need buffer, define buffer there and just use it as buffer? I don't know what the problem is :)
03:54 AM Jartza: global .noinit struct and just pointer to buffer
03:55 AM Haohmaru: i may forget about this some day, and copy/paste some example code for a .noinit variable, and then - boom, i may break my fragile bootloader
03:56 AM Haohmaru: and still, it's inconvenient.. to have to move something into this one struct in order to use the .noinit feature
03:57 AM nuxil: do you intend to update it for the next 10 years ?
03:57 AM Haohmaru: update what?
03:57 AM nuxil: you worried you will forget about it someday
03:58 AM Haohmaru: potentially
04:00 AM nuxil: just make a big note in your code/documentation so you cant miss it therfor never forget it when you peek at your code again :)
04:01 AM Haohmaru: that's like.. leave a big note "don't sh*t your pants EVER!"
04:02 AM Haohmaru: i think you might be missing the point here
04:02 AM Haohmaru: i will write this bootloader hopefully once, then it shall not need much modification
04:02 AM nuxil: No. its like. remember to go to toilet if you want to take a crap so you dont shit your pants :p
04:02 AM Haohmaru: hopefully no modification (besides recompiling it for a different xmega chip)
04:03 AM Haohmaru: however, i am constantly changing the firmware, and i have other firmwares for different devices
04:03 AM Haohmaru: the location of this special structure has to match between the bootloader and all of these firmwares
04:04 AM nuxil: 0.o
04:04 AM Haohmaru: nuxil why should i leave this responsibility to the human (me), when there is a f*cking computer here that is supposed to deal with remembering sh*t
04:05 AM Haohmaru: don't you agree on that at least?
04:12 AM nuxil: no. the responsibility is always on the homan , you tell it what to compute and if you didnt tell it good enuf how do it.. its your responsibility that the computed result is false, and that it remembering only shit :p
04:13 AM Haohmaru: O_o
04:14 AM Haohmaru: nuxil, y r u doing this
04:14 AM * Haohmaru blames Emil
04:14 AM nuxil: well its true right ?
04:15 AM * Haohmaru removes the timer mechanism on nuxil's toaster
04:15 AM * nuxil doesnt have a toaster :D
04:15 AM * Haohmaru removes the thermostat on nuxil's water boiler
04:16 AM * Haohmaru removes the sleep timer on nuxil's TV
04:16 AM Haohmaru: THERE YA GO, YA WANT MOAR?
04:16 AM * Haohmaru removes the fuel indicator on nuxil's car
04:17 AM Haohmaru: while (1) { ++nuxil.responsibilities; }
04:18 AM nuxil: you sure you want to do that ? i might be responsible for you code.
04:18 AM nuxil: and i dont think anyone want that :p
04:19 AM Haohmaru: my code is a little bit written in C++
04:19 AM Haohmaru: be my guest
04:19 AM Haohmaru: you'll take me later for this wonderful decision
04:20 AM Haohmaru: * thank
04:22 AM nuxil: i'll probably kill you :p
04:22 AM nuxil: https://i.redditmedia.com/fd1fXVWX3BTJHzhYdq93uTjSsPOv5ZFm0SRTgpoh1AI.jpg?s=b89551b25c19ea5e7d115004ee7a1609
04:23 AM Haohmaru: you can't fight my static_assert()s with yer asterisk
04:29 AM nuxil: https://img.devrant.com/devrant/rant/r_333193_KZA2y.jpg
04:37 AM polprog: https://i.redditmedia.com/hSBk3sw15_ptbuXoQ7KjGaFvSUZi9Q5B_s8BEnePUQA.jpg?s=a4b2d9069de27a19bab7d744e41355fa
04:39 AM nuxil: hehe. i though this was a good one :D https://img.devrant.com/devrant/rant/r_272119_3kV77.jpg
05:57 AM polprog: how many c++ programmers does it take to change a lightbulb
05:58 AM polprog: 5, one to hold the lightbulb and 4 to turn the table
05:58 AM polprog: :p
05:59 AM Haohmaru: one C++ code plus 4 C coders
06:01 AM Tom_L: yeah, they're in a class by themselves
06:02 AM polprog: Marx would be proud of your code, everything in one class
06:04 AM Haohmaru: nah, not everything, just the PODs
06:37 AM nohitzzzz: murder king cheese burgers for breakfast
06:37 AM nohitzzzz: what a nice day
06:37 AM nohitzzzz: and Haohmaru needs to work
06:41 AM Haohmaru: work rarely equals code
06:47 AM nohitzzzz: isnt bulgaria christian country? why dont you have these christian holidays
06:48 AM nohitzzzz: its helatorstai today
06:55 AM nuxil: kristi himmelfartsdag
06:59 AM nuxil: i think its the Lutheranism/Protestant christianity that does have hollidays on these kinds of days. while the ortodox does not. im not sure
06:59 AM nohitzzzz: yeah
07:00 AM nohitzzzz: i think bulgaria is ortodox
07:05 AM nuxil: afik. most eastern europeian contrys are.
07:28 AM Haohmaru: nohitzzzz we're ortodox shizzle
08:19 AM nuxil: page 230 in the datasheit for my atmega88. SPI Control Register 0 , Name: SPCR0
08:19 AM nuxil: why do they put the wrong name in the datasheet. its SPCR not SPCR0 :\
08:20 AM Haohmaru: if the chip has just one SPI, then it could be SPCR
08:20 AM Haohmaru: and this inconsistency might be coming from avrlibc
08:20 AM nuxil: wrong nameing in the datasheet comes from avrlibc ?
08:21 AM Haohmaru: don't worry, PICs are full of such small inconsistencies
08:21 AM nuxil: i do not intend to get pic's
08:22 AM Haohmaru: well, i don't know for sure, but normally IMO it should've been SPCR0
08:22 AM nuxil: when you say. pic . in my language it sounds like pikk. and a pikk is kind of synonym with penis
08:22 AM Haohmaru: however, if there's just one SPI, the zero has been omitted (nasty)
08:23 AM Haohmaru: in my language, pik is peak
08:30 AM nuxil: Haohmaru altho the examples in datasheet uses SPCR, while the place where it is described it is named as SPCR0.
08:30 AM nuxil: i blam Emil for bad datasheit :p
08:32 AM nuxil: i think we need to get Emil a puuseppä :)
08:33 AM Haohmaru: yeah, i was also gonna suggest blaming Emil for this inconsistency
08:35 AM nuxil: *
08:35 AM nuxil: puusepäntyö
08:35 AM nuxil: anywho. time to test some spi
08:38 AM Haohmaru: spi is nais and simple
09:57 AM polprog: apropos pics
09:57 AM polprog: wonder if my free pic board ever arrives xD
09:57 AM polprog: wow my phone tried to correct xD to x86
10:10 AM Haohmaru: u let ur phone talk instead of you?
10:18 AM Emil: nuxil: what do I need a carpenter for?
10:19 AM nuxil: no.a place for you to go.. like Emil i lønneberget :p
10:20 AM Emil: but you said "we need to get Emil a carpenter"
10:20 AM Emil: ah you mean
10:21 AM Emil: puuverstas
10:21 AM Haohmaru: puuverwat?
10:21 AM nuxil: yes :)
10:22 AM nuxil: Haohmaru, your not from the nordics. so you most likelt dont get it.
10:22 AM Emil: I already have a place for woodworking
10:22 AM Emil: puusepäntyö would be carpenter's work
10:23 AM nuxil: well. you know.. goofle translator
10:23 AM Emil: Voiiiii herranjestas minkälainen lapsi oli hän
10:24 AM Emil: on hyvä ettei Eemeleitä ole enemmän
10:24 AM nn7: bless you
10:24 AM Emil: Or, as you'd actually sing it
10:24 AM Emil: Voiiiiii herranjettas minkälainen lapsi ooooli hään, on hyyvä ettei Eemeleitä ooole eeneemmän
10:26 AM Haohmaru: o_O
10:26 AM nn7: I think you have some stuck keys
10:26 AM Haohmaru: i think his face fell onto the keyboard
10:27 AM nuxil: voi vittu
10:28 AM Emil: voi vittu, vitun vitun vitun VITTU saatana perkele jumalauta helvetti SAATANA
10:28 AM nuxil: meh.
10:28 AM Emil: nuxil: better than how Norwegians swear >:D
10:29 AM nuxil: hell no. :p
10:29 AM * Haohmaru throws Emil into virustotal
10:29 AM nn7: !
10:29 AM Emil: nuxil: also awesome laughing at Swedish swearing: https://www.youtube.com/watch?v=cF0As6gaIGg
10:30 AM Emil: JÄVLÄ FITTA VA FAN
10:30 AM Emil: It's just
10:30 AM polprog: you should see some polish swearing
10:30 AM Emil: you can't call it swearing
10:30 AM Emil: Haohmaru: virustotla?
10:30 AM Emil: >usin AV
10:30 AM Haohmaru: no, not virustotla ;P~
10:31 AM Haohmaru: u seem corrupted, Emil
10:31 AM Haohmaru: you act suspicious
10:31 AM Haohmaru: i will scan you for viruSES
10:31 AM Emil: polprog: o it
10:31 AM Emil: do it*
10:32 AM Emil: https://www.youtube.com/watch?v=eiCPw2DWa78
10:32 AM polprog: lol
10:59 AM polprog: meanwhile in ##asm
10:59 AM polprog: i have a ardunio set here, with a java ide, that act's as compiler to produce
10:59 AM polprog: bcode for the cpu, it costs 30 dollars
10:59 AM polprog: my mind
10:59 AM polprog: it hurts
11:08 AM MrFahrenheit: yeah, who writes "act's"
11:13 AM cehteh: non native english speakers
11:14 AM cehteh: for a german that translation doesnt sound much off
11:16 AM nn7: so I'm just starting to play with JTAG. I've been doing debugging with OCDEN disabled. What do I gain with OCDEN?
11:30 AM polprog: wow
11:30 AM polprog: my void linux install actaully booted
11:31 AM polprog: in less than 3 seconds after pressing enter in grub
11:37 AM MrFahrenheit: they caught up to systemd?
11:37 AM MrFahrenheit: :P
11:37 AM Emil: >no having only busybox and the kernel
11:37 AM Emil: >why even use linux
11:38 AM Emil: hmm
11:38 AM Emil: I feel like taking a shower and then going to bed
11:38 AM Emil: Woke up at 07, after sleeping fro 4,5ish hours
11:39 AM Emil: then car trip to range, build the challenges, judge the competition with other people and also shot
11:39 AM Emil: shoot*
11:39 AM Emil: and then car trip home at 16ish
11:39 AM Emil: Car trip is 1h20min ish
11:40 AM MrFahrenheit: nuxil, I'm having to troubleshoot this new PLA I got, I'm getting really shit overhangs with it that were not a problem for the stock PLA
11:40 AM Emil: and of course no sunscreen
11:40 AM nuxil: maybe to high temp?
11:40 AM MrFahrenheit: currently printing a test at 185
11:40 AM Emil: yeah higher temp
11:41 AM Emil: also check your motors and how big steps you make
11:41 AM Emil: and how fast
11:41 AM MrFahrenheit: "that were not a problem for the stock PLA"
11:42 AM Emil: so?
11:42 AM nuxil: take a look at that guid/faq i gave you. it should tell whats causing it & how to fix it
11:42 AM Emil: stock PLA != new PLA
11:42 AM MrFahrenheit: doubt the motors broke since yesterday
11:42 AM Emil: mate
11:42 AM Emil: just because your stock PLA might be good
11:42 AM Emil: and withstand motor issues
11:42 AM Emil: doesn't mean your new PLA does
11:43 AM nuxil: https://www.simplify3d.com/support/print-quality-troubleshooting/#not-extruding-enough-plastic
11:43 AM nuxil: bookmark it :p
11:45 AM nuxil: MrFahrenheit, for big overhangs you might need to add in support strucktures.
11:58 AM Emil: add?
11:58 AM Emil: not automatically calculated for you?
12:02 PM Ameisen: interesting
12:02 PM Ameisen: libgcc can be lto
12:02 PM Ameisen: so far avr-libc cannot
12:02 PM Ameisen: that's... unexpected
12:02 PM Ameisen: avr-libc should be LTOable, libgcc shouldn't be
12:02 PM Ameisen: my crashing earlier appears to be a bug in binutils master. Had to go back to the last fixed version
12:08 PM Jartza: nuxil: https://rigid.ink/pages/ultimate-troubleshooting-guide
12:09 PM Jartza: that's even better one than s3d guide
12:09 PM Emil: _nice_
12:09 PM Ameisen: I use Cura, generally.
12:09 PM Emil: I'll share that
12:09 PM nuxil: thanks :)
12:09 PM Ameisen: sooometimes slic3r does a better job
12:09 PM Ameisen: but the newest Cura has a ton of bridging options which basically makes it feature-parity with slic3r
12:13 PM Jartza: I use IdeaMaker nowadays more often than S3D
12:14 PM Emil: https://emil.fi/m/2018-05-10_19-39-03_YNZsEVO3.png
12:19 PM nuxil: lol.
12:51 PM nuxil: https://pastebin.com/9DR13VGX the spi sck ticks and data are sent, but it does not set CS pins low for wanted device on the bus.
12:52 PM nuxil: why isnt my PORTB |= 0x07^cs; working as i want ?
12:53 PM nuxil: the line cs lines are always high :(
12:56 PM nuxil: oh my.. just noticed i have defined miso as output
12:57 PM Ameisen: so, now if avr-libc is built with gcc, it can't find vfprintf... which is part of avr-libc.
12:57 PM Ameisen: err
12:57 PM Ameisen: built with lto
12:57 PM Ameisen: as in, is right there as a symbol
12:58 PM Ameisen: otherwise, I am making progress
12:58 PM antto: nuxil cuz you are doing PORT |= mask^minusmask;
12:59 PM Ameisen: that reminds me
12:59 PM antto: you can only turn bits on this way, not turn bits off
12:59 PM antto: you want:
12:59 PM Ameisen: I need to add variable-specific memory barriers, and a scheduling barrier.
12:59 PM Ameisen: the latter has been complained about on a ton of AVR forums
12:59 PM Ameisen: GCC will happily move instructions in/out of critical sections
12:59 PM nuxil: antto, ahh so i want ~
12:59 PM antto: PORT |= mask; PORT &= (~minusmask);
01:00 PM nuxil: thanks
01:01 PM * antto removes the alarm function on nuxil's phone
01:01 PM Ameisen: I forget - does AVR _not_ have clear/set registers for ports?
01:01 PM Ameisen: having to load and store seems frustrating
01:01 PM antto: Ameisen xmega has
01:01 PM Ameisen: and... also might not work
01:01 PM antto: clear, set, toggle
01:01 PM Ameisen: if an interrupt hits between the load and the store, the value of the PORT might change
01:01 PM Ameisen: and thus you change it to something that isn't valid
01:02 PM Ameisen: so you need to put that in a critical section...
01:02 PM Ameisen: unless it's in an ISR with interrupts cleared, of course
01:02 PM antto: Ameisen i use ATOMIC_BLOCK(ATOMIC_RESTORE_STATE) { stuffz_here }
01:02 PM Ameisen: no idea what that is, but I presume it's a weird wrapper around saving sreg, clearing interrupts, and restoring sreg.
01:03 PM antto: yes, it's in <avr/atomic.h> or so
01:03 PM Ameisen: I have other wrappers for that
01:03 PM Ameisen: including a null wrapper that does nothing just so I can re-use code in ISRs
01:03 PM antto: i'm sure you have
01:04 PM Ameisen: main issue is, again, GCC has no scheduling barriers
01:05 PM Ameisen: it will happily move non-volatile ops in/out of critical sections
01:05 PM Ameisen: which is annoying
01:05 PM Ameisen: it comes up a bit when you try to put heavy math _outside_ of the critical section
01:05 PM Ameisen: GCC will sometimes just relocate it into the critical sectoin
01:05 PM Ameisen: because it has no way to say 'don't move stuff in/out of this block'
01:06 PM antto: eh, wasn't there some memory barrier thing?
01:06 PM Ameisen: memory barriers doesn't control scheduling moves
01:06 PM antto: or are you talking about something different
01:06 PM Ameisen: there's more than one kind of barrier
01:06 PM Ameisen: and none of them control scheduling
01:06 PM Ameisen: there's no scheduling barrier
01:06 PM antto: i don't even know what you mean with scheduling *shrug*
01:06 PM Ameisen: memory barriers will just control that memory is written/read properly (you're basically telling the compiler that memory should be considered invalid at the barrier point)
01:07 PM Ameisen: scheduling = the compiler reordering instructions to improve optimizatiomn
01:07 PM antto: hm
01:07 PM Ameisen: there's no schedulnig barrier, so it happily will move instructions into a critical section if it thinks it's faster
01:07 PM Ameisen: since it doesn't know what a critical section is
01:07 PM antto: the only place i can think of, that is sensitive to that, is for CCP
01:08 PM antto: aka configuration change protection
01:08 PM Ameisen: people have literally seen the compiler relocate a function that performed some heavy math before a critical section
01:08 PM Ameisen: it decided to inline it and then relocate it into the critical section
01:08 PM Ameisen: so the critical section went from 5 cycles to like 60
01:09 PM antto: like, in order to change some very important setting, like, to initiate a software reset, which is done by RST.CTRL |= 0x01; (i think), you need to execture another instruction before that
01:09 PM antto: CCP.CTRL = 0xD9; (some magic value)
01:09 PM Ameisen: all critical sections are sensitive to it.
01:09 PM antto: when you write this magic value, you got 4 clock cycles to change the RST.CTRL
01:10 PM antto: if you put some other instructions in there - it won't work ;P~
01:10 PM Ameisen: the issue is that the compiler happily will put more instructions into your critical section
01:10 PM Ameisen: making it take longer while interrupts are disabled
01:10 PM Ameisen: thus potentially starving your ISRs
01:10 PM antto: now, you can just write these in C/C++ and the compiler does the right thing no matter what optimization options
01:11 PM antto: but that's probably because those are SFRs and are volatile
01:11 PM Ameisen: I need to figure how to write a scheduling barrier for GCC
01:11 PM Ameisen: might make sense just to add direct support for critical sections for AVR into GCC
02:01 PM * nuxil just eat spareribs grilled on the barbecue
02:01 PM nuxil: yummy yummy in my tummy
02:02 PM nuxil: so antto
02:02 PM nuxil: why do it in two lines.
02:02 PM nuxil: PORTB |= ((0x07) & ~(cs)); gives the same result right ?
02:04 PM nuxil: isnt (0x07 & ...) evaluated before the or
02:05 PM cehteh: that should even be statically evaluated and emit no code
02:05 PM nohitzzzz: i too ate barbeque
02:07 PM nohitzzzz: steaks and feta salad
02:07 PM nohitzzzz: and beer and milk
02:07 PM nuxil: cehteh, how do i do that when i only want to modify the 3 lsb in portb register ?
02:07 PM nuxil: beer & milk
02:07 PM nuxil: that does not compute
02:08 PM cehteh: modify as in set, clear, toggle or assign?
02:08 PM nohitzzzz: well beer while grilling, milk when eating
02:08 PM nuxil: cehteh, // = nnnnn110, (nnnnn101, or nnnnn011)
02:08 PM nuxil: the n's must not be modifyed
02:09 PM cehteh: atomic or dont care?
02:09 PM nuxil: cs has value 1 , 2 or 4
02:10 PM nuxil: i dont care about atomic :p
02:10 PM cehteh: i mean all with one set instruction or can you afford multiple set instructions (with immediate states)
02:12 PM nuxil: well.
02:12 PM cehteh: then your code is ok (but why do you invert cs?)
02:12 PM nuxil: because antto told me that PORTB |= 0x07^cs dont work.
02:12 PM nuxil: and it didnt either
02:13 PM cehteh: sure, that does strange things :D
02:13 PM nuxil: the CS line needs to go from high to low. thats why i invert it
02:14 PM cehteh: you need PORTB = (PORTB & ~7) | ~cs .. that equals to your above code
02:14 PM cehteh: in some cases (for example you know the old cs value) there may be easier/better ways
02:15 PM cehteh: aka atmegas can toggle bits in one instruction, when you know the old state then you can create a bitmask which just toggles it to the new intended state
02:16 PM nuxil: hmmm. intresting
02:16 PM nuxil: tell me more :D
02:16 PM cehteh: thats PINB = mask; each bit which is set in mask toggles (xor) the corespondending bit in PORTB
02:17 PM cehteh: sometimes you dont need to calculate this mask, for example this could be a table
02:17 PM cehteh: or otherwise implicit
02:18 PM nuxil: im not sure i understand.. do you mean by toggeling "A" 0|1, i can create a seq of example 0b110, 101, 011 ?
02:18 PM cehteh: when thats the case you have a nice shortcut, otherwise, calculating a mask might not be worth it
02:18 PM nuxil: remember i have 3 CS pins i need to control. not just 1
02:20 PM cehteh: that bit toggle works on the entire PORTB, 8 bits
02:20 PM cehteh: you must ensure that the higest 5 bits of that mask are always 0 then nothing there (nnnnnxxx) the n's wont be toggles
02:20 PM nuxil: can you make a simple example ?
02:20 PM cehteh: can cs be arbitary or does it follow some schema, like counting up / down or so?
02:21 PM cehteh: 1 2 4 1 2 4 1 2 4 .. etc
02:21 PM nuxil: it can be anything.. as long as it can do atleast 3 states.. to tell which chip to enable
02:22 PM cehteh: ok then you better just use the PORTB |= ((0x07) & ~(cs));
02:22 PM nuxil: :D
02:22 PM nuxil: lol
02:23 PM cehteh: well technically there may be smarter solutions, but i am not motivated to explain right now :D
02:23 PM cehteh: plus, make it work first, the easy way, optimize later
02:24 PM nuxil: PORTB |= ((0x07) & ~(cs)); works just fine.. already tested it :)
02:28 PM cehteh: yes will surely work, i just thought you bitbanging some protocoll and want to shave every instruction cycle you can do
02:29 PM nuxil: no no. just send data to 3 different devices using spi. no bitbaning involved.
02:29 PM nuxil: using the hw
02:30 PM cehteh: alright then
04:20 PM antto: ehm, nuxil
04:20 PM antto: |= is OR
04:21 PM antto: "PORTB |= (mask);" is the same as "PORTB = (PORTB | (mask));"
04:21 PM nuxil: well to be presise its a = a | b :p
04:21 PM antto: yes, so if you are trying to set and clear bits with that - it's not gonna work
04:22 PM nuxil: PORTB |= ((0x07) & ~(cs));
04:22 PM antto: 1 or 0 is never 0
04:22 PM nuxil: works fine
04:22 PM nuxil: 0.O
04:23 PM antto: if the given bit in PORTB is currently on, then you can't turn it off with that code ^
04:24 PM nuxil: huh? ports are set high by default. and it shurly sets the port low by using that.
04:24 PM nuxil: *them
04:24 PM antto: then i must have lost all my bitwise knowlage
04:28 PM nuxil: idk .lol
04:29 PM nuxil: let me verify that all 3 cs lines works as should.. only tested 2 and they work.
04:30 PM MrFahrenheit: got a 5020 radial fan yesterday, but it somehow seems too loud... can't say for sure though, never seen a fan like it before
04:36 PM antto: nuxil, http://cpp.sh/5tefy
04:37 PM antto: press RUN then check the text in the execution tab
04:37 PM antto: but it comes down to this very basic thing:
04:38 PM antto: 0xFF | 0x00 == 0xFF
04:38 PM antto: you can't turn bits off with OR
04:46 PM nuxil: yes your right.
04:47 PM antto: nuxil and pls, i am almost falling asleep, but i know my bitwise shizzle well
04:47 PM nuxil: :D
04:49 PM antto: | turn bits on, & turn bits off, ^ toggle bits, ~invert
05:01 PM antto: there should be a new operator - operator @ for blaming something
05:01 PM antto: @Emil
05:15 PM polprog: https://youtu.be/YjCeoTTeQXQ
05:22 PM polprog: check this out
05:34 PM nuxil: polprog, are you inspired by https://www.youtube.com/watch?v=IE9jShG9sD0&list=RDIE9jShG9sD0&t=3 ?
05:36 PM polprog: sure
05:36 PM polprog: jean michel jarre is a great composer
05:36 PM polprog: i think ive got his tape and a cd
05:37 PM nuxil: i bet you do :p
05:43 PM polprog: https://youtu.be/vSgGNd6thrc
05:43 PM polprog: hmm so the original bassline was even more "acid"
06:19 PM Jartza: d'oh
06:19 PM Jartza: nuxil: https://gist.github.com/Jartza/56d006504316ef5fe5a3db1b3e438ca9
06:19 PM Jartza: :D
06:21 PM nuxil: Jartza, where is your #define BIT_ISSET(B, b) (((B) >> (b)) & 1) ?
06:27 PM Jartza: you don't need one
06:27 PM polprog: #define while if
06:27 PM polprog: night ;)
06:27 PM Jartza: #define SOME_BIT BITP(DDRB, PB4)
06:27 PM Jartza: if (SOME_BIT) ...
06:27 PM nuxil: alright
07:06 PM cehteh: #define IF_SOME_BIT if(SOME_BIT)
09:06 PM JanC is now known as Guest69049
09:06 PM JanC_ is now known as JanC
09:12 PM Ameisen: polprog #define if if (false) if
09:12 PM Ameisen: guaranteed to make your code faster.
09:13 PM Ameisen: unless stuff is expensive in the else, of course. but that's solveable with more defines
11:48 PM rue_mohr: the idea is to make your code readable as the goal of what your trying to do
11:49 PM rue_mohr: so instead of saying X = X & (X-1)| (X>>2) & (X ^ X);
11:49 PM rue_mohr: just say X = 0;
11:49 PM rue_mohr: of say _CLEAR(X);
11:50 PM rue_mohr: most people prefer X = X & (X-1)| (X>>2) & (X ^ X);
11:50 PM rue_mohr: it doesn't make the goal of the code clear
11:58 PM rue_mohr: most people also prefer to use 64 bit, 60Mhz controllers for processes that operate at 1Khz and use numbers no larger than 16 too.
11:59 PM rue_mohr: I _AM_ the guy who just built a pure 8 bit FFT and put it on an m328