Back
[08:45:52] <kristoiv> Is there a reason I have to disconnect my AVRDragon from my laptop, the power to my Atmega328P and the TWI-connectors between my master rPI and my Atmega328p, EVERY time I program it before I can switch to avarice / avr-gdb debugging it?
[08:46:18] <kristoiv> I get "set paramater command failed: DEBUGWIRE SYNC FAILED
[08:46:18] <kristoiv> Failed to activate debugWIRE debugging protocol
[08:46:18] <kristoiv> USB bulk read error: usb_bulk_read: An error occured during read (see messages above)
[08:46:18] <kristoiv> USB daemon died"
[08:47:40] <kristoiv> After the power is hooked up again it works perfectly. But this really slows down my debugging. Advice on how to fix that is much appreciated :)
[09:22:07] <rue_house> must be under widnows
[09:27:37] <kristoiv> rue_house, nope. OS X + avr-gdb
[09:28:18] <kristoiv> So it's not business as usual?
[09:29:34] <rue_house> osx
[09:30:02] <rue_house> I dont think these things were devleoped for anyting more than windows
[09:30:17] <rue_house> so, I'd say you want to find a bug mailing list somewehre
[09:30:46] <rue_house> unless you can find anyone else trying to use a debugger under osx
[09:31:32] <rue_house> I run linux, but I dont use debuggers like that, I progressivly write my code and test as I go
[09:44:13] <kristoiv> rue_house, well my code is awesome ^^,; it's when I enable optimization in the compiler stuff stops working.
[09:44:59] <rue_house> did you go above o3?
[09:45:48] <kristoiv> rue_house, nope. It stops working for any level except the one which is was developed under (no optimization -O0)
[09:46:03] <kristoiv> rue_house, currently trying to debug it under -O1
[09:46:33] <kristoiv> n
[09:49:03] <rue_house> o1 dosn't break anything that wasn't already broken
[09:49:27] <rue_house> your prolly overflowing bufferes and it works without optimization because it runs into the freespace after the buffer
[09:51:05] <kristoiv> rue_house, interesting. Thanks! It's weird though, currently seems like the CRC calculated by an external device is the problem, so probably around the communication something fails
[09:55:07] <rue_house> what means of communication is it?
[09:55:23] <rue_house> avian carrier?
[09:55:30] <rue_house> (known to be lossy)
[09:56:48] <rue_house> RFC2549?
[09:57:13] <rue_house> / rfc 1149
[09:57:32] <kristoiv> Hahaha
[09:57:38] <kristoiv> rue_house, I found the bug
[09:58:16] <rue_house> k...
[09:58:33] <kristoiv> My code was throwing an unhandled error on write (it actually never wrote), due to a missing null-pointer check in my SPI-write
[09:58:56] <kristoiv> But thanks, your input helped a lot. I just finally GDB-steped into the problem
[09:59:42] <kristoiv> Though I found a new bug... Lots of things show themselves when optimising code
[10:00:15] <rue_house> yup
[10:00:22] <rue_house> you have to write each part and test on its own
[10:00:50] <rue_house> then test each two parts you join togethor
[10:01:40] <kristoiv> rue_house, well I thought I had. Didn't know that optimizing code changed features like this.
[10:04:15] <kristoiv> Ahh, it works :D
[10:33:16] <ravon> Is anyone here doing OOP for their devices?
[10:33:56] <LeoNerd> Mm?
[10:35:37] <ravon> Figuring out what question to ask. Bumping into a design issue whether I should encapsulate power control inside my device objects (GPS, modem etc) or if I should put that logic inside one single board controller.
[10:37:00] <ravon> The former makes it so all functionality is located (or at least wrapped) in one logical object, but it requires a lot of boiler plate code just to get one GPS to work with different boards where you might have a GPS power pin at different locations on different boards.
[10:38:38] <twnqx> i would never use OOP
[10:38:51] <twnqx> on no platform whatsoever, in no language whatsoever :P
[10:39:37] <ravon> Sometimes I wonder if it's worth the effort :)
[10:40:00] <twnqx> from my mindset - no
[10:40:08] <twnqx> objectively, "sometimes"
[10:41:10] <ravon> It does have its advantages, but my god have I spent time at questions similar to the above. I guess it says more about me as a designer than OOP as a theory though.
[10:41:40] <twnqx> i simply don't see any point in OOP
[10:41:54] <twnqx> code reuse - you have that with libraries unless you are incompetent
[10:42:17] <twnqx> permissions for variables - god, you only have yourself to blame if you do bad things
[10:43:25] <twnqx> abstraction - sure, adding layers of layers on top of layers ight not be so problematic if you have ghz at your hand, but with a few MIPS you might run into limit just from your overhead
[10:44:02] <twnqx> (i still am pissed that my 1mhz c64 is instant-on, while my several 1000 times faster PC takes several thousand times longer until i can use it)
[10:44:36] <ravon> I like how Python didn't implement support for public/private sections. "We're all conenting adults here"
[10:44:50] <twnqx> and then there's the whole boilerplate typing thing that seems to blow up code volume for no good reason
[10:45:02] <twnqx> well, i hate python as well
[10:45:06] <ravon> :D
[10:45:13] <twnqx> but that's because it's unwriteable with my development way
[10:45:37] <twnqx> unless i learn to indent/outdent complete blocks with my editor
[10:46:27] <twnqx> adding an if and two braces and tell the editor reindent automatically is just not possible...
[10:48:47] <ravon> I guess my indecisiveness would be somewhat similar if I went pure C though. Power control through a GPS module (via a function pointer?) or through a board controller?
[10:51:26] <ravon> Leaning towards keeping everything inside the GPS/modem modules even though the boiler plate is a pain and it's a bit hard to follow at first. It makes it more intuitive to turn devices on and off on the fly.
[10:58:37] <twnqx> that decision would be so strongly coupled to what's available on the final device
[10:58:46] <twnqx> that there is no generic "this way" method
[10:59:37] <LeoNerd> I generally don't see a need for OO in a program the size of a typical AVR
[11:00:00] <LeoNerd> OO might make sense if hundreds of developers are building systems to run on thousands of machines with terabytes of RAM between them
[11:00:47] <LeoNerd> But on my ATtiny with 2Ki of RAM and cycle-perfect timing to drive an LED chain - no. OO is just going to waste bytes and cycles
[11:21:26] <ravon> LeoNerd: Actually, I'm on AVR32 with plans on ARM in the future so resources are less of an issue. Except for RAM.
[11:24:38] <ravon> On an ATtiny I'd probably still go OO but I'd use static polymorphism instead of virtual calls, I think.
[11:57:44] <PureSine> I have a product that its older model uses ATMega128 and it is only C . newer model uses ARM and it is a mixture of C and C++. in my opinion for real time embedded programs with C, if a product is not going to be expanded considerably in the future and no architectural changes are going to happen and the code is under 128K probably C is the best choice, but if the product will be under active development(not just bug fixing) and the code is bigger th
[13:44:47] <msev-> just installed avr studio 7, how do i now make a hex file of this ->
https://github.com/hagleitn/nun-radio
[13:48:35] <RikusW> build it
[13:55:50] <msev-> how RikusW :D
[13:55:54] <msev-> where is the button to press
[13:56:14] <RikusW> I haven't used studio 7
[13:56:32] <RikusW> but basically open the project and select build from the menu
[13:57:06] <msev-> thats the problem I can't find it
[13:59:52] <msev-> im watching a tutorila
[14:01:29] <msev-> i have the build button grayed out
[14:03:29] <RikusW> did you open the project ?
[14:04:44] <msev-> https://github.com/hagleitn/nun-radio
[14:04:50] <msev-> i'm trying to compile this
[14:04:58] <msev-> I dragged all the files inside atmel studio
[14:05:07] <msev-> can you tell me whats the right way to do it
[14:05:12] <msev-> please
[14:05:32] <RikusW> open the project file first then build
[14:06:33] <msev-> whats the project file
[14:07:54] <msev-> in the case of this nun-radio repo
[14:10:30] <RikusW> use studio to open the project, it should show you the file appropriate file extension
[14:10:37] <RikusW> - file
[14:11:05] <msev-> if i click open project it doesnt show me anything
[14:12:10] <RikusW> then you'll need to create one
[14:12:37] <RikusW> or possible import a previous format or use the makefile
[14:21:20] <msev-> makefile is for arduino-mk so probably not useful?
[14:21:54] <msev-> based on files what do i need to choose
[14:22:24] <msev-> C executable project, c static library project, c++ executable project, c++ static library project
[14:23:01] <msev-> or create project from arduino sketch
[14:55:15] <hetii> Hi
[14:55:43] <hetii> I don`t get it, in this article they wrote that Q5 and Q11 which must have almost identical H21e.
http://www.pavouk.org/hw/dynalo/en_index.html but if it means hfe then even in datasheet one of them have range from 40-170 and second over 300
[15:25:26] <ravon> PureSine: You can keep the footprint low with C++ as well
[15:26:46] <ravon> PureSine: You have to steer away from exceptions, RTTI and virtual function calls but other than that you should be good
[15:27:18] <ravon> PureSine: Interrupt routines into C++ objects will be an issue unless you write your own interrupt springboard.
[15:49:51] <PureSine> ravon: sure you can, you can also write 256K code with assembly. I think some of it backs to the personality of the developer. for example I never liked C# personally for desktop development(maybe because I don't like using proprietary libraries) , though I know I will have better productivity using managed development but still use native code even for big projects with a lot of GUI.
[15:51:24] <ali1234> C++ without virtual is kinda pointless isn't it?
[15:51:38] <ali1234> i mean you might as well just use C
[15:51:39] <inkjetunito> templates \o/
[15:51:46] <inkjetunito> enums
[15:51:50] <inkjetunito> & shit
[15:52:23] <ravon> PureSine: You still have the benefit of coupling functionality with data
[15:53:15] <ravon> Not sure what the fuzz is about templates and references either. Neither of them add overhead per se.
[15:53:53] <ravon> Templates add space overhead but increases optimization possibilities. It's the standard RAM vs speed tradeoff.
[15:54:19] <ali1234> do you really need templates in a microcontroller?
[15:55:38] <ravon> Not sure what you mean. Should you write two functions for swapping int<->int and float<->float or should you write one template?
[15:55:50] <ali1234> i mean pretty much the whole point of OO is code reuse and getting rid of boiler plate... C++ doesn't even do a great job at that
[15:56:15] <ali1234> but when you can only fit a couple kb of code in the device, do you really even need to use tools to reduce code footprint?
[15:56:28] <ali1234> because OO only reduces the source code size, not the binary
[15:56:32] <ravon> Why do you assume that templates and classes add overhead?
[15:56:41] <ali1234> they don't add overhead
[15:56:52] <ali1234> they don't reduce it either
[15:57:01] <ali1234> all they do is reduce the amount of duplicated source code
[15:57:02] <ravon> Sweet :)
[15:57:31] <ali1234> they don't reduce the amount of duplicated binary code, and given the resource limitations, the source code size cannot grow to be unmanageable
[15:57:56] <Strangework> That sounds like a good enough justification for me. Sounds like it ultimately comes down to taste.
[15:58:10] <ravon> So it reduces the source code and don't add to the binary, yet it's a bad thing?
[15:58:22] <ali1234> yes, because it brings other problems... it's a trade off
[15:58:38] <Strangework> By brings other problems, you mean irresponsible use of the more costly features?
[15:58:54] <ali1234> yes, along with just generally making the code harder to understand
[15:59:00] <ali1234> te source code i mean
[15:59:24] <ali1234> and you can't really blame people for using the wrong bits
[15:59:25] <inkjetunito> heh. macros aren't any easier to read either
[15:59:43] <ali1234> it's not easy to tell how expensive any given thing is in an OO language like C++
[15:59:56] <ravon> That I agree with.
[15:59:57] <ali1234> you just have to know
[16:00:10] <PureSine> if the code is really big >128K , i think OO helps to understand the code but for small code yes it is like to have a lot of sheets and put each sheet in a separate file.
[16:00:31] <ali1234> assuming you mean 128k lines of source code then yeah :)
[16:00:52] <PureSine> 128K binary ;)
[16:01:08] <ali1234> i'm exaggerating of course... i agree
[16:02:12] <ravon> Still, placing things inside a class for the purpose of having the same logic function block under the same umbrella does not increase binary size OR code complexity.
[16:02:43] <ravon> But yes, using STL and virtual function calls will cause an explosion, I agree.
[16:02:43] <ali1234> it kind of does increase source complexity if you just have totally flat classes
[16:03:08] <ali1234> vs .c and .h with static functions instead of private class members
[16:03:10] <ravon> You think?
[16:03:25] <ali1234> yeah... it makes every function declaration twice as long for one thing
[16:03:48] <ravon> Now we're just walking in habit territory :)
[16:04:05] <ali1234> because instead of "void foo(int ...)" it's now "void MyClass::foo(int ...)"
[16:04:29] <ravon> nah, instead of led_on, you have LED::On
[16:04:41] <ali1234> in an ideal world :)
[16:05:04] <ali1234> unfortunately OO code rarely seems to turn out clean like that
[16:05:19] <ali1234> you end up with stuff like MyLEDFactory::make_LED()
[16:05:37] <ali1234> don't get me wrong that stuff has it's place
[16:05:46] <ali1234> but i just don't see it when you have 1kb of flash...
[16:05:56] <ravon> With no overhead ;)
[16:07:11] <ravon> No matter how you twist and turn it, plain classes offer data encapsulation with no binary or runtime overhead. If you want to be clever you can use templates and get compile time polymorphism as well. With no overhead.
[16:07:46] <ali1234> those recent C++ standards really help a lot with cutting out the stupid helper classes too
[16:07:54] <ali1234> if you have them that is
[16:08:13] <ali1234> on the other hand, i've no idea how efficient that stuff is
[16:08:59] <ravon> The features in C++11 an 14 are a nightmare TBH as they use lambdas which secretly allocate memory through new. And yea, your're right, you just have to know. That sucks donkey porn.
[16:09:35] <ali1234> i was specifically thinking about constructor delegation i think it's called?
[16:09:51] <ali1234> constructor can now call another constructor of the same class
[16:10:09] <ali1234> i love that feature when writing big bloated desktop apps :)
[16:11:47] <ravon> Yea, that's pretty neat, though rarely used :) At least not in my cases
[16:50:40] <xrlk> hey how do i intuitive ly learn to understand circuits after differential equations, linear algebra, and E&M
[16:50:44] <xrlk> what can I study
[17:14:26] <Jartza> https://drive.google.com/file/d/0B2dTzW9TMeBxZk1RSmZWdlVvajQ/view
[20:48:51] <osteri> ravon: what features are nightmare?
[20:49:31] <Casper> https://www.flickr.com/photos/93694432@N04/22434273270/in/album-72157660503093616/ <=== that might be nightmare
[20:50:14] <osteri> Casper: nice, is it halloween? we don't even celabrate such things :P
[20:50:29] <Casper> https://www.flickr.com/photos/93694432@N04/albums/72157660503093616 full album
[20:50:36] <Casper> those guys are crazy
[20:50:50] <Casper> one of them said he put 50 hours and 3 weeks to install all
[20:51:36] <osteri> crazy
[23:39:17] <pewpau> is avr ,mips?