Back
[00:08:13] <carabia> hey, i watched that carmack oculus demo where he was pushing a little framework to implement little vr programs in lisp
[00:08:46] <carabia> well, racket. not basic lisp.
[02:42:39] <proteusguy> Just curious - under linux, what avr C/C++ compiler environments do people prefer? Still using gcc or are there better/interesting options out there now?
[02:46:01] * inflex still uses avr-gcc + gvim
[02:52:16] <Casper> gcc do the job right
[03:21:50] <Jartza> I bet this Makefile-competition will not be very popular because nobody provides any information for it :)
[03:24:37] <Casper> yeah, it's one of rue's bad idea
[04:23:17] <carabia> I think he meant an IDE. Probably 99% of code c compiled for avrs is done with avr-gcc
[04:23:45] <carabia> don't even know any sane alternatives...? IAR but that's some hella $$
[04:24:05] <carabia> didn't mean to type "code" there
[04:25:15] <carabia> or actually now that i re-read it it doesn't make any sense. proteusguy there really is no such thing as "compiler environment"
[04:26:51] <proteusguy> carabia, actually a compiler + dependency options is properly considered an environment.
[04:27:01] <proteusguy> And I do not mean ide.
[04:28:26] <carabia> alright. i learned something then. so, dependency as in compiler assembler linker?
[04:29:04] <carabia> is there an inherent limitation in avr-gcc or why the question?
[04:30:03] <carabia> i guess IAR's proprietary compiler does a pretty neat job but not really worth it for avrs...?
[04:32:46] <proteusguy> I'm curious if llvm has caught on in the avr world or if other compilers are popular. In the x86 space llvm is gaining marketshare on gcc, especially in modern C++ support. So just trying to get a sense of whether or not llvm or anything else is gaining more traction in the avr community.
[04:35:10] <carabia> yeah, i've understood that llvm is implementing the standard at a rapid pace which is basically like piling more dogshit on a clusterfuck platform
[04:35:16] <carabia> c++, that is
[04:39:45] <proteusguy> carabia, ah you're one of those irrational C++ haters i see. understand that the ansi C committee has backported many of the improvements of C from the C++ community and that C++ is indeed a superset of the C language and can be strictly used as a better C rather than an OO language.
[04:40:18] <carabia> with bloated binaries, sure
[04:40:29] <proteusguy> but I'm not here to try to influence what people use - just to guage what people are using.
[04:40:52] <proteusguy> carabia, you think C++ produces bloated binaries or llvm?
[04:41:18] <carabia> it depends on what you use
[04:41:27] <carabia> of the "improvements", as you say
[04:42:22] <carabia> however as we're on the subject, do share the benefits of c++ over c on an avr?
[04:43:35] <proteusguy> carabia, that's right - it depends. and, in fact, C++ is not bloated compared to C for equivalent functionality. I have created embedded projects that were 33% smaller than their already optimized C equivalents (and only 25% of the source code size) by making good use of C++ parametrized types which C could only simulate by making massive unreadable macros and would not be able to deliver the type safety of the C++ version. So
[04:43:35] <proteusguy> I guess it depends more on understanding your tools than any inherent flaw in the language.
[04:45:04] <proteusguy> carabia, strong static typing of C++ and parameterized types lets you build safe very efficient code that is impervious to issues such as bit sizes of types and devices without having to create significant new source versions. Makes debugging far simpler as well.
[04:45:39] <proteusguy> Some of this strong type checking has started adoption at the ANSI C committee now but the parameterized types probably will never make it.
[04:47:37] <proteusguy> carabia, but I'm not saying everyone should switch from C to C++. C, properly used, is a platform independent assembly language and excels at such things. There are some new capabilities of C++ that can help C in this regard and some knowledgeable developers have benefited from their incorporation.
[04:47:43] <carabia> you wouldn't happen to have these projects on hand, would you?
[04:48:42] <proteusguy> carabia, none are public domain. they're owned by the clients. but what I described should be something any experienced embedded developer has experienced as a challenge for C code that must support different hardware in tight spaces.
[04:49:51] <carabia> hardware such as?
[04:50:58] <proteusguy> carabia, if you're not aware, parameterized types (templates) in C++ are compile-time resolved type safe macros that only generate code when they are explicitly instantiated in code so you can have very abstract interfaces that, when used, only generate the exact code necessary to implement what was used for the exact type bit-sizes.
[04:51:25] <proteusguy> carabia, anything from as small as a pic to as large as i386 systems and everything inbetween.
[04:51:29] <carabia> yes and i get that argument of yours, but to me it feels like we're outside the realm of stricly avrs
[04:51:37] <carabia> strictly even
[04:52:16] <proteusguy> carabia, almost all my real avr code projects that weren't pure asm have been C++. Anywhere you can use C you can use C++.
[04:54:01] <carabia> of course you can, while i understand your argument for safety, for the simplicity of things ran on avrs, i cannot see the benefits of c++'s abstractions
[04:55:17] <proteusguy> carabia, well, like I said, if you don't feel a need for it I'm not saying switch to C++. I was just responding to your blanket statement that C++ was bad and bloated which is not really an accurate or responsible thing to espouse.
[04:55:53] <carabia> so what are the code sizes in comparison with your "real avr code projects"?
[04:56:34] <carabia> i.e. we're not trying to write ultra portable code that runs on everything and the toaster
[04:57:20] <proteusguy> there's zero code size difference between the C++ and C output from the same compiler set for compatible code run through both compilers yet the C++ version is type-safe.
[04:58:24] <proteusguy> For systems that have to target multiple versions or types of hardware the C++ generated code can actually be somewhat smaller than the C code and the source code far smaller than the C code since C++ has an higher abstraction support.
[04:59:18] <carabia> that i do understand to an extent
[04:59:42] <proteusguy> There are some things that C must resolve at runtime (unless you use extremely large complex macros) that C++ can simply resolve at compile time. In those instances your C++ output will be smaller than your C output.
[05:00:24] <carabia> but the referring to what you said earlier, what do you mean by "compatible"?
[05:00:32] <carabia> -the
[05:00:44] <proteusguy> I have embedded systems written in 1991 that have been running and migrated to new hardware without any source code changes that still operate today.
[05:01:23] <proteusguy> carabia, ANSI C code, with very few exceptions, is valid C++ code except the C++ compiler will enforce and guarantee type safety if you let it.
[05:03:15] <proteusguy> carabia, I never use "built in" types in my C++ code. Everything is a typedef with a more semantically meaningful name and the typedef is built to guarantee the correct bit-size/bit-order inherently so my code doesn't have to think about such issues when it's ported to other environments. You change the declaration of the typedef dependency and recompile and it just works every time.
[05:03:35] <proteusguy> Zero run-time cost/overhead.
[05:05:40] <carabia> which is beyond the realm of "real avr code projects", as you put it
[05:06:24] <proteusguy> the bit-size/bit-order stuff yes but not the type safety aspects.
[05:06:53] <carabia> yeah, but that in turn is beyond the language's abstactions and their usefulness
[05:06:59] <carabia> abstractions, even
[05:07:08] <proteusguy> but when I move a project from a non-avr to avr my code still just works - so it's relevant for avr space as well.
[05:07:16] <carabia> well it is and it isn't
[05:07:33] <proteusguy> carabia, don't understand how you mean beyond the language's abstractions.
[05:09:01] <carabia> well, it's not really c++
[05:10:50] <proteusguy> carabia, afraid I don't follow. Using C++ as a better C is absolutely C++ and gaining value that ANSI C by itself cannot provide. No you're not using exception handling, virtual methods, etc (which have no place in embedded code typically) but a key architectural goal of C++ is that you don't pay for what you don't use.
[05:12:21] <carabia> well, you said your avr code projs are just ansi c fed to a c++ compiler
[05:12:43] <proteusguy> I'm doing an fpga project right now that may involve an AVR target or a completely custom CPU. If it's AVR then I'll try to post a link to demo what I'm talking about in the future.
[05:12:46] <carabia> that's not really taking advantage of any inherent linguistic advantages of c++
[05:14:11] <proteusguy> carabia, no I said you could just run your ANSI C code through a C++ compiler and get the advantages of type safety with zero binary cost (in response to your equivalence question). My projects actually use C++ templates quite heavily and other abstractions C doesn't provide.
[05:15:59] <carabia> and giving your best guess, how big would be the drawbacks in terms of execution speed and binary size
[05:16:15] <carabia> vs optimized c
[05:16:30] <proteusguy> equivalent or better vs. optmized C in my experience.
[05:16:46] <proteusguy> but generally indistinguishable.
[05:17:04] <proteusguy> any optimizations you do in C you can also do in C++/.
[05:17:26] <proteusguy> but there are optimizations in C++ that can't easliy be performed in C.
[05:17:31] <carabia> yes except that abstractions will always remain as abstractions
[05:18:42] <carabia> if i could do good c++ optimization i'd hold you up to that claim, but as i can't, and i'm generally lazy... i guess i'll have to leave it at that
[05:18:55] <proteusguy> carabia, only at the source code level - not resulting binaries. that's what templates provide that are so powerful. you have to consider whether these abstractions are reconciled at compile time or runtime. compile time resolved abstractions not only cost you nothing in the end but provide strong development time improvements as well.
[05:19:47] <proteusguy> carabia, fair enough. :-) i've gotta get dinner now. ttyl.
[05:19:58] <carabia> alright, have a good one
[14:41:53] <antto> what'cha guys think 'bout running some sort of script or other language on the avr?
[14:43:48] <antto> i looked a bit into some possible languages, no idea if they'll actually fit any useful amount of code.. angelscript, lua, micropython, squirrel
[14:44:05] <specing> Ada.
[14:44:21] <specing> ^ language that was designed for embedded systems
[14:44:26] <antto> hm, doesn't gcc do that already?
[14:44:30] <specing> it does
[14:44:47] <antto> right.. well i'm not familiar with ada, at all
[14:44:57] <specing> Time to get familiar then :)
[14:46:27] <antto> i was thinking from another perspective.. i got a few projects where i code the hardware-specific stuff (on xmega) and then this whole thing is used together with a server, where the server stuff, and the code for the big picture is written by some other guys
[14:46:33] <cehteh> ada isnt scripting
[14:46:47] <cehteh> needs a fat compiler
[14:46:54] <antto> they kinda use other languages
[14:46:55] <specing> "or other language"
[14:46:55] <cehteh> you may try some forth there are a few
[14:47:25] <specing> antto: Ada scales very well to large projects
[14:47:35] <cehteh> what purpose anyway? just fun? or want to remote script/configure an application?
[14:47:43] <specing> you can do the x86 side in it
[14:47:46] <specing> as well
[14:48:08] <cehteh> but ada doesnt scale on human brains :D
[14:48:12] <specing> it does
[14:48:16] <cehteh> haha
[14:48:19] <antto> not fun, more like access control systems, home automation.. etc..
[14:48:21] <specing> it was designed to be readable
[14:48:35] <cehteh> well its rarely used anymore, had some good ideas but never got through
[14:49:05] <antto> those guys aren't really into electronics that much, they are more into web stuff ;P~
[14:49:33] <cehteh> antto: i often end up for some ad hoc things, like sequencers for led blinking or so
[14:49:48] <antto> what sequencers?
[14:49:54] <cehteh> instead full programming language
[14:50:03] <cehteh> just as example
[14:52:02] <cehteh> if you want to configure some RGB blinking sequence then write a sequencer reading a string with color codes "rrbb" .. "rygcbm" ...
[14:52:21] <cehteh> thats simple and takes less memory than some full programming language
[14:52:51] <cehteh> or for auth some bulding blocks and a state machine plus the keys/config
[14:53:58] <cehteh> allows some flexibility to reconfigure the system without the oeverhead (and possibly bugs) of a full scripting solution
[14:53:59] <antto> as a more real example.. we got for example this board with a big xmega dealing with relays, rfid readers, leds, sensors, there's also another xmega and w5500 doing an ethernet pipe.. so we use this board in a few different scenarios, but the actual control and decision making is taken by "them" .. which currently happens via the ethernet, cuz their "decisions" come from a server-side program
[14:54:19] <antto> this means show's over when the ethernet gets cut off
[14:55:04] <antto> i was thinking to let them have a significant chunk of code (script) running directly on the xmega, so that they can put their decision-making logic right there
[14:56:19] <cehteh> yes, could be done, but think if you can make it simpler, maybe event/table driven
[14:56:55] <cehteh> events trigger state changes and somewhere is configured what should happen if a state becomes active/inactive
[14:57:23] <antto> yes, obviously i'll handle the boring stuff myself as much as possible (like replying to ping requests and other requests from the server, instead of letting them handle those via script)
[14:58:07] <cehteh> with some 'virtual' states and logic operations you can create a quite flexible system without all the worryness of a full scripting thing
[14:58:56] <antto> yeah, i don't need a full scripting language, obviously.. i got a bunch of functions i would want to expose so that they can do enough things
[15:01:36] <antto> we currently have a communication protocol (which runs via the ethernet) between this device and the server app, if they have a script running on the device - they can be left to freely design the new messages to the protocol
[15:01:37] <cehteh> i am thinking that i'll may evenually make a generic engine for such things
[15:02:39] <antto> cuz right now it's mostly me adding the new messages, then i inform them, and they implement them in their app.. they're not always happy ;P~
[15:03:12] <antto> and i hate making different variations of the same thing just because it's used in a slightly different context
[15:03:17] <cehteh> think about a bit table, on one axis you have events (ethernet connected, ethernet disconnected) on the other axis you have events (LED on, LED off, Beeper on, beeper off, flush toilet, ...)
[15:03:38] <cehteh> evaluating that would be straightforward and simple
[15:03:49] <antto> yeah, i can sort of brew something myself
[15:04:21] <antto> but then what's more important is how it'll look like on their side, because _they_ will have to be "coding" it
[15:05:06] <cehteh> plenty of options
[15:05:59] <antto> i'll need to expose functions for constructing and sending messages to the server, as well as events for when the server sends a message, and functions for parsing it.. then also they need to have a few timers so that they can count time, and some variables that they can use to count some stuff
[15:06:57] <antto> events for when the rfid reader reads a card, events for the sensors, functions for controlling the relays
[15:07:49] <antto> i could easily design something like that using something like byte-code i guess.. but then how will they write that?
[15:07:53] <antto> not gonna be fun
[15:08:05] <cehteh> yes
[15:08:35] <cehteh> i like it data driven, having some limited interpreter which can only do as much as required
[15:08:44] <antto> yes
[15:08:57] <cehteh> that has the big advantage that things are much easier to cope for humans and there is less chance of bugs
[15:09:02] <antto> i can only dedicate so much RAM for the "script"
[15:09:26] <cehteh> thats a point too
[15:09:28] <antto> another big concern is how to actually load this
[15:09:48] <cehteh> with my bit-table approach you can save a lot ram
[15:10:14] <antto> the final version can be hardcoded into the flash together with the firmware, but that's not fun during developement
[15:10:34] <cehteh> i'd even leave it dynamic when it works
[15:11:08] <cehteh> then you can store the configuration in eeprom, and make things easier upgrade/fixable if its only some error/fix in the state machine
[15:11:16] <cehteh> no reflashing required then
[15:11:49] <antto> when i said "developement" i really meant the process of them writing their script
[15:12:32] <antto> cuz firmware wise, there shouldn't be much to do, most of the basic functionality is already there
[15:12:52] <antto> and those guys don't have an icsp programmer ;P~
[15:13:50] <antto> i know a bootloader can write to the flash, obviously.. but can the firmware write to the flash?
[15:14:19] <antto> i'm thinking it would be most convenient to have bootloader-like functionality in the actual firmware
[15:14:22] <cehteh> depends on fuses and what AVR you use
[15:14:27] <antto> xmega
[15:14:40] <cehteh> just trigger a reboot
[15:14:45] <cehteh> then bootloader takes over
[15:14:50] <antto> :/
[15:15:10] <cehteh> you can send some data to the bootloader
[15:15:32] <cehteh> sram is not cleared on reboot, the clib initilaization does that
[15:15:35] <antto> this'll be tricky
[15:15:46] <cehteh> needs a custom bootloader
[15:15:54] <antto> certainly
[15:15:54] <cehteh> but should work fine
[15:16:09] <antto> but i would prefer if i could do this from the actual firmware
[15:16:29] <Lambda_Aurigae> antto, there are versions of BASIC that could easily be ported to avr
[15:16:30] <cehteh> that would lead to some insecure fuses, if possible
[15:16:30] <Lambda_Aurigae> and have
[15:16:49] <Lambda_Aurigae> I've played with a few
[15:16:56] <cehteh> pita
[15:16:57] <Lambda_Aurigae> and with a C interpreter as well.
[15:16:59] <antto> insecure is not a problem during the "script developement" process
[15:17:16] <antto> convenience is important then
[15:17:18] <cehteh> why dont you just go over the bootloader?
[15:17:28] <cehteh> looks simple to me
[15:17:54] <antto> the bootloader will have to know where in the flash to put the "script" data
[15:18:23] <antto> i've not actually coded a bootloader for the xmega yet
[15:18:44] <antto> i've only modified (slightly) an stk500v2-based bootloader for atmega
[15:20:25] <Lambda_Aurigae> as for ram for the script....add an external serial sram chip..
[15:20:30] <antto> i can simply add messages to the communication protocol for "begin receive script, script data, end" so that they can reprogram the script via the eithernet connection
[15:21:11] <antto> hmz, that would raise the price i think
[15:21:12] <cehteh> if it is a script, why dont you put it in eeprom
[15:21:21] <Lambda_Aurigae> my pic32 C interpreter does just that....loading the C program to be interpreted in an external serial sram chip.
[15:21:38] <cehteh> or even ram
[15:22:04] <antto> Lambda_Aurigae wait a minute, don't forget that i will back them up by doing as much of the hard and boring work from my side
[15:22:13] <cehteh> like my statemachine/table approach .. you keep the table in ram (its small) and may have commands to save them to eeprom
[15:22:20] <cehteh> on boot its loaded to ram
[15:22:46] <Lambda_Aurigae> looks like about 2 USD for a 1Mbit serial sram.
[15:23:01] <Lambda_Aurigae> anyhow, just a thought.
[15:23:09] <cehteh> then you can have command to modify this table on the fly, either by uplaoding a complete new table or with some scripting language alike constructs which get parsed
[15:23:38] <antto> yeah, i thought about using external memory (eeprom or so) if we run out of space for the "script"
[15:24:14] <cehteh> how many events/states/actions do you have?
[15:26:17] <antto> rfid reader has some events and functions for setting it up, relays only have functions, sensors are boolean, so they got just events, power supply sensors (adc) actually generate just 3 events (too low, too high, normal)
[15:26:43] <antto> i'd also expose some UARTs so they can have fun, thus event there and a few functions
[15:27:28] <cehteh> i'd go my table like approach needs events*actions bits .. i bet thats not much
[15:27:30] <antto> event for the communication protocol (packet received) as well as functions for parsing from the packet, and for constructing packets and sending..
[15:28:14] <antto> some 10ms and 1s timer events will be useful
[15:29:04] <antto> it might be also good to expose some pins, so they can set() or get()
[15:29:17] <cehteh> i should find some time to finish my mµOS .. you'll prolly like it :D
[15:29:36] <cehteh> anyway .. bbl office work, taxes grr