#avr Logs
May 09 2018
#avr Calendar
02:35 AM Emil: antto: still super easy
02:38 AM Emil: antto: atmega defines are mucj better
02:38 AM Emil: polprog: yeah, 6,5 seconds silent, 0,5s beep, 2,5s silent, 0,5s beep
02:38 AM Emil: overall 7 seconds prepare 3 seconds to shoot twice
02:38 AM Emil: but you can also use it for hiit oe whatever
02:38 AM Emil: its general purpose
02:38 AM polprog: nice
02:38 AM polprog: what kinda gun do you have?
02:38 AM Emil: just a saiga m3 (exp~01), so ak-103
02:38 AM Emil: getting a g17 in the summer
02:38 AM polprog: nice
02:38 AM polprog: yesterday i managed to get xdmx working
02:41 AM Emil: hmm so
02:41 AM Emil: multiple machines and multiple screeb
02:41 AM Emil: s
02:41 AM Emil: abd xdmx provides a cursor that can travel between them all
02:41 AM Emil: ?
02:42 AM polprog: yeah
02:42 AM polprog: in many cases also xinerama
02:42 AM polprog: plan is
02:43 AM polprog: get a moderately cheap ass ssd
02:43 AM polprog: slap it into the hacktop
02:43 AM polprog: install gentoo^Wvoid
02:43 AM polprog: set it up as xdmx slave, enjoy 3 screens on workshop PC
02:44 AM Haohmaru: Emil they're not better, shadap!
02:44 AM polprog: maybe write a small bash/tk wrapper
02:46 AM Emil: polprog: nice
02:46 AM polprog: ;)
02:46 AM Emil: in our previous lab we used vnc for music
02:46 AM polprog: did you see the hacktop?
02:46 AM Emil: no
02:46 AM Emil: link again?
02:46 AM polprog: https://youtu.be/jV2mH5UZnBc
02:46 AM Emil: There qas a single server with audio capability and everyone used vnc to play lusic
02:47 AM polprog: nice
02:48 AM Emil: _nice_
02:48 AM polprog: ;)
02:48 AM polprog: hirens <3. mini xp is so cute
03:14 AM Emil: hmm
03:14 AM Emil: does struct packing (alignment) matter in avr?
03:15 AM Emil: apparently struct {u8; u32}; results in sizeof 8
03:37 AM polprog: this year its the 400 th anniversary of the start of the Thirty Years' War
03:37 AM polprog: you know who to blame
03:37 AM * polprog defenestrates Emil and Ameisen
04:26 AM pitastrudl_ is now known as pitastrudl
05:02 AM Ameisen: What's a good benchmark program/code that I can use to test algorithms/flags
05:04 AM thardin: make and time?
05:08 AM * thardin vaguely remembers the 30 years' war being taught in swedish history
05:35 AM MrFahrenheit: just installed gcc-fortran :)
05:40 AM Haohmaru: gccfortransgenderpeople?
05:57 AM Haohmaru: struct huhwub { uint8_t a; uint32_t b; };
05:57 AM Haohmaru: struct dub { static_assert(sizeof(huhwub) == 5, "oh noes!"); };
05:57 AM * Haohmaru slaps Emil
05:57 AM Haohmaru: ^ this sh*t works
06:00 AM Haohmaru: Emil trying using __attribute__((packed)), or something like -fshort-enums
07:03 AM Emil: Haohmaru: -fpack-struct
07:03 AM Emil: I see Haohmaru is in flames today :D
07:08 AM Ameisen: fucking makefiles
07:08 AM Ameisen: especially libgcc
07:08 AM nuxil: i have use -fpack-struct on my projects.
07:09 AM Ameisen: "oh, your CFLAGS has -O3 -g0? Let's fail spuriously."
07:09 AM nuxil: beavare everything else needs to be compiled with -fpack-struct for it to work. and it can make your code suboptimal.
07:09 AM Ameisen: -fpack-struct is meaningless in AVR, at least in my experience. It packs on alignment bounds.
07:09 AM Ameisen: it does give fun compiler errors though
07:10 AM Ameisen: when libgcc's makefile is assembling .S files, it duplicates CFLAGS, and adds its own
07:10 AM Ameisen: so it has -O3 -g0 -O2 -g -O3 -g0
07:10 AM Ameisen: it doesn't like this
07:10 AM Ameisen: starts erroring about input/output files being the same
07:10 AM Ameisen: if you delete the first -O3, works fine
07:10 AM Ameisen: this is difficult to do since it's their makefile donig crap
07:10 AM nuxil: Emil, https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Code-Gen-Options.html#Code-Gen-Options check the warning text for -fpack-struct and -fshort-enums
07:11 AM Ameisen: also, for some reason, -fshort-enums generates worse code
07:11 AM Ameisen: I believe this is due to GCC presuming that 'int' is the native word size
07:11 AM Ameisen: rather than a byte
07:11 AM Ameisen: though in C++ at least you can specify the size of the enums. Not sure if you can in C.
07:12 AM Ameisen: I need to write a tool to go through all the flags, and figure out output size, and output speed
07:15 AM nuxil: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Option-Summary.html#Option-Summary
07:15 AM nuxil: wtf is -mbranch-cost=cost for AVR options
07:16 AM Ameisen: it adds a 'cost' value to branches for scheduling
07:16 AM Ameisen: I'd have to check the compiler source to see if there is one by default
07:17 AM Ameisen: AVR branches are weird though, with a 1 cycle cost if not taken, and 2 if taken
07:17 AM Ameisen: In the .opt file at least: Set the branch costs for conditional branch instructions. Reasonable values are small, non-negative integers. The default branch cost is 0.
07:18 AM Ameisen: 1 might be better?
07:18 AM nuxil: no idea.
07:19 AM MrFahrenheit: maybe it calculates how much work each branch will do and takes the easier one to make your code super fast :P
07:19 AM Ameisen: well, it's a common property
07:19 AM Ameisen: used for multiple ISAs
07:19 AM Ameisen: I actually don't think it's implemented for AVR
07:19 AM Ameisen: it's exposed but does nothing
07:20 AM Ameisen: there's no use of OPT_mbranch_cost_ anywhere in AVR
07:20 AM Ameisen: on AVR at least all the instruction costs are known beforehand, so it shouldn't need hints anyways
07:20 AM Ameisen: may make sense to validate that those costs are right though
07:23 AM Ameisen: hmm
07:23 AM Ameisen: a lot of the AVR stuff in GCC is hardcoded
07:23 AM Ameisen: like, it has hardcoded commands
07:29 AM Ameisen: I'm looking at the source right now if you have any questions
07:34 AM Emil: waitwaitwait
07:34 AM Emil: so
07:35 AM Emil: does avr-gcc handle structures smartly without -fpack-struct?
07:35 AM Ameisen: I don't recall -fpack-struct doing _anything_ in my tests.
07:35 AM Emil: top kek
07:35 AM Ameisen: struct packing is usually performed on alignment bounds, and AVR's alignment is hardcoded to '1'
07:35 AM Emil: ah
07:35 AM Emil: then its fine
07:35 AM Ameisen: well, it did do something - it gave me compiler errors
07:36 AM Ameisen: it didn't like some syntax in the struct or something
07:36 AM Ameisen: the internal comparison code in avr.c doesn't handle uint64s. I will fix that.
07:42 AM Ameisen: #define MOVE_RATIO(speed) ((speed) ? 3 : 2)
07:42 AM Ameisen: interesting
07:45 AM Ameisen: Might be harder to add more integer types than I thought.
07:45 AM Ameisen: Will have to implement helpers for them
07:54 AM Ameisen: LLVM doesn't require that :(
08:10 AM nuxil: i want to clear the 4 lsb in a port register and keep the 4msb. what would be the best way to do this ? would this be the best way to do it? DDRn = (DDRn >> 4) << 4 ?
08:13 AM Ameisen: I don't recall off-hand if there is a set/clear register.
08:14 AM Ameisen: DDRn &= 0b11110000;
08:14 AM Ameisen: or 0xF0 or whatnot
08:19 AM nuxil: yes ofc.
08:19 AM Ameisen: if there's a clear register, then DDRCn = 0x0F;
08:21 AM Ameisen: sigh. I haven't even gotten to working on avr-libc's LTO problem yet. Dealing with other build issues still.
08:22 AM nuxil: :D
08:23 AM nuxil: you have dug yourself a real deep hole :p
08:23 AM Ameisen: mainly the reason that this assembler step in libgcc fails for arguments that should be fine :|
08:23 AM Ameisen: duplicate gcc arguments shoudl be fine. Yet it breaks.
08:23 AM Ameisen: and it's the makefile that's duplicating them :|
08:24 AM Ameisen: Also, I should note that I really hate it when projects set up optimization flags themselves.
08:24 AM Ameisen: since they tend to override the flags you set
08:25 AM nuxil: automake ?
08:25 AM Ameisen: it's one of the gcc makefiles in libgcc
08:26 AM Ameisen: it duplicates CFLAGS twice, and then adds their own flags
08:26 AM Ameisen: this causes the assembler steps to fail spuriously
08:26 AM Ameisen: interestingly, if I build with -j1, it works fine
08:26 AM Ameisen: but with -j16, it doesn't
08:26 AM Ameisen: I have no friggin' idea.
08:27 AM nuxil: if its one of the "auto generated" makefiles, automake is the root to your problems :p
08:29 AM Ameisen: yeah, but it's still something they've configured.
08:42 AM Haohmaru: abstract the makefile's makefile with another makefile
08:42 AM Ameisen: this is why none of my projects use makefiles or configure scripts.
08:42 AM Ameisen: :|
08:42 AM Ameisen: my build system doesn't have these issues
08:42 AM Haohmaru: yeah, nor mine
08:42 AM Haohmaru: i use the IDE
08:42 AM Ameisen: it has different, unique issues.
08:42 AM Ameisen: I use Visual C++ for editing
08:42 AM Ameisen: which communicates with a set of build scripts I wrote in Ruby
08:43 AM Haohmaru: Code::Blocks for me
08:43 AM Ameisen: which handle the building
08:43 AM Ameisen: they also build far faster than all the other tools I've seen
08:43 AM Haohmaru: i click the BUILD butten
08:43 AM Ameisen: they also handle dependency analysis and compilation, multi-threaded
08:43 AM Ameisen: only thing that would improve it would be multithreaded linking, but ld.gold would need AVR support for that
08:43 AM Haohmaru: leave that for later
08:44 AM Haohmaru: IMO link time for avr programs is not a huge deal
08:44 AM Haohmaru: how big can your program be?!
08:44 AM Ameisen: the object files can be huge if you are doing a lot of LTO and compile-time code generation
08:44 AM Ameisen: they link to a tiny binary
08:44 AM Ameisen: but that's the linker's job
08:44 AM Haohmaru: yeah, okay, so you'll wait 1 minute instead of 4 seconds?
08:47 AM Ameisen: right now, building my printer firmware from a clean build takes about 9 seconds.
08:47 AM Ameisen: it could be 8.
08:47 AM Haohmaru: >:/
08:47 AM Haohmaru: Ameisen pls
08:47 AM Ameisen: However, I'd rather have gold support simply because gold tends to be more stable when messing with LT
08:47 AM Ameisen: LTO
08:48 AM Ameisen: it was designed around LTO. bfd requires plugins.
08:56 AM darsie: Is it worth the effort to get wifi to an avr when you can use something like a raspberry pi zero w instead?
09:01 AM Ameisen: that depends on a lot of factors
09:01 AM Ameisen: I suspect processing wifi on your AVR is going to take up most of its time
09:04 AM darsie: thx
09:04 AM darsie: I thoght of the effort to write code or put it all together.
09:05 AM polprog: im not sure how that esp chip works
09:06 AM polprog: iirc it was arbitrary uart commands
09:06 AM darsie: ESP8266?
09:06 AM polprog: yeah
09:06 AM Ameisen: I mean
09:06 AM Ameisen: you could always get a second AVR chip, or a dinky ARM like a cortex M0
09:06 AM Ameisen: and run it on that
09:06 AM Ameisen: the Cortex M0 is gonna be cheaper. And faster.
09:07 AM polprog: yeah, the case of Amiga SD-card adapter being faster than the amiga itself
09:07 AM polprog: :p
09:07 AM Ameisen: I've actually been considering writing a simple AVR AOT-emulator for ARM, so you could run AVR binaries on a Cortex M0
09:07 AM Ameisen: and also run them at arbitrarily-higher clock rates
09:07 AM darsie: Yeah, I considered adding an avr to a pi for time critical stuff.
09:07 AM Ameisen: well, I'd say that most of the time, the Cortex Ms are more suitable
09:07 AM Ameisen: they're faster and cheaper, usually
09:07 AM polprog: however, a chip that would be a wifi modem, if you know what i mean
09:10 AM polprog: would be nice
09:10 AM Ameisen: AVR is simpler, though
09:10 AM Haohmaru: there's an arm cortex emulator for attiny
09:10 AM Haohmaru: huhuhu
09:10 AM Haohmaru: maybe tun that inside a cortex m with an attiny emulator
09:10 AM Haohmaru: * run
09:10 AM polprog: good platform to test the arm avr emulator on
09:10 AM polprog: you could then port docker
09:11 AM polprog: and run several AVRs on one
09:11 AM polprog: :^)
09:13 AM Ameisen: damn right
09:13 AM Ameisen: would have to figure out a way to handle multiple emulators trying to use one GPIO though
09:14 AM Ameisen: err
09:14 AM Ameisen: why the heck would you want to emulate ARM on AVR
09:14 AM Ameisen: AVR can barely run AVR
09:20 AM Haohmaru: to run linux, of course
09:20 AM Ameisen: I mean
09:20 AM Ameisen: you'd have to emulate the MMU
09:20 AM Ameisen: that... is goign to be incredibly slow
09:20 AM Haohmaru: http://dmitry.gr/?r=05.Projects&proj=08.%20uM0
09:21 AM Ameisen: Cortex M0 doesn't have an MMU though
09:21 AM Ameisen: Actually, most Cortex Ms cannot run Linux
09:21 AM Ameisen: "On average the emulated CPU runs at 200KHz on a 16MHz ATTiny. "
09:21 AM Ameisen: fantastic.
09:22 AM Ameisen: where is he finding i2c/spi ram modules"?
09:22 AM Ameisen: I've looked and found nothing
09:22 AM Haohmaru: okay http://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit
09:22 AM Haohmaru: ..wrong link ;P~
09:22 AM Ameisen: That is going to be incredibly slow
09:22 AM Ameisen: The MMU alone is going to kill it
09:22 AM Ameisen: Though... I don't think Linux _requires_ 32-bit
09:23 AM Ameisen: it _does_ require an MMU, though an MPU might be sufficient?
09:23 AM Haohmaru: i have no idea what those are
09:23 AM Haohmaru: ;P~
09:23 AM Ameisen: might have made more sense for him to have written an AVR backend for Linux, and to implement some simple virtualized instructions for user/system mode, and an MMU
09:23 AM Ameisen: would have run faster
09:24 AM Haohmaru: yeah but this way he can just use existing software for cortex-mortex-whatever
09:24 AM Ameisen: Yes, in a completely useless fashion
09:24 AM Ameisen: since it will take 2 hours to run printf
09:24 AM Haohmaru: who are you to judge!
09:25 AM Haohmaru: greeks take it slow
09:25 AM Ameisen: https://www.tindie.com/products/onehorse/spi-flash-memory-add-ons-for-teensy-3x/
09:25 AM Ameisen: neat, 128 Mbit
09:25 AM Ameisen: 16MiB
09:25 AM Ameisen: but I want more than that
09:27 AM Haohmaru: can i tell gcc to put a global/static variable at a specific location in RAM?
09:28 AM Ameisen: using a linker script
09:28 AM Ameisen: GCC has no attribute for addresses
09:28 AM Haohmaru: nooooooo :~(
09:28 AM Ameisen: though you could do something like
09:28 AM Ameisen: int &foo = *(int *)address;
09:28 AM Haohmaru: will that "reserve" that space for it?
09:29 AM Ameisen: no
09:29 AM Ameisen: there's no good way to do exactly what you want.
09:30 AM Haohmaru: what about.. if i use a section attribute, and then pass one of those -Wl,-section-blahblah=address ?
09:30 AM Ameisen: even if you had something like __attribute__((address:n)), the linker might not know about it at the right time, and may try to use that address beforehand
09:30 AM Ameisen: that would work. Basically an inline linker script.
09:30 AM Ameisen: The _compiler_ wouldn't know the address though
09:30 AM Ameisen: if you use LTO it won't matter
09:30 AM Ameisen: but the compiler, without LTO, cannot perform any optimizations based upon the address otherwise
09:31 AM Haohmaru: i am using -flto here, since it's a bootloader and i'm already at 5KB
09:32 AM polprog: Ameisen: i was accessing registers (memory mapped) on stm8 in C with a pointer typecast
09:32 AM polprog: apropos Haohmaru
09:32 AM polprog: ^
09:32 AM Ameisen: that'll work fine
09:32 AM polprog: You can do it, its just a bit of an abuse
09:33 AM Ameisen: since the linker isn't going to overwrite those registers' memory
09:33 AM Haohmaru: polprog SDCC has a way to specify that you want a specific address
09:33 AM polprog: i dont remember
09:33 AM Ameisen: doesn't work great in C++ since you cannot cast a pointer to anything else as constexpr :(
09:33 AM Ameisen: you used to be able to
09:33 AM polprog: so Ameisen , you mean that on a later stage the linker can "overerite" my chosen location?
09:33 AM Ameisen: but newer versions of g++ fixed it
09:33 AM Haohmaru: uint8_t blah = 0 __at(0x0005); or some such thing
09:33 AM Ameisen: polprog - if you were to just pull a random address out of your ass, then yes
09:34 AM Ameisen: since the linker has zero idea that there's anything there
09:34 AM Ameisen: if you're using the address of a register, then no
09:34 AM Ameisen: since those addresses are forbidden in the linker script
09:34 AM polprog: yeah. so that AND linker script to tell it to keep out of there
09:34 AM Ameisen: sure. Gets really tedious to have to alter the linker script though
09:34 AM polprog: hence i said it was abuse :p
09:34 AM rue_mohr: void * foo = 0xdeadbeef; ?
09:35 AM polprog: all in all, always check the damn output assembly
09:35 AM polprog: or to be puristic, deassemble it
09:37 AM Haohmaru: i'm no cr4x0r
09:38 AM polprog: rue_mohr: #define PA_ODR (*(unsigned char*)0x5000)
09:38 AM Ameisen: ugh
09:38 AM Ameisen: don't do that in C++
09:38 AM polprog: clackety clack. thats an ugly hack
09:38 AM Ameisen: I hate that the headers do that
09:38 AM Ameisen: can't use it in constexpr
09:39 AM polprog: owait it has to be volatile as well
09:39 AM polprog: fun
09:44 AM nn7: Where can I find a list of what I can put in tracepoints for Atmel Studio 7?
09:44 AM rue_mohr: I recommend debugging in a way you wont want to
09:45 AM Haohmaru: Ameisen i think i'd only need a uint8_t in ram at the exact same location in both firmware and bootloader
09:45 AM nn7: I recommend eating things you don't like.
09:45 AM Haohmaru: in order to pass the reset reason
09:46 AM Haohmaru: cuz the bootloader has to check it and clear the flags, yet, the firmware want's to know the reset reasons too
09:46 AM Haohmaru: * wants
09:47 AM Haohmaru: maybe.. i could use some register of some peripheral..
09:47 AM Haohmaru: as a last hope
09:50 AM Haohmaru: gotta fly
09:50 AM nn7: Ug, they did a really bad job of documenting any of this
10:04 AM polprog: i tried to rebuild the project with debugging symbols
10:04 AM polprog: dev cpp crashed :D
10:06 AM polprog: http://polprog.net/papiery/x86/declare_a_variable.c
10:13 AM Emil: lulz
10:13 AM Emil: teaching our linux course
10:13 AM Emil: background:
10:14 AM Emil: https://elepaja.fi/telegram/media/AgADBAADQa0xG-ycmFPFjfx0d7vaPkEPjhoABEXKc9lWDSlA-jsFAAEC.jpg
10:14 AM Emil: live feed with audio of White-tailed Sea Eagle and Saimaa ringed seal
10:14 AM Emil: :3
10:15 AM polprog: <3
10:25 AM polprog: vs 17
10:25 AM polprog: it is a challenge to make an editor that lags on a 4x4ghz cpu with 8 gigs of ram
10:25 AM polprog: and my trial expired, fu, i didnt even like it
10:30 AM Emil: http://tv.eenet.ee/merikotkas.html
10:31 AM polprog: cute bird
10:31 AM polprog: interesting image artifacts hmm
10:32 AM polprog: how about some live bisons?
10:32 AM polprog: https://www.lasy.gov.pl/pl/informacje/kampanie_i_akcje/zubryonline
10:32 AM polprog: none of them is there right now
10:58 AM MrFahrenheit: so I went to the hardware store to buy some 608 roller bearings, and they only had 607 and 609 ones
10:58 AM MrFahrenheit: then it started raining
11:39 AM nuxil: what are you making ?
11:41 AM Emil: https://luontolive.wwf.fi/norppalive/
11:42 AM nuxil: hmm.. if i do. DDRn = 0; set all pins as input.. and PORTn = 0xff so pullups are enabled.. now if i do DDRn = 0xff .. will this reset the PORTn register and set the values to 0 ? or will the pin be set high when doing this ?
11:46 AM MrFahrenheit: nuxil, spool holder
11:46 AM nuxil: alright :)
11:46 AM MrFahrenheit: so I just saw a chinese smartphone with android 7, a 5in screen and 2gb of ram, and it's $64
12:07 PM polprog: lol
12:07 PM polprog: on the other hand if we can make a 5 bucks sbc...
12:08 PM polprog: i just got some screwdrivers and pliers
12:08 PM polprog: not an excellite greenie though
12:14 PM Ameisen: ah
12:14 PM Ameisen: that's why this patch wasn't working
12:14 PM Ameisen: makefile commands don't honor spaces
01:02 PM antto: Ameisen so, there's attributes io(), address() for avr
01:02 PM antto: unfortunately, i get side effects with them
01:04 PM antto: i think imma try using a made-up section and linker arguments to position that section in ram
01:04 PM Ameisen: what side-effect do you get with them
01:05 PM Ameisen: remember though, those are _not_ going to be known to the compiler
01:05 PM Ameisen: err
01:05 PM Ameisen: linker
01:05 PM Ameisen: io/io_low are for addresses in the IO address space, address is for addresses outside of the valid address range
01:05 PM antto: with address() i can put my variable at 0x800200 (the first byte of the .data section) but i got another variable in one of my .cpp files that normally sits on this byte, and it's not moved
01:05 PM antto: so this results in a collision
01:05 PM Ameisen: yes.
01:06 PM Ameisen: Variables with the address attribute are used to address memory-mapped peripherals that may lie outside the io address range.
01:06 PM Ameisen: the linker doesn't know about it.
01:06 PM Ameisen: thus the linker is free to put something else ther.e
01:06 PM Ameisen: volatile int porta __attribute__((address (0x600)));
01:06 PM Ameisen: is semantically equivalent to doing
01:06 PM antto: so it doesn't "reserve" that location, just positions the variable there.. meeeh
01:06 PM Ameisen: volatile int &porta = *(volatile int *)0x600;
01:07 PM antto: this would be useful for the io headers tho
01:07 PM Ameisen: yes
01:07 PM antto: VERY useful
01:07 PM antto: if only it was used ;P~
01:07 PM Ameisen: it's what it is primarily intended for
01:07 PM Ameisen: unfortunately, many of the AVR attributes are either rarely used, or not really fully functional
01:07 PM Ameisen: attribute progmem is only half-useful in gcc
01:08 PM Ameisen: it will put the data into program memory, but it would change the access semantics
01:08 PM Ameisen: won't*
01:08 PM antto: so i'll try a section("pls_santa") and then -Wl,-something
01:08 PM Ameisen: so you still have to emit the instructions for it
01:08 PM Ameisen: gcc has __flash for that, but it doesn't work in g+
01:08 PM Ameisen: g++
01:09 PM LeoNerd: gcc's handling of flash isn't very nice yet :/
01:15 PM antto: crap
01:15 PM antto: so i did that, and that other unrelated variable still collides
01:16 PM antto: if i make my own made-up section and position it with -Wl,--section-start, it's like the .data section is not moved forward at all
01:16 PM antto: duh
01:17 PM antto: this little detail was a very important assumption in my fancy bootloader idea
01:31 PM Ameisen: LeoNerd - at least in C, though, gcc will use the proper access semantics for it
01:31 PM Ameisen: g++, __flash isn't even defined
01:31 PM Ameisen: there's no address-space support
02:16 PM polprog: ssd in the hacktop
02:16 PM polprog: void installing
02:28 PM Emil: nuxil: that is mentioned in the datashit
02:28 PM Emil: as an issue
02:29 PM Emil: switching from high impedance input to driving the output means either having the pullups on or temporarily driving strongly against ground
02:29 PM Emil: nuxil: why would writing to DDRx have an effect on PORTx -.-
02:30 PM Emil: You cannot atomically switch from high impedance no pullup to low impedance high drive
02:30 PM Emil: or from high impedance pullup to low impedance low drive
02:41 PM polprog: lol void linux' partitioner is broken
02:41 PM Emil: wot
02:41 PM Emil: :D
02:41 PM Emil: omegalul
02:41 PM polprog: cannot toggle a bootable flag
02:41 PM polprog: "cfdisk"
02:42 PM polprog: fdisk is some poor mans version, doesnt have the 'a' command to toggle bootable
02:42 PM Emil: you sure it's not just user error?
02:42 PM polprog: no parted
02:42 PM polprog: no im sure
02:42 PM Emil: yeah but I mean
02:42 PM polprog: im reading the mailing list
02:42 PM Emil: lots of students say "yeah I checked I sweeaaaaar!
02:42 PM Emil: "
02:42 PM polprog: there is no 'boot' column
02:42 PM Emil: ah
02:42 PM Emil: lol
02:42 PM polprog: they say there should be....
02:42 PM polprog: nothing happens when i press b
02:43 PM polprog: gosh im installing netbsd on it
02:43 PM Emil: >not LFS
02:43 PM polprog: lets see how fast it boots from an ssd
02:43 PM Emil: >why even live
02:43 PM Emil: btw I use Arch
02:43 PM polprog: id like to go to sleep in 2 hours at most
02:43 PM polprog: btw i actually do
02:44 PM Emil: lol nerd
02:44 PM Emil: I'm a well adjusted young person who only runs Debian
02:44 PM polprog: wait, theres slackware
02:44 PM polprog: :D
02:45 PM polprog: i hope its not the 32 bit version
02:45 PM polprog: whatever
02:49 PM polprog: huh so its this bloody EFI
02:49 PM polprog: if i set the disk as MBR its all OK
02:49 PM polprog: fuck that
02:49 PM polprog: its a 240 gig SSD
02:49 PM polprog: i dont need GPT on this
02:49 PM polprog: KISS
02:50 PM Emil: noooo
02:50 PM Emil: GPT all the way
02:55 PM nohitzzzz: i like how they do the header files with STM32, much more elegant than avr https://pastebin.com/mv2nSzVD
02:59 PM nohitzzzz: and when you use IDE and type "USART1->" it gives you the list of the registers that belong to that peripheral
03:00 PM polprog: gah fck that
03:00 PM polprog: im installing debian
03:01 PM Emil: nohitzzzz: it's just an abstraction (or a helper) layer on top of what avr offers
03:01 PM Emil: what I dislike about it is that you must carry that struct everywhere
03:01 PM Emil: which is annoying
03:02 PM Emil: but as a programming concept it's goodish design
03:02 PM Emil: since you know all your registers are within the context of the struct
03:09 PM polprog: huhuhu
03:09 PM polprog: i dont need a whole debian on it
03:10 PM polprog: ill go with netbsd, just need to burn a 64 bit CD
03:16 PM antto: nohitzzzz the xmega headers are exactly the same, except missing the handy USART_BASE address offset thing
03:16 PM antto: it would've been better if they were actual declarations with __attribute__ shizzle
03:19 PM antto: hmzz
03:19 PM antto: how are the first 0x200 bytes of ram called?
03:20 PM antto: ..the bytes where the SFRs go
03:20 PM antto: i mean, how's that section called?
03:20 PM * antto is thinking of a hack
04:13 PM nohitzzzz: do you have the patterns saved for that Acid Jam (2016_05) thats on youtube
04:13 PM nohitzzzz: you should produce a track from that
04:13 PM aczid: antto: memory mapped IO?
04:14 PM antto: nohitzzzz probably
04:15 PM antto: aczid i have the feeling they don't have a name in the linker script
04:15 PM polprog: 100 MiB/s untar wooo
04:15 PM polprog: WOOOOOO
04:15 PM polprog: FAST
04:17 PM * antto calls the cops
04:18 PM aczid: antto: where ram ends depends on the avr core, iirc
04:20 PM polprog: ramend noodles
04:20 PM aczid: it's in the preprocesesor as RAMEND on avr-gcc(!)
04:21 PM polprog: delicious macros
04:21 PM aczid: I don't have much experience with the linker process though
04:21 PM antto: aczid i was thinking more about the beginning of the ram
04:21 PM polprog: isnt it at 0x0000?
04:22 PM aczid: yeah, that?
04:22 PM antto: no, 0x800200
04:22 PM polprog: thats the memory mapped area for IO registers though
04:22 PM polprog: oh
04:22 PM antto: but 0x800000 to 0x800200 should be for the SFRs
04:22 PM antto: 0x800200 is section data
04:23 PM antto: i was asking if the first 0x200 bytes have a section name
04:23 PM antto: but it smells like "nope"
04:23 PM aczid: antto: RAMSTART
04:23 PM aczid: it's all in the io*.h files under constants
04:23 PM polprog: Because of the Harvard architecture of the AVR devices, you must manually add 0x800000 to the address you pass to the linker as the start of the section. Otherwise, the linker thinks you want to put the .noinit section into the .text section instead of .data/.bss and will complain.
04:24 PM polprog: https://www.nongnu.org/avr-libc/user-manual/mem_sections.html#harvard_arch
04:24 PM antto: yeah, i read that
04:25 PM antto: thing is
04:25 PM antto: blah..
04:27 PM antto: i can't seem to even move the .data section away
04:28 PM antto: fuuuug
04:30 PM antto: -Wl,--section-start,data=0x800222
04:30 PM antto: muh variables still start from 800200
04:35 PM antto: -Wl,--section-start=.data=0x800222 damn it.. this
04:36 PM antto: pff, well, "success"
04:36 PM antto: static uint8_t bleh __attribute__((used, address(0x800200))) = 0;
04:36 PM * antto slaps Ameisen with that ^
04:52 PM aarcane: oiy, I have an atmega324pa, and I'm trying to add a bootloader (optiboot) and an application (17078 bytes, 52.1% usage). Optiboot wants to use 0x00003E00 - 0x00003FFF, but the application wants to use that address as well. I am at a loss. What must I do?
04:55 PM nuxil: Emil, yes ofc. i had a brainfart there for a while. was a bit frustrated why my matrix keypad was not working properly.
04:56 PM nuxil: see places i can improve it ? https://pastebin.com/RFAkdRUR
04:56 PM nuxil: my keypad code.
04:58 PM nuxil: aarcane, antto is your friend in that case :p i belive he just had issues like that :p
05:02 PM nuxil: https://www.avrfreaks.net/sites/default/files/bootloader_faq.pdf maybe that is of some help
05:09 PM nuxil: aarcane, what is the PA variant? i got atmega324-20PU myself.
05:09 PM aarcane: nuxil, I'm not really sure. I couldn't ever find anything to differentiate the p, a, or pa from the ''
05:10 PM nohitzzzz: do you guys have that asm code example of that arduino digitalWrite() function
05:10 PM nohitzzzz: compared to "PORTB = 0xF;" or whaever
05:11 PM nuxil: i belive the p is for plastic package
05:11 PM aarcane: nuxil, I think it's just a tiny formfactor chip. it's one of the little ones with ant-sized legs rather than a big DIP package.
05:12 PM nohitzzzz: Emil the disassembly of the arduino code do you have it
05:12 PM nohitzzzz: digitalWrite()
05:12 PM nuxil: nohitzzzz, its not asm
05:13 PM nuxil: https://pastebin.com/g3vaFC3Q
05:15 PM nuxil: copy pasted direcly from wiring_digital.c in ../Arduino/hardware/arduino/avr/cores/arduino/
05:15 PM nuxil: nohitzzzz, why do you want to mess around with the arduino code ?
05:15 PM nuxil: its so boated :p
05:18 PM nuxil: *bloated
05:20 PM Emil: nohitzzzz:
05:20 PM Emil: sur
05:20 PM Emil: https://emil.fi/d/overhead.cpp
05:29 PM nohitzzzz: is this 100% valid
05:33 PM aarcane: uh... antto nuxil.. No clue what's going on here. I tried telling gcc: -Wl,-section-start=.bootloader=0x3e00, but 0x3e00 still has non-bootloader code in it. Is it possible to tell the compiler "Just write around this address" or "Application code starts after bootloader at address 0x4000" and if so, how do I tell optiboot to start application at 0x4000 ?
05:48 PM antto: aarcane eh? why do you want to put app at 0x4000?
05:49 PM antto: setting the section location of the .bootloader would only make any difference if you actually use that section for anything
05:50 PM aarcane: I just have application + bootloader code overlapping
05:50 PM antto: overlapping?!
05:52 PM aarcane: antto, yes
05:52 PM aarcane: that's what I'm trying to fix
05:52 PM aarcane: they both want to place their hex contents at 0x3E00... and optiboot is for some stupid reason not letting me move optiboot...
05:54 PM antto: is this optiboot compiled for a 16kb atmega?
05:54 PM antto: how big is optiboot
05:54 PM antto: does the firmware not start from 0?
05:58 PM aarcane: firmware starts at 0... I'm just trying to solve the optiboot/firmware overlap issue and make my firmware uploadable
05:58 PM antto: i had some issues with getting my xmega bootloader working
05:58 PM antto: at the end, i think i had to actually objdump a binary instead of a hex
05:58 PM antto: and flash it directly with -U boot:w:file.bin:r
05:58 PM antto: (note: xmega has dedicated flash for bootloader)
05:58 PM antto: aarcane dude, there can't be an overlap
05:59 PM antto: the bootloader on atmega can sit on one of a few locations at the end of the flash
05:59 PM antto: you can't slap it just anywhere
05:59 PM aarcane: antto, I eventually narrowed it down. It had to do with how AVR and atmel studio and avrgcc and hex files and all were misrepresenting addresses.
05:59 PM antto: your atmega has 32K flash, right?
06:01 PM aarcane: so I *finally* figured out how to get optiboot to link itself at the proper 0x7000 and 0x7FFE addresses instead of 0x3xxx
06:01 PM nuxil: antto, yes atmega342 has 32kb atleast the pu variant.
06:02 PM antto: 342 or 324?
06:02 PM nuxil: 324
06:02 PM nuxil: sorry
06:02 PM nuxil: typo
06:02 PM antto: nuxil typing fast doesn't count if ya make typos ;P~
06:02 PM * nuxil turn on a div8 prescalar
06:03 PM antto: use one finger to type, for safety
06:03 PM nuxil: haha :D
06:03 PM aarcane: just don't use one hand to type ;)
06:03 PM antto: no, one finger on one hand
06:03 PM antto: otherwise u gon get typos again
06:04 PM nuxil: aarcane, so what did you do to fix it ?
06:05 PM antto: he probably got lost with the bootloader address
06:05 PM nuxil: heh :D
06:05 PM antto: datasheets, compilers, sometimes say it in bytes, sometimes in words
06:06 PM antto: fusebits for bootloader size also change that address
06:06 PM antto: xmega is simpler
06:07 PM aarcane: nuxil, brute forced the address for optiboot to 0x7000 and the fuses to 3800, then I was able to both merge the files and flash them separately.
06:07 PM nn7: so I'm just starting to play with JTAG. I've been doing debugging with OCDEN disabled. What do I gain with OCDEN?
06:57 PM Ameisen: running into some unusual build errors
06:59 PM Ameisen: assembler output: the input and output must be distinct
06:59 PM Ameisen: if I run the command that failed, it throws that error. If I run it again, it doesn't. Ad infinitum
06:59 PM Ameisen: doesn't fail if I run with -j1 instead of -j16
07:03 PM Ameisen: I'm wondering if some dangling bash shells are sitting around
11:21 PM day__ is now known as day