#avr Logs

Oct 10 2017

12:07 AM day__ is now known as daey
02:43 AM Haohmaru: very weird
02:44 AM Haohmaru: why do i have the feeling that avrgcc doesn't warn me about declaring big buffers and running out of memory?
02:47 AM Haohmaru: on an xmega32a4u-au, i had two 512-byte buffers for my fifo (transmit and receive), then i figured i need a bit more, and i made them 2x 1024, but i got a weird bug where data seem to get corrupted/broken for no clear reason
02:47 AM Haohmaru: and periodically
02:48 AM Haohmaru: now i just tried declaring both buffers as 2048 bytes each - and it compiles o_O
02:48 AM Haohmaru: that xmega has 4K RAM
02:54 AM thardin: maybe your link script is poop?
02:55 AM thardin: mine certainly complains if I try to allocate too much, especially non-bss data
02:55 AM thardin: since I have bss + heap in xmem
02:57 AM thardin: perhaps something simple, like avr-ld not getting -mmcu= ?
03:06 AM Haohmaru: i'm not using any scripts myself, i compile via the IDE
03:09 AM Haohmaru: http://paste.debian.net/989967/
03:11 AM Haohmaru: just for the funz, i declared 3x1024 buffers and one 1124 buffer, and that's beside the other stuff i have (like another, smaller FIFO for another usart and a bunch of objects)
03:13 AM Haohmaru: so, for linking, avrg++ is called, and i see something that looks like arguments to the linker
03:13 AM Haohmaru: and -mmcu
03:19 AM Haohmaru: what's "bss" exactly?
03:20 AM Haohmaru: cuz i changed one of the buffers to 18KB and it still compiles, but i noticed the reported value for bss also went up
03:24 AM LiaoTao: Haohmaru: https://en.wikipedia.org/wiki/.bss
03:26 AM Haohmaru: hmz
03:27 AM Haohmaru: well, 4x512 buffers works (after testing) but i need slightly bigger, and i can't easily tell how big i can go with the buffers except for running the test again and waiting to see if something would get broken after a while or not
03:28 AM LiaoTao: If you get no warnings when statically allocating over 4k on a 4k system you should probably try to troubleshoot your toolchain
03:28 AM Haohmaru: so bss is for global-scope declared variables which are not initialized in their declaration?
03:29 AM Haohmaru: like my buffers.. uint8_t buffer[1024];
03:29 AM Haohmaru: my toolchain is avrgcc :/
03:29 AM LiaoTao: Or for local variables declared static
03:29 AM LiaoTao: But yes, that's the gist of it
03:30 AM Haohmaru: thing is, two of the buffers are declared locally in main()
03:30 AM Haohmaru: the other two are global scope
03:31 AM LiaoTao: So you've got two of them on the stack?
03:32 AM Haohmaru: well, i don't know stack schmack
03:33 AM Haohmaru: two of them are declared in the global scope, the other two are local, in main(), all of them are just declared as arrays, no initializers
03:33 AM Haohmaru: and the language is C++11
03:34 AM LiaoTao: You should probably allocate all large buffers statically and just pass around some pointers
03:34 AM LiaoTao: That way you can keep track of memory usage
03:34 AM Haohmaru: statically meaning...?
03:34 AM Haohmaru: with the static keyword?
03:35 AM LiaoTao: Globally would probably be better in your case
03:35 AM LiaoTao: That way the compiler can check for over-allocation
03:35 AM LiaoTao: If you let the stack grow far enough it will intersect with your statically allocated memory and create all sorts of weird issues
03:38 AM Haohmaru: so i'm trying to figure out how big i can set those buffers, and depending on buffer sizes i declare, sometimes the chip seems to "work" other times it doesn't start at all, and now i even got it to loop and reboot like mad
03:39 AM LiaoTao: Yes - you're running into the problem I described above
03:39 AM LiaoTao: You need to ensure that you leave enough memory for dynamically allocated variables
03:39 AM LiaoTao: i.e. for the stack to function properly
03:39 AM LiaoTao: That's why you should allocate your large buffers statically so that you know how much dynamic memory you have to work with
03:40 AM Haohmaru: even so.. how would i know that?
03:40 AM Haohmaru: i don't actually allocate dynamically
03:41 AM LiaoTao: If you're using local variables you're allocating dynamically - just not heap allocating if that's what you thought dynamic allocation meant
03:43 AM Haohmaru: so i moved those two buffers to global scope
03:44 AM Haohmaru: and i still get no warning or anything
03:45 AM Haohmaru: i declared one of them 8KB, bss says 10611, compiles "fine"
03:46 AM LiaoTao: That indicates to me that your toolchain is incorrectly configured or broken
04:23 AM Haohmaru: how do i "set it up" then?
04:27 AM Haohmaru: could it be that since the xmega supports external memory to be used (which becomes part of the normal RAM address space) that the compiler would only warn me if i try to take more ram than THAT
04:27 AM Haohmaru: iirc you could have several KB or even MB?
04:34 AM LiaoTao: Sorry, I'm an AVR newbie as well
04:34 AM LiaoTao: What I said above just applies in general
04:39 AM Haohmaru: yeah, sure
04:39 AM Haohmaru: in the io header for the xmega32a4u, RAMSIZE is defined as INTERNAL_SRAM_SIZE, which is defined as 4096
04:40 AM Haohmaru: while the external memory has sepparate definitions (XRAMSIZE, etc..)
04:40 AM Haohmaru: so hm..
05:38 AM Emil: avr-size will tell you sizes of sections
05:38 AM Emil: and if it overflows
05:38 AM Emil: imho
05:38 AM Emil: iirc*
05:56 AM Haohmaru: no, it doesn't
05:56 AM Haohmaru: or at least i'm not seeing it
09:03 AM Haohmaru: bss - bullsh*t section :~(
09:35 AM thardin: I'm starting to suspect my CFLAGS are bork. avr-gcc does not generate an sbi instruction for something like DDRG |= (1<<3);
09:36 AM thardin: unless DDRG is outside the low 32 or 64 addresses..
09:36 AM thardin: it is
10:02 AM MrCircuitMatt: what's the method du jour for via fencing? dropping vias all over the place or still the via-footprint approach? I see an "add via" button that I hadn't noticed before
10:09 AM MrCircuitMatt: yeah fail. I invite everybody to ignore that line of mine while I copy & paste it into the correct channel
10:19 AM Cracki_: thardin, ddrg is way outside the register range
10:19 AM Cracki_: ah, you got that :)
10:25 AM thardin: yeah
12:25 PM Emil: thardin: -Os
12:31 PM Emil: MrCircuitMatt: kicad?
12:31 PM Emil: MrCircuitMatt: via footprint, select net, array
12:33 PM MrCircuitMatt: Emil: OK thanks
12:40 PM Emil: Basically make a footprint that's just a throughhole
12:41 PM Emil: then in pcbnew ctrl+o that footprint
12:42 PM Emil: associate that single footprint with the relevant net
12:42 PM Emil: and then you can copy and paste and make arrays out od it
12:42 PM Emil: the polar array one is fucked, though
12:43 PM Emil: It's super ridiculous that you cant just via stitch easier
01:10 PM bss36504: Emil: "It's open source, just fix it yourself" -- Paraphrasing you when I was complaining about KiCAD ;)
01:24 PM Emil: I have never said thay
01:24 PM Emil: that*
01:24 PM Emil: If I have, it was in jest
01:37 PM bss36504: I know, I'm just jesting you back friend :)
01:41 PM Emil: bss36504: my irclogs disagree with you
01:48 PM bss36504: Maybe it was carabia then haha
01:56 PM Emil: prooolly :D
02:57 PM LeoNerd: Offhand: anyone know if the ATmega328PB's ADC is basically the same as the 328P? I.e. can I just reuse the same driver code?
02:58 PM LeoNerd: (Otherwise I'm going to have to sit and meticulously read the datasheets)
03:03 PM LeoNerd: Hrm - seems to be to my casual inspection anyway
03:19 PM Emil: Eh
03:19 PM Emil: just look at the register descriptions
03:19 PM Emil: But yes it is the same imho
03:22 PM hetii: Hi :)
03:22 PM Emil: Evening
03:23 PM hetii: I have 110W toroid that give me 2x12v and after AC bridges I give caps like 2x20000uF, the question is should I add also a softstart for such toroid or make no sense cause its too small power?
05:18 PM Emil is now known as FBI
05:19 PM FBI is now known as Guest32405
05:19 PM Guest32405 is now known as Emil
05:28 PM DarkUranium: hey, question: can the ATTiny25 detect conflicts when using I2C? (e.g. for multi-master, SMBus, and such)
05:33 PM HighInBC: detect or resolve conflicts?
05:34 PM Lambda_Aurigae: DarkUranium, if you program it right, yeah, probably.
05:34 PM HighInBC: I am not 100% but I think I2C conflicts result in two responses being overlaid on each other like and AND
05:34 PM DarkUranium: HighInBC, yeah.
05:34 PM DarkUranium: Lambda_Aurigae, I mean, it requires reading the state after setting it.
05:34 PM DarkUranium: so the module needs to include that (or else I'm stuck with bit-banging)
05:34 PM Lambda_Aurigae: again, if you program it to do so, probably...
05:34 PM DarkUranium: HighInBC, I doubt many things can resolve them, since that's application-specific.
05:34 PM Lambda_Aurigae: I doubt the USI can do it automagically.
05:34 PM DarkUranium: right.
05:34 PM DarkUranium: I'm not very familiar with the USI, so.
05:35 PM Lambda_Aurigae: Jartza is our USI master here far as I know.
05:35 PM HighInBC: I can imagine a situation where a response is garbled due to a conflict but the garbled response makes sense by chance. that would be hard to detect
05:35 PM DarkUranium: conflict resolution is not about responses
05:36 PM DarkUranium: it's about sending
05:38 PM DarkUranium: automated resolution is basically limited to an abort in time
05:38 PM DarkUranium: (which is a must)
05:47 PM DarkUranium: and it's only not noticable if there are two messages sent at once
05:48 PM DarkUranium: with the same data
05:48 PM Emil: Didn't tiny's have a twi driver?
05:48 PM Emil: If not
05:48 PM Emil: then no the driver doesn't do shit for you
05:48 PM Emil: meaning you can do it yourself
05:48 PM Emil: manually
05:49 PM DarkUranium: I'm just asking because I saw I2C in the product finder. Whether that refers to USI or not, I have no idea.
05:49 PM DarkUranium: maybe I'll try PIC12F1822 instead
05:49 PM DarkUranium: see if that has it
05:49 PM Emil: stop
05:49 PM Emil: no
05:49 PM Emil: pls
05:49 PM Emil: god
05:49 PM Emil: no
05:50 PM DarkUranium: what?
05:50 PM Emil: no pic
05:50 PM Emil: don't go that route, man
05:50 PM DarkUranium: why not.
05:50 PM Emil: AVR/ARM
05:50 PM Emil: those are your options
05:50 PM DarkUranium: if it can do shit AVR can't, then I'm gonna do PIC
05:50 PM DarkUranium: and you're not being helpful by saying that
05:51 PM Emil: Oh we have a salty person here
05:51 PM DarkUranium: "stop no pls god no no pic don't go that route man" isn't exactly constructive, you know.
05:52 PM Emil: top kek
05:52 PM DarkUranium: what's your problem?
05:53 PM Emil: Nothing, just laughing at your choise
05:53 PM Emil: Of all the flavours you chose salty
05:53 PM DarkUranium: how is it salty?
05:53 PM DarkUranium: it's the better tool for the job.
05:53 PM DarkUranium: hell, they even advertise SMbus compat in the datasheet
05:53 PM DarkUranium: which means they need to do resolution
05:54 PM DarkUranium: or rather, detection
05:54 PM Emil: /kickban DarkUranium for being salty
05:54 PM * Tom_L kicks Emil
05:55 PM Tom_L: either atmel was ripe for picking or failing. either way PIC owns their arse now
05:56 PM DarkUranium: I mean
05:56 PM DarkUranium: Atmel MCUs are part of Microchip's product list & product finder as of a few days ago
05:56 PM DarkUranium: I think as of yesterday
05:56 PM Tom_L: the attractive thing about avr always has been their free tools
05:56 PM Emil: as of like over a year
05:56 PM DarkUranium: or at least that's when I noticed they added 'em
05:56 PM DarkUranium: Tom_L, yeah
05:57 PM Tom_L: i've got ccs c etc for pic but had to pay
05:57 PM DarkUranium: Tom_L, the fact that Microchip asks money for a friggin compiler is criminy, though
06:03 PM Lambda_Aurigae: microchip bought atmel quite a while ago.
06:03 PM Lambda_Aurigae: atmel products have been on microchip site for months.
06:04 PM DarkUranium: Lambda_Aurigae, not in the product selection tools, IIRC
06:04 PM DarkUranium: but I might mis-remember
06:04 PM Lambda_Aurigae: been there for a while now.
06:05 PM DarkUranium: *shrug*
06:05 PM DarkUranium: at any rate, no point in not using PIC if it's the more appropriate tool for the job.
06:05 PM Emil: stop
06:05 PM Emil: no
06:05 PM Emil: this is a prank right
06:06 PM Emil: It's just a brank bro
06:14 PM DarkUranium: Emil, I'm gonna wire a PIC on a relay, and send 220V through your precious Atmels!
06:14 PM Tom_L: how personal we can take a piece of sand
06:17 PM Emil: DarkUranium: not my loss of components
06:24 PM DarkUranium: Tom_L, see also: El Alamein!
07:08 PM noHitW_work: i got this today http://www.ftdichip.com/Products/Modules/VM800C.html
07:09 PM noHitW_work: this http://brtchip.com/product/vm800c50a-d/