Back
[00:00:33] <Badaboom> Mot trying to spook anyone?
[00:00:37] <Badaboom> Not
[00:00:53] <braincracker> no, nukes are not spooky you know
[00:02:18] <Badaboom> anonymous
[00:02:34] <theBear> nah, spooky is infinitely more subtle, it sounds like the wind and creaky doors and stuff... nukes kinda sound like the wind for a moment, but then the doors go flying off into the distance, and soon after the walls and everything else nearby... not spooky at all
[00:03:10] <Badaboom> well,, heres a term MAD
[00:03:33] <theBear> heh, i like it too
[00:03:50] <Badaboom> 1 push = all launch
[00:03:51] <theBear> i also like scorched earth policy, just got a nice ring to it
[00:03:57] <Badaboom> lmao
[00:04:05] <Badaboom> I thought i was the only one
[00:04:21] <Badaboom> Want some barbacue sause wit that?
[00:04:25] <Badaboom> sauce
[00:04:48] <theBear> nah that's cool, i prefer to savour the scorch
[00:05:14] <Badaboom> peel it back like the crust on a nice cooked piece of pork?
[00:05:55] <theBear> yeah, a lot like that
[00:06:28] <Badaboom> braincracker: it's only a matter of time
[00:08:22] <Badaboom> for to long has the balance of society been one sided without anything on the other end of the =
[00:08:54] <theBear> too long
[00:08:57] <Badaboom> the Universe demands balance
[00:10:33] <Badaboom> we can't keep making the rules as we go along and expect that "if we dig a hole over here that we wont cause a cave in over there"
[00:11:49] <Badaboom> or as i was always fond of saying You can only pull a dogs tail so many times before it eventually turns and bites you
[00:17:22] <Badaboom> so i have a question concerning key mapping
[00:18:19] <Badaboom> if (!(PIND & 0x02))
[00:18:36] <Badaboom> PORTD = 0xEF;
[00:19:18] <Badaboom> with that setup i should be able to call a function correct?
[00:20:05] <Badaboom> only i place it wrong in here
[00:20:18] <Badaboom> portd is on top
[00:33:15] <braincracker> :) guy suggests pouring some clorox into your long-term storage tap water
http://www.youtube.com/watch?v=5GOV8Or0xTg drink bleach bitches
[00:34:36] <Badaboom> 1 cap per 5 gallons
[00:35:40] <braincracker> i'd add h2o2 lol.
[00:35:48] <braincracker> not bleach
[00:35:54] <Badaboom> :)
[00:36:08] <Badaboom> btw im making an array for the numbers
[00:36:21] <Badaboom> if itll work
[00:39:53] <braincracker> http://www.youtube.com/watch?v=BeXHKpuHVZg
[00:40:05] <braincracker> btw if you get an RO filter you can make drinking water from pee
[00:40:28] <braincracker> or non radioactive sea water
[00:42:23] <Badaboom> braincracker: are you in prep mode?
[00:42:41] <braincracker> i'm not in usa but...
[00:42:57] <Badaboom> it will have a global effect
[00:43:18] <Badaboom> we may not be the country we once were but..
[00:43:21] <braincracker> a few hundred MT of nuke would ba nasty
[00:43:28] <Badaboom> we still have dangerous weapons
[00:43:39] <braincracker> russia has big nukes
[00:43:49] <braincracker> and china has who-knows what
[00:44:00] <braincracker> chemica, biological?
[00:44:05] <Badaboom> if one goes off they all will and itll all be over
[00:44:30] <Badaboom> China scares me
[00:44:49] <braincracker> china will send over biobombs to usa
[00:45:04] <Badaboom> more than likely they have things we arent aware of
[00:45:05] <braincracker> viruses
[00:45:32] <braincracker> and iran ?
[00:45:33] <Badaboom> well... its more complicated than that
[00:45:46] <braincracker> maybe they don't have large H-bombs, but they may stil lhave viruses
[00:46:21] <braincracker> terrorists will spread shit even if they do suicide mission
[00:47:03] <Badaboom> you gotta stop watching all the doomsday videos man
[00:53:35] <Badaboom> have you ever seen a MOAB go off?
[00:53:49] <Badaboom> a/k/k the fridge bomb
[00:53:52] <Badaboom> aka
[00:56:12] <Badaboom> https://www.youtube.com/watch?v=cuGrDSP0rj8
[00:57:06] <Badaboom> https://www.youtube.com/watch?v=cuGrDSP0rj8
[00:58:24] <Badaboom> https://www.youtube.com/watch?v=ZX5h2fjhKyQ
[01:02:35] <Badaboom> __________---->
https://www.youtube.com/watch?v=oVceh8ZLTcQ
[01:03:54] <braincracker> i don't really care about a simple explosive
[01:04:15] <braincracker> it is radioactive fallout that will kill you
[01:04:47] <braincracker> and chemical/biological weapons
[01:05:58] <braincracker> Badaboom <=
http://www.youtube.com/watch?v=AN8dmKgrn64 ...
http://www.youtube.com/watch?v=JBIdH26Uqr8 50MT+
[01:06:08] <braincracker> russia will throw these on usa
[01:07:38] <Badaboom> those are from the 50's
[01:09:43] <Badaboom> http://rt.com/news/tsar-bomb-thermonuclear-test-111/
[01:10:41] <Badaboom> ok developed in the 50's detonated in 61
[01:11:09] <Badaboom> you know what i say to that brain?
[01:11:14] <Badaboom> <------
[01:11:51] <braincracker> hm ok...
[01:12:17] <Badaboom> ahy are you so concerned about TNF?
[01:12:29] <braincracker> so i liked the idea of a 57MT H-BOMB taking out london
[01:12:37] <braincracker> and surrounding
[01:12:41] <Badaboom> lol
[01:13:04] <Badaboom> why London?
[01:13:16] <braincracker> ( the devil's nest is located there )
[01:13:20] <Badaboom> oh wait..nm
[01:13:25] <Badaboom> The Queen?
[01:13:30] <braincracker> no:)
[01:13:37] <Badaboom> Parlam?
[01:39:30] <braincracker> https://www.youtube.com/watch?v=5q-IkvDZ9nY nice, i want one
[01:52:22] <beaky> hello
[01:52:38] <beaky> is there a difference between the attiny85 and attiny85s besides the fact that the V variant can run at 1.8V
[04:21:16] <RikusW> https://www.youtube.com/watch?v=6ukMId5fIi0
[07:36:16] <KidBeta> with my FPGA would a case statement be syntheised in a more optimised manner then say a bunch of ifs without else chaining
[07:37:38] <antto> switch () ?
[07:37:56] <KidBeta> its similar i believe yeah
[07:38:12] <KidBeta> i thought it should because it means only one of the statements gets executed where as currently all of them can
[07:38:14] <antto> i *think* that turns into some sort of a table
[07:38:25] <antto> but i could be very wrong
[09:33:33] <megal0maniac> theBear: 650w PSU up and running. If this thing falls over, I'll throw shit
[09:37:39] <Casper> megal0maniac: I hope it's quality psu
[09:37:56] <megal0maniac> It's entry level Corsair, should be okay
[09:38:05] <RikusW> megal0maniac: I got the Aery32 :) finally
[09:38:07] <Casper> ya
[09:38:21] <Casper> worse are those 550W ones
[09:38:28] <megal0maniac> I don't buy or supply Chinese power supplies because the wattage really could mean anything :)
[09:38:33] <Casper> the cheap kind...
[09:38:36] <megal0maniac> RikusW: Nice :)
[09:38:51] <Casper> megal0maniac: I read the specs of one of those chinese ones...
[09:38:57] <specing> megal0maniac: you don't really need much wattage on newer computers
[09:38:59] <megal0maniac> Casper: I upgraded from a Chinese 450w to a decent 470w and there was a huge difference
[09:39:08] <specing> 150W is fine on integrated graphics
[09:39:42] <Casper> it was like a 550W.... peak.... for 10 secs.... immediatelly following a power on after a full cooling period... at 15C ambiant...
[09:41:05] <megal0maniac> It probably is overkill, but I'm sick of this
[09:42:19] <Casper> what a shitty weather :(
[09:42:27] <megal0maniac> What lovely weather :)
[09:42:38] <Casper> rain...
[09:42:39] <megal0maniac> RikusW: What do you think of the Aery framework?
[09:42:51] <megal0maniac> Sun. 18C :)
[09:43:00] <Casper> megal0maniac: I want that monday!
[09:43:04] <RikusW> not looked into the details, but they sure got nice graphics
[09:43:11] <megal0maniac> Haha :)
[09:43:37] <megal0maniac> Download the framework. It's basically a more lightweight alterative to ASF
[09:44:07] <RikusW> ok
[09:45:17] <megal0maniac> Works quite well. No need for Atmel Studio, and the makefile integrates with FLIP so it automatically compiles and uploads
[09:46:27] <RikusW> nice
[09:49:13] <RikusW> I ordered some GPS modules from Otto, paid on Tuesday and got it on Wednesday morning :-D
[09:49:19] <RikusW> now thats service :)
[09:49:29] <megal0maniac> That's impressive
[09:49:30] <RikusW> cost ZAR 125 for postage
[09:49:37] <RikusW> Fedex
[09:49:37] <megal0maniac> Faster than Aery :P
[09:49:45] <RikusW> much, that took a month
[09:49:57] <megal0maniac> Although it was cheaper ;)
[09:50:09] <RikusW> I had to wait a week or so for Otto to get stock..
[09:50:44] <RikusW> Those PA6H GPS modules are really easy to solder too :)
[09:50:59] <Casper> with digikey, I can order before 7:30pm, and I get the package next day for 8$
[09:51:04] <RikusW> Just use the footprint they give in the datastheet
[09:51:28] <RikusW> ZAR 80
[09:52:15] <RikusW> Those GPS modules cost $20 in low quantities
[09:53:23] * megal0maniac looks at XULA board again
[09:54:28] <megal0maniac> Damn exchange rate :(
[09:56:04] <RikusW> seems ZAR10 for 1 USD now...
[09:56:15] <RikusW> google can instantly convert :)
[09:56:15] <megal0maniac> Slightly more than that even
[09:56:31] <megal0maniac> Google can instantly make me sad
[09:56:38] <RikusW> google -> usd to zar
[09:56:44] <RikusW> R10 exactly now
[09:57:03] <RikusW> you can even put in an amount
[09:57:15] <megal0maniac> I know
[10:03:56] <megal0maniac> I'm off. Windows re-install time
[10:06:33] <Casper> megal0maniac_afk: hey! don't steal my job :(
[11:57:41] <ambro718> I made my interrupt code simpler but gcc compiles it into something that's slower than before :/
[11:58:48] <ambro718> looks like the register assignments it choses are bad because it has to mov values into the upper registers before my inline asm can use, and the result is exta mov plus extra push/pop (because the interrupt clobbers more registers)
[11:59:31] <ambro718> anyone have such experience? is there something I can do to make gcc choose registers more efficiently?
[12:00:27] <specing> ambro718: don't use the inline asm directive for upper registers, then
[12:00:44] <ambro718> I need to because this way the inline asm is much faster
[12:01:12] <specing> From where do these values come?
[12:01:22] <specing> (values in registers)
[12:02:04] <ambro718> from memory. Basically the only change was this, at the beginning of the interrupt handler: "if (m_x == m_length) {" to "if (m_x == 0) {"
[12:02:48] <ambro718> (and an inc was changed to a dec)
[13:54:04] <l9> is there a good rs232 tutorial for ubuntu users
[14:02:23] <specing> no
[14:02:45] <specing> But there are generic Linux rs232 tutorials
[14:10:34] <l9> I am lost
[14:14:04] <specing> l9: screen /dev/ttyUSB0 115200,ixoff,cs8
[14:16:00] <timemage> l9, lost doing what exactly?
[14:31:12] <Casper> l9: ubuntu is linux, just search for one for linux, you may have to do slight changes due to each distro that do stuff a bit differently
[14:31:19] <Casper> but that should be easy
[14:40:01] <jacekowski> ambro718: -O2?
[14:40:07] <jacekowski> ambro718: or -Os?
[14:40:45] <ambro718> jacekowski: -O2, 3 and 4. At -O2 the code is too slow anyway
[14:41:18] <ambro718> I mean at -Os
[14:44:06] <ambro718> I need some way to force the compiler to start with the high registers so it wouldn't have them later
[14:44:24] <ambro718> also add the extra push and pop needed by the interrupt because it uses more registers
[14:44:45] <ambro718> * wouldn't have to copy them
[14:46:19] <specing> ambro718: you could declare a global register variable shared between interrupts
[14:46:23] <specing> that is what I do
[14:48:54] <ambro718> umm I don't see how I could do that with my C++ code. My interrupt handler is this
http://ideone.com/UvwUie line 280 (well it's not an ISR but is being called directly from the ISR)
[14:50:19] <specing> Yeah, that might be a problem with templatized code
[14:50:32] <ambro718> oops that's supposed to be "if (m_current_command.x.bitsValue() == 0) {"
[14:50:39] <specing> since registers are a scarce resource
[14:51:00] <ambro718> the problem is gcc doesn't seem to understand that very well ;)
[14:51:30] <ambro718> it's funny because with a more complex version of the code, it manages to use less registers and the interrupt is significantly faster
[14:57:12] <Casper> ambro718: there is no such thing as -O4
[14:57:41] <ambro718> Casper: sure there is, it's right there in the gcc man page
[14:57:50] <Casper> then it must be quite new
[14:58:04] <Casper> as in less than a year old
[14:58:09] <ambro718> oh wait it's not there :D
[15:01:39] <RikusW> ambro718: gcc for avr is less than optimal...
[15:01:52] <RikusW> I've seen it generate some horrible asm
[15:02:24] <specing> "some"
[15:02:35] <ambro718> but there's nothing better than gcc!
[15:03:11] <RikusW> asm ;)
[15:03:20] <specing> That is hardly better
[15:03:27] <RikusW> there are some commercial C compilers
[15:03:37] <specing> unless you want to lock yourself up in a cave for a year
[15:03:38] <braincracker> h
[15:03:38] <RikusW> specing: depends on who is coding ;)
[15:03:40] <braincracker> https://privacysos.org/node/822
[15:03:43] <braincracker> :)
[15:03:46] <ambro718> you can't even buy the IAR compiler for example
[15:03:55] <ambro718> you need to have a company to get it, lol
[15:03:58] <braincracker> don't you just love when they aim high power microwave antennas at you ?
[15:04:10] <braincracker> (thousands of watts)
[15:44:57] <ambro718> yay, I fixed it!
[15:45:36] <ambro718> I changed some of my inline assembly to use a higher register even though it doesn't need it.
[15:45:50] <ambro718> to use a high register for its output
[15:51:58] <Roklobsta> reall, for the money why is gcc so offal?
[15:53:18] <Roklobsta> ambro718: interrupts are *meant* to be short and sweet affairs.
[15:53:27] <Roklobsta> not some C++ templatey nightmare
[15:53:50] <ambro718> I need to solve a quadratic equation in the interrupt
[15:54:00] <Roklobsta> how after does the interrupt go for and does all the code get executed in time?
[15:54:39] <ambro718> yes, my steppers work very nice as long as I'm not trying to run them too fast
[15:54:52] <ambro718> what do you mean "how after does the interrupt go for"?
[15:55:02] <Roklobsta> how long
[15:55:09] <ambro718> about 500 cycles
[15:55:21] <Roklobsta> gimme a break it's 640am, i just woke up and coffee is stll brewing
[15:56:10] <ambro718> if I *do* run the steppers to fast, then the clock gets messed up and the stepper control malfunctions
[15:56:37] <ambro718> that's because the timer interrupts for stepper control have higher priority than the timer overflow interrupt which I use for timekeeping
[15:57:26] <ambro718> so if the steppers are running too fast, I never get a chance to register timer overflow, and when it overflows the second time then steppers go nuts
[16:01:12] <ambro718> at this point I can handle 17k steps per second
[16:01:38] <ambro718> and I'm running my atmega1284p at full speed 20MHz
[16:02:37] <Roklobsta> ok, so it's not a stepper timer issue, you just have a hard limit to how fast you can run the steepers because your system timer/clock period is too long?
[16:04:06] <ambro718> yes (or code is too slow)
[16:05:09] <Roklobsta> ok.
[16:10:14] <megal0maniac> Well this is nice. Seems that SSD actually can increase battery life :)
[16:10:55] <megal0maniac> 7 hours on a 6 cell battery using PuTTY over wifi
[16:11:36] <megal0maniac> And PC isn't crying yet so I'm happy
[16:12:12] <ambro718> * wait, it's actually 34k steps per second :P Which is probably too slow for a 3d printer when it needs to retract filament, especially because multiple steppers run at the same time.
[16:14:55] <Roklobsta> megal0maniac: ssd is the best thing since sliced bread
[16:15:11] <Roklobsta> cristy old pc's with ssd are usable again
[16:33:04] <megal0maniac> Roklobsta: yeah but crusty old pcs cost as much as ssds ;)
[16:34:01] <Roklobsta> ambro718: maybe, if possible have the interrupt just do a task and set a flag when it's done. Have a non timer interrupt loop do all the preparation and updating of the task. doing sqrt(), div and muls in irq isn't, as Paris would say, 'hot'.
[16:34:51] <Roklobsta> i just updated crusty old pc's with ssds and win7 for a small company and it's been cheaper to do that than buy new pc's just to use office.
[16:35:01] <Roklobsta> and new pc's won't have ssd
[16:35:23] <Roklobsta> and office runs fantastically well on a 2.6GHz Core 2.
[16:36:08] <megal0maniac> Our definition of "crusty old" is not the same :)
[16:36:27] <Roklobsta> ok
[16:36:33] <Roklobsta> is your's worse?
[16:36:52] <ambro718> yes it's a bit unusual, but I think trying to outsource the computations to outside the interrupt would just add computational overhead so it would be even slower
[16:37:20] <ambro718> I've manually coded sqrt/div/muls in asm, they're heavily optimized :D
[16:38:01] <Roklobsta> ambro718: so that way each timer irq would quickly do a preassigned task and set a flag. outside the irq you can have time to synronise the next set of jobs for the stepper.
[16:38:03] <megal0maniac> Well no. It's an i5 2450m with 4gb 1333mhz RAM. But crusty old is 478 socket stuff. But I guess I'm just behind. Haswell has arrived so even my shiny new stuff is outdated
[16:38:38] <Roklobsta> even if the outside loop takes too long the steepr won't go crazy because of a missed timer tick.
[16:38:58] <Roklobsta> i3/i5/i7 anything is fast
[16:39:13] <Roklobsta> i have an i7-720QM laptop and it's hella fast. just needs an ssd
[16:39:20] <ambro718> Roklobsta: I don't see what I would gain by doing this. I already do some preprocessing outside the interrupts to make the interrupts do less work, but the work that happens in an interrupt is specific to some step.
[16:40:19] <ambro718> I could avoid the interrupt flood so the clock would keep working, but then I can just limit the max stepper speed externally to avoid that
[16:41:02] <ambro718> my assembly code for sqrt/div/mul is here btw, .L510
[16:41:17] <ambro718> https://github.com/ambrop72/aprinter/tree/master/avr-asm-ops
[16:41:31] <megal0maniac> Roklobsta: SSD power usage seems pretty erratic compared to a traditional drive. My laptop can't make up its mind how long the battery will last :)
[16:41:57] <Roklobsta> i thnk different ssd manuf's have wildy varying useage too
[16:42:05] <Roklobsta> i mean wattage/usage
[16:42:46] <megal0maniac> Yeah. I sort of accidentally got a "performance" SSD so laptop battery does suffer a bit for it
[16:43:42] <megal0maniac> It's nice though. There's a 30mm or similar fan, spinning at min rpm and no other noise or movement. Feels strange
[16:44:23] <Roklobsta> i am stuck with an nvidia laptop gpu so the fan is always blazing
[16:44:43] <Roklobsta> and it blows harder in linux than windows
[16:44:58] <Casper> linux sadly don't have a good power management
[16:45:00] <megal0maniac> Mine is a thinkpad, integrated graphics, nice and quiet :)
[16:45:03] <Casper> not as good as in windows...
[16:45:11] <Casper> and windows xp is better than win7
[16:45:15] <megal0maniac> Casper: It's more about the graphics driver
[16:45:51] <megal0maniac> But yeah, you're right. In general it isn't as good
[16:46:54] <Roklobsta> ambro718: yeah, ok. i was just thinking that parhaps if you prepared and dispatch the tasks externally from the irq and just have the orq quickly do the job you'd probably then go as fast as the CPU could generate the jobs.
[16:47:39] <Roklobsta> ambro718: ah nice hand coded maths. i did the same once though the cpu i had did have a nice 32x32 HW multiplier which made things a bit easier
[16:47:44] <ambro718> the CPU is the bottleneck ;)
[16:48:01] <megal0maniac> xmega!
[16:48:13] <ambro718> I've done some calculations and it looks like the irq is fast enough to avoid overflowig uart receive buffer
[16:49:39] <Roklobsta> yeah xmega
[16:49:43] <Roklobsta> have dma do all the work
[16:49:58] <ambro718> can dma compute square roots?
[16:51:25] <megal0maniac> You'd probably need to use the CPU from time to time ;)
[16:51:31] <megal0maniac> There's the event system too
[16:52:04] <ambro718> I'd really need a FPU though
[16:56:05] <megal0maniac> Now you're just being spoilt
[16:56:52] <ambro718> another gcc stupidity... does movw r26,r16 before an inline asm section even though it could easily have given r16/17 and had the assembly mess it up, since it's not used afterward
[16:57:25] <Roklobsta> for serial just make a fifo in softwarethat the UART irqs deal with and then in your main code use putc/getc to the fifos. that way you wont' be dropping chars.
[16:58:00] <Roklobsta> use -O6
[16:58:28] <ambro718> Roklobsta: I think the problem is dropping received chars
[16:58:39] <Roklobsta> yeah, make a fifo
[16:58:57] <ambro718> if your fifo overflows because the non-interrupt code can't process it fast enough
[16:59:11] <Roklobsta> allocate a bigger fifo!
[16:59:16] <Roklobsta> i am using 256 bytes!
[16:59:19] <Roklobsta> for 115200
[16:59:28] <ambro718> doesn't help, it'll just overflow later
[16:59:49] <ambro718> think of a 10M g-code file being received
[17:00:19] <Roklobsta> ok, use RTS/CTS
[17:00:22] <Roklobsta> i do
[17:00:26] <Roklobsta> work's even better
[17:00:31] <ambro718> ah of course
[17:00:42] <Roklobsta> nothing gets lost
[17:02:04] <Roklobsta> even XON/XOFF
[17:02:35] <Roklobsta> nah RTS/CTS is better
[17:03:14] <ambro718> I don't know, I'll try to do whatever existing 3d printers do so it would work with existing host software
[17:03:24] <ambro718> hopefully they do *something*
[17:03:36] <Roklobsta> yeah but host systems can be made to use RTSCTS
[17:03:54] <Roklobsta> if they can't they stupid
[17:04:22] <Roklobsta> is your avr a command->movement controller?
[17:04:48] <Roklobsta> i don't know shit about 3D printing. what does the host software generate? generic 3D plotting commands?
[17:05:55] <ambro718> Roklobsta: you use a "slicer" to turn a 3d model into g-code, which is pretty much a sequence of move commands, as a text file
[17:06:18] <ambro718> G1 X6 Y6 E7 <-- move to X=6, Y=6, extruding 7 along the way
[17:06:55] <Roklobsta> heh, LOGO lives!
[17:07:13] <Roklobsta> who ever played with a LOGO turtle?
[17:07:57] <ambro718> the stepper driving code in my software for now understands motion in constant-acceleration slices (displacement, time, acceleration), so the printer will have to be smart and convert g-code into that
[17:08:21] <ambro718> taking into account maximum permitted velocity and acceleration for each of the axes
[17:08:49] <Roklobsta> did you do some control system equations?
[17:09:10] <ambro718> hm, no, I'm just doing this for fun. What exactly did you have in mind?
[17:09:40] <Roklobsta> oh it sort of sounds like to made a maths model of the motor system and applied control loop theory
[17:09:50] <Roklobsta> to maximise the speed
[17:10:50] <Roklobsta> as for rts/cts and serial fifo, it works like a charm on my multitakser and 3Gmodem
[17:10:58] <Roklobsta> no lost chars
[17:12:21] <Badaboom> Evening Gents
[17:12:35] <Roklobsta> oh, there goes the neighbourhood
[17:12:41] <Badaboom> lol
[17:13:22] <Badaboom> I need your email again i got really sick and was down for a week
[17:13:48] <Roklobsta> whose?
[17:14:00] <Badaboom> Oh oops
[17:14:03] <Badaboom> ,,nm
[17:15:25] <Badaboom> Sigh,, now i forgot who it was i promised that connector too
[17:16:51] <Badaboom> It's strange because the past week i got sick and we found out one of the planes had way more damage than originaly thought
[17:17:58] <Roklobsta> i think you are still sick and somewhat delerious
[17:18:06] <Badaboom> ?
[17:18:22] <Roklobsta> planes. WTF?
[17:18:45] <Badaboom> we have aircraft
[17:18:50] <Badaboom> plane
[17:18:55] <Badaboom> Cessna's
[17:22:24] <Badaboom> Roklobsta: I have a share in a Cessna 182RG and help take care of a couple of other aircraft
[17:24:32] <Badaboom> and what i meant by refering to me being sick relating to the plane ..it originally went in for landing gear problems due to a hard landing but we found out the engine mount was cracked.
[17:26:24] <Badaboom> anyway
[17:28:55] <Roklobsta> aha finally some information
[17:30:12] <Roklobsta> as sick as this?
http://www.dougronan.com/ontario/images/Interestingplane/chewedphoto39.jpeg
[17:32:14] <Badaboom> lmao.. no not quite that bad
[17:32:45] <Badaboom> good got what happend to that plane
[17:33:11] <Badaboom> prop got it?
[17:34:04] <Badaboom> Yeah that's what it looks like,, i can see the pattern
[17:34:41] <Roklobsta> yes runaway startup
[17:34:49] <Badaboom> Ill have to save that for my friend.. hell get a kick out of that
[17:35:36] <Badaboom> I had a friend years ago that decided to land where the blue lights are,,lol
[17:35:47] <Badaboom> we still tease him about it
[17:42:53] <Roklobsta> ambro718: are you busy hacking up a fifo with rts/cts?
[17:47:06] <ambro718> Roklobsta: no, I'm not doing that right now, still optimizing the stepper code ;) Actually I just checked, and I see the electronics I have doesn't even connect RTS/CTS from the FTDI to the MCU. I've already implemented the basic serial port though (no flow control),
https://github.com/ambrop72/aprinter/blob/master/aprinter/system/AvrSerial.h
[17:48:29] <Roklobsta> is AMBROLOCK a fancy sreg=SREG;CLI();...;SREG = sreg;?
[17:49:11] <Roklobsta> mmm, some wires and 2 spare GPIO's, if you have any, should sort that.
[17:49:22] <ambro718> Roklobsta: yes :P It's implemented with templates; it depending on whether the 'c' is an AvrInterruptContext it either does cli/sei or not.
[17:50:05] <ambro718> so you can have functions like this: template <typename ThisContext> void func (ThisContext c, ...);
[17:50:19] <ambro718> and they work both from interrupt context or not
[17:50:33] <ambro718> (and no runtime checking of interrupt enabled flag)
[17:51:59] <ambro718> and once you're inside a lock, you have "lock_c" which is always an AvrInterruptContext, so if you call some other function from in there it knows not to disable interrupts
[17:52:08] <ambro718> yeah, I'm crazy about templates :D
[17:53:52] <Roklobsta> fruitier than a nutcake
[17:59:39] <ambro718> hmmm gcc assigns structures with this
http://ideone.com/i4ulVk
[18:00:30] <ambro718> and this is *not* at -Os
[18:02:57] <ambro718> memcpy produces the same code
[18:05:04] <braincracker> ahahaha
http://www.youtube.com/watch?v=AYjCXjIeNJk#t=3m44s
[18:06:44] <Badaboom> lmao,, look at the brain
[18:12:39] <Roklobsta> ambro718: how much ram/rom does your code use
[18:12:49] <Roklobsta> do you dynamically allocate anything?
[18:13:42] <ambro718> Roklobsta: currently for driving 2 steppers it's 28k, and uses about 1k ram. I don't allocate dynamically, I just use preallocated ring buffers for commands.
[18:14:01] <ambro718> 1k ram that excludes stack
[18:14:19] <ambro718> the atmega1284p has 128k flash and 16k ram, so I think it'll fit
[18:14:27] <Roklobsta> ok
[18:14:39] <Roklobsta> i am using the 1280
[18:18:58] <braincracker> Surgeon Simulator 2013 | Part 1 | I'M A DOCTOR!!
http://www.youtube.com/watch?v=-hQTehezJoI
[18:33:10] <Badaboom> atmega328 has 2 8 bit counters and 1 16 correct?
[18:33:27] <Badaboom> bah,, lemme grab the datasheet
[18:35:24] <braincracker> ye
[18:35:47] <Badaboom> wtf is ye?
[18:36:08] <braincracker> i mean ya
[18:36:23] <braincracker> timer1 is 16 bit
[18:36:30] <Badaboom> ok
[18:36:42] <Badaboom> total of ?
[18:36:43] <braincracker> timer0 and timer2 are 8 bit
[18:36:46] <Badaboom> 3 or 2
[18:36:56] <Badaboom> ahh ok
[18:37:20] <Badaboom> I had it counting last night,, went to 32768:(
[18:37:44] <Badaboom> so ill divide the counter then
[18:37:54] <Badaboom> maybe use a RTC
[18:38:12] <braincracker> you mean a watch crystal?
[18:38:24] <Badaboom> yeah basicly
[18:38:37] <braincracker> div by 128, and program timer2 then.
[18:38:41] <Badaboom> I have one out of an old clock
[18:38:45] <braincracker> you'll have a 1s timer2 overflow interrupt
[18:38:46] <Badaboom> prescaler
[18:38:47] <Badaboom> ?
[18:38:47] <Roklobsta> how good is the calibrated rc vs an xtal
[18:39:03] <braincracker> calibrated RC is +-3%, xtal is 50ppm
[18:39:12] <Badaboom> bah,, overflow was last night too
[18:39:20] <Roklobsta> i haven't looked into it yet, can you use say, a 16MHz main xtal and an 32Khz xtal to keep time when the AVR is asleep?
[18:39:28] <Badaboom> well internal is 10% correct?
[18:39:45] <braincracker> it will probably do +-5%...
[18:39:56] <braincracker> mine was like a second off in a minute
[18:39:56] <Badaboom> Hmm
[18:40:01] <Roklobsta> tick
[18:40:03] <Roklobsta> yicl
[18:40:05] <braincracker> the 8MHz int osc
[18:40:07] <Roklobsta> yick!
[18:40:09] <Badaboom> I heard 10%
[18:40:49] <braincracker> i measured less
[18:40:54] <Badaboom> well ill definitly use an external
[18:41:25] <Badaboom> xmega is better internal from what i understand
[18:41:28] <braincracker> 10% is the cheap resistor accuracy
[18:41:30] <Roklobsta> oh doh the board i have uses a proper RTC
[18:41:32] <Roklobsta> on i2c
[18:41:42] <Badaboom> :)
[18:41:54] <Roklobsta> must write a driver
[18:41:57] <braincracker> i mostly have 1% precision resistors ...
[18:42:07] <Badaboom> wow
[18:42:28] <Badaboom> I could use a 555
[18:42:35] <Roklobsta> loldongs
[18:42:36] <braincracker> for what?
[18:42:47] <Badaboom> What's the accuracy on the 555?
[18:42:54] <braincracker> lol is the accuracy on 555
[18:42:57] <Badaboom> probably shitty for this
[18:43:09] <Roklobsta> it's the cap that will let you down
[18:43:09] <Badaboom> lol
[18:43:15] <braincracker> i just told you the best solution on your atmega
[18:43:16] <Roklobsta> never mind the r
[18:43:21] <Badaboom> ok scratch that idea:)
[18:43:59] <braincracker> you can use internal whatever oscillator for clock, and set timer2 to use your external watch crystal, and tick at 1.00000Hz
[18:44:02] <Badaboom> a resistor?
[18:44:12] <Badaboom> ahh ok
[18:44:28] <braincracker> and you increase your time variable with the timer2 ovf interrupt
[18:44:32] <Roklobsta> read this about caps and accuracy
[18:44:33] <Roklobsta> http://www.maximintegrated.com/app-notes/index.mvp/id/5527
[18:45:26] <braincracker> Badaboom <= you do not need any magic ics for measuring time ;>
[18:45:34] <braincracker> only a stable crystal
[18:45:42] <Badaboom> I know:)
[18:45:55] <Badaboom> just thinking outside the xtal,, err box
[18:46:30] <braincracker> i don't get it how an 555 will solve the problem
[18:46:34] <Badaboom> so the xtal is actually from an old Brookstone clock
[18:46:41] <braincracker> ok...
[18:46:42] <Badaboom> should work great
[18:46:49] <braincracker> and all motherboards have it too
[18:47:04] <Badaboom> what's a motherboard?
[18:47:12] <Badaboom> <----Asshole
[18:48:15] <Badaboom> oh come on,, it was a little funny
[18:49:05] <Badaboom> I think i found it on this one im looking at it appears to be near the chipset
[18:50:45] <Badaboom> 32768??
[18:53:08] <Badaboom> Yep 32768 with 12.6pf caps
[18:53:14] <Badaboom> err 12.5
[18:57:08] <Badaboom> 32767.96Hz -1.22PPM with a loss of 3.3sec a month
[18:57:57] <Horologium> http://www.smbc-comics.com/comics/20130628.png
[19:00:16] <Badaboom> damn Badgers
[19:01:59] <Horologium> badger badger badger badger lama!
[19:02:49] <Badaboom> Abstract Oxen??
[19:02:57] <Horologium> that too.
[19:02:58] <Badaboom> lol
[19:14:28] <ambro718> how do I use memory operands in inline assembly? I tried an output operant like this: "m" (&something). I see the compiler chooses the register pair X for the pointer, *but* it assumes that I don't modify it in the assembly.
[19:15:13] <ambro718> so how am I supposed to access X+1 etc from the assembly? I can't do std X+1 because X doesnt' support std, and I can't do std X+ because I'm not allowed to modify X.
[19:43:21] <timemage> ambro718, you can tell the assembly directive that your chunk of asm is going to make use of X.
[19:43:38] <ambro718> timemage: but I don't know that
[19:43:39] <Roklobsta> it's in the avrgcc docs somehwere
[19:43:50] <timemage> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
[19:43:52] <Roklobsta> i am sure i read it recently on how to do it properly
[19:44:14] <ambro718> actually I'm just seeing how a memory operand passed as a constant address, not a register
[19:44:24] <ambro718> timemage: it doesn't ever mention memory operands
[19:46:59] <timemage> ambro718, what are you trying to do?
[19:47:36] <ambro718> timemage: write a function which copies 23 bytes from one place to another
[19:47:56] <ambro718> unrolled, without a loop (which gcc likes to generate)
[19:48:32] <timemage> ambro718, you're sure you have to resort to inline assembly for that?
[19:48:43] <ambro718> timemage: it looks like
[19:48:49] <ambro718> what do you suggest?
[19:49:41] <ambro718> If I just do struct assignment, or even memcpy, gcc uses an inline loop with a counter for each byte...
[19:49:45] <timemage> ambro718, well, you can manually unroll it and just see what the compiler does with your code. if you find it's generating way to much code, see what happens if you apply the restrict keyword where it makes sense.
[19:50:14] <Horologium> the lack of loop is because of a speed issue I take it?
[19:54:57] <ambro718> Horologium: unrolled load/store takes 92 cycles, loop takes 161 cycles
[19:57:58] <ambro718> timemage: tried it in C, compiles all right to ldd+sts :)
[19:58:46] <timemage> ambro718, vs what?
[19:59:15] <ambro718> timemage: vs nothing, the C code with assignment of individual bytes works
[19:59:50] <timemage> ambro718, so,then just a difference between avr-g++ and avr-gcc ?
[20:00:06] <timemage> ambro718, or that messing with assembly was not needed.
[20:00:24] <ambro718> hm no. I just did what you suggested ("manually unroll"), and it produces sane assembly.
[20:00:41] <timemage> ambro718, if you want something a bit more generic look at duff's device.
[20:01:08] <ambro718> i.e. I did this
http://ideone.com/FkKywI
[20:01:19] <ambro718> yeah I know about duff's device ;)
[20:02:33] <Horologium> "sane assembly"
[20:02:40] <seldon> I have a feeling I will regret getting into this discussion, but you can automatically manually unroll loops in C++ with template magic.
[20:04:55] <seldon> template<int n> struct unrolled_loop { static void run(char const *dest, char const *src) { unrolled_loop<n - 1>::run(dest, src); dest[n] = src[n]; } }; template<> struct unrolled_loop<-1> { static void run() { } }; unrolled_loop<23>::run(dst, src);
[20:05:22] <seldon> But I digress; you were talking about sanity.
[20:06:52] <ambro718> http://ideone.com/AxmM7O
[20:06:59] <ambro718> ah you were faster :D
[20:07:21] <Horologium> seldon, sanity is overrated you scurvy son of a programmer's mother.
[20:08:19] <seldon> Well, in production code I'd consider looking into compiler options (and pragmas).
[20:09:11] <ambro718> I've looked in the gcc man page and found nothing that unrolls memcpy on AVR. There are some options for memcpy inlining but they're unrecognized by avr-gcc.
[20:09:13] <seldon> Also, I tend to run out of progmem before I run out of cycles, so I'd only do *that* if I had a particular reason.
