#avr Logs

Sep 11 2018

12:46 AM HighInBC: rue_bed: yup, bc canada
01:21 AM rue_bed: HighInBC, I'm on the sunshine coast, you in vancouver?
07:39 AM [1]MrMobius is now known as MrMobius
10:30 AM nabil_ is now known as nabil
10:31 AM merethan_w: What exactly does A Twi´s interface SLAVE.ADDRMASK do?
10:37 AM skz81: merethan_w, where do you read this ?
10:37 AM merethan_w: Some sourcecode someone else wrote
10:37 AM merethan_w: Funny thing is, my device now responds to two i2c addresses
10:38 AM polprog: let me guess, they differ by the least significant bit ? ;)
10:38 AM merethan_w: By setting the 2nd bit (LSB+1) to one, this bit no longer matters in the address matching?
10:39 AM skz81: polprog, thinking of R/W bit ?
10:40 AM polprog: skz81: yeah
10:40 AM polprog: i dont remember if ADDRMASK is a register, this might be some library code
10:41 AM polprog: check the datasheet, theres a register list at the end
10:43 AM skz81: polprog, not a register, at least in atmega328. 'addrmask' not even found in DS...
10:44 AM polprog: must be a lib thing
10:44 AM skz81: That's why i were asking "where do you read this" :)
10:59 AM merethan_w: ADDRMASK is in Atmel´s include\avr\iox32e5.h file
11:16 AM davor_ is now known as davor
01:36 PM PoppaVic: OK, am I missing a c-pointer that can access RAM, EEP or FLASH? (I know the methods are different, but I thought gcc was capable of keeping like a 24bit pointer around)
01:42 PM polprog: RAM is accessed normally
01:42 PM polprog: EEPROM and FLASH have their own routines
01:43 PM polprog: eeprom.h handles eeprom, flash reading is done via PROGMEM and flash writing is possible only in bootloader mode
01:43 PM PoppaVic: No, I know that - what I am wondering is if gcc has a "pointer" that needs shift/mask, but addresses any of the three? (a void* for harvard)
01:43 PM Ameisen: which compiler?
01:43 PM Ameisen: they work a little differently
01:44 PM Ameisen: also, C or C++?
01:44 PM PoppaVic: oh, gods. C - screw c++
01:44 PM Ameisen: well, you lost my help.
01:44 PM Ameisen: :)
01:44 PM PoppaVic: winner!
01:44 PM polprog: i dont think theres any other way to access flash in AVR
01:44 PM polprog: Ameisen is a C++ prophet ;)
01:44 PM Ameisen: It's one thing to say 'I am using C', it's another to insult the language someone else specializes in
01:44 PM Ameisen: for no particular reason
01:44 PM polprog: joking
01:44 PM PoppaVic: Ameisen: it's ok, I forgive you.
01:45 PM Ameisen: polprog - at the moment, I should be getting better codegen than C or normal C++
01:45 PM Ameisen: obviously that's sorta hard to test
01:45 PM polprog: you can use normal c ptrs to access eeprom
01:45 PM polprog: you just pass them to calls
01:46 PM polprog: what is your question?
01:47 PM PoppaVic: polprog: what that tells me is that "normal" and void* devolve to uint16_t - and you still need the apropos routines or cast.
01:47 PM polprog: yeah. avr uses 16bit pointers
01:47 PM PoppaVic: which is OK, I was just running-down shit I vageuly remembered: for example a MAP file that uses 24bit or special sizes to address eeprom, ram, flash
01:48 PM Ameisen: AVR uses 16bit and 24bit pointers
01:48 PM Ameisen: depending on the context.
01:48 PM polprog: yes
01:48 PM Ameisen: GCC C supports automatic context handling
01:48 PM Ameisen: GCC C++ does not
01:49 PM Ameisen: that is - the __flashX attributes not only specify the storage location, but also specify the semantics to be used for access
01:49 PM PoppaVic: yeah. I have yet to deploy the 1284P I picked up, but I already knew that the 328p and 2560's had issues even with the optiboot.
01:49 PM PoppaVic: Ameisen: I dunno "flashx" - got a link?
01:50 PM polprog: never heard of that as well
01:50 PM polprog: is it a cpp thing?
01:50 PM polprog: must be new stuff
01:50 PM PoppaVic: BTW, I recently ordered an adafruit Feather M0 - it was so impressive;y priced and sized I managed to get an EE to order the m4 itsy-bitsy ;-)
01:51 PM PoppaVic: But, yeah.. I am working on the Uno to try to flesh-out code for a guy partial to ATtiny88.. Making my head hurt.
01:52 PM Ameisen: one sec
01:52 PM Ameisen: polprog - it is _not_ in c++
01:52 PM Ameisen: which is annoying
01:52 PM Ameisen: mainly because the g++ maintainers suck
01:53 PM Ameisen: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
01:53 PM PoppaVic: so is c++, but I am kind and allow for crazies all day long ;-)
01:53 PM polprog: why havent i heard about it before LOL Ameisen
01:53 PM polprog: you make my day
01:53 PM Ameisen: i mean
01:53 PM Ameisen: I've brought it up before.
01:53 PM Ameisen: and got into a fight with Emil about it once
01:53 PM PoppaVic: polprog: named-spaces are not really "new", but that doc is
01:54 PM polprog: id use pgm_read_xxx() before
01:54 PM polprog: this is ingenious
01:54 PM Ameisen: doesn't work in C++, which is incredibly frustrating
01:54 PM Ameisen: I have some workarounds
01:54 PM Ameisen: but I really need compiler support
01:54 PM polprog: #pragma C
01:54 PM polprog: ?
01:55 PM Ameisen: wouldn't help
01:55 PM polprog: :/
01:55 PM PoppaVic: polprog: #pragma has been known to be a clusterfuck for about 20 years.
01:56 PM PoppaVic: The best you can say for it is: well, you can ignore it.
02:08 PM nabil_ is now known as nabil
02:10 PM Ameisen: #pragma specifies compiler-specific things.
02:10 PM Ameisen: MSVC even has __pragma (which allows it to be used as an expression)
02:12 PM PoppaVic: It's worse than the html/javascript shit - which is why you ignore it: you can't trust it, OR you are there to exploit it.
02:18 PM Ameisen: the annoying thing about #pragma is also that since it's a preprocessor statement, you cannot map it to a different define
02:18 PM Ameisen: the MSVC ones you can (the __pragma form)
02:18 PM PoppaVic: they've tried at least 2 times since I learned C to create something LIKE pragma and make it stick.
02:19 PM Ameisen: well, C++ has [[ attribute ]] now, but it has a similar problem
02:19 PM Ameisen: there's only a few _standard_ attributes
02:19 PM Ameisen: the rest are system defined.
02:19 PM PoppaVic: yes
02:20 PM Ameisen: part of the problem is also that the C and C++ VM specification is very broad
02:20 PM Ameisen: #pragma pack, for instance, makes zero sense in regard to either spec
02:20 PM PoppaVic: PRAMA was supposed to be "per build" and ATTRIBUTE wa supposed to be "per identifier"
02:20 PM Ameisen: it makes sense to a programmer
02:20 PM Ameisen: but it's hard to standardize
02:20 PM Ameisen: what do you mean by 'build'
02:21 PM Ameisen: neither C nor C++ have a concept
02:21 PM Ameisen: just compiling
02:21 PM Ameisen: (linking is actually separate from the specs altogether)
02:21 PM Ameisen: I would love to get away from the translation unit model
02:21 PM Ameisen: LTO gets us like, 1/4 of the way there
02:23 PM PoppaVic: I am of mixed mind: linkers make great sense in Linux/unix - but to keep targeting that for a microcontroller is right on the edge of "wtf is wrong with you?!?"
02:41 PM Ameisen: the problem with translation units is optimization (thus LTO), but in C++ it also impedes templates from being as useful
02:41 PM Ameisen: since they have to be defined per TU
02:41 PM Ameisen: you ncan still have a linker to handle things like linking to a static lib
02:41 PM Ameisen: but I'd rather that every source file not be its own object file
02:43 PM * PoppaVic chortles
02:45 PM MarcinWieczorek_ is now known as MarcinWieczorek
08:38 PM rue_mohr: --
11:25 PM day__ is now known as day
11:43 PM [1]MrMobius is now known as MrMobius