Back
[05:05:31] <Skippy_421> mornin' guys
[05:25:32] <_abc_> .
[05:26:38] <_abc_> I ran into the problem that avr/bin/ld is compiled without --sysroot= capability yielding the error message 'avr/bin/ld: this linker was not configured to use sysroots'. Browsing seems to show this is a 'popular' error. It appears in several systems I have so various avr-gcc vintages from 2010 to present.
[05:27:09] <_abc_> ld is invoked via avr-gcc here in the final linking step of the project. Please suggest a way to invoke the sysroot-less ld in this case?
[05:29:53] <_abc_> I note that the -B option is passed to avr-gcc in this case and points at the correct location. Should I simply try to run ld by hand?
[05:35:01] <_ami_> i never ran across of this kind of issue before.
[05:35:22] <_ami_> which linux platform are you using? _abc_^
[05:40:54] <_abc_> Not relevant, everything is installed manually. The key solution was: ensure the last avr-gcc call, when called as linker, does NOT have the --sysroot= set ; as opposed to all previous calls as as and gcc which must have it set. The ld step avr-gcc call MUST have the -B option set when it calls avr/bin/ld.
[05:41:12] <_abc_> You have not run into this because you probably do not use/write custom makefiles
[05:41:36] <_abc_> This question should be in the faq I googled/ducked a lot and no results came forth so I tried something I "felt" was right.
[05:42:42] <_abc_> So, avr guys, the solution above should be put in some faq please? ^^
[05:44:25] <_abc_> The solution is confirmed to work on any avr-gcc install including very old ones (2010)
[05:44:29] <_abc_> As well as new ones.
[06:36:57] <_ami_> hmm
[06:37:57] <_ami_> i just use target_link_libraries to link libraries. cmake does the job of linking
[06:38:16] <_ami_> why to waste time on writing Makefile.
[06:38:26] <_ami_> either use cmake or automake.
[06:38:44] <_ami_> i have tried writing makefiles before but its just a pain to ass.
[06:45:41] <Jartza> allo
[06:58:43] <carabia> pain to ass.
[06:58:56] <carabia> amen. and some curry to boot.
[07:04:23] <carabia> Whoever are the ones in charge of writing "easy-to-use"-libraries for ARM at various silicon mfgs should be sodomized with a god damn cactus. So far on my list are STM and Atmel
[07:10:10] <Jartza> why not use some modern tools
[07:10:36] <Jartza> like meson and ninja.
[07:10:42] <Jartza> http://mesonbuild.com
[07:10:52] <Jartza> https://ninja-build.org
[07:12:08] <Jartza> carabia: I'm not trying to scare you but I can say that atmel and STM libraries are like honey on waffles when you compare them to for example freescale ones :)
[07:13:41] <carabia> Jartza, I do love the stdperiph-libs STM has
[07:14:16] <carabia> the HAL ones (for M7 etc.) are the proverbial "pain to ass"
[07:14:31] <Jartza> yea
[07:14:48] <carabia> well, don't really "love" them, but they are very usable and easily debuggable
[07:14:49] <Jartza> but still much nicer than for example freescale kinetis sdk :)
[07:14:52] <Jartza> aka KSDK
[07:15:01] <carabia> probably, haven't touched them
[07:15:28] <bss36504> Have you ever tried using the blessing/curse that is processor expert?
[07:16:06] <carabia> Is that something like ST's cubemx?
[07:17:39] <bss36504> No clue. But basically it provides (via Freescale's Eclipse build *shudder*) code "beans" that help you configure and instantiate things. They have everything from IOs up to a FreeRTOS bean.
[07:18:47] <carabia> Yeah, it's exactly like cubemx then
[07:18:51] <bss36504> It's often not worth the trouble for simple things like just setting up an IO, but for the RTOS or flash writing or even setting up the spi port, it's fairly helpful. But, if you fuck something up in the generated code, it completely breaks your code haha
[07:19:12] <bss36504> Neat idea for sure, I prefer the ASF route though
[07:19:16] <bss36504> Little more hands on
[07:19:46] <bss36504> and now that ASF integration isn't quite as stupid as it used to be, it's fairly useful to me to not have to hunt down all the libraries and dependencies.
[07:21:32] <carabia> the cubemx lets you map io and other peripherals, clock config, and some "middleware" such as an RTOS (I guess it was FreeRTOS), fatfs, etc. Then it bundles all up with the driver libraries into a SW4STM32 (Eclipse), IAR, or KEIL project you can import
[07:23:01] <carabia> SW4STM32 Isn't _all_ that bad, actually.
[07:23:14] <_abc_> Hello again. Would this work for /any/ gcc? I think yes? RTL is portable between architectures, no?
http://www.gson.org/egypt/egypt.html Looks /very/ nice thank you
[07:23:29] <carabia> Well, technically it's just eclipse with gnuarmeclipse, openocd and gdb ":D"
[07:24:01] * _abc_ hopes Finland is less hot than Romania now (sweat pant pant)
[07:24:09] <_abc_> So, any input on the above would be nice.
[07:27:16] <carabia> _abc_, gcc on any platform, any version of gcc, any c std, waat?
[07:27:22] <_abc_> I am going to try egypt later on a little avr-gcc project
[07:27:49] <_abc_> waat waat? RTL code should be portable so egypt should be able to make a graph out of it.
[07:28:05] <_abc_> I mean any gcc's RTL output
[07:29:04] <carabia> did i say waat? i mean w00t?
[07:29:15] <_abc_> That is much better ;)
[07:31:22] <carabia> figures
[07:32:17] <carabia> oh and _abc_ ... finland is mostly a very chilly place to be in.
[07:32:45] * _abc_ wants chilly willy now, 33 degC here
[07:34:18] <carabia> I wouldn't mind that
[07:34:38] <_abc_> After a month of it you will start hiding in meat fridges
[07:35:07] <carabia> I read that as "hiding meat in fridges", figured it'd be a penis thing...
[07:35:09] <_abc_> wunderground.com says 36 degC. My outside thermometer may be inaccurate >;)
[07:35:29] <_abc_> no, meat fridges are kept at -18C, feels great to step inside for a moment
[07:36:10] <carabia> yeah well, pretty much any freezer is kept at -18 C or so, I have a few actually. One vertical, one horizontal, you would fit in both so take your pick
[07:36:42] <_abc_> So, anyone else who wants to try egypt+dotty on avr-gcc code?
[08:41:41] <Skippy_42> Do you think using malloc on an atmega is ok?
[08:44:04] <LeoNerd> Personally, no
[08:55:35] <bss36504> Skippy_42: Malloc is prone to heap fragmentation, which is fine on a PC but on a micro it's real bad. You'd be better off writing your own heap manager.
[09:00:22] <_ami_> bss36504: does avr-libc support malloc or new?
[09:00:34] <bss36504> Yes
[09:00:37] <bss36504> It's in there
[09:00:39] <bss36504> It does work
[09:00:48] <_ami_> aha, i did not know.
[09:00:51] <_ami_> ok, nice.
[09:01:37] <bss36504> But if you make a lot of allocations you'll quickly run out of heap. Even if you free some of it, the heap can be so fragmented that you don't have enough contiguous space to allocate new blocks
[09:02:35] <_ami_> does it support placement new too? then i could write some allocator which uses both data/bss section along with heap.
[09:03:00] <bss36504> That I do not know
[09:03:17] <bss36504> I assume you are trying to use some C++ dynamic allocation?
[09:03:25] <_ami_> static int last_resort_for_mem[100]; int *x = new (last_resort_for_mem) int;
[09:03:41] <_ami_> bss36504: no, placement new
[09:04:42] <bss36504> Sorry, had to refresh on what that was. I dont know, you could try it. I see your point though
[09:05:51] <bss36504> But why do you need to support placement new? You could just overload the regular 'new' operator to use your custom allocator.
[09:09:45] <_ami_> bss36504: i could use it but it won't do the automatic allocation of variables on bss/data section memory. i would have to write some C types of casting/intelligence to do it.
[09:09:57] <_ami_> placement new already takes care of thi
[09:10:01] <_ami_> this*
[09:13:02] <bss36504> Placement new just calls the constructor and places the object at a particular address, right? It doesnt actually do any allocating because the allocation was done ahead of time (or at least, it assumes so). So if you are going to bother writing a custom allocator anyway, you get placement new for free, but you *also* get regular, allocating new
[09:13:35] <_ami_> bss36504: i meant allocation as pointing to memory area.
[09:13:36] <bss36504> You just need to overload the allocator new operator to use your allocator instead of std::malloc
[09:13:51] <_ami_> indeed. it is.
[09:14:11] <bss36504> you can point all you want but if the heap is not managed, what's to prevent collisions?
[09:14:32] <bss36504> So again, you're back on using malloc, or a custom allocator to include data and bss
[09:14:52] <bss36504> but it's all the same problem, you must have SOME allocator somewhere
[09:15:24] <sabor> static is a very nice allocator :)
[09:15:32] <_ami_> bss36504: if i do something like in my setup(), int *allocfullheapmem = new int[100]; //already allocated 400 bytes, this is just one time call.
[09:15:42] <_ami_> then after there won't be any allocation.
[09:15:56] <bss36504> but what if you want to put 40 ten-byte objects in there?
[09:16:07] <_ami_> A *a = new (allocfullhelpmem) A;
[09:16:19] <bss36504> Ok and then the next one
[09:16:19] <_ami_> a is allocated at the start of allocfullhelpmem
[09:16:22] <_ami_> yeah
[09:16:22] <bss36504> yes
[09:16:40] <_ami_> this is who most of big applications or games work like that.
[09:16:49] <bss36504> but then what about A *A2 = new(allocfullheapmem+sizeof(A)) A;
[09:16:56] <_ami_> yup.
[09:17:11] <bss36504> right, but that code is literally a means of managing heap
[09:17:18] <_ami_> this will be job of memory allocator class or std::malloc/new override
[09:17:24] <_ami_> yeah, indeed.
[09:17:44] <_ami_> i was talking abt using this placement new concept in your memory manager
[09:17:51] <bss36504> Ah, gotcha
[09:18:03] <bss36504> I think we were talking about the same thing, but missing it haha
[09:18:09] <_ami_> Yup. :)
[09:18:09] <bss36504> ships in the night, as they say
[09:19:00] <bss36504> Question though, doesn't fetching from data/bss require different instructions than loading from ram or am i totally wrong? If i'm not, how will that work?
[09:19:37] <_ami_> no no, C should take care of it. i don't think dev needs to worry abt it.
[09:20:02] <_ami_> just allocate a big mem area in bss/data, and use it.
[09:20:19] <_ami_> static int mem1[10]; //goes to data
[09:20:32] <_ami_> int mem2[20]; // goes to bss
[09:20:39] <bss36504> Oh silly me, bss/data are sram so it's fine
[09:20:49] <_ami_> int *mem3 = new int[100] ; // goes to heap.
[09:21:42] <bss36504> yeah for some reason my brain cramped and I thought those were in flash and I was thinking about how you have to do that pointer translation macro in order to map it properly.
[09:22:08] <_ami_> bss36504: happens :P
[09:22:22] <_ami_> when you deal with so many low level things
[09:24:17] <bss36504> I'm fairly out of practice with some of those nitty gritty details too. Not like it's every day that you care about the memory sections.
[09:27:54] <_ami_> i am trying luck with fritzing software.. :D
[09:28:44] <carabia> ?
[09:28:45] * LeoNerd runs a mile
[09:28:48] <LeoNerd> It's terrrrrible
[09:28:56] <bss36504> lol
[09:29:03] <rain1> I've een using fritzing
[09:29:07] <carabia> is fritzing that thing where you do those breadboard diagrams?
[09:29:08] <rain1> it's very very slow
[09:29:11] <rain1> a bit stressful
[09:29:14] <LeoNerd> It's great if you want to produce silly pictures of what your breadboard looks like with a couple of sparkfun modules and an arduino plugged in, to go on your "arduino" blog
[09:29:27] <rain1> http://i.imgur.com/8tysWId.png
[09:29:32] <rain1> thats my design with i
[09:29:33] <LeoNerd> But if you're actually seriously intending to produce real things by way of PCBs it won't help you
[09:29:43] <_ami_> oh. :P
[09:30:17] <carabia> Try that foss-one... KiCAD?
[09:30:26] <bss36504> Or Eagle
[09:30:30] <carabia> eagle's getting pretty gay, to be honest.
[09:30:35] <bss36504> Or nut up and buy Altium
[09:30:57] <bss36504> Yeahhh im annoyed with the sluggish pace of eagle's development
[09:30:58] <_ami_> although i needed to send a working schematic of a project to my client. :) i think fritzing is the quickest one.
[09:31:11] <bss36504> Still baffles me why Autodesk bought Cadsoft.
[09:31:26] <carabia> Yeah cause why not. I'm sure we can just throw what, 5k on something you absolutely don't even need ... per year
[09:31:38] <bss36504> carabia: I was kidding of course :)
[09:31:41] <carabia> If 5k's even enough. Who knows with their wanky licenses
[09:31:47] <carabia> :)
[09:32:13] <carabia> You should buy Altium, and KEIL MDK too, while you're at it. To get you going, so to speak.
[09:32:30] <_ami_> learning KiCad is in my TODOs
[09:32:53] <LeoNerd> kicad, yes, will get you a lot further
[09:33:06] <LeoNerd> I suspect there's already quite a few kicad users in this very channel, so help is close at hand
[09:33:16] <_ami_> nice, good to know that.
[09:33:20] <_ami_> encouraging :)
[09:34:08] <carabia> I suspect kicad has a freenode channel
[09:34:16] <carabia> ...and i was right
[09:34:21] <LeoNerd> mhm
[09:34:22] <_ami_> ##kicad?
[09:34:30] <carabia> #kicad
[09:34:31] <LeoNerd> No, one hash. It's the official one
[09:34:45] <LeoNerd> In fact it's right next door, see. ;) This is /win 23, and #kicad is /win 24
[09:34:57] <LeoNerd> In fact if I shouted in here perhaps they'd hear me over there
[09:35:07] <carabia> Oh yes, so better be quiet.
[09:54:11] <twnqx> i started kicad once
[09:54:23] <twnqx> ... i gave up about 10 minutes later
[09:54:28] <twnqx> :X
[09:58:28] <bss36504> twnqx meeee too.
[09:59:26] <twnqx> admittedly, i might give it another try
[09:59:36] <twnqx> eagle is far out for what i need
[10:00:19] <twnqx> maybe looking at Zuken or something of that class
[10:01:30] <bss36504> I had never heard of Zuken until now
[10:01:53] <carabia> Me neither, looks expensive :)
[10:02:09] <bss36504> Also looks nice
[10:02:18] <twnqx> it is... not cheap
[10:02:24] <twnqx> around altium level
[10:02:24] <bss36504> I get a little excited by "truly new software"
[10:02:52] <twnqx> but i prefer something with integrated highspeed signal integrity analysis
[10:03:00] <bss36504> Because i'm sick of EDA/CAD companies just layering more shit on top of their old shit and then polishing it to sell to you so you can shit out a product
[10:03:19] <twnqx> if i have 5+gbit/s links in the design
[10:03:31] <twnqx> and ddr 3/4 memories
[10:03:32] <bss36504> twnqx looking at the product page, seems as though CADSTAR has SI stuff
[10:03:56] <twnqx> so does... who bought hyperlynx? mentor? :S
[10:04:07] <carabia> If it's "around altium-level", I figure altium would be a bit more... established
[10:04:25] <twnqx> yes, but altium has the same kind of suckage kicad
[10:04:32] <twnqx> e.g. not automatically numbering components
[10:04:34] <carabia> as I guess a 3rd party SI analyzer is a bit... out there I guess
[10:04:51] <twnqx> yeah, everyone these days has a hyperlynx exporter
[10:05:19] <bss36504> Hyperlynx looks cool, though it might be because Mentor sends me an email almost daily to tell me how cool it is
[10:05:35] <twnqx> it's at least an old product
[10:05:37] <bss36504> Also, Zuken CR-5000 starts at US$65K
[10:05:42] <twnqx> i have a.... copy... from 2005
[10:05:55] <bss36504> a "copy" you say?
[10:06:09] <bss36504> did you "purchase" it?
[10:06:28] <carabia> bss36504: is that one-time downpayment or will you get some amazing annual licensing fees?
[10:06:30] <twnqx> i... found... it
[10:06:40] <carabia> needs... more... dots
[10:06:47] <twnqx> or coffee
[10:06:49] <bss36504> carabia no clue it was just a press release I found via google
[10:07:49] <carabia> $65k. That altium-buff (the one whose balls are in constant pinch), would be happy.
[10:09:18] <twnqx> but i think you need cr-7000 for SI :P
[10:12:34] <carabia> Who knows, maybe they give out free samples \o/
[10:13:19] <bss36504> Maybe if I promise to put there logo in silk across an entire side of the board, I can get it for free
[10:13:31] <bss36504> their* jeez
[10:15:36] <carabia> Can't find cr7000, only 8000, and the way I see it, that's a lot more than a PCB-designer
[10:32:56] <twnqx> or 8000. can't remember exactly, didn't follow up with it due to other work
[11:41:42] <_abc_> Are GPIORx used for anything by gcc or usual libraries? I think not.
[11:48:17] <liwakura> afaik no
[11:48:33] <liwakura> but they are pretty awesome for bitwise switches
[12:05:32] <_abc_> That's what a project I am studying uses them for,
[21:10:27] <carabia> After a great deal of blood, sweat and borderline tears, I managed to get the SDIO HAL-driver working for stm32f7 \o_
[21:11:54] <carabia> CubeMX's clock config is amazing, if you happen to mistype an impossible clock, it will try to calculate divisors for it until the end of time I guess... :)
[21:13:59] <learath> carabia: instead of using irrational clocks? :)
[21:14:40] <carabia> learath: irrational is irrelevant. I'm quite sure it goes through same clocks several iterations
[21:14:54] <carabia> And the point is you can't cancel the process, you have to kill the program
