Back
[06:14:42] <eballetbo> On xmega is it ok write more than one byte to the SPIC.DATA inside interrupt handler?
[06:14:48] <eballetbo> something like this
http://pastebin.com/tL4fV7aa
[06:20:04] <sabor> eballetbo: generally i would recommend to not put any waiting loops into an ISR
[06:22:30] <eballetbo> then how can I send multiple bytes via SPI, e.g master sends a command, slaves answers with the length of data + data + checksum, is that possible with an xmega
[06:25:10] <sabor> generally you send one byte per interrupt, so the ISR would just put the next byte into the register and return
[06:25:50] <sabor> when it is sent the next interrupt is generated and the ISR is called again
[06:29:02] <eballetbo> hmm, i see, so maybe the best way to do this is implement a state machine that sends a byte on every interrupt
[06:29:31] <sabor> exactly, that's how it usually is done
[06:30:01] <eballetbo> do you know if there is somewhere any code as example?
[06:30:55] <sabor> sorry, not for xmega
[06:31:29] <eballetbo> np, thanks for your support :)
[06:31:43] <sabor> you're welcome
[09:40:52] <Levitator> So, am I right in the observation that atomic fetch/set is omitted on SREG because the MCU is designed around the assumption that all interrupt handlers restore SREG anyway and have zero net effect on it?
[09:44:34] <LeoNerd> Mmm?
[09:45:16] <Levitator> You can construct atomic fetch/set by wrapping things in a critical section, but you can't do that for SREG because it contains the I bit.
[09:45:53] <Levitator> You cannot obtain a backup of its contents and set it at the same time.
[09:46:27] <Levitator> You have to just assume that between the time that you read it, and the time that you disable it, nothing can happen that has a net effect on it.
[09:53:34] <Casper> just use sbi and cbi?
[09:54:13] <Casper> atomic is mostly for multi-bytes variables
[09:55:30] <LeoNerd> The atomic fetch-and-modify operations
[09:55:41] <LeoNerd> On newer AVR cores.. I don't think many chips have those. Possibly just some of the new XMEGAs currently
[10:02:54] <Levitator> Casper: That doesn't tell you what the old value was so that you can restore it.
[10:03:39] <Levitator> Surprisingly, SREG is actually a low-IO register, so you can use sbi and cbi on it to twiddle any bit you want.
[10:03:53] <Levitator> But that still doesn't provide you with the old value.
[10:04:42] <LeoNerd> Could be nice to have a TASB / TACB instruction pair
[10:05:34] <Levitator> What is a TASB instruction?
[10:06:09] <LeoNerd> test-and-set-bit
[10:06:17] <LeoNerd> (ditto test-and-clear-bit)
[10:06:30] <LeoNerd> It would fetch the previous value to the T bit, while at the same time mutating the target as requestd
[10:06:46] <skz81> <Levitator> You have to just assume that between the time that you read it, and the time that you disable it, nothing can happen that has a net effect on it. >> hum, unsure but... As I understand it, when an iISR is triggered, I bit is cleared in SREG, restored by IRET
[10:08:00] <skz81> so, your ISR _IS_ atomic, unless you set I explicitely in your code. Then, you can fetch SREG as your very first instruction
[10:09:24] <Levitator> IRET does restore I, but it doesn't restore SREG. I imagine that the compiler knows to emit stack instructions to do that.
[10:09:54] <Levitator> I mean, I guess it would have to.
[10:11:04] <skz81> huh...first my point was about _NAKED_ ISR (so no compiler magics in my words... But it may work also, don't know)
[10:11:29] <Levitator> It would work as long as you don't change anything.
[10:11:34] <LeoNerd> What actual problem are you actually trying to solve?
[10:11:38] <skz81> second, obviously, if you fetch it at first, you have to restore it before returning. it was implied
[10:13:01] <Levitator> I'm writing an atomics header in C++.
[10:13:20] <Levitator> And I wanted to make sure to handle the special case for SREG correctly.
[10:13:56] <LeoNerd> That's not an *actual* problem
[10:14:03] <LeoNerd> That's a step you are taking because you believe it will help you solve a problem
[10:14:05] <LeoNerd> What problem?
[10:14:33] <Levitator> You could say that about pretty much anything since nothing is an end in itself.
[10:14:43] <Levitator> I'm writing an IO library. Shall we proceed recursively?
[10:15:00] <LeoNerd> Indeed, lets. Continue until you hit something concrete in the real world and we'll start there
[10:16:28] <Levitator> If you like to just hack everything together for single-use purposes and rewrite it every time you change it, then you needn't worry about abstraction.
[10:16:40] <LeoNerd> Sure
[10:16:48] <LeoNerd> But give us an example. Something concrete to work from
[10:16:56] <LeoNerd> "Iwant to make an X" <= hard to work with
[10:17:14] <LeoNerd> "I want to make an X because it can be used to make Y that solves problem Z" <== much better even if it's ultimately the same thing
[10:19:26] <Levitator> I want to be able to develop apps for avrs using a basic set of components which can be statically recombined to create other components.
[10:22:19] <Levitator> Part of that involves operations on unknown or unspecified registers, and different registers have different properties and instructions available.
[10:22:48] <LeoNerd> That's a useful goal. But I'm still not seeing a need for an atomic test-and-set operation on SREG at the moment
[10:22:59] <LeoNerd> Can you expand and maybe give an example of a time you'd be calling it?
[10:23:15] <Levitator> There may not be, because of the use case for which it's intended, and that was my original question.
[10:23:36] <LeoNerd> Ah. See I find I don't bother making abstractions for things until I need them
[10:23:43] <LeoNerd> Moreover, unti I need them the *second* time
[10:23:55] <Levitator> For example, I have a generic interrupt class that doesn't know, upfront, what register or mask is involved in toggling the interrupt.
[10:23:59] <LeoNerd> If I don't need it at all, I don't bother. If I only ever need it once as a one-off there's no point abstracting it out
[10:24:48] <Levitator> You pass it a register and a mask, and it internally creates the appropriate atomic for that register so that it can toggle it on and off.
[10:25:11] <Levitator> The global interrupt, as we discussed, is a special case.
[10:25:22] <LeoNerd> Yah; the global one behaves very differently, also
[10:25:27] <LeoNerd> They're not even similar in any way
[10:25:37] <LeoNerd> Specific unit IEs control whether an interrupt is generated *at all*
[10:25:45] <LeoNerd> If you disable the interrupt there, then no interrupt happens at all
[10:26:00] <LeoNerd> Whereas, the I bit in SREG controls whether pending interrupts are serviced *right now*
[10:26:23] <LeoNerd> An interrupt can be generated but still pending unserviced if the I bit is clear; setting the I bit will fire it
[10:26:49] <LeoNerd> But setting an IE-like bit in a peripheral unit won't cause an interrupt to happen just because the prevailing condition happens to hold
[10:26:59] <Levitator> Yeah, it might not actually be useful to include the GIE in this abstraction.
[10:28:15] <LeoNerd> The SREG save and restore mechanism built into ISRs already nicely atomically handles that situation, also
[10:28:44] <LeoNerd> Once inside an ISR you know more interrupts won't happen anyway, so in that sense all operations become atomic
[10:28:52] <Levitator> Incidentally, I was disappointed to find that C++ is crippled in avr-land due to poor Harvard architecture support.
[10:29:07] <LeoNerd> Is it any worse than c?
[10:29:09] <LeoNerd> C?
[10:29:26] <Levitator> In gcc, to be specific. It places vtables in dynamic RAM for no good reason, and that eats your memory.
[10:29:31] <LeoNerd> Ahh
[10:29:39] <LeoNerd> OH.. yes. Wow, avoid that most definitely
[10:29:58] <LeoNerd> virtual methods on MCUs? terrible idea
[10:30:09] <Levitator> I don't see what's wrong with that idea, fundamentally.
[10:30:16] <LeoNerd> *basically* this is why I don't bother with C++ on AVRs. You have to avoid so much of what makes C++, C++, that you end up just writing straight C
[10:30:25] <Levitator> It's just that this implementation is crippled.
[10:30:27] <LeoNerd> So I just write straight C anyway and don't have to put up with all of C++'s other crap
[10:30:38] <LeoNerd> ... like g++ getting upset about trailing commas in enums :P
[10:31:21] <Levitator> So, anyway, if you want to use virtual methods, you have to implement vtables yourself, which is tedious and error-prone.
[10:31:30] <LeoNerd> It means in those rare cases where I do actually want to implement some sort of dynamic dispatch, I can still do it.. but then I'm in control of PROGMEM
[10:31:45] <Levitator> Because unfortunately, for all of the introspection which C++ provides, it doesn't allow you walk or enumerate the members of a type.
[10:32:07] * LeoNerd would love a C-like language with a lot more compiletime evaluation, to be fair
[10:32:26] <LeoNerd> Perl's BEGIN {...} or Scheme's (let-for-syntax ...) really has no parallel in C
[10:32:29] <Levitator> You can still do it, you just have no native language support.
[10:32:50] <Levitator> C++ has utter tons of compile-time evaluation, and now more than ever.
[10:33:19] <LeoNerd> Can C++ let me make an array at link time, by merging individual elements of it from across different .c files?
[10:33:43] <LeoNerd> I want one toplevel array of "task" structures. Ideally it would be nice that lots of indivdidual .c files can insert there own task into the scheduler, and keep the source separate
[10:33:59] <Levitator> People have implemented static collections in C++. See the boost library.
[10:35:03] <Levitator> There are static linked lists which you can append to each other among other relevant operations, IIRC.
[10:35:08] <LeoNerd> Well I'd want an array of linktime-known size, not a linked list
[10:35:31] <LeoNerd> Then -flto can turn sizeof(tasks)/sizeof(tasks[0]) into a constant, for the for loop to iterate on
[10:35:31] <Levitator> You could probably do something like that, yeah.
[10:36:13] <specing> C and C++ aren't the only languages that you can use on AVR
[10:36:18] <Levitator> You could have a template type that takes two templates, and incorporates them into itself. Returns an iterator type that knows how to jump the discontinuity.
[10:36:28] <specing> just saying :D
[10:36:51] <Levitator> I don't know if you can append two arrays to each other to be continuous in memory, though.
[10:37:39] <Levitator> But C++ has a notion of abstract pointer-like objects that internally perform logic to enumerate something as if it's an array, even if it's something else, such as a list of arrays.
[10:37:57] <LeoNerd> Yah I don't want that
[10:38:14] <LeoNerd> I want it to compile into a *literal* array in memory that Ican iterate with pointer increments of compiletime-constant size
[10:38:38] <LeoNerd> Rightnow, C lets me do it, I just have to assemble my array in one .c file by inserting elements that other .c files extern'ed
[10:39:02] <Levitator> Does there exist any syntax to merge two arrays? I am only aware that you can do it for character string literals.
[10:40:00] <LeoNerd> I can *almost* do it with linker-time scripts
[10:40:37] <LeoNerd> You can make lots of static __attribute__((section,"task")) Task task[] = { one single task here }; declarations in each file and then have the linker merge them
[10:40:51] <LeoNerd> But... you don't get control of the order, and you don't get to know how big the result is or how many elements it contains
[10:40:57] <LeoNerd> So it's useless for actually iterating on
[10:42:04] <Levitator> Dunno. It's an interesting question, but I don't know if the syntax exists to stuff an indeterminate number of elements into an array.
[10:42:38] <Levitator> I don't think it does. There is something called a "tuple", and I believe it is implemented by inheriting a recursive type, or something similarly crazy.
[10:43:09] <Levitator> By studying the memory placement rules, you could probably contrive some sort of alchemy which ensures that the end result is effectively an array.
[10:43:54] <Levitator> And you could cast the thing to an array, and have it work.
[10:44:17] <Levitator> Cast a pointer or reference to it, specifically.
[10:45:01] <Levitator> Yeah, I think that would work. I believe the arrangement of the data blocks within an inheritance chain is well defined, so that is probably the way to do it.
[10:45:54] <Levitator> Well, it is well-defined for some types, all of which are from C anyway, I believe.
[10:49:33] <Levitator> Yeah, so you define this type so that when you perform a "prepend" operation, you are getting back a type which consists of a new type containing your new element, and inheriting the orginal type, containing the rest of the elements.
[10:50:00] <Levitator> And they will all be contiguous in memory (if you do it right), and are therefore an array.
[10:50:22] <LeoNerd> I don't want a "prepend" operation
[10:50:30] <Levitator> Which is kind of weird coming from C, because you have operations which take types as arguments and return other types as opposed to values.
[10:50:48] <LeoNerd> "prepend" would imply a linear chain of .c files that each knows about the previous
[10:51:05] <LeoNerd> I want multiple /independent/ C files that all know nothing about the others, and possibly one master one that ties them together at the end
[10:51:08] <LeoNerd> This is what I have right now
[10:51:41] <Levitator> Did you not just point out that you want your resulting array to be well-ordered?
[10:52:11] <LeoNerd> No
[10:52:26] <LeoNerd> What Isaid was that since I get neither ordering control *nor* size information, it's useless to iterate over
[10:52:32] <LeoNerd> If I had size information I wouldn't care about order
[10:52:50] <LeoNerd> If I didn't get size information but I did have at least some control over order, Ican put a special NULL element at the end to control my iteration
[10:53:04] <LeoNerd> I only need either one of these mechanisms, I don't require both.
[10:54:57] <Levitator> I don't see how you could do that within the language other than using linker trickery.
[10:55:19] <LeoNerd> I believe I said this right at the beginning
[10:55:36] <Levitator> Only the linker has cross-module knowledge.
[10:55:38] <LeoNerd> when I said I wanted extra compiletime executed code, in a language that would be like C but extended
[10:58:24] <Levitator> Oh, well. BBL.
[11:10:10] <skz81> <LeoNerd> Once inside an ISR you know more interrupts won't happen anyway, so in that sense all operations become atomic >> thanks, that what I said too !
[11:10:25] <LeoNerd> :)
[11:10:31] <LeoNerd> Nice to see *someone* was paying attention anyway
[11:55:12] <skz81> #esp*-open-rtos
[11:55:20] <skz81> oops sorry
[12:53:45] <PinkTieGuy> Hey everyone. Just wondering if there's any best practices when making new parts in eagle. Specifically, I'm wondering how big I should make smd pads given a min and max value in the relevant datasheet. Do you average? Do you set it so they're as big as possible just in case? Any suggestions? Thanks
[14:03:51] <Casper> PinkTieGuy: the bigger the pad, the easier it is to solder until the gap between the pads become too small and the solder just bridge across, or until the voltage can arc across that gap
[14:03:55] <Casper> so, go average?
[14:04:51] <PinkTieGuy> Casper : That's what I ended up doing. Seemed to have worked fine for me in the past but I just got a little nervous because some of them are tiny!
[14:34:55] <carabia> if you're not doing stuff with voltages in the realm of hundreds, you really don't have to worry about arcing
[14:35:29] <carabia> the cheap fab houses won't even do trace spacing nowhere near small enough to facilitate for it
[14:36:32] <_ami_> http://www.zdnet.com/article/move-over-raspberry-pi-here-is-a-4-coin-sized-open-source-linux-computer/ - this looks promising.
[14:38:09] <carabia> not even bothering to read the article -- i'm really baffled as to what the fuck is up with breaking out pins of application processors
[14:38:56] <carabia> it's just wrong to fucking veroboard them
[14:39:03] <carabia> wrong wrong wrong
[14:42:39] <carabia> oh that's a mips-core
[14:46:22] <carabia> probably easier to init that without a crappy loonix on it than arm a
[14:54:19] <_ami_> carabia: the cheap price excites me! :)
[15:32:07] <_ami_> st7735 in color666 mode would be too slow ? need to test and share results here. adafruit uses color565
[15:32:19] <_ami_> adafruit lib*
[15:38:04] <carabia> _ami_: well it's not that spi will be fast in the first place
[15:38:15] <carabia> s/that/like
[15:39:04] <carabia> rgb565 is just more popular than 666. And aligns in 2 bytes.
[15:40:13] <carabia> which makes calculating position in a buffer a bit more painless
[15:41:29] <carabia> i really don't think there will be a really noticeable difference in the color quality that would justify using 666
[15:41:59] <carabia> well obviously there's a difference but 565 should be fine and less of a hassle.
[15:42:02] <_ami_> color666 is definitely slower than color565.
[15:42:16] <carabia> of course it is
[15:43:15] <carabia> it also might have to go through additional reads off the display because it doesn't align to a whole byte
[15:43:48] <carabia> well nevermind additional, reads in general.
[15:44:45] <carabia> in case you're using a library that is. Are you?
[15:44:55] <carabia> or just writing to the buffer?
[15:45:59] <_ami_> carabia: write an avr lib for st7735.
[15:46:44] <_ami_> thought of supporting all color modes but then realized that it might slow down code a bit if i am trying to achieve the mode switch at run time.
[15:47:01] <_ami_> writing*
[15:47:02] <carabia> really, just do 565
[15:49:39] <carabia> with 18bpp you'd have to read the first/last byte back from the display buffer to do it correctly... if i'm thinking straight.
[15:50:17] <carabia> unless you don't care about overwriting the overlap
[15:51:06] <carabia> and you'd have to do funny business to calculate the position
[15:51:59] <carabia> or would you... I'm not invested in this enough to think as far as that
[15:53:54] <carabia> it's not like you can expect to sensibly pipe any bitmaps (or arbitrary pixel formats) from external storage to the display anyway, it will be daaaaamn slow
[15:54:20] <carabia> with an avr... so bpp shouldn't matter that much
[15:54:56] <carabia> or=of*
[16:12:56] <_ami_> carabia: i shall implement that tomorrow. its getting late here. already 2.00 am
[16:13:01] <_ami_> nn
[16:14:51] <_ami_> btw, i think for color666. i just have to transfer three bytes where 2 x 3 = 6` bits are total wastage.
[17:06:20] <Emil> Can I have multiple USB endpoints simultaneously?
[17:06:37] <Emil> So for example serial and keyboard at the same time through usb
[17:08:23] <LeoNerd> Sure
[17:08:42] <Emil> Are there examples?
[17:10:40] <specing> lufa?
[22:49:37] <carabia> _ami_: you there?
[22:49:59] <_ami_> carabia: yeah
[22:55:46] <carabia> yeah actually nevermind
[23:00:18] <carabia> and yeah you were right you can't do back to back write to the framebuffer if the pixel format doesn't align to a byte boundary... instead it will just ignore some data
[23:00:25] <carabia> :|
[23:02:14] <_ami_> ok :)
[23:02:32] <_ami_> carabia: watch football? EPL?
[23:02:45] <_ami_> do you watch football?
[23:02:50] <carabia> not really, why?
[23:03:18] <carabia> which league is EPL?
[23:03:33] <_ami_> Engligh premier leauge
[23:03:46] <carabia> ah oh.
[23:04:14] <carabia> I used to keep up with it a bit, when I was more of a betting man, but that's about ten years or more ago :(
[23:04:28] <_ami_> i am planning to go to London to watch my beloved Chelsea match. wanted to ask which time is best to go there?
[23:04:39] <carabia> never, it always rains in london
[23:04:43] <_ami_> :P
[23:04:56] <carabia> ask LeoNerd !
[23:05:13] <carabia> not sure if he's in ol' london town though.
[23:05:47] <_ami_> ok, i shall ask him then.
[23:06:58] <carabia> how about India, what's big there? Football and umm... cricket?
[23:07:19] <carabia> i guess badminton to an extent too. I think badminton is the most popular racket sport in the world overall
[23:08:40] <_ami_> cricket is big. but i find it boring now. its just too much cricket these days. lacks quality. i used to like test matches though.
[23:08:51] <_ami_> i love badminton!
[23:10:22] <_ami_> we were never good at football.. although a football league has started in india too. big old stars like Anelka, rabrto carlos plays here. but they are old now :P lacks quality
[23:11:25] <carabia> yeah i love badminton too, rio men's singles was quite nice but i really wanted to see lee win :(
[23:12:26] <carabia> so sad, he'll probably never get an olympic gold
[23:14:33] <_ami_> how old he is? 30+?
[23:14:43] <carabia> something like 35 I think
[23:14:55] <_ami_> ah, then impossible i think :/
[23:14:57] <carabia> tokyo would be really pushing for it for him
[23:16:33] <carabia> badminton is a game for the younger peeps. to me it's one of the most enjoyable sports to watch. I don't really wants too much sports, just that, ice hockey and snooker if it qualifies. As I guess it's more of a game rather than a sport.
[23:16:56] <carabia> s/wants/watch
[23:17:37] <_ami_> individual games like badminton are great. but the team games teaches a lot you several valuable lessons in life.
[23:18:28] <_ami_> i just find cricket too much boring. its kind of uncommon in a cricket loving nation.
[23:18:57] <_ami_> what i don't like abt cricket is that its a passive team game.
[23:19:17] <_ami_> football is too intense and u can't take your eyes off for 45mins or so.
[23:19:51] <_ami_> Tv channels shows advertisement after every over here. :/
[23:20:15] <carabia> well in ice hovkey it's more like ten seconds. But it's also a... what we call a "contact sport"
[23:21:01] <_ami_> also the cricket commentary (english) is pretty bad these days. they talk abt everything other than GAME. :P
[23:21:14] <carabia> ice hockey is about as offensive team game as they come. Though the hockey league over at 'murica takes the concept too far and ruins the game.
[23:21:42] <carabia> haha, yeah, that happens but it also depends a lot on the commentators
[23:22:24] <carabia> tbf though, i've never watched cricket and i'm not even familiar with the ruleset
[23:22:48] <_ami_> carabia: :)
[23:23:19] <carabia> but then again cricket is mostly played in the ole Commonwealth right
[23:25:23] <_ami_> yeah, only 10 nations plays it (India subcontinent (india, pakistan, sri lanka, bangladesh), England, Aus, Nz, South Africa, )
[23:25:43] <_ami_> 2 more i don't remember.
[23:26:09] <_ami_> Zimbabwe
[23:27:08] <carabia> Canada?
[23:27:11] <_ami_> Ireland
[23:27:29] <carabia> oh alright
[23:28:10] <_ami_> yah, canada also (mostly indians :P ) .. but they are not test cricket playing nation.
[23:29:59] <carabia> yees the esquimos are not into that kind of a thing.
[23:30:30] <_ami_> haha
[23:30:43] <carabia> well anyway gotta catch ya later. time for the morning run and then off to work. good talkin to ya.
[23:31:02] <_ami_> hv fun! :)
[23:31:19] <_ami_> weekend here though. :)
[23:38:33] <sabor> again weekend?