#avr Logs
Apr 17 2017
#avr Calendar
12:41 AM rue_house: what you filtering?
12:52 AM xentrac: Boldo, at the moment
12:54 AM xentrac: one of the few plants from which you can distill explosives
12:56 AM rue_house: xentrac, should I be worried?
12:56 AM xentrac: no, I'm almost certainly not drinking enough of it to poison me
12:57 AM xentrac: certainly that isn't the idea
12:57 AM xentrac: the explosive and toxic ascaridole mostly gives this tea a strong flavor
01:02 AM xentrac: the tea is tastier if you filter the leaves out of the liquid, you see
01:05 AM xentrac: for better or worse, a FIR filter does not help with that no matter how you window it
05:01 AM Emil: that's why you have to iir filter it
06:24 AM Lambda_Aurigae: you can make explosives from almost any plant...turn it into charcoal, grind it up, mix with a couple of other things and it go boom.
06:25 AM Emil: everything can be an explosive if you have enough initial energy :3
06:25 AM Emil: except Iron
06:25 AM Emil: well, that one too when you have anti iron
06:48 AM Lambda_Aurigae: oh, I dunno. finely powdered
06:48 AM Lambda_Aurigae: iron can be made to rust quite energetically.
07:06 AM Emil: oh yeah if you mix it with things
07:06 AM Emil: surw
07:32 AM antto: crap, i miss encapsulation in C so much
07:32 AM antto: i made a mess again
07:47 AM polprog: im giving carbon making a try
07:47 AM antto: can i mix C++ and C in the same project?
07:47 AM polprog: looks like a cool hobby
07:47 AM polprog: antto: that may be tricky i think
07:47 AM antto: like.. have certain chunk of the code written in a .cpp file
07:47 AM Tom_itx: polprog go one step further and make diamonds
07:48 AM polprog: Tom_itx: my oven can't handle the pressure ;)
07:49 AM polprog: antto: cant you write everything in C++
07:49 AM polprog: i believe you should compile everything to object files and then link
07:50 AM antto: polprog i could, but this project is initially written entirely in C, and is currently about almost 100KB worth of firmware binary
07:50 AM polprog: but i havent done anything that low-level, so dont take that for granted
07:50 AM antto: neither have i, i use an IDE to build it
07:51 AM antto: don't laugh, Lambda_Aurigae
07:51 AM polprog: dont laugh at us, i learned java as my first real language
07:51 AM antto: mine was mIRC script
07:51 AM Tom_itx: oh god i feel sorry for you
07:52 AM inflex: hello Tom_itx
07:52 AM Tom_itx: hi
07:52 AM antto: if that can even be considered a language
07:53 AM Tom_itx: my first real language was english
07:53 AM polprog: well i consider logo a language. might be cool to make hardware turtle with avrs
07:54 AM specing: < polprog> dont laugh at us, i learned java as my first real language
07:54 AM specing: polprog: watch Javatar the movie
07:54 AM specing: < antto> mine was mIRC script
07:54 AM specing: I was lucky enough to have switched to *NIX before learning programming
07:54 AM polprog: me too
07:55 AM specing: how did you land on Java then?
07:55 AM polprog: openjdk
07:55 AM polprog: :)
07:55 AM specing: yeah, but how?
07:55 AM specing: what was the motivation?
07:55 AM specing: Everything on *NIX is either in C or C++
07:56 AM polprog: i bought a book about java, and i started to go by it
07:56 AM specing: why did you buy a book about java?
07:56 AM polprog: i dont rember honestly
07:56 AM polprog: really, i was 12
07:56 AM polprog: :D
07:56 AM specing: remember it fast because I'm going to come over and waterboard you
07:57 AM polprog: waterboard?
07:59 AM antto: polprog u better run
07:59 AM specing: have you been living under a rock?
08:00 AM polprog: i just checked the meaning
08:00 AM * polprog runs away
08:01 AM * antto makes himself a shield against specing, written in mIRC script
08:03 AM polprog: i cant find time to make the morpheus vs neo mattrix fight scene pic
08:03 AM antto: stop trying to hit me and hit me!
08:05 AM polprog: specing used splash. its not very effective
08:07 AM * specing uses splash continously for hours, it is very effective
08:09 AM polprog: i could go java enterprise and run a hobby enterprise app, yet i found the homepage of the guy who made the first musical floppies
08:10 AM polprog: and it inspired me to go avr
08:11 AM polprog: storyofmylife
08:17 AM antto: i am wondering how to have two variants of a FIFO, one which is done with uint16_t size (so it can be fairly big) and another one with uint8_t that would be smaller but supposedly faster..
08:18 AM antto: in C++ this would be done using a base class, i guess
08:19 AM specing: in C? With macros and double include
08:19 AM antto: hm
08:19 AM specing: #define element_type uint8_t
08:19 AM specing: #include "fifo.h"
08:19 AM specing: #define element_type uint16_t
08:19 AM specing: #include "fifo.h"
08:20 AM specing: and prefixing functions with element_type
08:20 AM antto: but i am using instances of this
08:20 AM specing: fifo_uint8_t_insert()
08:20 AM antto: i need the bigger FIFO for one of the USARTs, the smaller one for the other one
08:21 AM antto: and it's actually.. my "object" really represents a whole buffered interrupt driven USART
08:21 AM specing: and in C++ this would be done with templates
08:21 AM specing: not base classes
08:22 AM antto: so it really includes a FIFO with the interrupts, and USART reading/writing
08:22 AM specing: but why not emulate a 16-bit fifo by inserting two elements at the same time?
08:22 AM antto: uh?
08:22 AM specing: if it is a usart then it operates on bytes already (ok, few use 9-bit mode)
08:24 AM specing: this way the usart tx interrupt can be the same for both
08:24 AM antto: i gotta learn templates..
08:24 AM specing: yup
08:24 AM specing: you know Java is complete and utter shit when you learn something like C++
08:24 AM antto: i don't speak Java at all
08:24 AM specing: polprog: ^ then
08:24 AM antto: i read about templates and how they can be used like uber-clever macros
08:25 AM antto: but, similarly to macros, they look ugly to code
08:25 AM antto: ehm, confusing, not ugly
08:26 AM specing: they aren't ugly
08:27 AM antto: for something like this it seems worth it, you write a confusing template once, and then you can just reuse it with any combination of different specs
08:27 AM specing: C macros are ugly
08:27 AM antto: and afaiu, there's no "penalty" other than increased compile time
08:28 AM specing: indeed
08:28 AM antto: while currently i got basically two chunks of almost indentical code, and i hate it
08:30 AM antto: i'm worried if i'll have trouble if some chunks of my code are written in C++ tho
08:30 AM specing: just go with C++
08:30 AM specing: or better yet, Ada :D
08:30 AM antto: i wish the whole code was written in C++ from the beginning, but it isn't
08:31 AM specing: C++ is mostly backwards compatible
08:31 AM specing: with C
08:31 AM specing: Its the reason why its so terrible :D
08:32 AM antto: well, that must have its positive sides too
08:32 AM antto: afaik C is not too far from assembler
08:32 AM antto: in some way
08:32 AM specing: it does. Migrating from C to C++ is easy
08:33 AM antto: i'm somewhere in the middle between C++ and C
08:33 AM antto: but now the newer stuff (new for me) in C++11 and onwards i think is really usable by my criteria
08:35 AM specing: yes, for loop iteration was greatly improved
08:35 AM antto: uh.. i didn't mean that
08:36 AM specing: there was something else that made my life much easier as well
08:36 AM specing: can't remember now
08:38 AM antto: i learned C++ to be able to play with realtime DSP and other such things, and the stuff i was reading about C++ was talking about inheritance and all kinds of crazy things, which afaik are not very good ideas for certain purposes, so i kinda stopped at encapsulation, and didn't use any of the stl or even most of the std stuff
08:39 AM antto: i guess at one point i was overthinking about "optimizing as early as possible" while writing code
08:40 AM antto: but when i recently read about C++11, and templates, i really think that's a much better route
08:41 AM antto: you write your stuff like an algorithm, then you can sort of instantiate that algorithm with adjustable aspects, and yet the result would be as if you really went and hand-wrote each instance precisely
08:42 AM specing: Aaah now I remember
08:42 AM specing: static ifs
08:43 AM specing: though I'm not sure if that is supported
08:43 AM antto: ..and then you still got the compiler being able to optimize that thing
08:43 AM antto: static ifs?
08:44 AM antto: i really liked that you can make your own numeric suffixes thing..
08:44 AM antto: you could say x = 0.1uF;
08:44 AM antto: how kewl is that
08:47 AM antto: the recent-ish avgcc can do those fancy things, right?
08:48 AM antto: like template voodoo magic and such
08:49 AM specing: antto: Ada has supported that for decades
08:50 AM specing: numeric suffixes
08:50 AM antto: sure but.. i don't speak Ada
08:50 AM specing: you should
08:50 AM antto: i know
08:50 AM specing: it was also pretty much the first object oriented langage
08:51 AM specing: though object handling is a bit odd there since there were no reference languages to compare to
08:59 AM Lambda_Aurigae: I learned C++ in about 93 to write a program to manage commercials for a local tv station. cost per 30 seconds depending on time of day and show it is being played during...used nielson ratings database and the database interface had a C++ class library.
08:59 AM Emil: what the heck do you win with your own suffixes?
09:00 AM Lambda_Aurigae: Emil, ease of reading code
09:01 AM Lambda_Aurigae: and that's about it.
09:01 AM Emil: eeeeh
09:01 AM Thrashbarg: Lambda_Aurigae: neat. Any reason for doing it in C++?
09:01 AM Lambda_Aurigae: Thrashbarg, none that I know of.
09:01 AM Thrashbarg: hehe
09:01 AM Lambda_Aurigae: oh, you mean the nielson ratings database thing?
09:02 AM Emil: I mean, units are kewl and using them for compile time checks would be absolutely kawaii
09:02 AM Lambda_Aurigae: it was new and special and they dropped the old C library and sent out a C++ lib instead.
09:02 AM Emil: but other than that
09:02 AM Emil: you win nothing :D
09:02 AM Thrashbarg: Lambda_Aurigae: ahh right
09:47 AM * antto is trying to do templates..
09:47 AM antto: who am i kidding x_x
09:50 AM specing: :D
09:54 AM Lambda_Aurigae: templates in da cabinet need ta go on tatable.
09:55 AM Lambda_Aurigae: I'm sure there's a database metafer in there somewheres.
10:16 AM antto: i wonder if there's some way to make the compiler to somehow "tell you" how your template voodoo will look like at the end after being instantiated
10:16 AM antto: and i don't mean ASM
10:17 AM antto: ..so you can monitor if you're doing what you think you are
10:37 AM twnqx: yes.
10:37 AM twnqx: as in, yes there is
10:37 AM twnqx: gcc -E will do that
10:52 AM antto: "ld returned 1"
10:56 AM antto: hm, does that change the .o files to a text format?!
11:04 AM Lambda_Aurigae: generally a return of 1 is an error, isn't it?
11:04 AM antto: yiz
11:05 AM Lambda_Aurigae: you use avr-objcopy to make the .hex file.
11:05 AM twnqx: gcc -E should just output preprocessed source code to stdout
11:05 AM antto: oh
11:06 AM antto: i use an IDE actually
11:06 AM antto: i do see some output from the compiler but i'm not sure to what degree it is interpreted
11:07 AM antto: ld actually complains that it cannot recognize the file format
11:07 AM twnqx: "surprise" :D
11:08 AM antto: i opened the .o files in \release\ and they appear to be binary (begin with ELF and contain non-text)
11:08 AM antto: then i opened the files in \debug\ (built with -E) and they were plain text
11:08 AM antto: i can see chunks of the source code there
11:09 AM antto: i can even see my "template" structure, but it seems it's just as-is defined
11:09 AM antto: ..i mean i do not see it "in its final form"
11:10 AM bss36504: antto: http://stackoverflow.com/questions/4448094/can-we-see-the-template-instantiated-code-by-c-compiler
11:10 AM bss36504: tl;dr no
11:10 AM antto: i see typename ValueType even tho i've instantiated it with uint8_t for example
11:11 AM antto: crap
11:12 AM antto: so then cout << sizeof() is my friend
11:13 AM antto: i'm playing with this with normal gcc in a console app, not avrgcc yet
11:13 AM bss36504: why do you need the sizeof uint8_t?
11:13 AM bss36504: surprise, it's 1
11:13 AM antto: i'm actually getting the size of my buffer's first element, which is ValueType ;P~
11:14 AM bss36504: oh gotcha
11:14 AM antto: ..just to see if i'm not doing things terribly wrong
11:14 AM antto: tewibwy wong!
11:14 AM bss36504: I guess a better question to ask is why you care about what code the compiler spews for a template instantiation.
11:14 AM bss36504: That's sort of the point...you don't need to know
11:15 AM antto: what if it's wrong?
11:15 AM Lambda_Aurigae: unless you are trying to optimize things by hand maybe.
11:15 AM antto: not the compiler, the code
11:15 AM Lambda_Aurigae: if it's wrong then it won't work.
11:15 AM antto: exactly
11:15 AM antto: it won't work
11:16 AM bss36504: Well I'd argue that if you're trying to hand optimize template instantiations, you're doing it wrong. Just do it by hand with function overloads.
11:16 AM Lambda_Aurigae: antto, so, what you are doing is not working?
11:16 AM antto: nonono
11:17 AM Lambda_Aurigae: just checking.
11:17 AM twnqx: templates are not expanded at source level, just #define/#include meta programming
11:17 AM antto: it's complicated.. i recently rewrote my USART-related stuff to use non-blocking, interrupt-driven, FIFOs (and it's in C)
11:18 AM antto: but now i'm also rewriting my MIDI code, which uses that stuff
11:18 AM antto: but i got stuck in my own trap
11:18 AM twnqx: i want to rewrite some major piece like that too
11:18 AM twnqx: but i'll have to do it all at once to switch to event based programming
11:19 AM antto: so i have two sepparate data structures and sets of functions for them, which resemble my current FIFOs for the two USARTs
11:20 AM antto: and i'm unable to (re)write the MIDI code in an acceptable way
11:21 AM antto: now, my buffered FIFO thing doesn't actually include the USART init code, thus it's very very simple in the sense that there are only a few references to actual USART registers (UDR)
11:22 AM antto: so i am thinking to make this whole thing into a template struct with methods and template parameters for specifying the FIFO sizes, and the USART-related register(s)
11:23 AM antto: but i'm a template n00b, so i will probably do something wrong, and it won't work
11:23 AM antto: that's why i'm first trying these templates in a computer where its easier to figure out what's going on
11:25 AM antto: i'd inspect the ASM code if i could, but i can't read ASM
11:27 AM antto: i've seen ASM code with the original C code as comments beside it, there i have a better chance, but i'm not sure if i can get that out of gcc
11:30 AM bss36504: antto: Template programming doesn't need to be complicated per se. In your use case it seems pretty basic. I'd also say though that your FIFO shouldn't know anything about the USART. It should be the other way around. The FIFO is a data structure (reusable) and the USART is hardware (limited use) a
11:31 AM bss36504: If you make the FIFO class depend on the usart, you'd never be able to use it for something else like SPI or I2C without a rewrite, which defeats the purpose of OOP
11:31 AM antto: uhm
11:32 AM antto: but.. there are very specific things that need to happen for interrupt-driven transmit
11:32 AM bss36504: Yeah, but there are probably better paradigms than making the FIFO class depend on a piece of hardware
11:33 AM antto: then i definately can't think of any
11:33 AM bss36504: Also, in what case does a FIFO need to be "in charge" of giving the next piece of data? It's merely a data structure. The user should request data from it
11:33 AM bss36504: the user being the USART, in this case
11:33 AM antto: the very first time you put a byte into the transmit FIFO - it has to actually send it to the usart directly, and enable "data-register-empty" interrupt
11:34 AM antto: from then onwards, the DRE interrupt takes charge of squeezing out the remaining bytes from the FIFO
11:34 AM bss36504: So route that "put" operation through your USART lib
11:34 AM antto: but when they run out - it has to shut itself off
11:35 AM bss36504: The USART lib can handle placing a byte either to the USART or into the FIFO (if one is transmitting) then the USART lib internally handles querying the FIFO until it's empty
11:35 AM antto: well hm..
11:36 AM bss36504: So put another way, you write a USART function called SendByte. Your USART lib is backed by this generic FIFO class. When you try to send one byte, it sends no problem. Try to send a bunch of bytes quickly, the USART lib places them into the FIFO temporarily and removes them as necessary
11:37 AM antto: well, that's what i do, except i view this as one single entity "buffered usart"
11:38 AM bss36504: Ok, yeah that's fine and all. The point is you write the FIFO class which does ONE THING. Then you write a USART class which does ONE THING that relies on the FIFO class
11:38 AM bss36504: That's good OOP design
11:38 AM bss36504: If youre just trying to hack this out then do whatever you want, I'm just saying, there's always a way to separate functionality
11:38 AM bss36504: You can have your Buffered USART Cake and eat it too.
11:40 AM antto: thing is.. for one of the USARTs i need a different FIFO
11:40 AM antto: the difference being the size
11:40 AM bss36504: Like a totally different implementation or just a different instance of a FIFO?
11:41 AM antto: yes, different instance, but also different in terms of the exact size of some variables
11:41 AM bss36504: Ok so that's literally the point of making a standalone FIFO class. You could construct a FIFO of one size (using templates) and pass it to one USART instance, construct another of a different size and pass it into the other USART instance
11:42 AM bss36504: You wouldn't be passing the FIFO as a template argument to the USART. Pass by reference.
11:42 AM antto: one of the FIFOs will have to be big, so i am using uint16_t for storing sizes and read/write index, the other one is smaller and thus those will fit into uint8_t
11:43 AM antto: hm
11:44 AM bss36504: Ok great so add another template arg for your FIFO. It would be something like template<typename T, int S> struct FIFO{... Where T is the underlying data type of the FIFO (unit8_t, uint16_t etc) and S would be the depth of the FIFO
11:44 AM antto: i already did that
11:44 AM bss36504: and then your constructor for the USART would be like USART(FIFO &F) where you pass a pre-constructed FIFO reference to it
11:44 AM antto: but how would that work if the FIFO is sepparate from the USART?
11:45 AM bss36504: (don't ding me on syntax, haven't coded C++ in a while)
11:45 AM bss36504: Because the USART would have a reference to the FIFO.
11:49 AM antto: i'll try to put that together in a console app first..
11:50 AM bss36504: Yeah that should be doable
11:50 AM bss36504: read up on the reference passing rules, they're needlessly complicated IMO and I can never remember if I need a * or an ampersand or a happy face or what to pass by reference.
12:18 PM antto: i managed to get asm output, but.. it's like alien
12:35 PM antto: i can't figure out how i would specify for example the UDR0 register as a template argument
12:36 PM antto: it's declared as a volatile uint8_t located at a specific place in memory
12:36 PM Emil: hint
12:36 PM Emil: abort while you can
12:36 PM antto: so do i use a reference to a volatile uint8_t?
12:36 PM antto: Emil why?
12:41 PM specing: reference to uint8_t and hope gcc is smart enough to carry over the volatile tag
12:44 PM antto: what would happen otherwise?
12:45 PM MickyW: antto: Could use volatile modifier inside function at accesses to make it explicit again.
12:46 PM antto: it seems to work in console app (with a dummy volatile uint8_t UDR0 declared in global scope)
12:46 PM bss36504: Why do you need to use a template argument for the UDR?
12:46 PM bss36504: That's unnecessary.
12:46 PM bss36504: Just pass it as an argument to the constructor.
12:47 PM bss36504: Templates really shine when you're trying to customize an internal type, eg the underlying data type of your FIFO.
12:47 PM antto: then i have to store a pointer to it in the struct?
12:47 PM bss36504: Yeah
12:47 PM antto: bss36504 i'm actually writing the usart struct here
12:48 PM bss36504: Yeah I know, but just make the UDR a constructor argument instead of a template argument
12:48 PM bss36504: It's just a pointer
12:48 PM Emil: This sounds like ardweeny
12:48 PM antto: and it will be simplified, i will not have initializing functions and bitrate methods.. just transmit receive and deal with the FIFOs
12:48 PM Emil: Smells like one, too
12:48 PM bss36504: Emil: It's not
12:48 PM Emil: bss36504: no, but it smells like reinventing one
12:49 PM bss36504: Nothing wrong with trying to write a good library (which isnt to say arduino is) using C++
12:49 PM Emil: C reigns supreme
12:49 PM bss36504: lol
12:50 PM antto: bss36504 so i will have to have a pointer to the UDRn in the struct then?
12:50 PM antto: a volatile uint8_t* pointer
12:50 PM bss36504: Yeah
12:50 PM bss36504: exactly
12:50 PM antto: hm..
12:50 PM bss36504: just set that equal to whatever you pass in for the UDRn in the constructor
12:51 PM antto: the reason for this over passing UDR0 as a template argument is.. because UDR0 is not exactly a variable..?
12:52 PM bss36504: In fact, passing UDR as a template argument is LESS efficent, code space wise than passing it in through the constructor. If you do it via the template the compiler will generate object code for each variation of the class
12:52 PM bss36504: No, it exactly is
12:52 PM bss36504: Its a variable that holds a memory address to a specific register
12:53 PM Emil: This sounds like a tumour
12:53 PM antto: okay.. so if its a template argument, i'll get sepparate instances of the whole usart code for each USART
12:53 PM bss36504: Think about a store operation in asm; you're just writing to another address like you could write to any in the address space.
12:53 PM bss36504: sorta yeah
12:54 PM bss36504: whateever the compiler deems necessary to replicate
12:54 PM antto: UDR0 is read/written with the same sort of instructions that a normal uint8_t variable in RAM would?
12:54 PM bss36504: Someone better versed on AVR assembly will probably correct me, but yeah, it's basically the same operation
12:54 PM antto: tbh code space is not a problem
12:55 PM bss36504: And that's how it is in Core M stuff
12:55 PM Emil: bss36504: UDR0 is using the in/out instructions
12:55 PM bss36504: No, but it's less efficient and you'd be abusing a language feature in a "yucky" way
12:55 PM MickyW: Not quite sure, but I think gcc is smart enough to use in/out instead if applicable.
12:55 PM antto: this is an atmega2561, and i have barely reached half the available flash capacity
12:55 PM bss36504: Emil: Ok thanks
12:55 PM Emil: bss36504: flash is accessed using two cycle instructions
12:55 PM Emil: registers using one
12:56 PM bss36504: I would think that The compiler can decode a SFR alias....otherwise you'd never be able to do stuff like the PORT structs that the atmel libs provide
12:57 PM bss36504: The pointer should be fully resolved by the compiler
12:57 PM antto: i've only seen PORT structs on xmega
12:57 PM Emil: sorry, ram/stack is put into registers first if you want to use the variables
12:57 PM bss36504: antto: well yeah same difference though
12:58 PM antto: i have no idea how much of a difference there is internally between xmega and atmega
12:58 PM antto: but at least from the code in io.h - huge diff
12:58 PM bss36504: I dont think there is much but it doesnt matter.
12:58 PM antto: they are certainly very enjoyable
12:58 PM bss36504: the compiler would need to be able to do an address resolution and choose the appropriate instruction.
12:59 PM bss36504: If necessary, there would be a compiler directive to inform the compiler "hey, this is a hardware register, treat it as such", in which case you can just declare your struct variable as such
01:00 PM bss36504: but idk off the top of my head, and im not at my home pc to poke around
01:01 PM antto: okay, i'll just trust you and use a pointer, and i'll also write a comment for what the reason is
01:01 PM antto: because otherwise i might look at it later and go "wtf? why haven't i made this a reference instead"
01:03 PM antto: for now i think i'm left with no template arguments then, that would make it a plain struct?!
01:03 PM bss36504: sounds like it
01:03 PM antto: or do i use an empty template <> struct { .... };
01:04 PM bss36504: the FIFO class is a better candidate for templating, since you want to be able to alter the underlying data type
01:05 PM antto: yes, there is some other specific stuff in the USART receive interrupt later, but i hope it won't require anything special
01:06 PM bss36504: dont do an empty template, that doesnt really make sense, if it's even valid
01:06 PM antto: one of the USARTs is used as MIDI, and there i process each byte in the interrupt itself, removing some values so they never go to the FIFO at all
01:06 PM bss36504: Basically, templates shine when you need to customize an internal type. The compiler will generate new code as necessary to support all instantiations of that class with different types
01:07 PM bss36504: Anything else, sizes, etc, are just member variables that are type independant and can be passed in through the constructor
01:08 PM antto: uh
01:08 PM antto: for the FIFO, shouldn't the "fifo size" be a template argument?
01:09 PM antto: cuz in my case it's known at compile time, and also a power of 2
01:09 PM bss36504: you should write a quality USART class that can optionally use a FIFO, has all the functions to set it up, packetize data, send data etc. then subclass it to make your MIDI usart. Just override the functions that you need the MIDI class to do differently
01:10 PM bss36504: FIFO size should not be a template argument if you can avoid it, However if you wanted to ENFORCE that it be a power of 2 at compile time you *might* be able to make a template argument and do some SFINAE magic to check. But if you don't really care, just make it a constructor variable.
01:10 PM bss36504: Though why would a FIFO need to only be a power of 2 in size?
01:10 PM bss36504: Stop thinking about what you need the FIFO for right this second for this project.
01:11 PM bss36504: It's a data structure, and should be flexible
01:11 PM antto: cuz it's a power of two, and i wrap the index with binary AND ;P~
01:12 PM bss36504: yeah but you could, you know, not do it that way
01:13 PM bss36504: if currentIndex == maxIndex, currentIndex = 0
01:13 PM antto: >=
01:13 PM bss36504: You gain virtually 0 performance using binary AND
01:16 PM bss36504: Personally I'd write a fully flexible FIFO class. Customizable type and size, so I can have a 238 slot FIFO of uint8_t or a 19 slot uint16_t or whatever
01:16 PM bss36504: If you're going to all the pain to write a C++ class, you might as well do it right. If you need something fast and dirty, use C or assmebly.
01:16 PM bss36504: assembly*
01:17 PM bss36504: Then I'd write a fully flexible USART class, and subclass it to make my MIDI usart class
01:17 PM bss36504: you could stub out the ISR in the USART superclass and then just override it in the MIDI class
01:17 PM bss36504: This should all still be very fast, as the compiler/linker can resolve all this stuff at compile time.
03:01 PM antto: bss36504 my MIDI stuff has some exotic things, so i'll keep it sepparate
03:02 PM antto: it'd be enough to just be able to have a pointer to a "buffered usart" to write bytes to, and poll
03:02 PM antto: and i don't think i'll need this exact same thing in another project
03:29 PM antto: how do i have a pointer/reference to the "FIFO" struct when it requires me to specify its exact template arguments in the usart struct declaration?
03:30 PM bss36504: Fair enough
03:30 PM antto: don't i need to put those as template arguments for the usart struct too?
03:30 PM antto: * definition, not declaration
03:32 PM bss36504: ooh well here the fun begins....
03:33 PM bss36504: I believe you need to either specify the USART class as a template class as well, something like this: template<T> class USART....USART(FIFO<T> fifo), or you can just make a template function on the USART class that accepts the FIFO in a similar manner.
03:34 PM antto: so basically relay the template arguments of the FIFO out thru the usart
03:35 PM bss36504: Alternatively, (en)force a particular type with your constructor/function signature like USART(FIFO<uint8_t> fifo)
03:35 PM bss36504: more or less
03:35 PM antto: :/
03:35 PM antto: that's definately not gud
03:35 PM antto: then i cannot use two such "usarts" with different FIFOs
03:36 PM bss36504: However, you could also go to a factory-builder pattern with a USART builder function that can be a template function. See answer 2 here: http://stackoverflow.com/questions/3960849/c-template-constructor
03:37 PM bss36504: Personally that's probably the best; you'd specify your USART constructor as private (so it's not accessable), then have a static template function as part of the USART to build a USART instance for you. This function can deduce the FIFO type argument
03:38 PM Lambda_Aurigae: sounds like making it waaay more complex than it has to be in order to "simplify" it
03:39 PM antto: "new" ?!
03:39 PM bss36504: Sorry, it's not technically a factory-builder pattern....Kinda sorta like a singleton-but-not-really
03:39 PM antto: is that gonna be dynamic allocation?!
03:39 PM bss36504: Lambda_Aurigae: It's not really that hard
03:39 PM bss36504: It's just template ;)
03:39 PM bss36504: templates*
03:39 PM bss36504: Really though, not trying to be patronizing, but the builder function approach is pretty standard
03:39 PM bss36504: you dont need to use new
03:39 PM bss36504: wait...
03:39 PM bss36504: hmmm.
03:39 PM antto: somehow my nose tells me not to use "new" on this atmega
03:40 PM bss36504: No you should avoid it
03:40 PM bss36504: It's not the worst thing ever but it will require a heap obviously.
03:42 PM bss36504: I think you can get away without new. Just declare it like you normally would within the builder function and return a reference to it. When the function returns, that local variable goes out of scope but the reference should persist.
03:42 PM bss36504: Not sure though, it's getting kind of murky.
03:42 PM antto: it gets very complicated x_x
03:42 PM Lambda_Aurigae: fifo buffer....an array of whatever size, a variable to point to start, a variable to point to end, a routine to add something to the buffer and a routine to remove something from the buffer.
03:42 PM bss36504: If you cant do it with the builder without new, just make a template function on the USART class that accepts a FIFO. If you want that USART to be buffered, just set it via that function
03:43 PM antto: i still think it would've been simpler to just make one single template struct for a usart+fifo
03:43 PM bss36504: Lambda_Aurigae: Yeah but we're specifically trying to create a templated FIFO so that the size requirments for each element can be tailored to the application
03:43 PM antto: bss36504 what will it do when it gets passed a fifo then?
03:44 PM bss36504: antto: Maybe simpler. I said that earlier, if you just want something quick and dirty than whatever. But if you're going to use templates you might as well do it right
03:44 PM Lambda_Aurigae: #define fifo_size
03:44 PM bss36504: Lambda_Aurigae: Yes I'm aware but template metaprogramming > preprocessor metaprogramming.
03:45 PM Lambda_Aurigae: seems like a lot more work
03:45 PM antto: Lambda_Aurigae i need a big FIFO for USART1, with uint16_t size, and a smaller FIFO for USART0 with a uint8_t size
03:45 PM antto: i'll also have different sizes for receive vs transmit buffers
03:45 PM bss36504: That's an additional reason to go OOP. Preprocessor stuff is fine if you need one of something, but there's no way to do multiple, customized instances
03:46 PM bss36504: Again, I'd say its not *too* hard to do this correctly, just takes a bit of thinking. Once it's done he'll never have to write another FIFO class.
03:47 PM Lambda_Aurigae: so, a struct that contains data array, size, start, and end....and a couple of functions that you pass the struct to that do add and remove.
03:47 PM antto: i probably will ;P~
03:47 PM bss36504: oi ffs do whatever..
03:47 PM Lambda_Aurigae: int fifo_push(struct, data); int fifo_pop(struct, data)
03:48 PM Lambda_Aurigae: it works
03:48 PM antto: bss36504 i don't think i'm at a level where i can write something so perfect that it deserves to be carved in stone
03:48 PM bss36504: Lambda_Aurigae: I'm not saying there isnt a pure C way to do this. But if you want to leverage the power of templates (such as compile time type checking) then this is the way to do it
03:48 PM bss36504: antto: Thats fair.
03:48 PM Lambda_Aurigae: would have to be pointers to the struct, but,,
03:49 PM antto: Lambda_Aurigae i really.. really don't like that sort of thing
03:49 PM antto: object.method() is soooo much better
03:49 PM Lambda_Aurigae: to each their own.
03:49 PM Lambda_Aurigae: I find that so much harder to read myself.
03:50 PM Lambda_Aurigae: but I was doing C for years before I ever heard of C++
03:50 PM antto: and encapsulation is one of the first nice thing i learnt in C++
03:51 PM antto: ..what a broken sentence
03:51 PM antto: x_x
03:52 PM bss36504: Lambda_Aurigae: Harder to read? How so? You're calling a function on an instance of a class. It's different, sure, but harder....?
03:52 PM Lambda_Aurigae: bss36504, to me it's harder to read...probably not to anybody else, but it is to me.
03:52 PM antto: FIFO lil; FIFO jon;
03:52 PM antto: jon.accept(0xFF);
03:52 PM Lambda_Aurigae: not just the calling...the whole setup of the classes.
03:53 PM Lambda_Aurigae: I get kinda set in my ways.
03:55 PM antto: this whole thing requires some atomic blocks in a bunch of places, so i'm not sure if the FIFO struct will really be super reusable for non-USART things
04:10 PM antto: hm.. i've actually used transmit-complete interrupt, not data-register-empty o_O
04:33 PM aczid: picked up one of these https://hidiot.com/
04:33 PM aczid: kinda neat, an arduino/digispark clone on attiny85 with only like 10 passives
05:01 PM Emil: antto: you do realise uarts are always max 9 bits?
05:01 PM Emil: and most ofteb 8 bits
05:01 PM Emil: so 16 bit uart is like wtf niga you doin
05:02 PM Emil: oh you meant buffer siE
05:02 PM Emil: size*
05:02 PM Emil: nvm
05:07 PM antto: im crazy niga ;P~
05:08 PM specing: > wtf niga you doin
05:09 PM specing: bae is thicker than 16 bits
05:23 PM arij is now known as arij_work
06:03 PM Emil: Is ADA a thik bae?
06:03 PM specing: Ada is a mature and wise bae
06:24 PM Emil: Does she look good?
06:28 PM specing: yes
06:37 PM Emil: So she's a LILF?
06:39 PM specing: LILF?
06:39 PM Lambda_Aurigae: more like "LILP"
06:40 PM Lambda_Aurigae: at least for specing
06:40 PM Lambda_Aurigae: although, F might well fit too
07:42 PM julius: hi
07:44 PM julius: when you have something like this: while(!(ADCSRA & (1<<ADIF))); it does compare the contents of ADCSRA for exampe: 11100000 with itself, but ADIF set as 1.. example: 11110000 ADIF is the 4th bit in the register
07:45 PM julius: so it does 11100000 & 11110000 which would be 0 for ADIF
07:46 PM julius: or does it only check one bit, the ADIF bit with the current state against (1<<ADIF)
07:47 PM julius: for example 0 & 1
07:48 PM Lambda_Aurigae: (1<<ADIF) will resolve to not just one bit but a full byte.
07:49 PM Lambda_Aurigae: then it will do a comparison between the two.
07:51 PM julius: is it then 00010000 ?
07:51 PM julius: i mean the (1<<ADIF)
07:52 PM Lambda_Aurigae: yes.
07:52 PM julius: but when that is "anded" (&) with the current status it will never be true if just one other bit is not 0
07:52 PM julius: oh wiat
07:53 PM Lambda_Aurigae: any bit set to 1 makes it true.
07:55 PM julius: actually i know that this: 00010000 & 00010000 is true on the 4'th bit...but what about the other positions, whats the overall true or false value for all 8 bits?
07:55 PM Lambda_Aurigae: 00010000 & 1101000 = 00010000
07:55 PM Lambda_Aurigae: which is true
07:55 PM julius: so just one bit has to be 1 to make it all true
07:56 PM Lambda_Aurigae: yes
07:56 PM Lambda_Aurigae: true = !0
07:56 PM julius: ok thanks
07:56 PM Lambda_Aurigae: false = -
07:56 PM Lambda_Aurigae: err
07:56 PM Lambda_Aurigae: false = 0
07:56 PM julius: sure i know those
07:56 PM julius: just wasnt sure about the true value about a whole byte when its not all 1
07:57 PM Lambda_Aurigae: any bit set to 1 makes it true
07:57 PM Lambda_Aurigae: anything 0 is false
07:57 PM Lambda_Aurigae: anything not 0 is true
07:58 PM Lambda_Aurigae: any single or combination of bits set to 1 makes it true.
07:58 PM julius: and single or combnation of bits (also including zeros) set to 1 makes it true. ?
08:00 PM Lambda_Aurigae: if it's 0 then it's not 1....
08:00 PM Lambda_Aurigae: any bit set to 1 makes it true
08:00 PM Lambda_Aurigae: any number that's not 0(zero) is defined as true.
08:01 PM Lambda_Aurigae: standard digital maths.
08:01 PM julius: yes
08:01 PM julius: i learned it with 1 & 1 = true, 0 & 1 = false
08:02 PM Lambda_Aurigae: 1 & 1 = 1
08:02 PM Lambda_Aurigae: 1 & 0 = 0
08:02 PM julius: so im now again unsure about 11110000 & 1111111
08:02 PM Lambda_Aurigae: how can you be unsure
08:02 PM Lambda_Aurigae: ?
08:02 PM Lambda_Aurigae: what does that come out to?
08:02 PM julius: whats the overall value of that
08:02 PM Lambda_Aurigae: 11110000 & 11111111 = 11110000
08:02 PM Lambda_Aurigae: standard
08:02 PM julius: comes out to 11110000
08:02 PM Lambda_Aurigae: binary
08:02 PM Lambda_Aurigae: math
08:02 PM Lambda_Aurigae: which is
08:02 PM Lambda_Aurigae: non-zero
08:03 PM julius: so its true
08:03 PM Lambda_Aurigae: non-zero = true
08:03 PM julius: ok
08:03 PM julius: got it
08:03 PM Lambda_Aurigae: how many ways can I explain it?
08:03 PM julius: well, there are zeroes in there...
08:03 PM Lambda_Aurigae: so?
08:03 PM Lambda_Aurigae: the overall number....0xF0
08:03 PM julius: so one can at least doubt that its true if you only ever worked with single positions
08:03 PM Lambda_Aurigae: is not zero
08:03 PM julius: yes thanks, got it now
08:04 PM Lambda_Aurigae: oh good glub.
08:04 PM Lambda_Aurigae: binary math 101
08:04 PM julius: its been some time
08:28 PM arij_work is now known as arij
08:54 PM enhering: hi.