Back
[01:12:42] <R0b0t1> GuShH: You will be glad to know I worked on a project which used the Arduino libraries and an ATmega644 as its backbone.
[01:13:55] <GuShH> R0b0t1: good for you?
[01:14:08] <R0b0t1> No.
[01:14:12] <R0b0t1> It is horrible for everyone.
[01:14:12] <GuShH> then?
[01:14:18] <GuShH> why do it?
[01:14:20] <R0b0t1> I thought you might chuckle a little.
[01:14:26] <R0b0t1> Oh, because monies.
[01:14:29] * GuShH shrugs
[01:18:14] <GuShH> R0b0t1: I had to work on something like that in the past, actually.
[01:21:23] <R0b0t1> D:
[01:21:38] <R0b0t1> It's like we've got a connection now. Tell the world about it.
[01:22:06] <GuShH> o.o
[01:22:45] <R0b0t1> Tell the world about that shitty Arduino project, that is.
[01:22:55] <GuShH> no thanks.
[01:23:06] <GuShH> and I didn't have to touch an arduino.
[01:24:29] <R0b0t1> Too much below your level, I see.
[01:48:00] <w|zzy> what was that ^
[01:50:30] <R0b0t1> w|zzy, GuShH hates arduino.
[01:50:48] <R0b0t1> And I can't bug him in ##electronics anymore so I upset the peace and quiet here.
[01:50:57] <w|zzy> hmmph
[02:35:02] <R0b0t1> Does "DDRB ^= _BV(0);" not work? It doesn't seem to be toggling the pin in/out state for me.
[02:51:14] <Xark> R0b0t1: DDRB is a R/W register, so it should work. Why aren't you setting it explicitly to input or output though? I can't think why toggling it would make sense... :)
[03:02:42] <tomatto> what is size of float or double?
[03:05:25] <Casper> iirc, 32 and 64
[03:05:46] <Casper> but I'm not sure
[03:10:10] <jaeckel> 32 and 64
[03:23:53] <tomatto> Casper: is possible to reduce it to 16bit?
[03:24:28] <tomatto> 8bit and 8bit
[03:24:55] <tomatto> jaeckel: ^^^ ?
[03:28:56] <jaeckel> uhm
[03:29:21] <jaeckel> do you really need flating numbers?
[03:29:34] <jaeckel> otherwise you could use a fixed point notation for your math
[03:30:04] <jaeckel> s/flating/floating
[03:38:41] <R0b0t1> Xark: Sorry, zoned out - reason I am not explicitly setting it is because I set it to a known state before the xor happens, so I know what it will end up as.
[03:38:49] <R0b0t1> Or rather I need it to end up explicitly as the opposite.
[03:39:08] <R0b0t1> So hm, wonder why this doesn't seem to work.
[03:39:31] <R0b0t1> (and it saves quite a bit of code to do it this way)
[03:40:50] <grummund> does it really save any code when you consider that gcc will do separate read-modify-write instructions?
[03:40:54] <Xark> Hmm, so that would do IN, EOR, OUT. I don't think you save anything vs IN, AND, OUT then IN, OR, OUT (e.g.).
[03:41:57] <grummund> in any case it *should* work
[03:42:54] <grummund> Xark: gcc will optimise "IN, AND, OUT" into a single instruction
[03:43:03] <grummund> it can't do that for XOR on DDR
[03:43:08] <theBear> and that's why gcc doesn't get laid more often
[03:44:34] <Xark> grummund: When it ia single bit I assume? Good point. So it is even more efficient not to EOR.
[03:44:55] <Xark> is*
[03:45:13] <grummund> yep assuming single bit
[03:45:28] <R0b0t1> Well, the xor version saved me 3 bytes
[03:45:34] <R0b0t1> which is kind of wtf
[03:46:42] <Xark> If the bit number were not a constant, EOR could make some sense I suppose (and even save code).
[03:48:40] <R0b0t1> oh fuck I am an idiot
[03:48:57] <R0b0t1> I forgot I was using biphasal coding and my test tx was 0xAA...
[03:49:44] <Xark> That could explain some things. :)
[03:49:47] <R0b0t1> Why are half my bugs stuff like this, I mean c'mon.
[03:49:52] <R0b0t1> Oh well, thanks.
[03:50:11] <R0b0t1> And it is strange that I do only save TWO bytes from omitting the repeated code that the DDRB xor saves me
[03:50:27] <Xark> That is often how it goes, the "stupid obvious stuff" is so obvious it hides in plain sight. ;)
[03:51:41] <grummund> maybe focus less on optimisation tricks and write straight forward code? :p
[03:53:20] <Xark> Or you could disassemble it and see exactly what it is doing (if you are caring about a few bytes). :)
[03:53:28] <R0b0t1> Well I would consider this fairly straight forward :) Straight forward enough I thought it was beyond the impossible it was going wrong
[03:54:01] <R0b0t1> Well right now I am on a tiny85 - I hope to move this to a tiny13 at some point for cost, even though the savings might not end up mattering that much
[03:54:15] <grummund> you used a "trick" and then doubted it when things didn't work
[03:54:54] <R0b0t1> grummund, I only doubted it because it was the only thing I had done differently from before. I figured there might have been some random shenanigans going on.
[03:55:12] <R0b0t1> When I first started I thought 16k program memory was small, now 8k is huge...
[03:55:21] <Casper> hehe
[03:55:31] <R0b0t1> Hell 4k is pretty big
[03:55:53] <Casper> and then you realise that the programmers on windblows are lazy as hell
[03:56:00] <Casper> and don'T know how to code anymore
[03:56:00] <grummund> hmm, but had you not done it "differently" then you would have realised the problem sooner...
[03:56:15] <Xark> Casper: Layers on wrappers on layers on buffers on thunks. :)
[03:58:16] <R0b0t1> grummund: Well, I rewrote it the "straightforward" way, saw the output, wtf'ed, and then chanced to look at the value I was actually sending. And realized because I was sending 0b10101010 biphasal it looked like 1/2 the frequency
[03:58:27] <theBear> hehe
[03:58:31] <R0b0t1> and then cheered because it had worked in the first place...
[03:59:15] <Casper> ever since I saw fr-08 I can't help but think that all the programs are badly written
[04:03:07] <R0b0t1> Casper: :o
[04:07:54] <Xark> Casper: Good point. If people would code like that we could have AVR Studio procedurally generated using a 123KB executable (allowing a bit of bloat). :)
[04:10:07] <Casper> for those who don't know fr-08, it's a 3d demo with 7 scenes, few basic animation, 15 minutes of music, camera movement, some effects and more, all in 63.5k. It also contain like 12k of text once decompressed
[04:16:43] <theBear> sounds like yer standard 90's 'demo'
[04:16:48] * R0b0t1 's code is so sexy.
[04:17:00] * theBear is too sexy for his pants
[04:18:21] <PlastyGrove> Casper: fr-08? Is that the one by sevenheaven?
[04:19:09] <Casper> no, the product, by a german group
[04:24:25] <PlastyGrove> Casper: Sounds similar to teh one by heaven7 - about 64kb
[04:24:26] <PlastyGrove> http://pouet.net/prod.php?which=5
[05:53:09] <tomatto> jaeckel: how can i do/declare/use fixed point notation?
[06:33:12] <jaeckel> tomatto: you have to do it yourself
[06:35:32] <tomatto> jaeckel: but how
[06:36:25] <jaeckel> well first you need to know how accurate your result has to be
[06:36:56] <jaeckel> and what your possible range of values is
[06:39:53] <tomatto> i want max value 2000.99
[06:41:29] <tomatto> and min value 0.00
[06:46:20] <jaeckel> ok
[06:46:39] <jaeckel> so you would require 200000 values
[06:46:57] <jaeckel> 18 bit
[06:48:07] <jaeckel> you really need a resolution of 0.01?
[06:48:51] <tomatto> i thing 0.1 or 0.05 would be ok
[06:53:33] <jaeckel> you have your floating point value and round it to 0.1 accuracy
[06:54:07] <jaeckel> multiply it by ten and store this in an unsigned 16bit integer
[06:54:24] <jaeckel> :)
[06:55:20] <tomatto> what is the best and code optimized way to round it?
[06:55:28] <tomatto> in C
[06:56:29] <jaeckel> ask google
[06:56:45] <jaeckel> floor()? ceil()? roundf()?
[06:56:55] <jaeckel> depends on your stdlib
[06:57:19] <jaeckel> http://stackoverflow.com/questions/497018/is-there-a-function-to-round-a-float-in-c-or-do-i-need-to-write-my-own
[06:59:23] <tomatto> i have avr-gcc
[07:15:34] <k-man> where is that site that lists the sort of overview of each avr chip?
[07:16:07] <specing> k-man: you mean the parametric search or ...?
[07:18:46] <k-man> i have an attiny25, i just can't remember anything about what it can do
[07:19:26] <specing> 1st page of the datasheet? :P
[07:19:56] <k-man> ah, good idea
[07:28:05] <jaeckel> tomatto: where does the float come from?
[07:29:16] <OndraSter> may I suggest using 32bit (un
[07:29:18] <k-man> hmm. avrdude does not seem to know about the attiny85
[07:29:20] <OndraSter> whoops
[07:29:26] <OndraSter> may I suggest using 32bit (un)signed numbers rather 16bit floating ones?
[07:29:57] <specing> k-man: t85?
[07:31:33] <RikusW> its snowing over here.
[07:32:47] <Steffanx> Yay
[07:33:01] <Steffanx> RikusW the snowman
[07:33:44] <k-man> ah it does, thanks
[07:34:14] <RikusW> Its not white yet, only wet
[07:34:24] <RikusW> slightly wet
[07:34:39] <RikusW> but in other parts of the country its 10 to 40cm thick
[07:36:32] <OndraSter> <RikusW> Its not white yet, only wet
[07:36:35] <OndraSter> is it yellow?
[07:37:50] <k-man> is there a sort of boilerplate .c file to get you started with an avr?
[07:41:47] <RikusW> OndraSter: it melts too fast, starting to get white noew
[07:41:50] <RikusW> *now
[07:43:10] <RikusW> lets hope the power stays on....
[07:44:22] <specing> lol
[07:45:18] <RikusW> last year the power lines broke, twice.... was without power for a week :S
[07:50:40] * specing watches RikusW get disconnected ;P
[07:59:44] <OndraSter> I have found users' manual from old 386SX board we used to own
[07:59:46] <OndraSter> well
[07:59:50] <OndraSter> there is not just list of jumpers
[07:59:55] <OndraSter> and what is each memory bank and what it can take etc
[08:00:00] <specing> RikusW: seriously, what were you doing all that time without power?
[08:00:00] <OndraSter> but it contains full schematics to the board! :o
[08:00:27] <OndraSter> one could build a replica of the board rather quickly :P
[08:00:55] <specing> OndraSter: I guess that was before the chinese started copying everything?
[08:01:01] <OndraSter> probably
[08:01:12] <RikusW> specing: good question....
[08:01:31] <RikusW> in the evenings we turned on a petrol generator..
[08:01:33] <specing> the chinese are the reason that we can't have nice things :/
[08:02:22] <specing> *we*?
[08:02:34] <RikusW> kind of hard to live a week without power...
[08:03:09] <RikusW> specing: I live on a farm, fortunately not alone...
[08:03:38] <RikusW> OndraSter: I have the manual + schematics for 8088 :-P
[08:03:48] <RikusW> and the actual board too
[08:03:53] <OndraSter> :)
[08:05:04] <RikusW> AVRs are faster than the old 8088's !!!
[08:05:23] <specing> YARLY !!!?
[08:05:49] <RikusW> Just think if there were ram based AVRs back in 1980 :)
[08:06:10] <RikusW> then the current PC arch would've been AVR32 :)
[08:06:14] <OndraSter> heh
[08:06:16] <OndraSter> AVR64
[08:06:22] <OndraSter> more likely
[08:06:31] <OndraSter> I wish AVRs would allow execute from RAM :(
[08:06:37] <RikusW> AVR32 does
[08:06:40] <OndraSter> well AVR32
[08:06:43] <OndraSter> but I want AVR8 :D
[08:06:55] <RikusW> in fact you need to, to use breakpoints
[08:07:01] <RikusW> me too....
[08:07:13] <specing> AVR128!
[08:07:32] <RikusW> now specing is going overkill...
[08:07:50] <OndraSter> it is just a matter of time when x64 won't be enough
[08:07:54] <OndraSter> and we will have to invent x128
[08:07:58] <OndraSter> or switch to something more bearable
[08:08:07] <specing> AVR4294967296!
[08:08:11] <OndraSter> :)
[08:08:28] <OndraSter> the chip would contain just the PC register :D
[08:08:49] <specing> the switch to x64 was mostly because 32 wasn't able to address all the rams
[08:09:02] <RikusW> no it would be too small for the PC reg...
[08:09:06] <specing> with x64 you could have memory-mapped harddisks...
[08:09:54] <specing> It was either that or going for segment + offset like the x16 did
[08:10:40] <RikusW> seg+offs is UGLY
[08:11:43] <OndraSter> memory segmentation was outdated the time they switched to 32bits... long mode doesn't support segments at all
[08:12:23] <specing> yeah but they still support it
[08:12:28] <RikusW> there were 48bit addressing on some 32bit x86 cpu's...
[08:12:30] <specing> in real mode
[08:12:33] <OndraSter> only in 32bit modes
[08:12:45] <agile_aardvark> heh, real mode.
[08:12:53] <OndraSter> RikusW, 48bit? Currently 64bit CPUs have hardware of 48bit addressing I think
[08:12:53] <specing> 32bit cpus have 36 bit addressing
[08:12:56] <OndraSter> yes
[08:12:56] <specing> (PAE)
[08:12:57] <RikusW> but any one process still could only have 4GB
[08:12:57] <OndraSter> PAE :)
[08:13:08] <OndraSter> 2GB for the app itself actually
[08:13:13] <RikusW> ah yes 36 bit PAE
[08:13:21] <specing> RikusW: generally you don't have processes over 4GB...
[08:13:42] <OndraSter> long mode is superset of PAE
[08:13:47] <specing> it usually means you are doing something wrong ;P
[08:13:53] <RikusW> but some need more than 2G...
[08:13:53] <OndraSter> specing, VM :(
[08:14:12] <agile_aardvark> hm, i have processes running with 26gb usage :P
[08:14:19] <RikusW> though I can't imagine what for
[08:14:29] <OndraSter> I am currently using 14GB RAM
[08:14:35] <OndraSter> I have got only one VM running :)
[08:14:55] <agile_aardvark> here its 3d graphics/rendering eating up all that mem
[08:15:16] <OndraSter> also appearantly installing Windows XP in Hyper-V which is running inside VHD inside virtualized Windows 8 is quite slow
[08:15:29] <OndraSter> VIRTUALCEPTION!
[08:15:34] <theBear> this whole house doesn't have 14gb ram !
[08:15:46] <OndraSter> my computer has 16GB... I thought about upgrading to 24GB RAM soon
[08:15:52] <OndraSter> (8GB sticks weren't available back in the day)
[08:16:01] <OndraSter> here
[08:16:08] <OndraSter> in the US and UK they were already :(
[08:16:18] * RikusW though 640kb would be enough for anybody :-D
[08:16:22] <theBear> i don't think i got a computer that would take 8gb, let alone 16
[08:16:35] <OndraSter> RikusW, are you made in IBM? :P
[08:16:52] <RikusW> lol
[08:22:30] <Blecha> Good morning internets :D
[08:23:12] <OndraSter> well I got up 3 hours ago
[08:23:15] <OndraSter> so it is still morning
[08:24:53] <Blecha> I got up about 2 hours ago
[08:25:11] <Blecha> although im pretty sure I was asleep till about 10 minutes ago
[09:50:47] <tomatto> jaeckel: i don't know
[09:53:07] <tomatto> OndraSter: so i had wrongly set timer
[09:53:33] <OndraSter> which one?
[09:54:19] <tomatto> OndraSter: timer1, that which generates pwm output
[09:54:24] <OndraSter> ah
[09:54:26] <OndraSter> what was set wrong?
[09:54:49] <tomatto> i used Fast PWM, 8-bit
[09:55:02] <tomatto> i switch to PWM, Phase Correct, 8-bit
[09:55:18] <tomatto> and now it is ok and no starting and stoping timer is needed
[09:56:19] <tomatto> OndraSter: do you remember schematic from appnote i spoke yesterday?
[09:56:50] <OndraSter> not really
[09:58:32] <tomatto> R3 as the pull-up for p mosfet is very hot and i don't know how can i do something better instead of this resistor
[09:58:42] <OndraSter> bigger resistor
[09:59:17] <tomatto> something better to decrease current over it
[09:59:36] <OndraSter> what AN was it?
[09:59:51] <tomatto> 450
[10:00:04] <tomatto> to decrease power dissipation
[10:10:04] <OndraSter> many of you are maybe psychopats!
[10:10:04] <OndraSter> http://www.dailymail.co.uk/news/article-2184658/Is-joining-Facebook-sign-youre-psychopath-Some-employers-psychologists-say-suspicious.html
[10:10:05] <OndraSter> lol
[10:10:14] <OndraSter> (I know that here is quite a hatred against FB)
[10:22:34] <specing> OndraSter: indeed
[10:22:45] <specing> IRC is fairly sufficient
[10:49:12] <drobban> I love FB! =) I use it cover up my psychological problems.
[11:03:35] <specing> I dont think you can hide on FB
[11:03:49] <specing> the thing is a pure spy platform
[11:04:45] <specing> Ok so #avr:
[11:05:29] <specing> If you were to create a command line interpreter (a basic shell), how would you pass arguments to commands?
[11:07:45] <specing> option 1) command (argc, pointer to pointers to parameters) and '\0' delimit them?
[11:08:49] <specing> option 2) command (argc, pointer to pointers to parameters) and have the command figure out where it ends ( while(ptr[i] != ptr[i+1]) {} )
[11:09:51] <specing> option 3) command (argc, string), delimit with \0 and have the command figure it out again
[11:10:33] <specing> option 4) ???
[11:18:43] <OndraSter> option 5) profit
[11:19:13] <OndraSter> put them on stack and delimit them by \0 (if we are talking x86)
[11:20:33] <specing> we are talking AVR
[11:24:16] <OndraSter> well then, how many arguments are you thinking of?
[11:24:30] <OndraSter> 1.45m
[11:24:34] <OndraSter> *perfect height*
[11:26:03] <specing> <10
[11:26:29] <specing> afaik first UNIXes had ARG_MAX of 255 ;)
[11:27:04] <specing> 1.45m?
[11:27:32] <serp_> 1.45 meters of arguments
[11:28:11] <Landon> 1.45 meters of stack, not arguments
[11:28:32] <Landon> in pt14 font, wordwrapping left up to editor
[11:29:15] <serp_> makes sense
[11:30:01] <specing> ...
[11:30:44] <specing> I want this thing to run on an t2313 with 128b ram ;P
[11:31:05] <Landon> shouldn't need much paper then
[11:31:06] <Landon> :)
[11:40:15] <OndraSter> whoops, the 1.45m *perfect height* belonged to link which xchat refused to post
[11:40:17] <OndraSter> anyway
[11:40:22] <OndraSter> specing, same thing as for x86 then
[11:40:34] <OndraSter> specing, may I know what are you creating? :D
[11:40:36] <OndraSter> shell for AVR
[11:40:38] <OndraSter> that will launch Python?
[11:50:34] <specing> OndraSilly
[11:51:41] <specing> > lcd u 3 b -- sets HD44780's upper row character position 3 to 'b'?
[11:53:33] <specing> > port b -- prints current value of portB PINs
[11:54:02] <specing> > port b 0 1 -- sets PORTB0 high
[11:54:29] <OndraSter> ah
[11:54:54] <specing> > mem 6a ff -- sets memory location 0x6a contents 0xff
[11:55:12] <OndraSter> I had binary version of this long time ago :P
[11:55:14] <OndraSter> written in asm
[11:55:19] <OndraSter> and then even ASCII version of it!
[11:55:27] <specing> Of a command interpreter?
[11:55:48] <OndraSter> well, it had few commands
[11:55:52] <OndraSter> read, write
[11:56:02] <OndraSter> and all the port/pin/.. regs were just mem locations
[11:57:37] <specing> struct command { char name[4]; command_form func;
[11:57:37] <specing> } commands[] = { { "NOP", [] (int argc) -> void { printf ("\nnop"); } }, { "lcd", lcd }
[11:57:38] <specing> };
[11:57:58] <specing> Currently testing the parser on x86
[11:58:40] <Blecha> Yay, looks like im actually going to have a small ammount of money ~$50 to spend on fun electronics!
[11:58:51] <OndraSter> wife allowed?
[11:59:08] <specing> s/allowed/did not spend for clothes/
[11:59:27] <Blecha> what should I get? so far my ideas are a cheap open-wrt router, some avrs to start programming on other than my arduino, a bus pirate, or some kind of dev board/programmer
[11:59:45] <Blecha> naw, just finally getting caught up on bills
[12:00:00] <Blecha> would be more responsible to pay off some debt early but pfff
[12:03:44] <OndraSter> anyway, I managed to get a toaster oven for $13 (10.4€) incl. shipping
[12:03:47] <OndraSter> unused even
[12:03:55] <OndraSter> so PCBs won't smell like a bread!
[12:04:05] <OndraSter> should ship tomorrow
[12:04:11] <OndraSter> => weekend = planning the mod!
[12:37:06] <Blecha> OdraSter I want a heat gun and O-scope and copper clad and etchant and a bus pirate
[12:37:42] <Blecha> and a magic bag of descrete components that always gives me the exact value i need
[12:38:34] <OndraSter> didn't you say you have fifty bucks?
[12:38:40] <Blecha> yeah...
[12:38:44] <OndraSter> I paid $70 for my station
[12:38:47] <OndraSter> hotair + soldering gun
[12:38:53] <OndraSter> iron*
[12:39:07] <Blecha> I need a good iron also, but thats none of that stuff is really fun to play with
[12:39:19] <Blecha> I want a project that will keep me busy playing around for a couple weeks
[12:39:34] <Blecha> and im learning C/avr lib right now
[12:39:48] <Blecha> So thats kind of a factor
[12:40:12] <Blecha> I think I can get that openwrt router and some chips to start flashing.
[12:40:55] <Blecha> Then make myself a little wifi enabled portable prototyping bench
[12:48:25] <serp_> OndraSter: is it any good?
[12:48:27] <serp_> brand etc?
[12:49:17] <OndraSter> no idea, it is from some guy that sells them in Poland and CZE and SVK
[12:49:20] <OndraSter> and they are made in china
[12:49:28] <OndraSter> I never found it on the internet again except his "store"
[12:50:35] <Blecha> My problem is forgetting to turn it off and not cleaning it often enough...
[12:50:58] <serp_> hm
[12:51:02] <Blecha> I need to get one of those steel scrubber pads and put it in my stand
[12:51:24] <Blecha> but im still using a cheapo radioshack iron, for now it doesn't matter
[12:51:26] <serp_> do it, theyre awesome
[12:51:35] <Jordan_U> I would like to write my program such that I can change what port and pin corresponds to a given input (like a start button) simply by changing #define statements. For most things this is simple and clean, but for control of individual pins, like when setting START_BUTTON_PORT.PIN0CTRL, I can't think of a clean way to do it. Would I really need a switch statement to replace PIN0CTRL with something based on a #define? Example #define and code: ...
[12:51:39] <Blecha> Ive heard its about 50 times better than a sponge
[12:51:41] <Jordan_U> ...
http://paste.debian.net/182584/
[12:53:09] <serp_> is that arduino code?
[12:54:03] <Jordan_U> serp_: No, straight AVR C.
[12:54:27] <serp_> why can you do PORTD.PIN0CTRL ?
[12:55:06] <serp_> PORTD isnt supposed to be a struct
[12:56:03] <Jordan_U> serp_: That's straight from ATMEL's documentation, I'm looking for a reference now.
[12:56:32] <serp_> hm interesting
[12:56:34] <serp_> ignore me
[12:56:54] <OndraSter> Jordan_U, Xmega
[12:56:55] <OndraSter> ?
[12:57:01] <Jordan_U> OndraSter: Yes.
[12:57:31] <OndraSter> yeah
[12:57:40] <OndraSter> all the peripherals are structs there :)
[12:57:49] <Jordan_U> OndraSter: Does that mean that on tiny and mega chips they aren't structs?
[12:57:58] <OndraSter> they are not defined as structs
[12:59:32] <Jordan_U> OndraSter: What is the interface for peripherals with mega and tiny?
[12:59:46] <OndraSter> PORTD = something
[12:59:50] <OndraSter> DDRD = something
[13:06:08] <Jordan_U> OndraSter: Is there a least common denominator interface so that I could write code which could be used on at{tiny,mega,xmega} ? I'm writing code for a box which controls a pump, and the general logic (should the pump be turned on or not) doesn't require any speed or fancy features worth mentioning and could easily run on a tiny, but some versions of the control box will need to interface with CANBUS and do BLDC motor control which (as I understand it) ...
[13:06:14] <Jordan_U> ... would require us to use a mega or xmega chip. I'd like to keep that base logic code as common as possible.
[13:07:08] <karlp> make the user provide some function pointers for actually toggling pins, or doing a spi transfer
[13:07:27] <karlp> and provide some readymade backends for mega/tiny that have different spi interfaces, etc.
[13:08:58] <Blecha> Any good pages on making a target board with an XTAL?
[13:09:24] <Blecha> don't need lots of fancy stuff, just want to make a simple target board with a reliable clock for USART
[13:11:00] <OndraSter> Blecha, put the xtal as close to the chip as possible
[13:11:05] <OndraSter> including the loading cap
[13:11:05] <OndraSter> s
[13:11:15] <OndraSter> and put ground plane below the xtal
[13:11:17] <OndraSter> on both sides of the board
[13:11:24] <OndraSter> (if you do doublesided board ofc)
[13:11:43] <OndraSter> Jordan_U, as karlp said... Or you can do simple #ifdef #else #endif
[13:11:48] <OndraSter> always for mega/xmega/tiny
[13:14:12] <karlp> hmm, I was going to try and link some example code, but I don't seem to have pushed the right things to the right places
[13:20:55] <Blecha> OndraSter im too much of a noob for that answer to help sorry.
[13:21:25] <Blecha> I'm looking for an explanation on how the XTAL works and what it needs to drive the uC
[13:27:04] <jadew> Blecha, it doesn't need anything
[13:27:32] <Blecha> Most schematics show some caps
[13:27:57] <jadew> it's a simple cristal and the uC makes it oscillate
[13:29:33] <jadew> the caps are on the power lines, they're decoupling caps. they're needed to make sure the uC has enough current when it's doing stuff
[13:31:00] <jadew> you can deffinitely go with out them, but it's good practice to have them in there, they help reduce the noise in the circuit
[13:31:04] <karlp> I think he means the load caps on the crystal
[13:31:17] <jadew> ah, you don't need those
[13:31:33] <karlp> heheh.....
[13:31:35] <agile_aardvark> ?
[13:32:01] <karlp> if you're using a crystal because you want stable clcoking, you really should consider using proper load caps
[13:32:07] <karlp> otherwise, just use the internal RC oscillator
[13:32:16] <karlp> as clearly, crystals aren't anything you really need
[13:32:42] <jadew> well, he said he wants them for USART
[13:32:48] <agile_aardvark> or use crystals if you want a clock speed the RC cant supply :P
[13:32:52] <jadew> and you can't really do that with out a crystal
[13:32:59] <agile_aardvark> like 20mhz
[13:33:15] <karlp> I've got a pile of devices on my desk operating a uart with the internal RC
[13:33:31] <karlp> but if you're _going_ to use a crystal, you _should_ use the load caps
[13:33:36] <jadew> I'm sure you can do it, it can even self calibrate, but still
[13:33:52] <karlp> putting a crystal on and then not using it's load caps is kinda halfarsed.
[13:34:08] <karlp> like, you don't _need_ power bypass caps at all,
[13:34:14] <karlp> but you're going to have a bad day eventually
[13:34:25] <agile_aardvark> it sometimes works for 32khz crystals as the pins and traces have enough capacitance
[13:35:00] <agile_aardvark> well, more often than not it does work for those.
[13:38:51] <jadew> I never had problems
[13:39:10] <Blecha> See thats the stuff im curious about
[13:39:33] <jadew> ah, wait
[13:39:37] <Blecha> I want to make some simple boards that can do serial, and are stable and safe
[13:39:57] <jadew> I always use the 3 legged kind crystal
[13:40:02] <jadew> I think those ones already have caps in there
[13:40:03] <Blecha> Just the minimum needed for a board
[13:40:23] <Blecha> There are plan XTALs and then the oscilators
[13:40:40] <Blecha> the oscillators already have everything to generate a steady clock
[13:41:24] <Blecha> I know that much and ive worked with electronics enough to know the basics of that stuff but im trying to figure out what i need to order to make a handful of safe target boards
[13:41:58] <Blecha> so far it seems the xtal, some decoupling caps, and maybe loading caps?
[13:42:14] <GuShH> Blecha: you mean ceramic resonators?
[13:42:30] <GuShH> Blecha: the avr doesn't have internal selectable loading caps?
[13:42:57] <GuShH> resonators are crap if you want proper stability.
[13:43:33] <Blecha> no this is all external stuff im talking about
[13:43:38] <GuShH> either go with a xtal oscillator module (stand-alone) or if derating and drifting is an issue use a trimmer in series with your loaders
[13:43:50] <Blecha> also im a noob so any links to read would help
[13:44:05] <GuShH> Blecha: And I'm asking if you can make without it, I'm not into AVRs but modern uCs have internal load capacitors you can select by code.
[13:44:19] <Blecha> ah idk about any of that
[13:44:38] <GuShH> plus you have to take into consideration the parasitic capacitance of the leads and your tracks, if you want to be serious about this.
[13:44:54] <GuShH> the former is shown in the datasheet, the latter you calculate based on your pcb.
[13:45:05] <Blecha> not super serious right now
[13:45:36] <Blecha> its still just for me to play around with but reliable serial is kinda important so if i can order a bunch of mircros, xtals, and caps at once it would be cool
[13:45:39] <GuShH> read the app notes on using an external clock source then
[13:45:56] <Blecha> Not even going into the parastici cpacitance as its very likely to be made on a breadboard
[13:46:05] <GuShH> well, that has a lot more parasitics.
[13:46:10] <Blecha> exactly
[13:46:13] <GuShH> we're talking upward to 20pF per node
[13:46:30] <Blecha> yeah, I once tried to make a 555 radio on a breadboard
[13:46:36] <GuShH> typically 5-10
[13:46:42] <Blecha> the stray capacitance was murder
[13:46:44] <GuShH> AM? 555 cuts out at a few 100 KHz
[13:47:25] <Blecha> yeah, it was super simple
[13:47:28] <GuShH> it's only usable up to 250-300KHz and then it becomes crap, there are alternatives such as the CMOS that can easily go to 2MHz though.
[13:47:29] <Blecha> but I fail at analog stuff
[13:47:45] <GuShH> you set yourself up for failure by saying you fail at something.
[13:48:13] <Blecha> whats this app page you are talking about? "app notes on using an external clock source"
[13:48:26] <jadew> you can do serial just fine with a cermic resonator (aparently that's how this things that I'm using are called)
[13:48:36] <Blecha> and I can do some analog stuff but its definately lagging behind
[13:48:49] <GuShH> Blecha: datasheet
[13:48:57] <Blecha> oh kk
[13:49:07] <GuShH> jadew: of course you can, you could also inject yourself with caffeine and pulse it by hand.
[13:49:12] <GuShH> doesn't mean it's the best way though
[13:49:46] <GuShH> once you start looking into temperature coefficients and overall stability of your parts...
[13:49:48] <jadew> I'm sure the other crystals are better, but it seems easier to switch them around on a target board than a crystal
[13:50:03] <Blecha> also while a couple people are talking
[13:50:11] <GuShH> they're ok for some applications, specially because they are cheaper.
[13:50:12] <Blecha> Do you do most your stuff in C or ASM?
[13:50:28] <jadew> c
[13:50:33] <GuShH> Blecha: you'd go the ASM route when hand-optimizing
[13:50:46] <jadew> and you have high chances of failing short
[13:50:54] <jadew> since the compiler can optimize better than you do
[13:51:00] <GuShH> not always.
[13:51:04] <GuShH> specially size wise.
[13:51:33] <GuShH> that's a common misconception fed by the newmedia faggots really "the compiler is better than you" only applicable if you are a newbie and haven't been coding for over 10 years.
[13:52:32] <GuShH> generally speaking you can and you will beat any compiler, because you are not hard-coded and you can see things a piece of plain code just can't, no matter how many if statements you add to it.
[13:52:37] <jadew> well, I've been doing asm in the past and I can tell by looking at the optimized code, that comes out of the compiler, that it's hard to beat that
[13:53:12] <GuShH> also when dealing with legacy hardware AND programmers, you have to stick with ASM.
[13:53:13] <jadew> GuShH, that's obvious, but generally speaking, the compiler is better at it
[13:54:06] <Blecha> I am a newbie...
[13:54:09] <GuShH> you'd only write entirely in assembly if you are a masochist or if you enjoy it. In some cases it can even get you job security, believe it or not...
[13:54:36] <GuShH> (yes, some programmers are in it for the money and they don't give a shit about the common goal)
[13:55:03] <GuShH> Blecha: then no need to worry about it, specially when you could well fall into premature optimization land :p
[13:55:27] <GuShH> Some people never came back...
[13:55:32] * GuShH takes a minute of silence
[13:55:41] <Blecha> Im going to optimize the shit out of this hello world!
[13:56:25] <GuShH> hell yeah!
[13:56:46] <jadew> you can replace hello with hi
[13:56:49] <jadew> 3 bytes saved
[13:56:52] <GuShH> lol
[13:57:34] <Blecha> Nice
[13:58:04] <GuShH> if you save enough bytes you can build yourself a backdoor too.
[13:59:12] <GuShH> so next time you are short in moneis you can blackmail them.
[13:59:17] * GuShH nods
[14:00:50] <jadew> you'd have to build a backdoor that works trough the power grid, because most stuff built with AVRs are usually stand alone gadgets
[14:01:16] <Blecha> With high voltage programming you can reset lock bits can't you?
[14:01:23] <OndraSter> whole chip
[14:01:30] <GuShH> jadew: hey that's not a challenge
[14:01:55] <jadew> GuShH, been done before?
[14:01:58] <GuShH> jadew: however if battery operated and with no wireless communication...
[14:02:09] <Blecha> Yeah, thats how some of those home automation systems work
[14:02:17] <jadew> haha GuShH
[14:02:22] <Blecha> with the lights and stuff X11 is what its called i think?
[14:02:34] <GuShH> jadew: sure, that's also how public lighting is controlled in many places, a pulse is mechanically generated at a given frequency and fed into mains, then the nodes listen and react.
[14:02:37] <Blecha> its called a *physical* back door
[14:02:53] * GuShH ponders blue smoke signals
[14:03:14] <GuShH> Blecha: cue the cheesy porn music?
[14:04:02] <Blecha> ...
[14:04:09] <GuShH> o.o
[14:04:29] * GuShH hides behind amee2k's cone
[14:07:06] <jadew> Blecha, a little something I learned by making my target boards, make sure they're protected if you reverse vcc and ground
[14:07:22] <OndraSter> so called idiot proof
[14:07:38] <jadew> and put a lot of ground pins / plugs wherever you have data pins
[14:07:50] <Blecha> jadew any schematics?
[14:08:08] <OndraSter> I thought about adding protection to the eDice I am working on
[14:08:15] <jadew> let me see if I can find them
[14:08:15] <OndraSter> (still undecided whether to use 7 or 12 LEDs)
[14:12:21] <Blecha> thanks jadew :D
[14:12:51] <Blecha> OndraSter binary dice are the coolest but I have non computer nerd friends who play DND with me
[14:13:19] <jadew> Blecha, they all have problems in them
[14:13:23] <jadew> I'm a noob myself :P
[14:14:43] <Blecha> Im thinking about just getting this
http://evilmadscience.com/productsmenu/tinykitlist/74
[14:14:56] <Blecha> but thats not even with an xtal
[14:15:27] <jadew> you should know it doesn't come with the zif socket
[14:15:39] <jadew> those things are kinda expensive so $3 doesn't cover that
[14:15:48] <Blecha> yeah
[14:16:03] <Blecha> really i just want to order some xtals, caps, and the AVRs themselves
[14:16:16] <Blecha> then breadboard/perfboard my stuff for now
[14:16:24] <jadew> I'll get back to you with those schematics a bit later, I don't have time to dig them up
[14:16:31] <Blecha> Thats cool
[14:18:23] <specing> Blecha: no
[14:18:33] <specing> get a protoboard
[14:19:11] <specing> and if you fear breaking the fragile avr pins, get a normal dip socket
[14:24:26] <Blecha> Yeah I have some sockets lying around
[14:24:32] <Blecha> not sure what chip im getting first
[14:24:45] <Blecha> might be boring and just go with the ATMega328
[14:25:12] <OndraSter> Blecha, I didn't say anything about binary dice
[14:25:25] <OndraSter> 1 - 6 = as regular dice
[14:25:29] <OndraSter> 7 - 12 = extended regular dice
[14:25:30] <OndraSter> 1
[14:25:33] <OndraSter> 13+ = ASCII :)
[14:25:40] <OndraSter> (always each number half a second shown)
[14:25:47] <OndraSter> or a second
[14:25:48] <OndraSter> or whatever
[14:26:36] <jadew> Blecha, I usually build a board for every chip, here's one of my target boards:
http://imagebin.org/223679
[14:28:14] <Blecha> OndraSter why 7 leds then?
[14:28:21] <OndraSter> well 7 or 12
[14:28:21] <Blecha> dont you mean 6?
[14:28:24] <OndraSter> 7 = regular dice
[14:28:24] <OndraSter> no
[14:28:25] <OndraSter> count again :)
[14:28:35] <Blecha> 1,2,3,4,5,6,7
[14:28:46] <OndraSter> yes
[14:28:48] <Blecha> 7 sided dice?
[14:28:49] <OndraSter> now look at regular dice
[14:28:54] <OndraSter> how many points do you see?
[14:28:56] <OndraSter> DIFFERENT points
[14:29:11] <Blecha> 8
[14:29:18] <OndraSter> I see 7
[14:29:28] <OndraSter> - -
[14:29:30] <OndraSter> - - -
[14:29:32] <OndraSter> - -
[14:35:26] <Splats> This ^
[14:36:08] <Blecha> ... not sure what happened to my internets
[14:36:16] <OndraSter> <OndraSter> I see 7
[14:36:16] <OndraSter> <OndraSter> - -
[14:36:16] <OndraSter> <OndraSter> - - -
[14:36:16] <OndraSter> <OndraSter> - -
[14:36:54] <Blecha> ...You meant dots
[14:36:56] <Blecha> I see
[14:37:01] <OndraSter> ye
[14:37:04] <Blecha> Now you are making sense
[14:37:18] <Blecha> I thought you mean sides for some reason... my brain wasn't working right
[14:37:59] <Blecha> You could do it with 3 leds :P
[14:38:05] <Blecha> binary like a boss
[14:38:16] <kline> Blecha: the MIT method
[14:38:33] <OndraSter> because people are used to binary dices
[14:39:12] <Blecha> I think my first real project will be a binary/decimal alarm clock, that forces me to do progressively harder math before i can hit snooze
[14:39:15] <kline> OndraSter: its not too hard
[14:40:12] <OndraSter> well yes
[14:40:19] <OndraSter> but some players just look at the dice
[14:40:38] <kline> most people who play games with dice can add 4, 2 and 1
[14:40:48] <OndraSter> takes time
[14:42:02] <Blecha> you could save yourself pins and have it beep the designated number
[14:42:17] <OndraSter> well
[14:42:20] <OndraSter> I'd use tiny4
[14:42:26] <Blecha> then you could have it beep the number in morse code that would be translated to hexidecimal!
[14:42:28] <OndraSter> but that bloody dragon doesn't run TPI
[14:42:50] <Blecha> Then you could get to some really big numbers :D
[14:43:04] <OndraSter> 6 pins
[14:43:05] <OndraSter> 4 IOs
[14:43:09] <OndraSter> 1 for button
[14:43:15] <OndraSter> 3 IOs => 6 LEDs :)
[14:43:30] <Blecha> lol
[14:43:52] <Blecha> you cant even multiplex much with 3 pins...
[14:44:03] <Blecha> er ... at all
[14:44:04] <OndraSter> 4 IOs => 12 LEDs
[14:44:05] <Splats> OndraSter: Devil's advocate: Binary dice can be read as fast as real dice, eveyone is used to real dice so they just pattern match to a number-- Do you actually count the dots? Or just glipmse and know the value
[14:44:08] <OndraSter> 5 IOs => 20 LEDs
[14:44:19] <OndraSter> Splats, glimpse
[14:44:26] <OndraSter> and people are used to regular |-|
[14:44:27] <Blecha> How does 3 => 6?
[14:44:28] <OndraSter> matrix
[14:44:34] <OndraSter> Blecha, charlieplexing
[14:44:47] <Blecha> ah, never messed with charlieplexing
[14:44:51] <Blecha> only multiplexing
[14:44:59] <Blecha> It works for 3 pins?
[14:45:05] <OndraSter> sure
[14:45:17] <OndraSter> it works for any number of pins
[14:45:51] <Blecha> Oh hey, what do you know
[14:46:12] <Splats> multiplex would need as little as 2, but 3 for reliability
[14:46:16] <Blecha> 2 pins can control 2 leds!
[14:46:20] <Blecha> thats impressive :P
[14:46:26] <OndraSter> 1 pin can control 2 LEDs
[14:46:39] <Blecha> ah thats right
[14:46:47] <Blecha> so 2 would be 4?
[14:46:48] <Splats> CLK + Data, optional Reset to ensure starting from 0
[14:47:03] <OndraSter> no, with 2 with charlieplexing you can do 2
[14:47:04] <Blecha> no nvm
[14:47:10] <OndraSter> with 2 pins you can do in theory 4
[14:47:13] <OndraSter> (in reality as well)
[14:47:16] <OndraSter> but not with charlieplexing
[14:49:09] <Splats> Charlie plex can be thought of as a triangle - think cup stacking: Every pin added alows a new string of LEDs to the endge of the trinagle
[14:50:09] <Splats> each "edge" gets 2 leds per point
[14:51:36] <Splats> or cup as i mentioned
[14:53:16] <OndraSter> I lied, with one pin you can not drive two LEDs unless you use external transistors
[14:55:55] <tlvb> o/
[14:56:09] <OndraSter> \o
[14:56:34] <specing> OndraSter: ofcourse you can
[14:56:52] <OndraSter> oh
[14:56:53] <OndraSter> yeah
[14:56:53] <specing> well no you cant
[14:56:55] <OndraSter> sorry
[14:56:56] <OndraSter> yes you ca
[14:56:57] <specing> hmm
[14:56:57] <OndraSter> n
[14:57:00] <OndraSter> :)
[14:57:11] <OndraSter> pin -- |<| -- vcc
[14:57:17] <OndraSter> pin -- |>| -- gnd
[14:57:26] <OndraSter> pin LO = led1
[14:57:30] <OndraSter> pin HI = led2
[14:57:32] <OndraSter> pin HiZ = none :)
[14:57:36] <specing> yeah but then it will leak from the vcc to the gnd one?
[14:58:06] <OndraSter> in case of HiZ?
[14:58:08] <OndraSter> hmm
[14:58:09] <specing> no, pin HiZ = both
[14:58:12] <tlvb> won't hiz mean that both are alight?
[14:58:17] <tlvb> drat, too slow
[14:58:18] <OndraSter> well
[14:58:23] <OndraSter> how do you think that charlieplexing works?
[14:58:28] <OndraSter> ;)
[14:58:31] <specing> magic
[14:58:34] <OndraSter> same way
[14:58:54] <OndraSter> if you have 2.6V as Vcc on the LED, 1.3V per LED won't do anything
[14:59:10] <tlvb> true, or one could introduce resistors maybe
[14:59:18] <OndraSter> well both will :)
[14:59:22] <OndraSter> unless you have 2.6V Vcc
[14:59:55] * amee2k grabs his cone and runs away, indecently exposing GuShH in the process
[15:00:07] <OndraSter> is GuShH yiffing?
[15:02:02] <specing> 160 instructions for the command line parser embedded into the serial RX routine...
[15:02:26] <OndraSter> :)
[15:02:28] <specing> must...optimize...
[15:02:38] * specing peeks into firmware.s
[15:03:17] <specing> OH GAWD I NO WANNA LIVE ON THIS PLANET ANYMORE
[15:03:26] <tlvb> hah
[15:03:44] <specing> Scumbag GCC pushes every single register to the stack -.-
[15:04:16] <tlvb> make naked isrs
[15:04:32] <specing> 48 bytes just for entry/exit
[15:04:46] <OndraSter> lol
[15:04:55] <OndraSter> yeah, gcc sucks in that
[15:05:01] <OndraSter> do you have -Os or whatever?
[15:05:08] <specing> 48 cycles...
[15:05:10] <specing> -O2!
[15:05:14] <OndraSter> LOL
[15:05:33] <specing> scratch = UDR;
[15:05:33] <specing> ca: 6c b1 in r22, 0x0c ; 12
[15:05:33] <specing> cc: 16 2f mov r17, r22
[15:05:46] <specing> Eh shall first maek a copy...
[15:05:47] <OndraSter> *oh god why*
[15:05:52] <tlvb> I think it does not always push all registers, I recently inspected a serial rx (or tx) routine expecting it to push all the things but I was mistaken
[15:06:39] <specing> if (we_annoyed_the_programmer_enaugh) flags &= ~(1 << PSUH_EVERYTHING);
[15:06:52] <OndraSter> enough*
[15:07:02] <specing> whatever.jpg
[15:07:07] <monobit> PSUH ...
[15:07:12] <OndraSter> more like
[15:07:15] <tlvb> CFLAGS += -DPSUH_EVERYTHING
[15:07:19] <asteve> one does not simply taco into mordor
[15:07:19] <specing> liike!
[15:07:20] <OndraSter> if(true) flags |= (1 << PUSH_EVERYTHING)
[15:07:46] <OndraSter> if(true) flags |= (1 << WASTE)
[15:08:00] <asteve> i think i'm going to start writing code with WASTE
[15:08:14] <OndraSter> in asm?
[15:08:35] <specing> d2: e0 91 6e 00 lds r30, 0x006E
[15:08:36] <specing> d6: f0 91 6f 00 lds r31, 0x006F
[15:08:36] <specing> da: 80 91 6c 00 lds r24, 0x006C
[15:08:36] <specing> de: 90 91 6d 00 lds r25, 0x006D
[15:08:38] <specing> OH GAWD
[15:08:42] <asteve> why stop at asm? I'm writing a ruby app right now, I'll use the constant WASTE for everything 1
[15:08:54] <OndraSter> specing, originally?
[15:08:59] <specing> wut?
[15:09:08] <tlvb> #define ; ;volatile asm("nop");
[15:09:08] <OndraSter> what was the original code that translated into this
[15:09:09] <specing> this is GCC in its BEST mood!
[15:09:36] <specing> oh, my humble command-line shell ...
[15:09:42] <tlvb> ...I wonder if that would work...
[15:09:53] <OndraSter> lol
[15:10:05] <Blecha> LOL just ran into my girlfriends programming/computer science professor
[15:10:24] <specing> where do you get these girls?
[15:10:31] <Blecha> Ive talked to him some and he knows a code but I never went to college
[15:10:33] <OndraSter> C:\porn
[15:10:55] <specing> ah right
[15:11:14] <Blecha> This is the first time ive talked without her around and he looks around all sly like and says, "You helped Athena with her final project didn't you?"
[15:11:33] <Blecha> "I know she did most of the work but I looked at the code, you must have helped her out"
[15:11:37] <OndraSter> heh
[15:11:39] <specing> Holy it actually uses indirect addresing!
[15:11:41] <specing> e8: 04 80 ldd r0, Z+4 ; 0x04
[15:11:41] <specing> ea: f5 81 ldd r31, Z+5 ; 0x05
[15:11:44] <Blecha> lol she is going to be so mad
[15:14:17] <specing> Haha
[15:14:33] <specing> Blecha: Srsly, where did you find this girlfriend of yours?
[15:14:59] <Blecha> We were both in a play
[15:15:05] <specing> Uhm
[15:15:07] <specing> play?
[15:15:11] <OndraSter> WoW
[15:15:12] <Blecha> acting
[15:15:16] <specing> WTF
[15:15:23] * specing ragequits life
[15:15:40] <Blecha> Then later she invited me to video game nights and stuff
[15:15:42] <specing> HOW DID TWO PROGRAMMERS GET STUCK IN A PLAY?
[15:15:57] <specing> IMPOSSIBURU!!!
[15:16:17] <Blecha> because it was something to do?
[15:16:30] <Blecha> I was only in one but she kept doing drama stuff for awhile
[15:16:46] <OndraSter> was there some sexy scene? :P
[15:17:53] <specing> Ok, so if we go back to the call semantics... how should I interface commands with the shell?
[15:18:04] <OndraSter> .exe on SD card
[15:18:14] <karlp> why again are you building a shell on a t2313?
[15:18:18] <Blecha> Not at all, I was a little boy and she was the family maid.
[15:18:23] <specing> pass them (u8 argc, char *null_seperated_args)?
[15:18:34] <specing> karlp: because Im insane
[15:18:36] <OndraSter> Blecha, family maid.. that's how it always starts§
[15:18:58] <tlvb> specing: why not parse the args in the parser?
[15:19:20] <tlvb> unless you have a variable amount of args
[15:19:24] <tlvb> for one function
[15:20:52] <Blecha> specing what will this shell do?
[15:21:02] <Blecha> are you going to make avr OS?
[15:21:53] <OndraSter> I thought about so
[15:21:58] <OndraSter> that would include managed language interpretert
[15:22:00] <OndraSter> interpreter
[15:22:03] <OndraSter> since there is no execute from RAM
[15:22:20] <OndraSter> or port .NET micro framework to AVR :P
[15:22:28] <tlvb> unless one implements a software instruction set running on top
[15:22:35] <OndraSter> exactly
[15:22:38] <specing> tlvb: I do parse them in the rx routine
[15:22:59] <specing> Im asking what would be the best way of passing them to the actual command?
[15:23:16] <OndraSter> atxmega128a1u + 16MB SDRAM
[15:23:18] <Blecha> Homing pidgeons
[15:23:19] <OndraSter> + SDHC card
[15:23:29] <OndraSter> + display(s) :)
[15:23:34] <OndraSter> with touchscreen
[15:23:38] <specing> Blecha: For the moment I just want something so I can experiment with writing to memory locations without having to reflash all the time
[15:23:48] <Blecha> ah gotcha
[15:23:52] <Blecha> sounds fun
[15:24:15] <Blecha> After i get more comfortable with C and ASM I want to play around with stuff like that
[15:24:22] <specing> Im thinking # lcd <row> <col> <char>
[15:24:39] <specing> and # mem <loc> [byte]
[15:24:50] <tlvb> specing: but do you need argc? are there cases where the parameter count would not be known beforehand?
[15:24:53] <specing> for starters
[15:25:04] <specing> tlvb: yep, all the time
[15:25:08] <OndraSter> specing,
[15:25:14] <OndraSter> oh
[15:25:19] <OndraSter> no byte = read
[15:25:19] <Blecha> man, im without internet at home right now
[15:25:27] <specing> tlvb: maybe I press a wrong key like enter?
[15:25:35] <Splats> pecing, supposedly you can flash blank 0xFF regions and selectively write back as long as you are going from 1 > 0 and not ht eother way
[15:25:45] <Blecha> and it took me like 15 min to get argv and argc working in a shell script because I couldn't google it
[15:25:49] <Blecha> I felt mentally retarded
[15:25:52] <Splats> so, you could maybe make a jump vector to go past "reqrites"
[15:26:08] <Blecha> had to go through the man pages for that shit
[15:26:14] <Splats> and reflash only when out of garbage space
[15:26:40] <specing> Splats: I'd still have to modify the .c file, compile and then do a whole ton of magic to do that
[15:27:10] <Splats> bleh
[15:27:10] <specing> I have to see how gcc does indirect func calls :)
[15:27:17] * specing opens firmware.s again
[15:28:22] <specing> I think I can get this thing below 100 bytes
[15:29:07] <tlvb> specing: I'm probably not getting everything then, I thought that the point of the parser would be to go from an unknown character stream, to a command + parameter 1,2,3... so I don't see what the parser would do if what is passed to the command function is the character stream unparsed, or is the so called parsing only newline detection?
[15:32:52] <Blecha> specing are you making a compiler :O
[15:32:56] <Blecha> That would be epic
[15:33:17] <Blecha> If a chip could compile and flash its own code :O
[15:33:43] <Blecha> They you just need an editor and you could do anything on the board itself
[15:33:50] <OndraSter> display
[15:33:51] <OndraSter> keyboard
[15:33:53] <OndraSter> ;)
[15:33:59] <OndraSter> some 320x480 display
[15:34:02] <OndraSter> PS/2 connector
[15:34:03] <OndraSter> BOOM
[15:34:07] <OndraSter> basic interpreter? :D
[15:34:32] <Blecha> Python!
[15:34:39] <Blecha> That already exists i think
[15:34:53] <Blecha> http://wiki.python.org/moin/PyMite
[15:35:39] <OndraSter> heh
[15:37:02] <OndraSter> I don't like Python
[15:37:09] <OndraSter> they haven't learned { } yet :D
[15:38:18] <tlvb> FORTH!
[15:39:03] <karlp> Blecha: forth/elua/pawn all do that already
[15:39:25] <karlp> with varying levels of overhead
[15:40:01] <Blecha> OndraSter didn't you admit yesterday thats all you know about python
[15:40:08] <OndraSter> yeah
[15:40:16] <OndraSter> and I know that there is django framework
[15:40:22] <karlp> Blecha: if it's not MS and C#, OndraSter doesn't like it, no matter what
[15:40:27] <OndraSter> aye
[15:40:31] <OndraSter> sounds about right :D
[15:40:35] <Blecha> ...
[15:40:42] <Blecha> wtf is wrong with you!
[15:40:47] <OndraSter> nothing
[15:41:21] <Blecha> I can't be your friend anymore :(
[15:41:59] <Blecha> C#?!
[15:42:10] <OndraSter> yes
[15:42:10] <OndraSter> C#
[15:42:12] <OndraSter> ftw.
[15:42:12] * Blecha wanders off grumbling about IDEs
[15:42:33] <tlvb> so, how about that emacs, nice os huh?
[15:42:35] <Splats> just VIM and STFU
[15:42:38] <karlp> there's nothing wrong with c#, it's OndraSter's claim that it is the one and only answer to all that is the problem
[15:42:46] <OndraSter> :P
[15:52:33] <tlvb> it is raining
[15:53:28] <specing> tlvb: yes, it does newline detection
[15:53:48] <specing> tlvb: It also does real-time first word parsing to lookup the command
[15:54:13] <specing> Blecha: no
[15:55:27] <specing> Im looking into optimizing the pointer comparisons associated with command lookup
[15:55:38] <specing> should save about 20 bytes
[15:57:08] <specing> if the command struct is sizeof(struct)-aligned, I can ldi r31 with a constant location and trim the LDS/STS
[15:58:14] <specing> and then Ima place everything into progmem.
[15:58:26] <specing> I only have 128 bytes SRAM on t2313
[15:59:33] <specing> I have to squeze in the 8+2 bytes for the tx ringbuffer and around 64 bytes for the rx linebuffer + about 10 control bytes
[15:59:39] <specing> ugh this is gonna be tight
[16:00:33] <specing> I certainly dont want it to overflow the stack on me
[16:03:53] <specing> Im going to do command(argc, null_delimited_string) thing and provide char *find_next_arg(char *) for commands to use
[16:04:03] <tlvb> specing: if you are not parsing the arguments to the functions then I guess that argc|v is the easiest solution, but perhaps not the best, because you will in every function taking more than one parameter repeat the same split-by-some-delimiter code
[16:04:28] <tlvb> instead of doing that in the parser
[16:04:38] <specing> } else {
[16:04:39] <specing> input_line[line_it] = ch;
[16:04:39] <specing> }
[16:04:39] <specing> ++ line_it;
[16:04:53] <specing> Not much is done for regular stuff beyond the command lookup ;P
[16:05:24] <tlvb> but if this is a problem I guess depends on the nature of the commands
[16:05:39] <specing> Im just going to do like I said
[16:05:54] <specing> the find_next_arg should be very lightweight
[16:06:18] <specing> think ldi Z, first_char
[16:06:35] <specing> ld rxx, Z+
[16:06:57] <specing> bne .-6
[16:07:59] <tlvb> neat
[16:08:19] <specing> ofcourse GCC is going to screw it up
[16:08:27] <specing> But I can always assemblify it
[16:11:43] <tlvb> for(char *Z=first_char; *(Z++)!='\0';);
[16:12:04] <specing> tlvb: &first_char :)
[16:12:42] <tlvb> ...no first_char is a pointer, I thought of it all along!!! /hides
[16:12:57] <tlvb> (or not)
[16:16:32] <specing> -26 bytes huehuehue
[16:17:02] <tlvb> huh?
[16:18:16] <specing> Im optimizing...
[16:18:19] <specing> pass #1...
[16:23:38] <Blecha> Ok everybody
[16:23:41] <Blecha> Time to go home
[16:23:48] <Blecha> bye :D
[16:23:51] <tlvb> o/
[16:27:35] <R0b0t1> specing: Program does what? And what are your current sizes and target sizes? :)
[16:32:09] <specing> R0b0t1: 320 bytes for the shell rx routine
[16:32:26] <specing> target: below 100 instructions (200 bytes)
[16:36:37] <R0b0t1> Damn.
[16:37:39] <specing> ?
[16:40:37] <specing> -34 bytes :P
[17:11:30] <specing> Ugh the bit_is_set macros in sfr_defs.h are retarded
[17:11:46] <specing> they assume you want to check if some bit in some IO reg is set
[17:12:03] <specing> while I want it to work transparently with that and registers
[17:25:27] <karlp> you don't think it's retarded to use macors targetting c users in your asm application?
[17:26:12] <specing> macors?
[17:26:22] <specing> macros?
[17:26:44] <specing> no. :)
[17:26:46] <buhman_> I was looking a few models of uC's on digikey, apparently in the atmega series, there's a few that do "EBI/EMI" instead of I2C (xx2-series apparently). Is that "better" than I2C? wikipedia gives a very lousy definition of EMI, and nothing relevant-looking for EBI
[17:27:14] <OndraSter> EBI is external bus interface
[17:27:20] <OndraSter> which is something absolutely different than TWI
[17:27:25] <specing> lol
[17:27:27] <OndraSter> EBI = on xmegas
[17:27:29] <OndraSter> EMI = on megas
[17:27:39] <OndraSter> EBI can also run SDRAMs
[17:27:41] <OndraSter> EMI only SRAMs
[17:27:45] <buhman_> O.o
[17:27:49] <buhman_> that sounds really cool
[17:27:58] <OndraSter> 16MB of external SDRAM on xmegas
[17:28:03] <OndraSter> 64kB on megas in SRAM
[17:28:29] <buhman_> aww; I was hoping the SRAM would be something more like >512kB
[17:28:45] <OndraSter> well 16MB SDRAM is much cheaper than 512kB SDRAM
[17:28:47] <OndraSter> err
[17:28:49] <OndraSter> well 16MB SDRAM is much cheaper than 512kB SRAM
[17:28:50] <OndraSter> by far
[17:29:02] <buhman_> but xmegas are expensive
[17:29:13] <specing> Do those xmegas have dram refresh circuitry?
[17:29:22] <specing> buhman_: false.
[17:29:23] <OndraSter> sure
[17:29:26] <OndraSter> buhman_, no
[17:29:27] <buhman_> still; sounds like a really fun project
[17:29:32] <OndraSter> well, that a1 series is a bit expensive
[17:29:38] <OndraSter> (let alone a1u)
[17:29:48] <buhman_> specing: erm, they have lots of pins
[17:29:50] <OndraSter> but you get a LOT for the buck
[17:29:51] <OndraSter> yes
[17:29:53] <buhman_> pins are scary
[17:29:56] <OndraSter> a1 with EBI has 100 pins
[17:30:00] <OndraSter> because you know, external memory
[17:30:04] <OndraSter> a3 has 64
[17:30:06] <OndraSter> a4 has 44
[17:30:14] <OndraSter> d4 has 32 maybe even, not sure.. maybe 44 as well
[17:30:24] <buhman_> wait, so is the s(d)ram *entirely* external on those?
[17:30:30] <OndraSter> no
[17:30:36] <OndraSter> there is still few kB internal
[17:30:39] <OndraSter> just as on regular xmega
[17:30:39] <buhman_> awesome
[17:31:08] <buhman_> that would be fairly awkward I think; having on-chip flash, but no ram
[17:31:11] <OndraSter> you can use still all those ports
[17:31:22] <OndraSter> if you don't use the EBI
[17:31:39] <OndraSter> ports are a b c d e f g h i j k I think
[17:31:39] <buhman_> but I assume it doesn't have the I2C circuitry then
[17:31:43] <OndraSter> it does
[17:31:52] <OndraSter> one per port on a3 series, not sure how about a1
[17:31:56] <OndraSter> but three TWIs at least as well
[17:32:00] <buhman_> I'm talking about like a mega162
[17:32:05] <OndraSter> oh
[17:32:07] <OndraSter> check datasheet
[17:32:22] <OndraSter> I used only mega128a
[17:32:38] <buhman_> is xx8 better than xx4?
[17:32:45] <buhman_> I've only played with xx4's
[17:32:45] <OndraSter> no idea
[17:32:50] <OndraSter> check datasheets :)
[17:32:53] <buhman_> heh
[17:36:14] <buhman_> I noticed there's both a atmega8515 and a at90s8515; are the two related?
[17:36:37] <OndraSter> aren't they from year 85? :D
[17:39:18] <buhman_> apparently the 8515 has emi, but the datasheet makes no mention of it
[17:39:48] <buhman_> same with the 162
[17:42:07] <buhman_> "Up to 64K Bytes Optional External Memory Space" is that it?
[17:42:15] <specing> Anyone knows of the top of their head how to make an alligned struct?
[17:42:40] <specing> *aligned
[17:42:57] <OndraSter> buhman_, yes
[17:43:07] <OndraSter> specing, aligned struct?
[17:43:10] <buhman_> oh, it spells it out; that's the problem
[17:43:15] <OndraSter> as in "instance" of struct?
[17:45:07] <specing> warning: 'alligned' attribute directive ignored
[17:45:10] <specing> I guess not...
[17:45:28] <specing> OndraSter: yes, I want to ldi the upper byte of a ptr and only load the lower one
[17:45:32] <specing> optimization :P
[17:45:43] <OndraSter> :D
[17:46:36] <specing> anyway, it seems to ignore my wishes
[17:46:49] <specing> http://a4.sphotos.ak.fbcdn.net/hphotos-ak-ash3/555506_173526919448317_489158378_n.jpg
[17:47:01] <OndraSter> did you just
[17:47:02] <OndraSter> post a photo
[17:47:05] <OndraSter> from facebook!
[17:47:56] <OndraSter> xkcd
[17:47:57] <OndraSter> ..
[17:48:32] <specing> I was given the link in some other channel
[17:51:43] <specing> Anyway DuckDuckGo doesent know anything about the above warning
[17:52:12] <specing> Oh wit
[17:52:18] <specing> I made a typo
[17:52:20] <specing> in code
[17:52:22] <specing> LOL
[17:53:51] <specing> Ok, bad idea
[17:54:27] <specing> GCC went nuts and increased .data size for 30 bytes
[17:55:12] <specing> I should put this into progmem though
[17:55:56] <specing> lpm takes 3 cycles... fair enaugh
[18:07:44] <specing> Getting the header to work on both AVR and x86 is quite challenging
[18:07:58] <specing> for debugging ofcourse
[18:08:07] <specing> (printf yay)
[18:08:18] <specing> I can be so inefficient on x86!
[18:09:58] <specing> 0.o it compiles
[18:10:51] <buhman_> I so it looks like I need 1) a atmega162 2) a 74AHC latch 3) a parallel? sram IC
[18:13:37] <OndraSter> buhman_, yes
[18:13:42] <OndraSter> regular HC works as well
[18:13:52] <OndraSter> without any timing delays
[18:14:15] <OndraSter> well, check the manufacturer's datasheet
[18:14:50] <OndraSter> I wish there was simple upgrade that when the top bits do not change it doesn't reload the latch
[18:15:00] <specing> I thought 64 bytes was enough for everyone!
[18:15:34] <buhman_> specing: well, there's no way I'm going to use more than the onboard 1K; I'm just wanting to give myself cool projects to do
[18:16:17] <OndraSter> I asked atmel about samples of the a1u chip as well as a3u and a4u
[18:16:22] <specing> command_ptr->func(); // execute program
[18:16:22] <specing> 31c: 04 80 ldd r0, Z+4 ; 0x04
[18:16:23] <specing> 31e: f5 81 ldd r31, Z+5 ; 0x05
[18:16:23] <specing> 320: e0 2d mov r30, r0
[18:16:23] <specing> 322: 09 95 icall
[18:16:28] <specing> gotcha
[18:16:29] <OndraSter> since I would like my project to expand to more chips
[18:16:41] <buhman_> OndraSter: O.o project?
[18:16:42] <OndraSter> wait
[18:16:45] <buhman_> someone actually has a project?
[18:16:46] <OndraSter> why first ldd
[18:16:47] <OndraSter> and then mov
[18:16:55] <OndraSter> buhman_, you are familiar with arduino I presume
[18:17:00] <buhman_> unfortunately
[18:17:07] <OndraSter> well, imagine arduino but with 256kB flash, real DAC, dual 8channel 2MSPS ADC
[18:17:12] <OndraSter> bazilion of IOs
[18:17:12] <specing> you do realize gcc is stupid, don't you?
[18:17:17] <OndraSter> specing, sure
[18:17:19] <OndraSter> but that much?
[18:17:31] <buhman_> OndraSter: shouldn't be that hard; a xmega breakout board already does most of that
[18:17:37] <OndraSter> exactly
[18:17:39] <specing> OndraSter: yep
[18:17:44] <OndraSter> that's 1/100th of the project though
[18:17:54] <buhman_> O.o so like the software nonsense too?
[18:18:03] <buhman_> wiring etc..
[18:18:08] <OndraSter> atmel studio libs
[18:18:33] <OndraSter> although I might switch to my own "IDE" to integrate flashing... but not in the beginning for sure
[18:18:43] <OndraSter> because no atmel studio on looniks or masox
[18:18:46] <OndraSter> but... there is Mono on both :P
[18:19:20] <buhman_> hey now, we have avr-gcc, avrdude, and make
[18:19:23] <buhman_> what else do you need?
[18:20:27] <OndraSter> something better than VIM
[18:20:29] <specing> we have vim too
[18:20:32] <specing> VIM FTW
[18:20:35] <buhman_> vim++
[18:20:37] <OndraSter> something that doesn't require brain damage to use
[18:20:43] * specing smacks OndraSter around
[18:20:50] * buhman_ teaches vim to 8-10th graders
[18:20:55] <OndraSter> lol
[18:20:57] <OndraSter> poor lads
[18:21:08] <specing> vim is easy
[18:21:17] <buhman_> easier than notepad
[18:21:18] <OndraSter> esc :wq
[18:21:21] <OndraSter> i
[18:21:29] <specing> yep
[18:21:32] <buhman_> once they get the whole insert-mode thing down; it goes pretty well
[18:21:55] <buhman_> then I have to break them of the "click to place the cursor" habit
[18:22:21] <buhman_> (I don't use that mouse=a nonsense)
[18:23:10] <OndraSter> why is arduino coded in "Wiring" when it is C++?
[18:23:59] <buhman_> OndraSter: so I'm looking at the 162 datasheet and comparing it to the datasheet of a parallel 8K x 8 SRAM datasheet, and looking at the wiring diagrams of each as well as the pinouts, and it doesn't look like what the 162 datasheet is telling me is physically possible on the sram I'm looking at
[18:24:15] <OndraSter> huh?
[18:24:41] <buhman_> it talks about this "D[7:0]" that connects directly to "AD7:0", and then you connect AD7:0 to the latch, which goes to A[7:0]
[18:24:56] <OndraSter> yes
[18:24:57] <buhman_> but I have no idea what "D[7:0]" corresponds to on the SRAM chip itself
[18:25:02] <OndraSter> well
[18:25:12] <OndraSter> the 8K SRAM chip has got how much addressing lines? 13 right?
[18:25:13] <OndraSter> err
[18:25:17] <OndraSter> yes
[18:25:18] <OndraSter> 13
[18:25:24] <buhman_> there a 8-bit "row decoder" and a 5-bit "column decoder"
[18:25:28] <OndraSter> the AD0:7 goes to the latch AND data0:7
[18:25:29] <buhman_> so yeah, 13
[18:25:37] <OndraSter> err
[18:25:43] <OndraSter> the AD0:7 goes to the latch AND address0:7
[18:25:52] <OndraSter> ehh
[18:25:55] <buhman_> oh
[18:25:56] <OndraSter> the AD0:7 goes to the latch AND address8:12
[18:26:10] <buhman_> ... so that's what the "I/O" lines are, duh
[18:26:11] <OndraSter> output of the latch goes to A0-A7
[18:26:18] <OndraSter> wait, let me re-check the datasheet
[18:26:22] <OndraSter> writing it from my head isn't a good idea
[18:26:40] <OndraSter> basically data and bottom address is muxed
[18:26:58] <buhman_> AD7:0 -> I/O[7:0] (or D[7:0] in atmega datasheet)
[18:27:16] <OndraSter> page 27
[18:27:20] <buhman_> that's what I'm looking at
[18:28:10] <buhman_> the SRAM I'm looking at:
http://www.cypress.com/?docID=25678
[18:28:32] <OndraSter> yes
[18:28:34] <buhman_> now that I've realized "D" means data, and "A" is address, it suddenly makes more sense
[18:28:39] <OndraSter> heh
[18:28:48] <OndraSter> and IO on SRAM = D on mega
[18:28:56] <buhman_> makes perfect sense
[18:29:07] <OndraSter> I have actually used 128kB SRAM
[18:29:10] <OndraSter> it was cheaper than 64kB
[18:29:15] <OndraSter> and with bank switching it can be used all
[18:29:23] <buhman_> but you just can't address the upper 64K, right?
[18:29:27] <OndraSter> well, about 60kB per bank
[18:29:29] <OndraSter> you can
[18:29:35] <OndraSter> BUT
[18:29:36] <buhman_> O.o bank switching?
[18:29:38] <OndraSter> yes
[18:29:41] <OndraSter> Z80 times?
[18:29:52] <OndraSter> http://en.wikipedia.org/wiki/Bank_switching
[18:29:56] <buhman_> does the 162 directly support that? or does that involve tons of hackery?
[18:29:58] <OndraSter> something like segments back in 8086
[18:30:00] <OndraSter> no
[18:30:02] <OndraSter> ton of hacker
[18:30:03] <OndraSter> y
[18:30:05] <OndraSter> easy via assembler
[18:30:09] <buhman_> heh
[18:30:18] <OndraSter> harder via C because you don't know what is in RAM and what is in registers
[18:31:09] <buhman_> so what's A15:8 ?
[18:31:30] <OndraSter> address bits 8 - 15
[18:31:39] <buhman_> I mean, there's 8 bits for that, and I assume that's the column bits
[18:31:40] <OndraSter> on your chip you have only 9 - 14
[18:31:44] <OndraSter> aye
[18:31:55] <OndraSter> note that your chip has got numbering from 1
[18:31:58] <buhman_> right
[18:32:00] <buhman_> really bizzare
[18:32:05] <OndraSter> well, not bizzare
[18:32:13] <OndraSter> just not using regular 0 :)
[18:32:19] <OndraSter> it is just to trick people's mind
[18:32:21] <OndraSter> still 8 bits
[18:32:25] <OndraSter> still the same thing
[18:32:35] <OndraSter> just they call it differently
[18:32:49] <OndraSter> also let me give you a hint - laying board to fit the mega + latch + memory is not fun..
[18:32:56] <OndraSter> I had to do 3 complete ripups till I got usable result
[18:33:20] <OndraSter> actually with SRAMs you can randomly change the address lines
[18:34:39] <buhman_> so I would connect A0 (SRAM) to A8 (uC), A9 to A9 ... A12 to A12?, and just pretend A13-15 don't exist?
[18:35:29] <buhman_> if that's 64Kbyte, why aren't I using all of the address lines?
[18:35:31] <OndraSter> A1:A8 SRAM to output of the latch
[18:35:39] <OndraSter> because it is not 64Kbyte
[18:35:41] <OndraSter> it is 64Kbit
[18:35:45] <buhman_> O.o
[18:35:53] <OndraSter> 8K * 8
[18:36:04] <OndraSter> 8kilobytes of words, word size = 8 bits
[18:36:08] <buhman_> that makes WAY more sense now
[18:36:14] <OndraSter> ;D
[18:36:25] <specing> 64 kilobit
[18:36:26] <OndraSter> anyway, I connected 1MB RAM to mega32
[18:36:33] <OndraSter> DRAM :P
[18:36:36] <OndraSter> from old 286
[18:36:41] <specing> I have a 256 kilobit SPI sram here
[18:36:46] <specing> in DIP8 ;P
[18:36:54] <OndraSter> specing, can't be used directly :P
[18:37:00] <specing> true
[18:37:03] <OndraSter> CPU load for refreshing the DRAM took about 10% CPU load @ 8MHz
[18:37:25] <buhman_> O.o what?
[18:37:42] <buhman_> refreshing the ram consumes CPU?
[18:37:51] <OndraSter> that was NOT using external memory
[18:37:54] <OndraSter> via internal circuitry
[18:37:58] <buhman_> oh
[18:38:03] <OndraSter> it was "homemade" software solution
[18:38:37] <buhman_> oh I missed the part where you said mega32
[18:38:42] <buhman_> which wouldn't have the EMI dark sorcery
[18:39:04] <buhman_> how do you compute cpu utilization?
[18:40:33] <buhman_> so erm
[18:40:50] <buhman_> looking for 512kbit sram chips, suddenly they're only in 100-TQFP packages
[18:40:51] <buhman_> why?
[18:41:18] <specing> 100 TQFP? lol
[18:41:32] <buhman_> I know, right?
[18:41:33] <specing> Even the ones on my arm board are 86 ssop
[18:41:45] <specing> and those are 32bit and 32 megabyte
[18:42:30] <specing> text data bss dec hex filename
[18:42:30] <specing> 1012 38 85 1135 46f firmware.elf
[18:42:35] <specing> I do not approve of this.
[18:43:04] <buhman_> and the 256kbit stuff comes in 28dip
[18:43:07] <buhman_> doesn't make sense
[18:43:50] <buhman_> so "70NS" SRAM would be more forgiving than "15NS" SRAM, yes?
[18:43:56] <buhman_> (probably why it's more expensive
[18:44:01] <OndraSter> 15ns is better
[18:44:08] <specing> _much_ better
[18:44:17] <buhman_> O.o so why is it cheaper?
[18:44:29] <OndraSter> different manufacturer
[18:44:31] <buhman_> same manufacturer/size/everything
[18:44:33] <OndraSter> check voltages
[18:44:38] <OndraSter> no idea then
[18:44:44] <buhman_> literally the *only* difference is speed
[18:44:46] <OndraSter> happens quite often
[18:44:48] <specing> and since xmega takes ~32 ns per cycle.. you want the 15 ns one
[18:44:59] <OndraSter> he is going for 162
[18:45:01] <OndraSter> since it is in DIP
[18:45:02] <buhman_> ..I'm planning on doing this with a 162
[18:45:06] <OndraSter> mega162
[18:45:40] <buhman_> so 15NS isn't going to be too fast or anything like that?
[18:45:57] <OndraSter> "too fast" doesn't exist here
[18:46:36] <specing> 15 is just guaranteed response time
[18:46:40] <specing> *ns
[18:46:51] <buhman_> Oh
[18:47:00] <specing> the whole thing should be synchronously clocked with the cpu
[18:47:02] <specing> AFAIK
[18:47:06] <buhman_> so this one only has 15 address lines
[18:47:14] <buhman_> why aren't there any DIPs with 16 :S
[18:47:23] <OndraSter> 15 address lines = 32kB
[18:47:28] <buhman_> indeed
[18:47:36] <buhman_> 16 = 64 = max
[18:48:10] <specing> buhman_: get an xmega ;P
[18:48:37] <buhman_> specing: heh, I hardly utilize a atmega fully; I wouldn't know what to do with myself if I had a xmega
[18:49:20] <specing> I hardly utilized an ATtiny fully
[18:49:24] <buhman_> plus I'd need to use my dragon; whereas I currently get a boner from my breadboard-SPI-ISP
[18:49:27] <buhman_> specing: that too
[18:49:39] <specing> well maybe t45...
[18:49:48] <specing> though I have yet to try SPM :)
[18:49:56] <buhman_> SPM?
[18:50:00] <specing> bootload
[18:50:19] <buhman_> like writing EEPROM stuff?
[18:54:19] <specing> FLASH
[19:00:31] <Splats> SPM Store Program Memory ... self-programming
[19:06:41] <cptG> Hello! I am having trouble getting started with my avr (using gcc 4.6.3) - avrdude recognizes the chip, can program and verify, but the program does not do what I'd expect...
[19:08:09] <cptG> The code:
http://pastebin.com/ZAwDfWcf - I'd expect that two of the pins of PORTB are pulled up but all are at level ~0.6V - mind I'm an electronics-noob.
[19:08:51] <buhman_> OndraSter:
http://www.wvshare.com/img/preview/M16-ADPII_l.jpg that wouldn't be that bad
[19:09:07] <buhman_> not sure if xmegas come in that package, but that's what it reminded me of
[19:09:17] <OndraSter> eh
[19:09:23] <OndraSter> these tend to be super expensive
[19:12:07] <buhman_> OndraSter: sure looks like it
[19:12:24] <OndraSter> these "openable" sockets are expensive on their own
[19:12:30] <buhman_> that socket is probably fancier than most "PC" motherboards :P
[19:12:37] <OndraSter> well
[19:12:42] <OndraSter> nothing can beat Intel's LGA sockets
[19:14:53] <Splats> cptG: Your program look sright, if you are intending to pull PB0 and PB1 high?
[19:15:56] <Splats> And the programmer generally doesn't power the device after programming - you ahve your own power supplied to it yes?
[19:16:30] <cptG> Splats: yes. I also tried PORTB = 0xFF; DDRD = 0xFF; PORTD= 0x00; to check if I am pulling down by assigning 0... But no difference between ports D and B
[19:16:50] <cptG> Splats: I have a simple parallel programmer that does not work without external power supply
[19:18:13] <Splats> Strange, it's very streight forward...
[19:18:35] <cptG> the assembly seems alright, too as far as I can see:
http://pastebin.com/JzvZcEnz
[19:18:43] <Splats> are you using avrdude to pass to the compiler, or runing avr-gcc manually first?
[19:19:21] <Splats> Do those port addresses match ttttttttttttttthe datasheet for the model AVR you are using?
[19:19:29] <cptG> I am using an example Makefile from a tutorial
[19:19:42] <cptG> Splats: let me check the datasheet...
[19:20:08] <Splats> eh 0x17 = DDRB, 0x18=PORTB
[19:23:42] <cptG> yep, seem to be matching.
[19:24:12] <cptG> stupid question: is it possible that the controller's just wrecked? It's been lying around for a few years...
[19:24:22] <cptG> So it can be flashed but does not execute?
[19:24:33] <buhman_> Splats: O.o assigning a register to a constant; impressive
[19:24:53] <Splats> buhman_ Its teh ultimate h4x0rz
[19:25:08] <cptG> ???
[19:25:27] <Splats> cptG: If you have an uninitialized avr laying around and it acts they says, then yes... but avrdude should be able to read-back teh program memory/validate it
[19:26:56] <Splats> like a -U flash:r:filename.bin:r
[19:26:57] <buhman_> One day, I was bumbling along and all the sudden BOOM, lost the magic smoke from my ISP (pololu). A few days later, I try to talk to the target uC again, and it doesn't seem to want to play with me.
[19:27:19] <buhman_> I pull out the uC and pop another identical uC in its place, and with the same wiring, it works just fine
[19:28:15] <buhman_> so I suspect that first uC is blown too; but it still has the magic smoke. So I wonder: is it possible to make *absolutely* sure I did in fact destroy the uC before I give it to those nice people that run landfills?
[19:28:41] <OndraSter> put it on some shelf
[19:28:52] <buhman_> OndraSter: erm? and then?
[19:29:01] <OndraSter> instead trashbin
[19:29:09] <buhman_> what's the shelf going to do?
[19:29:11] <OndraSter> usually I try ISP, JTAG and HVPP
[19:29:13] <OndraSter> nothing
[19:29:23] <OndraSter> I have got also some AMD and Cyrix and Intel CPUs on the shelf :P
[19:29:37] <buhman_> I have a dragon; I might do HVPP for the first time
[19:30:18] <cptG> Splats: I'm using avrdude -p atmega16 -c dapa -U flash:w:main.hex --> output:
http://pastebin.com/5gN2kxLA
[19:30:42] <buhman_> O.o dapa?
[19:31:17] <Splats> cptG: programmer appears fine then, avrdude would have at leaased failed on signature check
[19:31:45] <Splats> least
[19:33:14] <Splats> reset isnt tie7Teh reset pin is not tied low or floating, is it? ;)
[19:33:26] <Splats> cptG: The reset pin is not tied low or floating, is it? ;)
[19:33:33] <cptG> Splats: well... just got another chip that's been lying around - same model and virgin and it behaves the same...
[19:33:35] <cptG> lol
[19:33:47] <cptG> Splats: hope not, this pcb has been in use already
[19:34:00] <cptG> so I assumed... but let me check
[19:35:19] <cptG> Hrm... dammit, it's at 0V - I assume that's the solution to my problem?
[19:36:28] <Splats> Well, the atmega16 follows the usual inverted reset.. so maybe!
[19:41:53] <cptG> Splats: DUUHHH! It was sloppy soldering! :D
[19:42:09] <Splats> Haha.... alls well then?
[19:42:13] <cptG> the two pads got connected by accident - greasy fingers.
[19:42:18] <cptG> Yes, all is well
[19:42:22] <Splats> Excellence :
[19:42:29] <cptG> thanks a lot!
[19:42:33] <Splats> no problem
[19:42:49] <cptG> I'd never have found it. Darn reset pin.
[19:43:48] <Splats> Even more fun when you accidentally disable it in the fuses :[
[19:44:46] <Splats> Luckily the HV fuse reset stuff on the interwebs is easy to do!
[19:48:50] <cptG> Splats: fuses scare me - if you don't know if the chip works or not, thinking about fuses is kinda scary :P
[19:52:58] <Splats> :d
[21:59:17] <cyronin> hey guys
[21:59:51] <cyronin> any reason why SPCR = _BV(SPE) | _BV(MSTR); would cause an atmega328p to hang?
[22:09:10] <R0b0t1> If I'm needing to detect bi-phasal IR what kind of program structure should I go for? I don't need concurrency, but would an interrupt state machine be a good idea? Blocking function? I mean to optimize for code size, but it is not a huge concern.
[22:12:00] <cyronin> I got my issue solved, flawed debugging technique, no problems with spi
[23:12:16] <Splats> R0b0t1 go with interrupt and a timer to find the time passed between transitions
[23:52:38] <PlastyGrove> What am I doing wrong here?
[23:52:43] <PlastyGrove> 1: ldi r17, UCSR0A
[23:52:44] <PlastyGrove> sbrs r17, UDRE0
[23:52:46] <PlastyGrove> rjmp 1b
[23:53:02] <PlastyGrove> I get an error saying unexpected integer
[23:53:10] <PlastyGrove> ont he first line
[23:54:33] <PlastyGrove> I know I can always use a proper label instead of an integer label, but would like to know what's the problem here
[23:58:32] <PlastyGrove> does that work only with inline asm? :|
[23:59:22] <Xark> PlastyGrove: Are you sure UCSR0A is defined?
