Back
[00:46:41] <shodan45> what's the deal with the ata8743 & similar? is it discontinued?
[00:47:30] <shodan45> it's on atmel.com, but digikey says "call" & mouser says discontinued
[02:19:17] <RikusW> megal0maniac_afk: seems my usbblaster is finally working :)
[02:19:34] <RikusW> at least for erasing my device
[02:19:44] <RikusW> and then blank checking it
[02:20:09] <RikusW> its very much alpha code...
[02:20:34] <DL7LN> good morning everybody!
[03:30:19] <DL7LN> i'm testing around with USART for the first time and i'm getting the following behavior: i'm trying to send for example a 0x30, but on the other side i receive a 0x60-ascii-char. please take a look at
http://paste.lugons.org/show/4970/
[03:30:30] <DL7LN> baud-rate is set to 9600 8n1
[03:31:10] <DL7LN> this is reproduceable for example sending 0x10 getting 0x20 and so on...
[03:31:52] <DL7LN> clocksource is internal and running on 1MHz
[03:38:59] <joh__> Normally you don't have to define when initializing the I2C which ports are the SDA and SCL right? There are standard ports for that on most cards isn't there?
[03:43:29] <Roklobsta> er yes
[03:43:38] <Roklobsta> always check the data sheet
[03:43:52] <Roklobsta> but AFAIK with AVR the signals are fixed to particular pins
[03:48:55] <joh__> Roklobsta: Hmm interesting I'll have to check again. Seen that on some, maybe just missed it on mine
[04:06:49] <zmo> hi!
[04:09:49] <Roklobsta> zmo: too much enthusiasm. tone it down please.
[04:10:32] <zmo> hi.
[04:13:49] <zmo> basically, here am I asking the same question as in the room next door (#arduino): I got an atmega2560, I made the bootloader greet with 'stkv2' when it starts. When I do a brown out reboot, or just after reflashing my firmware, I can see the bootloader greet on the serial line, but when I do a reset or a WDT reset, the bootloader does not greet
[04:14:30] <zmo> so here is my question: how do I make the atmega get through the bootloader on "button" or WDT resets?
[04:15:25] <zmo> I RTFMed over the datasheet, bootloader articles etc..
[04:15:36] <zmo> but found nothing so far
[04:16:48] <zmo> in fuses, reset vector is set to "0"
[04:44:53] <joh__> I am a bit confused by the i2c address in a specification on Atmel. It says: "7-bit i2c address = 0x0E".
[04:45:23] <joh__> Does it mean then for the byte when sent through the I2C to look like "0000 000+RW" or "0001 110+RW" ?
[04:45:46] <joh__> sorry wrote wrong, first example should be "0000 111+RW"
[04:46:25] <joh__> I assume the 0X0E should be bitshifted once, so "0001 110+RW".
[04:48:34] <blathijs> joh__: That's also how I think it works, yes.
[04:49:08] <joh__> blathijs: Thanks! first time doing this and i have no clue what im doing it feels like.
[04:52:10] <blathijs> joh__: I also agree that this stuff is confusing as hell. Using the MSB instead of the LSB for R/W would have been easier :-)
[04:52:29] <joh__> haha agreed. :P
[05:11:14] <megal0maniac_afk> Woah. Arduino YUN. Looking at it as a dev board, it's pretty damn cool
[07:52:30] <Kre10s> Is there a way to reliably get the start of bootloader section from within the application?
[07:53:34] <Kre10s> I want to make a jump_to_boot_loader routine that will find out where the bootloader starts and then jumps to that.
[07:57:54] <zmo> me again, I finally asked my question on SO:
http://stackoverflow.com/questions/19518045/stk500v2-bootloader-only-loaded-on-brownout-reset-not-on-pin-wdt-resets
[07:58:03] <zmo> I hope will be able to help on that
[07:58:29] <zmo> Kre10s - I'm trying to do something close actually
[07:58:43] <zmo> but I was prefering to go through a reset before jumping to the bootloader
[07:59:06] <zmo> Kre10s - basically, the size of the bootloader is known through the fuse configuration
[07:59:30] <Kre10s> ah. you don jmp to ... you let a watchdog expire ...
[08:00:00] <Kre10s> let hardware find the right address...
[08:00:00] <zmo> yup, that's what I'm trying doing but I'm getting an issue there
[08:00:05] <zmo> see my SO question
[08:00:22] <zmo> but in your case, you can either consider the bootloader length known at compile time (using a #ifdef)
[08:00:43] <zmo> or if there's a way to do it, read the fuses settings from your code
[08:01:19] <zmo> once you know the bootloader length, you simply get the start of the bootloader by doing a JMP to the size of your flash memory less the number of bytes of your bootloader
[08:01:56] <zmo> as I've read in the datasheet, the bootloader start is N words before the end of the flash memory
[08:02:22] <zmo> for example, on an Atmega2560 with the fuses set to 000 (maximum), it's 4096 words (so 8192 bytes)
[08:03:03] <zmo> (a word length is 16 bits, so 2 bytes)
[08:03:12] <zmo> (in most AVRs)
[08:04:11] <Kre10s> yes. but the bootloader length method is iffy. because the fuses don't tell you that the bootloader is n bytes long. they tell you how many pages it has... and then you don't know how large pages are. or how many your mcu has.
[08:05:19] <zmo> Kre10s - why would you care? afaict, the bootloader starts at the sizeof(flash)-(N words), so if you do at this address you start your bootloader code how long that code can be
[08:05:21] <Kre10s> I made code for an atmega32. which should run fine on the 64 and equally well on the 16 should it fit in flash...
[08:05:46] <zmo> s/do at/do jump at/
[08:06:42] <Kre10s> but when you move them the code will make the wrong assumptions about the chip size and fail to jump.
[08:06:56] <Kre10s> fail to jump correcly....
[08:07:09] <zmo> well, that's you to make the right code to avoid doing wrong assumptions
[08:07:14] <zmo> actually you can do that check at runtime
[08:07:23] <DL7LN> i have no idea what's going wrong with my USART
[08:07:49] <twnqx> is that nick an amateur radio callsign?
[08:07:51] <zmo> just read BOOTSZ0 and BOOTSZ1
[08:08:06] <zmo> from your code, by include avr/io.h
[08:08:07] <DL7LN> seems like the higher nibble is being left-shifted....
[08:08:12] <DL7LN> twnqx: right...
[08:08:18] <zmo> use a ifdef for the different MCU you may be running your code on
[08:08:23] <Kre10s> zmo, how do i find out the flash size?
[08:08:31] <zmo> that calculates the right size of the flash as a constant
[08:08:43] <DL7LN> i use minicom on the other side...i give a 0x30 on the line...receiving a 0x60...
[08:08:49] <zmo> #if defined( _atmega_2560_ )
[08:08:58] <zmo> #FLASH_SIZE 256
[08:09:00] <zmo> for example
[08:09:04] <zmo> #define *
[08:09:06] <twnqx> did you accidently configure 7n2 somewhere :P
[08:09:58] <DL7LN> twnqx: i don't think so... ldi temp, (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0)
[08:10:05] <DL7LN> that looks like 8n1
[08:10:31] <twnqx> assembler... can't help you there
[08:11:31] <DL7LN> twnqx: but...your idea doesn't seem so far away from the problem....i will set minicom to 7n2 and 7n1 to check whether the data is received correctly
[08:13:21] <Kre10s> zmo, using hardware dependent #defines... will not allow me to build hardware independent executable.
[08:13:46] <twnqx> can you even have those, with IO at different addresses etc
[08:13:59] <zmo> Kre10s - I don't really see the point of having hardware independant executables
[08:14:33] <zmo> but if that's what you want, you can always set up runtime variables with the preprocessor time ifdefs
[08:14:37] <Kre10s> twnqx, if you assume that your working with the same chip _family_ yes.
[08:14:43] <zmo> #if defined ( _atmega_foo_ )
[08:14:53] <twnqx> DL7LN: my chip here has a UCSZ2 and no URSEL, so i can't really look that up
[08:14:58] <zmo> mcu = 1;
[08:14:59] <zmo> ...
[08:15:33] <DL7LN> twnqx: what's going wrong? i switched to 5n2 and the data comes like 8n1
[08:15:37] <DL7LN> no change...
[08:15:37] <zmo> and then do runtime conditionals to get the size of the chip, still using constants
[08:15:47] <DL7LN> maybe the controller sends with 5n1?
[08:15:52] <DL7LN> instead of 8n1?
[08:16:08] <twnqx> maybe you activate synchronous mode? no idea what URSEL does
[08:17:20] <DL7LN> URSEL defines the register to write in. UBRRH and UCSRC shares the same I/O
[08:17:48] <twnqx> definitely a different chip than i have :P
[08:17:56] <DL7LN> :)
[08:17:58] <DL7LN> no problem
[08:18:13] <DL7LN> one day i will get it :)
[08:18:18] <twnqx> there might be one thing
[08:18:36] <twnqx> that ldi...
[08:18:37] <DL7LN> those problems are annoying....but in some kind even interesting :)
[08:19:11] <DL7LN> yes? whatÃ's wrong with it?
[08:19:44] <twnqx> ah, temp is a register
[08:19:57] <twnqx> i thought it was [mem], immed
[09:35:58] <joh__> Hi, I have a project in Atmel Studio and I recently implemented some code using the I2C, however when I compile in Atmel Studio it tells me that "avr/io.h no such file or directory"
[09:36:17] <joh__> isn't that just a standard file? shouldn't it normally work without doing anything extrA?
[09:42:52] <megal0maniac_afk> did you say <avr/io.h> or did you forget the braces?
[09:53:09] <joh__> megal0maniac_afk: Ah I meant <avr/io.h> :)
[09:53:28] <joh__> just forgot to write them here
[11:14:59] <jenia> hello everyone
[11:15:25] <jenia> i want to change the frequency (the clock divider) for the 16 bit registers at run time
[11:15:37] <jenia> when i do that, there's either no change or the thing freezes
[11:16:09] <jenia> is there some tip that i can use?
[11:18:41] <jenia> im using pwm off course
[11:20:12] <dunz0r> What mcu are you using?
[11:21:00] <jenia> one second
[11:21:14] <jenia> AT90USB1286
[11:21:22] <jenia> thats the teensy 2++
[11:22:11] <dunz0r> Any code examples? I suspect you're doing something wrong, but I can't be sure until I see some code :)
[11:22:37] <theBear> hehe, entertainingly phrased :)
[11:23:15] <jenia> okay
[11:23:19] <jenia> ill paste it to pastebin
[11:24:22] <jenia> http://pastebin.com/Sriv4mXm
[11:26:00] <jenia> hehe. i share in your suspicions ;)
[11:28:16] <dunz0r> jenia: I might be missing something here, but I can't find the register WGM13 anywhere on TCCR1A
[11:29:13] <dunz0r> This is the register summary for TCCR1A from the datasheet "(0x80) TCCR1A COM1A1 COM1A0 COM1B1 COM1B0 COM1C1 COM1C0 WGM11 WGM10"
[11:30:13] <jenia> one minute please. let me think this over (im new to this)
[11:30:33] <dunz0r> jenia: It's quite far down in the datasheet :)
[11:31:03] <jenia> table 14-4 page 142
[11:32:15] <jenia> ahh okay
[11:32:36] <jenia> wgm13 is in TCCR1B
[11:45:02] <TechIsCool> So I am kind of curious what everyone uses for the programming wire to board connection. Anyone use something cool the standard is a .100 pitch connection correct.
[11:46:22] <jenia> dunz0r, now the things barely works. it just blinks (like once per second) and doesnt change intensity
[11:47:04] <dunz0r> jenia: It either works, or doesn't work, it can't "barely" work :)
[11:47:22] <dunz0r> jenia: I suspect you've misconfigured your registers. Read the full datasheet.
[11:47:40] <jenia> okay thanks
[11:47:49] <beaky> hello
[11:47:57] <beaky> given a choise of i2c and spi, which should I go for
[11:48:10] <beaky> i am working with external digital sensor
[11:48:41] <beaky> i2c needs only two wires, but it seems 10 times more complicated to work with than spi
[11:49:04] <beaky> whereas withs pi i can just set a couple of registers and periodically wait for readings
[11:51:28] <Kre10s> both i2c and SPI are supported by most avrs. in some cases (mine) i2c won't have any hardware support. in this case its easier to use SPI.
[11:51:57] <Kre10s> you can always bitbang i2c but thats no fun.
[11:52:28] <beaky> so TWI is atmel's name for i2c?
[11:53:03] <Kre10s> TWI is an atmel thingy that can be configured to do i2c... IIRC.
[11:53:52] <beaky> ah
[11:53:56] <beaky> so its like USI
[11:55:57] <Kre10s> hmm. don't know. which chip are you looking at?
[11:59:23] <beaky> attiny44
[12:00:28] <vsync_> TechIsCool: what?
[12:00:51] <vsync_> beaky: are you sure attiny44 is the _best_ mcu for this?
[12:01:19] <TechIsCool> vsync_: the connection for programming your custom boards do you use the normal 6 pin isp header or something custom
[12:01:23] <vsync_> I mean, you always want the absolute best. Have you studied it thoroughly with asking numbnut questions all around aimlessly?
[12:02:00] <vsync_> I, for one, use six spears
[12:02:00] <beaky> yeah i need a low-cost chip with two pwms, one uart, and one adc chanel
[12:02:06] <beaky> oh and one timer
[12:02:12] <TechIsCool> vsync_: Pogopins?
[12:02:19] <vsync_> Javelins
[12:02:26] <TechIsCool> lol :p
[12:02:34] <vsync_> :p
[12:03:18] <vsync_> beaky: yeah. Don't do too much pwming or adcing cus you will run out of battery
[12:03:33] <beaky> ok I will adc for one hour, then i will pwm
[12:03:43] <vsync_> you could - buy two attinys. Use the attiny #1 to pwm the vcc of attiny #2
[12:03:45] <beaky> oops i mean, use my timer to wake up every hour and adc
[12:03:46] <vsync_> saves you
[12:04:23] <vsync_> or well. much simpler if you use like a 555 instead of the attiny #1
[12:04:26] <vsync_> how bout that?
[12:05:22] <beaky> right
[12:05:30] <beaky> but 555 would be more expensive
[12:05:39] <beaky> a single attiny would be most cost effecivet
[12:05:51] <vsync_> umm...
[12:06:11] <vsync_> I doubt a 555 is more expensive than an attiny
[12:06:19] <beaky> 555 + all the configuration components
[12:06:24] <vsync_> not
[12:06:57] <vsync_> remember you are using the 555 to save energy consumed by the avr
[12:07:03] <vsync_> energy saved = good
[12:08:27] <vsync_> attiny "smps" will be more overhead and will be more expensive!
[12:08:30] <vsync_> =D
[12:08:37] <beaky> attiny has atmel's trademarked picopower technology that makes it sip power
[12:08:41] <beaky> in nanoamps
[12:09:11] <vsync_> ...derp
[12:09:29] <beaky> I have strong faith in atmel technology
[12:09:41] <vsync_> I have strong faith in your veroboard soldering
[12:10:54] <vsync_> tech is cool, like someone's nick suggests. However when it's not understood and misused or abused it ceases to be cool
[12:14:21] <TechIsCool> vsync_: really...
[12:14:35] * twnqx abuses TechIsCool
[12:14:42] <twnqx> see, is that cool? :P
[12:17:27] <vsync_> wai kewl
[12:28:08] <ambro718> Are there any open source FAT filesystem libraries I could use in my AVR, *and* with a non-blocking interface?
[12:31:23] <Grievre> how exactly do you do anything non-blocking on an AVR?
[12:33:09] <ambro718> you have a main loop continuously checking for things to do
[12:33:40] <ambro718> my main loop does other important stuff, I don't want to stop doing that while the SD card is busy
[12:41:05] <N1njAway> Typically you use interrupts and/or an RTOS to help with more complex situations.
[12:41:30] <ambro718> yeah I know
[12:41:54] <ambro718> I'll probably end up making a tiny task scheduler to deal with it, just for the fun of it
[12:42:09] <N1njAway> The SDCard is usually not going to be busy long enough to really stall things up much, and you won't even know its state without polling it via SPI transmissions, and since there are no DMA provisions on the AVR series, you are still having to interact with it for each byte transacted.
[12:42:52] <ambro718> do you happen to know how long sdcard operations normally take?
[12:43:07] <N1njAway> Depends on what you are doing.
[12:43:17] <ambro718> probably just reading
[12:43:46] <ambro718> yeah I may just start by letting it block, hoping it won't block for too long
[12:44:07] <ambro718> but I don't like it, lol
[12:45:44] <N1njAway> Sector reads are generally done in chunks of 512 bytes
[12:46:16] <N1njAway> And since it's SPI you have to push the bytes out, pull them back in, and stash to memory.
[12:47:19] <N1njAway> Often better to do that in a single shot as well, as there is a significant amount of overhead with an interrupt call if you trigger on each byte completion of the SPI, but some of that also has to do with how fast you are running the SPI bus, etc.
[12:48:00] <ambro718> but I can do that with a task scheduler too, right?
[12:48:17] <ambro718> i.e. no problem if spi stuff is interrupted and rescheduled later
[12:49:25] <N1njAway> You just have to take in to account additional factors if the SPI bus is being shared.
[12:49:52] <ambro718> ah okay, thanks. I guess I'll know more when I get into it.
[12:50:09] <N1njAway> It's generally a bit easier if it's not. If you need multiple SPI busses, I would suggest a larger AVR part that has multiple SPI peripherals present.
[12:51:17] <N1njAway> I have done applications that use two SPI busses and two UARTs all streaming a pretty reasonable amount of data (including from an SDCard) running at 8Mhz on an ATMEGA2560 without much problem.
[12:59:48] <ambro718> "as there is a significant amount of overhead with an interrupt call if you trigger on each byte completion of the SPI" <-- so the overhead is larger than the time spent polling if you don't use interrupts?
[13:01:54] <ambro718> how does the reading work? Do you tell the sdcard that you'd like to read a sector, the card performs a read, then sends all the data back in a quick burst?
[13:03:03] <ambro718> if that is so I could just have an interrupt that happens when the sdcard is done reading the block (how do I know this?), and then you read all the bytes in a blocking fasion
[13:12:35] <ambro718> if that is so, combined with a task scheduler, I could use a blocking fat library, but still avoid the overhead of polling for when a sector is finished being read (by putting the task to sleep)
[13:17:56] <N1njAway> Sorry, phonecalls here.
[13:18:11] <N1njAway> Have you done SPI communications before?
[13:18:25] <ambro718> I have a bit, but I don't remember much...
[13:18:50] <ambro718> you send something and you get something back, afaik
[13:19:17] <N1njAway> It may be useful for you to get aquainted with doing SDCard transactions first and getting all that working, then figuring out how to extend it from there.
[13:19:38] <ambro718> yeah I figured ;)
[13:19:49] <N1njAway> It's kind of a lot of interlocking details to get a handle on if you've not done it before, but the methods (and limitations) start to become clear pretty quick as you work through it.
[13:20:32] <N1njAway> There is an excellent set of information and code here
http://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-fat32.html that can be useful for starting to explore SDCard stuff.
[13:20:37] <N1njAway> +on AVR
[13:20:47] <ambro718> okay thanks :)
[13:21:05] <N1njAway> Keep in mind that with AVR SPI stuff --
[13:21:56] <vsync_> ambro718: just working on something similar and made some headway. Can ask if you get stuck
[13:22:14] <ambro718> vsync_: nice, thanks.
[13:22:22] <vsync_> or well. just reading. I myself don't need writes
[13:22:23] <N1njAway> The only ISR relating to SPI bus is a "SPI Transaction Complete" interrupt that fires once a full byte has been exchanged. There are regrettably no DMA mechanisms, so you cannot tell the hardware "Move the next 512 bytes on the SPI bus in to block of memory X and tell me when you are done" as you can on more sophisticated systems
[13:22:56] <vsync_> spi's quite basic
[13:23:06] <vsync_> shoudln't be too hard to comprehend that
[13:23:25] <N1njAway> But there is a tradeoff to using interrupts, namely the stack push/pop overhead cycles that happen every time one is invoked, unless you are doing some very tight custom assembler.
[13:26:07] <ambro718> I'm looking at this
http://ideone.com/7nJ0Zl and wondering if there's any way to avoid the overhead of line 19? Can I get notified from interrupt about start of block?
[13:26:15] <N1njAway> So often times if you are using a fast SPI bus, it can be more efficient to do the SPI transactions with the SDCard in a polled fashion, and then let other higher-priority operations (serial interrupts, etc) interrupt that process.
[13:26:50] <N1njAway> ambro: No, not natively with the AVR hardware.
[13:27:18] <N1njAway> ambro: You'd need a more sophisticated processor, or something like an external FPGA helper
[13:27:33] <ambro718> N1njAway: do I understand correctly I'd have to keep polling the sdcard? the card itself is not capable of notifying me any other way?
[13:27:37] <N1njAway> As I always tell people, though -- make it WORK first, make it work BETTER second.
[13:28:01] <N1njAway> All too many times people start looking at things that are really more fine-scale optimizations, before they even have a working solutions.
[13:28:15] <ambro718> the problem with making it work is that if I add long loops in my program that might just make the rest of my program stop working right
[13:28:41] <ambro718> but yeah I'll try that first anyway. I'm still interested in exploring all the possiblities though.
[13:28:53] <N1njAway> Then get so caught up in the details that (without more experience or more information) there is no way for them to choose one method over another. Often times both of which may be equally valid, equally wrong, or equally difficult with little to no gain :)
[13:29:09] <vsync_> ambro718: that's pmuch how spi works
[13:29:35] <ambro718> but you'd just need an interrupt line from sdcard
[13:29:48] <vsync_> yeah, but you don't
[13:30:00] <N1njAway> ambro: Just make sure you have enough information first that it will help you to more intelligently explore the possibilities.
[13:30:39] <N1njAway> The SDCard doesn't have an interrupt lines. It's a SPI slave device at the end of the day. All motion and transactions that happen in it happen because of the master, and the master's clocking.
[13:31:43] <ambro718> does the internal operation of the sdcard also depend on the master clock?
[13:32:02] <N1njAway> It functions from the SPI clock coming in, yes.
[13:32:18] <ambro718> i.e. do I need to poll it a sufficient number of times in order to ever complete a read?
[13:32:49] <N1njAway> It has no on-board oscillators I am aware of, which is one of the reasons after reset and when starting SDCard sessions you need to pump a bunch of dummy byte reads through it so it has clocking to take care of housekeeping and initialization.
[13:32:52] <ambro718> or, if I poll it more slowly, does that make it read the sector slower?
[13:32:54] <vsync_> basically yes
[13:33:28] <N1njAway> ambro: Get a copy of the SD Card specification - it's free and it explains all of this in very specific detail.
[13:33:30] <ambro718> ah ok, I see, thanks
[13:33:34] <ambro718> will do
[13:33:52] <N1njAway> https://www.sdcard.org/downloads/pls/
[13:34:28] <N1njAway> This will all make a lot of sense as soon as you start working with it, I promise! :)
[13:35:00] <vsync_> ambro718: what are you working on, if you don't mind me asking?
[13:35:47] <ambro718> vsync_: reprap (3d printer) firmware,
https://github.com/ambrop72/aprinter
[13:36:04] <N1njAway> There's a few of us in here that have done SDCard stuff on AVR, so some good resources. But to be able to get precise answers, it's helpful to be able to ask precise questions. Which is kind of a chicken-and-egg problem at times :)
[13:36:30] <N1njAway> But work through it, have fun, and you'll be an expert in no time!
[13:36:39] <vsync_> sofa engineering is the biggest problem around here
[13:37:17] <ambro718> I'm just trying to see what it would take do implement it, before I start ;)
[13:37:28] <vsync_> or couch, or armchair
[13:43:17] <N1njAway> Ambro: Helpful piece of advice - start with the biggest and fastest AVR you can, get it working, then scale down from there if necessary.
[13:43:53] <ambro718> Already done (working both on 1285p and 2560) ;)
[13:43:57] <N1njAway> I got my implementation working at 8Mhz, but not without a lot of very precision tuning and coding tricks. It would have been far easier to do at 16Mhz had I provisioned for it :)
[13:44:12] <Kre10s> N1njAway, so true. use this biggest badest devkit you have.
[13:45:01] <N1njAway> Well, I always do full PCBs for all of our designs, but easiest to step it back if cost is a factor. Especially since most AVR's are pin-compatible with other devices in the series.
[13:45:44] <N1njAway> As I like to say, better to have it and not need it to need it and not have it :)
[13:45:47] <vsync_> remember to consult beaky for max efficienct
[13:45:50] <vsync_> efficiency
[13:45:52] <vsync_> *
[13:46:06] <N1njAway> vsync_: Can we clock the SDCard at 1Hz?
[13:46:17] <vsync_> Hmmmm
[13:46:24] <N1njAway> That would be rather fun.
[13:46:30] <ambro718> I already manually check the assembly of all my ISRs (as generated by gcc), lol
[13:46:37] <N1njAway> Seeing how slowly you can transact it. Maybe just toggle-switches.
[13:46:43] <N1njAway> And an LED
[13:46:49] <N1njAway> And a notepad and pen
[13:46:50] <vsync_> Probably we can
[13:46:59] <vsync_> Possibly even under 1 Hz
[13:47:10] <N1njAway> That will consume less electrical energy, and more person energy.
[13:47:20] <vsync_> indeed
[13:47:28] <N1njAway> Anyhow, I'm out - bbl! Good luck ambro!
[13:47:38] <ambro718> thanks, bye
[13:48:39] <Kre10s> i think it would be more power efficient to read/write out data in a quick burst and then turn off the SD card than to keep the sd card idling between 1s clock cycles.
[13:50:42] <vsync_> no-one except beaky should give a rat's ass about power efficiency in a god damn 8 bit mcu
[13:51:14] <vsync_> or an sd card for that matter, hah
[13:52:38] <vsync_> and chances are a 3d printer will run off mains
[13:53:06] <vsync_> or a battery of notable size. The mcu is not the one hogging the power here .p
[13:53:31] <l9> I just stumbled upon something that is so weird that i had too share it
[13:53:34] <l9> https://www.bitcasa.com/pricing
[13:54:01] <l9> if you see they actually promise inifite with storage space
[13:55:42] <vsync_> one would be almost obliged to multi thread something like /dev/random dumping
[13:55:49] <specing> l9: NSA backup
[13:56:22] <l9> I CAN DOWNLOAD INTERNET!!!! WUUUHU
[13:56:28] <vsync_> you should wire up a botnet just to dump data in there
[13:57:13] <l9> how long do you think their drives would have lasted?
[14:02:39] <zmo> re... I'm getting some error using the AVR Dragon:
[14:03:29] <zmo> avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED / ISP activation failed, trying debugWire / bad response to set parameter command: RSP_DEBUGWIRE_SYNC_FAILED / failed to sync with the AVR Dragon in ISP mode / jtagmkII_close(): timeout/error communicating with programmer (status -1)
[14:03:47] <zmo> (I'm using avrdude, as you could guess)
[14:04:06] <zmo> the dragon+dude have been working for the last two weeks
[14:04:37] <zmo> and while I was bringing up a new AVR tonight and I was setting the fuses up
[14:04:48] <zmo> the dragon begun to show that error
[14:05:21] <zmo> I've built a new cable, switched the target board, reboot my computer
[14:05:23] <zmo> nothing changes
[14:16:26] <mdorenka> hi guys, i got a problem with the following code
[14:16:26] <mdorenka> https://gist.github.com/mdorenka/222fa14995444a1655dc
[14:16:42] <mdorenka> it modifies the brightness of an LED based on a value set by an encoder
[14:17:04] <mdorenka> unfortunately it seems to crash from time to time (dobule LED flash as defined in setup() routine)
[14:25:16] <mdorenka> oh and its designed for an attiny84
[14:28:19] <ambro718> it doesn't matter but why are you doing cli on start of isr and sei on end?
[14:28:32] <ambro718> both of these are superfluous
[14:29:13] <mdorenka> this was my first approach to solve the problem, obviously it didnt help :)
[14:30:57] <ambro718> also you can simplify this "if (((pinchange >> PINB2) & 1) == 1) {" to "if (pinchange & _BV(PINB2)) {"
[14:31:42] <ambro718> same for boolean a = (in & _BV(PINB0)) >> PINB0; no need to right-shift
[14:32:03] <ambro718> but this code doesn't seem to do anything that would crash
[14:32:42] <ambro718> oh wait it does
[14:33:41] <ambro718> never mind
[14:35:28] <ambro718> it could be an electrical not a software problem
[14:41:06] <mdorenka> hmmm
[14:41:32] <ambro718> you can try some arduino examples and see if they crash
[14:43:06] <mdorenka> well none of the example uses PCINTs
[14:44:24] <mdorenka> nor are they suitable for attinys (other pin layout, lesser ressources9
[14:47:31] <mdorenka> 21:16 ambro718 • same for boolean a = (in & _BV(PINB0)) >> PINB0; no need to right-shift <- why? the result of the bit-wise and would be something like 0b0001000
[14:50:01] <ambro718> mdorenka: arduino's boolean is an alias for bool which behaves... as a boolean
[14:50:26] <ambro718> when you assign to it, zero-->false, anything else-->true
[14:50:30] <mdorenka> ah okay
[14:50:33] <mdorenka> cool thanks :)
[14:50:41] <ambro718> same thing happens as the argument to if
[14:51:19] <ambro718> what electronics are you using? did you assemble it yourself?
[14:53:09] <mdorenka> yes
[14:53:22] <mdorenka> the attiny is mounted to a breadboard, powered by an ISP
[14:53:42] <mdorenka> the encoder is attatched to a stripboard with pins that are connected to the BB
[14:53:51] <mdorenka> on atmega2560 everything works fine
[14:53:51] <ambro718> check your wiring and voltage, I don't know what else to say...
[14:54:29] <ambro718> datasheet may have some considerations
[14:55:40] <mdorenka> hmm maybe it is caused by misusing PORTB as "internal pullups"?
[14:56:43] <mdorenka> ill try to attach "real" pullups
[14:57:40] <hetii> Hi :)
[14:58:05] <hetii> How to force on android device with OTG to provide power for my custom HID device ?
[14:58:17] <mdorenka> narf ... no resistors in range...
[15:01:18] <hetii> huh i see that is required to short some additional pin :/
[15:17:50] <hetii> What a dump way to do it by this way ... now i need to change my board :/
[15:18:03] <hetii> ehh
[15:18:29] <twnqx> pf, those two pins are a drop of solder
[15:18:46] <mdorenka> ambro718, i tried to add external pullups - didnt help
[15:18:47] <hetii> not in my case :/
[15:20:10] <hetii> I have a board that will switch beetwen host/otg/hid device, the data pin i handle already but now i have this additional one and need to use other connector :(
[15:38:38] <megal0maniac_afk> Anyone seen Dean?
[15:39:14] <megal0maniac_afk> Although judging by twitter, I suspect he might be binge drinking in Germany. Burning up his accumulated leave days before December :P
[15:52:40] <juri_> why would you burn leave before december in germany? burn it during december, by attending the 30C3! ;)
[15:53:12] <inkjetunito> where's 30c3?
[15:55:46] <inkjetunito> bleh. in hamburg
[15:58:28] <MannImMond_afk> megal0maniac_afk yap, Dean is on vacation
[16:00:44] <beaky> hellu
[16:10:42] <vsync_> hiii!
[16:12:00] <megal0maniac_afk> juri_: I'd have to cash in all my leave days just to get to Germany, and even then I wouldn't have enough, plus I wouldn't be able to go anyway because I'd have no leave days so I'd be working and this is all just assuming that I even have a job, which I don't.
[16:12:21] <megal0maniac_afk> So I'll stay here and study for exams :P
[16:15:33] <vsync_> get a haircut and get a real job
[16:16:23] <megal0maniac_afk> My hair is short and I'm not qualified. 2 or 3 more years to go
[16:16:51] <megal0maniac_afk> Holiday work is nice, but not fly-to-Germany-for-a-week kind of money
[16:34:39] <vsync_> not the real preceding the job
[16:34:42] <vsync_> note*
[16:40:13] <megal0maniac_afk> vsync_: Note that my main point was that I'm a student ;)
[16:56:17] <megal0maniac_afk> Also, I never called holiday work a "job"
[16:57:44] <vsync_> no it was sarcasm
[16:57:50] <vsync_> in case not noted
[16:57:51] <vsync_> hah
[17:19:33] <juri_> megal0maniac_afk: I was employed for $40/hr at age 15. whats wrong with you again? ;)
[17:20:30] <juri_> of course, i've been unemployed for three years now, so... all things are relative. :)
[17:22:03] <specing> $40/hr at 15? prostitution?
[17:23:05] <juri_> close. MCSE>
[17:24:35] <theBear> well i can't walk real good, or sit or stand more than about 15-25 minutes, and without mind numbing medication i can't walk at all and end up in emergency crying (and there's nothing quite as sad as watching a grown man crying in sheer pain, and i've operated on myself down to the bone with no anaesthetic, it takes a bit ...) that's why I don't have money :)
[17:30:16] <juri_> i got turned down for a cashier job the other week. according to my source inside of the store, it was because there were darker skinned applicants. irony? i'm an american indian. i appear white, because i have a skin condition that keeps me out of the sun. racist bastards come in all shapes and colours.
[17:31:03] <specing> MCSE + cashier? WTF
[17:31:25] <bss36504> This is the saddest exchange I've ever read on here
[17:32:50] <megal0maniac_afk> juri_: Try that in South Africa :D
[17:35:07] <theBear> specing, heh, you obviously don't know many mcse's without extensive provable real world experience <grin>
[17:35:26] <theBear> and i got 1000/1000 on networking essentials exam late last century, so suck my balls !
[17:35:47] <theBear> aside from that, i'm very ashamed, please forget i mentioned it
[17:35:56] * megal0maniac_afk is doing a Cisco network systems course next year.
[17:35:59] <megal0maniac_afk> Excited
[17:36:54] <bss36504> Question about the Preprocessor:
[17:37:11] <bss36504> If i have #define MY_NUM 0
[17:37:47] <bss36504> then can I have something like #define MY_NUM MY_NUM+1
[17:37:49] <bss36504> ?
[17:37:54] <juri_> specing: I'm 34 now, and entering the 'twilight' of having a career in IT, and cultural relevence. I'm sworn to only use/contribute to free software, so the jobs i can take are 'limited'.
[17:38:01] <bss36504> I get the issue with this would be redefining the macro
[17:38:04] <Tom_itx> bss36504, no
[17:38:08] <megal0maniac_afk> No
[17:38:13] <bss36504> I figured.
[17:38:16] <megal0maniac_afk> Because preprocessor is pre
[17:38:19] <juri_> this place has a free software cash register system. i volunteered to help install it, and i help maintain the code, as free software.
[17:38:20] <bss36504> Is there a way to do this?
[17:38:26] <megal0maniac_afk> +1 is processing
[17:38:29] <Tom_itx> think of a #define as the expression you assign to it
[17:38:42] <Tom_itx> #define idiot notme
[17:38:59] <bss36504> Right right, I know that, I just hoped that maybe there was something I didnt know abou the preprocessor.
[17:39:08] <Tom_itx> the preprocessor replaces the expression
[17:40:12] <bss36504> Like for example, I have a macro that instantiates a struct based on args, and then I want to create an array of the same number of instantiated things. Now I have an automatically sized (by the preprocessor in a perfect world) array that i can fill with, say, pointers to these structs.
[17:40:35] <megal0maniac_afk> In any case, defines are constants. So if you're using them like you should be able to calculate the values you want while coding
[17:40:44] <megal0maniac_afk> The preprocessor is quite dumb
[17:40:54] <bss36504> Oh wait, apparently there is something possibly supported called __COUNTER__
[17:41:11] <bss36504> http://stackoverflow.com/questions/652815/has-anyone-ever-had-a-use-for-the-counter-pre-processor-macro
[17:41:34] <megal0maniac_afk> How can it be capital (constant) and a counter (variable)?
[17:41:56] <bss36504> Because it's a compiler specific symbol, not a standard define
[17:42:05] <bss36504> sort of like __ATTRIBUTE__
[17:42:12] <bss36504> I think*
[17:42:44] <bss36504> well, lets see if it works...
[17:43:28] <megal0maniac_afk> Cool :)
[17:44:29] <twnqx> megal0maniac_afk: don't take cisco courses, get to understand networking first :P
[17:47:11] <bss36504> well that's sad, it appears __COUNTER__ is unsupported by avr gcc. This would do exactly what I wanted.
[17:48:28] <bss36504> Then again, maybe it is...
[17:48:32] <bss36504> I'll post later
[18:13:30] <ambro718> sounds like you need to get acquainted with C++ templates ;)
[18:14:23] <bss36504> Alright, Atmel Studio seems to want to let me use __COUNTER__ (it pops up the autocomplete) but it doesn't seem to work. And ambro718, I'm still in the process of learning C++, but my C is pretty dang solid.
[18:15:18] <ambro718> templates are one of the few C++ features useful for embedded, you don't need to bother with much more
[18:16:14] <ambro718> my C++ embedded code is really just C + simple classes (no inheritance/virtual/constructors etc.) + templates
[18:16:35] <bss36504> That would be handy to know for sure.
[18:16:58] <bss36504> I have OOP programing down as well (very comfortable with Java). Really its just learning the semantics of C++
[18:19:01] <ambro718> Don't try to transfer all your Java OOP skills to embedded C++, that would not end well ;)
[18:19:13] <N1njAway> C++ is very useful from an organizational standpoint as an extension to simply using classes, but a lot of the general power of C++ is often not used in embedded as much due to memory limitation and a limited or nonexistant heap. I've found it easier to use for writing reusable code, however, since well-written C++ allows design-by-composition very easily.
[18:19:43] <bss36504> whats wrong with System.out.println on my mcu?
[18:19:49] <ambro718> N1njAway: nobody is forcing you to use a heap. Using C++ in embedded in no way implies using a heap.
[18:20:00] <theBear> bss36504, i'm gonna guess it's not working :)
[18:20:08] <N1njAway> ambro: new and delete won't do much without a heap :)
[18:20:11] <theBear> woah, sorry, skipped channels without noticing
[18:20:19] <ambro718> ah sorry I didn't read your statement right, yes...
[18:21:18] <N1njAway> C++ is one of those things as well where to use it effectively, you first need to learn the syntax, learn how to write it well, and then learn how to use it effectively with design patterns and loosely-coupled objects.
[18:21:27] <ambro718> but still, IMO the most useful C++ think in embedded is templates. And I mean hardcode template metaprogramming, like passing compile-time lists to classes and having those classes do something for each element of the list.
[18:22:06] <N1njAway> I've seen HORRENDOUS C++ code that pretty well eliminates most of the overall benefits of the language because people start using very tightly-coupled code, which them immediately eliminates the ability to easily extend or reuse much of it.
[18:23:01] <ambro718> as a simple example, I have an AvrAdc class template, which is given a list of ADC pins, and it continously samples those given pins with the ADC.
[18:23:24] <N1njAway> That and without loose coupling, projects that start to have hundreds of source files and classes start taking 20 minutes to compile, because changing one thing forces the dependency chain to need everything to be retouched.
[18:23:30] <ambro718> Something like AvrAdc< MakeTypeList< AvrPinA0, AvrPinA2 > >
[18:23:59] <ambro718> adc.getValue<AvrPinA0>();
[18:24:51] <N1njAway> I also personally like C++ for the simple fact of using class-embedded enums. I avoid #defines because they clutter the hell out of the namespace, cause additional cross-dependencies, and generally you have no idea where they are being used or what they are being used for.
[18:25:25] <ambro718> N1njAway: I have full freedom to use C++ however I find most useful. I don't care about the "idioms", and especially when the idioms are inappropriate in the context.
[18:25:34] <N1njAway> Small projects aside, of course, thay may only have one or two source files. Global variables are generally more forgivable in smaller embedded projects as well
[18:26:26] <N1njAway> ambro: C++ power comes from having many, many different solutions to approaching a problem, all of which may be equally valid in certain circumstances.
[18:26:33] <Kre10s> are we using c++ on avrs now?
[18:26:34] <ambro718> yep
[18:26:55] <Kre10s> that sounds worse than the last idea we had.
[18:26:58] <N1njAway> Kre10s: I use C++ for a lot of my AVR work simply for organization sake of reusable classes.
[18:27:00] <ambro718> to both ^ ;)
[18:28:57] <ambro718> here's this AvrAdc class I mentioned,
https://github.com/ambrop72/aprinter/blob/master/aprinter/system/AvrAdc.h
[18:29:04] <N1njAway> I'm also used to working on projects that contain hundreds or more classes, so there are some methodologies of larger-scale design that simply aren't always warranted on simpler embedded designs that might have only a half-dozen source files. :)
[18:29:31] <ambro718> some infrastructure needs to be developed before you can works on lists like that (e.g. TupleForEach*) but once you work on it a bit it becomes easy
[18:30:23] <N1njAway> ambro: Yes indeed. And again, writing things with the intention of loose-coupling suddenly allows you to reuse code a lot more because you can pick and choose elements to composite together, like with your template examples.
[18:31:16] <N1njAway> Templates let you do some incredibly powerful stuff in C++ for sure.
[18:31:54] <juri_> ok, GICR is all zeroes, and when i call CLI, i get sent to the bootloader.
[18:32:26] <N1njAway> CLI or SEI?
[18:32:35] <juri_> CLI.
[18:32:55] <N1njAway> And you aren't using the watchdog?
[18:33:42] <juri_> I'm not..
[18:34:10] <N1njAway> That seems odd, then. I could possibly see it for SEI, but not for CLI. CLI shouldn't cause anything abnormal to happen when disabling interrupts.
[18:36:26] <N1njAway> Are you using the bootloader and associated bootloader reset fuse to jump the micro in to the bootloader on start?
[18:36:59] <N1njAway> That's why I had asked about the watchdog, as there's very few other things I can think of offhand that would cause it to reset-vector when turning OFF interrupts.
[18:40:00] <juri_> this chip appears to be ignoring the bootloader reset fuse, and jumping directly to the application.
[18:40:33] <juri_> should i be disabling the watchdog timer?
[18:41:30] <N1njAway> The watchdog won't run unless the fuse for it is set, or you are enabling it in software. If neither of those apply, you can rule out the WDT :)
[18:41:50] <Tom_itx> the bootloader may enable it
[18:42:06] <juri_> the bootloader isn't.
[18:42:06] <N1njAway> Do you have your bootloader installed at the right address, and is the BOOTSIZE fuses set correctly to point at it?
[18:42:15] <juri_> i control the bootloader and the app. ;)
[18:42:24] <juri_> yes, and yes.
[18:42:40] <N1njAway> Do you have HWB utilized?
[18:42:48] <N1njAway> What part, btw?
[18:42:52] <juri_> HWB?
[18:42:56] <juri_> 8535.
[18:43:03] <Tom_itx> it's on usb chips
[18:43:10] <Tom_itx> not on the 8535
[18:43:29] <Tom_itx> rather old critter
[18:46:27] <juri_> i'll be replacing it with a atmega48, soon as i get done developing the app.
[18:47:41] <Tom_itx> you may have some stuff to change code wise
[18:48:02] <Tom_itx> s/may/will
[18:48:03] <N1njAway> Yeah no HWB on that one, so that rules that out :)
[18:48:17] <N1njAway> Didn't know what part was being used
[18:48:35] <Tom_itx> N1njAway, pretty sure that's just on USB enabled chips
[18:50:06] <N1njAway> Tom: Yes, that's the only place I've seen it. I've done a bunch of 32U2 and 32U4 designs.
[19:26:23] <bss36504> on a scale of 0 to the worst thing ever, how bad would it be to use the setjmp library to perform context switching in a priority scheduled OS (it's not real-time strictly speaking)?
[19:27:03] <bss36504> I was going to malloc and free the necessary context buffers as needed.
[19:36:11] <bss36504> Actually, I guess making a setjump buffer for each task wouldn't be too terrible, since it's going to be some overhead+whatever the task uses for ram, which I believe is pretty typical for most RTOSs. Maybe I'm totally wrong though.
[19:42:30] <Roklobsta> i made a preemptive avr scheduler recently. dead simple. works. i should clean it up and post the code some time.
[19:43:06] <bss36504> Please do, I'm kind of enjoying this process though. I think I'm doing it right, but if not I'm not gonna whine about it.
[19:43:15] <Roklobsta> the idle task calls the sleep opcode.
[19:43:33] <Roklobsta> it was interesting. I need to doco it before I forget the details.
[19:44:39] <Roklobsta> but all you have to do is set up all the task function pointers, their stacks and that's it. i wrote it for an application in mind and it handles RTS/CTS for UARTS.
[19:45:33] <Roklobsta> it also has an i/o wait and sleep call which gives up the task quantum too.
[19:46:48] <Roklobsta> i'd like to abstract some SPI and I2C drivers too to remove some of the headaches.
[19:49:40] <bss36504> Right, so maybe I'm not that far off the mark. I have a nice struct (typedef'd as "task") that has some info for the task such as the priority (non unique), the ID (unique) and two function pointers, one points to the execution code that does stuff, the other was going to point to a simple function that checks to see if this task even wants time. There will be a timer interrupt that checks to see if each task wants to run, and if they
[19:49:41] <bss36504> do, then they get put in a priority queue. The scheduler now uses setjump (this is the part I haven't implemented yet) to store each context of each task function, and then run the one on the top of the queue. I also have in the task struct a "maxTicks" variable simply to act like a watchdog of sorts to help prevent tasks from hanging. I plan to make it so that if they exceed that, their whole context is destroyed, and a new one is
[19:49:41] <bss36504> malloc'd
[19:50:45] <bss36504> This way, I have a task queue that changes in size (probably implemented as a linked list of structs), and thus it should improve the overall servicing time in the timer interrupt.
[19:55:36] <Roklobsta> being an AVR my task list is simple and is an array and just iterates to the next task each time the timer ticks. if the next task has some i/o ready, it not sleeping any more or just in a run state it's called.
[19:55:48] <Roklobsta> along with the stack context switch
[19:56:37] <Roklobsta> if the task scheduler completey loops through the table and doesn't find a task to run it sleeps (idle task) until the next tick.
[19:56:47] <bss36504> Oh so are you saying that your tasks are effectively equal priority, but you just decide to run them if they are ready?
[19:56:52] <Roklobsta> yes
[19:56:59] <Roklobsta> it's an avr after all.
[19:57:28] <Roklobsta> having the sleep and i/o wait i didn't need priorities, yet.
[19:57:54] <Roklobsta> i mean sleep yield and i/o yield.
[19:58:01] <tzanger> I always think that people trying to implement tiny RTOSes inside AVRs are going about things the wrong way
[19:58:04] <tzanger> it's a great idea in theory
[19:58:14] <Roklobsta> what is the wrong way?
[19:58:44] <tzanger> Roklobsta: creating generic multitasking RTOSes for tiny micros
[19:58:59] <Roklobsta> like what i have done or what freertos has done?
[19:59:22] <tzanger> don't know what you've done, I'm reading what bss36504 said
[20:01:00] <tzanger> with the tiny micros you usually end up consuming a lot just with overhead, and then if you need to start with locking primitives and making device drivers generic enough to fit with a generic RTOS implemetation it just becomes a solution looking for a problem IMO
[20:01:17] <tzanger> larger micros it makes a lot of sense
[20:02:07] <Roklobsta> yeah i realy dont like the 33 pops and pushes i do in my context switch
[20:02:42] <Roklobsta> i brifly had a look at concurreny and the pico thread idea used in contiki
[20:03:45] <Roklobsta> but i'll get my current rtos working to satisfaction first before i start onto something perhaps more efficient.
[20:04:28] <bss36504> It's mainly a learning experience for me, tzanger, but I totally understand your point. It' been brought up before.
[20:04:29] <Roklobsta> i just watnted independant processes.
[20:04:57] <Roklobsta> that might communicate of need by via shared mem
[20:06:06] <Roklobsta> at the time i figured i could do my own rtos in the time it took me to learn and fluff about with something like freertos. and doing ones own meant i learned a few thinsg too.
[20:07:49] <Roklobsta> considering the last time i did something like it was a class assignment in 1993 on a 68000.
[20:07:52] <N1njAway> bss: Not sure if there's a lot of benefit to linked lists in embedded stuff unless you are needing to reorder items or are going to write something to emulate heap allocation, or have some other specific need. Seems safer to just define how many items maximum a list will hold and just do it as a contiguous array :)
[20:07:58] <tzanger> oh yes building an OS is quite an undertaking and you learn a LOT
[20:08:06] <tzanger> especially when you're debugging it. :-)
[20:08:07] <N1njAway> Er embedded stuff == on an AVR
[20:08:14] <Roklobsta> the 68000 is well set up for context switch with it's link/unlink opcodes.
[20:08:52] <Roklobsta> i am sure my scheduler is the 1000000th one written for AVR
[20:09:09] <N1njAway> Any time you get in to heap needs, you start to risk problems wih fragmentation, which can get dicey in things with super-limited resources and no memory paging.
[20:09:34] <Roklobsta> yeah if you need a frickin' heap you shouldn't be doing embedded.
[20:09:37] <Fornaxian> if only the avr could execute code from sram..
[20:10:15] <Roklobsta> avrgcc shouldn't support malloc/free on principle.
[20:10:28] <N1njAway> Roklobsta: Well which is why I clarified with "AVR" instead of "embedded" as things like ARM can handle heap much more eloquently. But I still prefer static allocations for things anyhow.
[20:11:10] <Roklobsta> ok i'll grant that for MIPS and ARM etc heaps are OK as you usually have a 1MB or RAM or so.
[20:11:21] <Roklobsta> heap is silly on an 8kB system
[20:11:43] <N1njAway> Roklobsta: C++ new[] and delete[] can be useful if you use them with their in-place allocation style calls. If you REALLY need it, you chunk off a block of RAM and do a memory pool so you can at least release the whole thing at once yourself. But again, if you need heap on an 8kB system, you should probably be rethinking your approach :)
[20:12:32] <Roklobsta> my fave is n00b's not ensuring all their constant data doesn't get copied to RAM at boot.
[20:12:42] <N1njAway> PROGMEM what?
[20:12:52] <Roklobsta> damned n00bs
[20:13:04] <N1njAway> Is beaky copying constants to RAM at 1Hz?
[20:13:12] <ambro718> isn't flash memory mapped?
[20:13:15] <bss36504> Roklobsta @ 8:50 echo's my sentiments. FreeRTOS seems too big for me to get to know in short time. N1njAway, Linked list for priority queue; highly efficient, especially since each task struct has a pointer to the next.
[20:13:16] <N1njAway> To save power?
[20:13:44] <N1njAway> bss: So static allocation, but linked list for rearranging priority order?
[20:13:52] <bss36504> yes
[20:14:15] <Roklobsta> if i decide to do priorities i'll swap from a table to a linked list
[20:14:21] <ambro718> but you can statically allocate linked lists!
[20:14:43] <ambro718> keep unused entries in one list
[20:14:46] <N1njAway> Unless you have more than 256 tasks, I'd reccomend an index byte rather than a full-blown linked list, as an u_int8 is going to be smaller than a * anything :)
[20:14:47] <bss36504> N1njAway: but now that I think of it, a pointer to the highest priority will serve exactly the same purpose that I need
[20:14:49] <bss36504> lol
[20:15:24] <MarkX> hi
[20:15:44] <bss36504> N1njAway: I'm holding almost this whole program in my head, so the specification and process is still a little fuzzy
[20:16:11] <N1njAway> bss: Just use indexing of a fixed array of structures. Everything will always appear in memory in the same place anyhow since it will all need to be statically allocated anyhow. If it was a PC application and heap and size weren't an issue, I'd totally aggree with you. But linked lists are generally not of much use without dynamic allocation.
[20:16:23] <Roklobsta> i am halfway through abstraction for file I/O so that i can write things like command lines that will work just as well on a UART or TCPIP port with lwip
[20:16:31] <N1njAway> -duplicate anyhow
[20:17:15] <N1njAway> Roklobsta: Nice! How do you like lwip so far? I've started playing with it on ARM, but still considering writing my own implementation as an excercise.
[20:17:28] <Roklobsta> i'm not at lwip stage yet!
[20:17:38] <Roklobsta> in fact i haven't done anything on it for a while. time to get back into it.
[20:17:50] <bss36504> oh right N1njAway, the one thing you haven't done yet
[20:18:32] <N1njAway> LOL one
[20:18:33] <Roklobsta> once that is done, i'll get ZFS and an array of SPI SD cards going.
[20:19:03] <N1njAway> bss: I've been playing with low-level Ethernet frames lately on some of the SAM4 devices, so look out :D
[20:19:19] <bss36504> Oh jeez. that stuff frightens me more than USB.
[20:19:44] <N1njAway> bss: I just think it would be a fun thing to get under the hood with. Really the only complex part of it is TCP. UDP and Layer2 stuff is pretty darn basic.
[20:20:12] <bss36504> I almost made up a project at work that was a PoE and multi-endpoint tester array for memory chips. Was gonna be friggin epic, but so, so hard for a greenhorn like me (also working alone)
[20:20:30] <ambro718> lwIP is very nice to use. Some time ago I made this with it,
https://code.google.com/p/badvpn/wiki/tun2socks
[20:20:33] <bss36504> I was gonna have to write all the hardware code, plus the computer side socket server deal
[20:20:36] <N1njAway> I keep threatening to write a technical blog one of these days. There's a lot of stuff I could write about that might be useful to people. :)
[20:21:22] <N1njAway> ambro: Nice!
[20:21:24] <bss36504> Its nice to look at a project from up high, but then you get down to basic protocol specs and it becomes more complex very fast.
[20:23:04] <N1njAway> bss: Devil is always in the details. But see at least YOU recognize that. Versus the armchair engineers that are all "Well you just do this and that and BOOM IT JUST WORKS!"
[20:24:09] <bss36504> Yeah, fortunately, I can always tell my bosses "I'm still an intern, I'm still learning, you are less helpful than me at embedded design".
[20:24:14] <N1njAway> And boom goes the dynamite. That dynamite being Arduino, going "You want me to do WHAT?!"
[20:24:27] <bss36504> hahaha
[20:25:10] <tzanger> I've thankfully never had to implement IP on a micro
[20:25:17] <N1njAway> bss: Because seriously... AVR has an opcode that is called OpenUART(), and you call it and pass a string, and it shovels the byes out the port!
[20:25:20] <tzanger> the worst was BCSP/L2CAP
[20:25:55] <tzanger> and even then I had the developer of btstack helping me understand some of the finer details of BCSP
[20:26:42] <bss36504> N1njAway: Yes, that's part of the RISC instruction set. They were like, "well lets just abstract over the accumulator and registers, and make all these opcodes better"
[20:26:52] <bss36504> "they" being Atmel :P
[20:27:20] <N1njAway> bss: You mean Arduino doesn't make new opcodes appear in the process when you upload a sketch? That's DUMB! XD
[20:27:26] <N1njAway> +processor
[20:27:56] <tzanger> lawl
[20:28:14] <tzanger> I want an instruction modifier named DWIM - do what I mean
[20:29:02] <bss36504> I should be able to just verbally describe to the arduino IDE what I want in terms of "Well see man, what I want is a thing that does some stuff when I push the button"
[20:29:05] <N1njAway> tzanger: And JMIW -- just make it work -- which is an extended debugging opcode
[20:29:18] <tzanger> N1njAway: every time I try to implement that I end up with a mess
[20:30:03] <bss36504> You could make millions if you succeeded.
[20:30:12] <bss36504> Closed source that kind of idea!
[20:30:14] <N1njAway> bss: Yes, Arduino's IDE needs a microphone input. Like we take a DJ, DragonNaturallySpeaking, some AI, and run them through the linker and we see what comes out.
[20:30:42] <bss36504> probably the most optimized and efficient code ever written.
[20:31:05] <N1njAway> bss: A loop so tightly written that it collapses in on itself like a singularity.
[20:31:36] <bss36504> now that's one tight ass loop, brah (as the kids say)
[20:31:41] <N1njAway> bss: Efficiency SO AMAZING that you don't even NEED IT
[20:32:20] <N1njAway> bss: And power-consumption SO LOW that it lowers the ambient temperature of the microcontroller like a Peltier cooler.
[20:32:30] <bss36504> Thats more efficiency than my micro has room for (< -- reminiscent of Power Thirst)
[20:32:52] <bss36504> The software is so good that it changes the device characteristics
[20:33:23] <N1njAway> IT HAS LIGHTNING. REAL-MODE LIGHTING! (for those x86 PowerThirt fans out there)
[20:33:46] <bss36504> Like a micro controller made of BICEPS!
[20:35:02] <bss36504> "With the new and improved Arduino IDE, you can make your very own bear blaster!"
[20:35:41] <theBear> that's not very nice
[20:36:09] <Tom_itx> :(
[20:36:23] <N1njAway> theBear: Hey, he didn't say "your very own theBear blaster!" :)
[20:37:53] <N1njAway> The Arduino IDE is now so sophisticated that you don't even need an Atmel, dev-board, or programmer. When hooked to a RepRap or Makerbot, it actually PRINTS your final working design and comes out with the code actually running.
[20:38:35] <N1njAway> It just runs kind of wobbly and the fine details are kind of non-existant, but other than that it... oh wait, that's kind of how it is now.
[20:39:26] <N1njAway> But damn, can you print some mean AVR coathangers!
[20:39:44] <N1njAway> But I kid, of course. :)
[20:39:53] <theBear> i don't think he likes me after the other day :-( for a crazy dangerous psychotic sociopathic kinda bear, i'm quite sensitive on the inside
[20:40:11] <MarkX> any recommendations for a (preferably tested) PID library?
[20:40:44] <bss36504> N1njAway: nah, I dont need to blast theBear :P
[20:41:08] <bss36504> MarkX: I dont know of one, but it should be fairly simple to make a simple one.
[20:41:31] <MarkX> bss36504: i was thinking of just porting over the android one
[20:41:40] <MarkX> PID isn't much beyond the equation
[20:41:40] <N1njAway> Yeah, I was gonna say... The PID thing seems like it is going to be fairly specific to the application that needs the PID
[20:41:50] <bss36504> MarkX: That seems impossible.
[20:41:56] <MarkX> ???
[20:41:58] <bss36504> android is java, avr is c or C++
[20:42:08] <MarkX> logic is logic :P
[20:42:21] <bss36504> Oh, well thats not exactly porting per se :)
[20:42:24] <N1njAway> That's not logical!
[20:42:34] <MarkX> heh
[20:42:35] <theBear> awesome ! now the rebuilding can begin <grin>
[20:42:57] <MarkX> i meant i can use it as a reference
[20:43:00] <theBear> sidenote: i'm sorry i upset you bss36504, i didn't intend to
[20:43:13] <MarkX> i was just hoping to find one that had been tested and reliable
[20:43:14] <MarkX> :P
[20:43:16] <N1njAway> Man, I think I should get the rest of these units built and calibrated so I can get out of here for the night... And go start on my network stack on the couch at home XD
[20:43:46] <bss36504> theBear: Nah, it's alright. I was just feeling like a buzz killington was swooping in.
[20:44:06] <N1njAway> MarkX: Just use the AVR PID instruction to do it! Right tzanger? :D
[20:44:25] <bss36504> N1njAway: Why are you still at work!?
[20:44:40] <bss36504> also, haaaaaa
[20:45:53] <MarkX> N1njAway: i'm not a developer
[20:45:56] <MarkX> :P
[20:46:24] <MarkX> i barely understood the first few paragraphs of the atmel provided "tutorial"
[20:47:13] <bss36504> Which tutorial was that? Perhaps you'd like to start at the links at the top of the IRC
[20:47:37] <MarkX> https://www.google.ca/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.atmel.ca%2FImages%2Fdoc2558.pdf&ei=iyVnUsqEIubK2AWvgIGwDA&usg=AFQjCNEsHLptFasMR-elzykppKP6wY3llg
[20:47:39] <MarkX> oops
[20:47:40] <MarkX> soprry
[20:47:46] <MarkX> http://www.atmel.ca/Images/doc2558.pdf
[20:47:55] <MarkX> i'd say thats more of a whitepage than a tutorial
[20:47:55] <N1njAway> MarkX: That was a joke. I think you came in slightly afterwards. We were making up silly opcodes that solve problems in a single clock cycle.
[20:48:22] <MarkX> ......
[20:48:24] <MarkX> .....................
[20:48:31] <MarkX> you guys need to get laid
[20:48:35] <MarkX> XD i kid i kid
[20:48:37] <N1njAway> bss: Because when you run the company, you work long hours XD
[20:49:04] <N1njAway> Oooh, perfect.... AVR opcode "LAID" -- improves the compiler's morale and leads to better long-term optimization
[20:49:29] <MarkX> but the longer that opcode goes unused, the more irritated the compiler becomes
[20:49:40] <MarkX> then one day it masters portuguese
[20:50:01] <bss36504> Speaking from experiance MarkX?
[20:50:04] <bss36504> :P
[20:50:06] <MarkX> seinfeld ;)
[20:50:09] <bss36504> ah
[20:50:19] <MarkX> http://en.wikipedia.org/wiki/The_Abstinence
[20:50:23] <bss36504> N1njAway: What's your company called again?
[20:50:25] <MarkX> and yes experience :P
[20:50:26] <N1njAway> MarkX: "Why didn't you get the BIG one?"
[20:50:31] <bss36504> :(
[20:51:49] <MarkX> N1njAway: i went on a cruise last week, was any of your handy work utilized there?
[20:52:10] <N1njAway> MarkX: Heh, which cruiseline?
[20:52:19] <MarkX> one of your clients ;)
[20:52:25] <bss36504> So confused.
[20:52:38] <bss36504> 0_0
[20:53:59] <N1njAway> MarkX: If the cruise happened to have any of
http://www.youtube.com/watch?v=6x8NQvaIluo then..... maaaybe :)
[20:54:05] <N1njAway> I know nothing!
[20:54:21] <MarkX> hahaha
[20:54:24] <MarkX> no unfortunately not
[20:54:28] <MarkX> otherwise i'd have bought one
[20:54:30] <MarkX> those things are sick
[20:54:38] <MarkX> i'd def try and make it work with everything else
[20:54:44] <MarkX> ....how hard can it be :P
[20:56:24] <N1njAway> It's amusing reading some of the tech teardown forums. Some people are pretty well dead-on, some people are so completely far off the mark that it makes it sound like launching the space shuttle in complexity.
[20:56:36] <MarkX> im assuming
[20:56:55] <MarkX> hmmm
[20:57:04] <MarkX> bluetooth might be too expensive
[20:57:10] <N1njAway> It's all IR
[20:57:13] <MarkX> ah
[20:57:20] <MarkX> i'd have gone with FM
[20:57:24] <MarkX> just cause
[20:57:24] <MarkX> XD
[20:57:37] <N1njAway> Can't do spatial-based effects
[20:57:43] <MarkX> ah good point
[20:58:06] <MarkX> so just multiple access points with local clients
[20:58:12] <MarkX> which have limited range
[20:58:21] <MarkX> :P
[20:58:52] <N1njAway> And RF is a lot harder to deal with, more expensive, and more difficult to deal with due to international restrictions, etc.
[20:59:48] <N1njAway> But IR on that scale has a unique set of challenges to overcome in its own right.
[21:00:40] <MarkX> see
[21:00:41] <MarkX> thats wicked
[21:00:47] <MarkX> i'd love to work on projects like that
[21:00:53] <MarkX> "heres what we need, make it"
[21:00:56] <MarkX> "k"
[21:01:18] <N1njAway> Go out and persue those kind of projects. They're out there!
[21:01:24] <MarkX> making my own
[21:01:26] <MarkX> :D
[21:01:35] <N1njAway> Perfect starting point!
[21:01:38] <MarkX> in the mean time, job pays off the debts
[21:01:47] <N1njAway> Also important.
[21:01:50] <MarkX> but its like bill burr's comedy skit
[21:02:08] <MarkX> i'm like a rock in the ocean and this job is the tide....slowly eroding me away
[21:02:08] <MarkX> XD
[21:02:09] <bss36504> I have a list of places I want to work: Sparkfun, Total Phase, Atmel and some others.
[21:02:24] <tzanger> you could get away with that with 433MHz cheap stuff
[21:02:50] <tzanger> I would have thought the lighting effects in the show would have provided too much interferene
[21:03:07] <N1njAway> Remember, the walls are there to make us prove how badly we want something. They aren't there to keep YOU out, they are to keep everyone ELSE out who isn't willing to scale them.
[21:03:33] <MarkX> looks that way when i look at the "lifers" at my company
[21:04:32] <N1njAway> tzanger: IR transmissions are particularly good at being filtered out on basis of wavelength and carrier. Some of the Vishay 3-pin devices are perfectly happy picking up data at 0.5 nanowatts/cm^2
[21:04:37] <tzanger> http://stuffandymakes.com/2012/07/08/disney-glow-with-the-show-ears-teardown/
[21:04:40] <tzanger> that seems pretty accurate
[21:04:53] <tzanger> N1njAway: nice.
[21:05:18] <MarkX> N1njAway: have you guys ever sent an anonymous message "dude you got it" when someone figures it out?
[21:05:19] <MarkX> :P
[21:05:51] <N1njAway> MarkX: No, people just disappear in to the night. XD
[21:06:04] <MarkX> ,,,,,
[21:06:17] <MarkX> well thank god i was miles off :P
[21:06:51] <N1njAway> To be fair, I subcontract. But I CAN tell you the Hidden Mickeys run deep. VERY deep. :)
[21:07:07] <tzanger> N1njAway: you're a contractor as well?
[21:07:13] <tzanger> or you subcontracted it out
[21:07:44] <MarkX> yea they showed us those on the cruise
[21:07:51] <N1njAway> Sorry, clarity. I am the subcontrator :)
[21:07:54] <MarkX> some were very intricate
[21:08:33] <N1njAway> Pretty nice soup-to-nuts operation here. Everything from PCB design to board layout, software, firmware, and full in-house SMT assembly.
[21:08:52] <N1njAway> Basically have vertically-integrated us as much as possible to work very, very fast.
[21:09:41] <tzanger> N1njAway: how many people?
[21:10:00] <N1njAway> My interests revolve primarily around entertainment technology design, especially the really fring/challenging custom stuff.
[21:10:25] <N1njAway> tzanger: Depends as it can vary from project to project, but usally 4-5 full-time people around here, and growing.
[21:10:46] <N1njAway> We have gotten good at doing a lot with a little.
[21:11:08] <N1njAway> But it's definately a lifestyle for me. I love working on this stuff, and I love working with cool people.
[21:11:14] <tzanger> oh yeah
[21:11:18] <tzanger> that's why I got into it
[21:11:18] <N1njAway> And talking to cool people, like you guys.
[21:11:19] <MarkX> N1njAway: thats an awesome description...
[21:11:22] <N1njAway> I'm big on paying it forward.
[21:11:25] <MarkX> might if i steal it?
[21:11:30] <MarkX> s/might/mind
[21:11:32] <tzanger> when I could finally no longer have a full time job and contract, I quit the full time job
[21:11:39] <tzanger> been at this full-time for 8 years now
[21:11:58] <N1njAway> So many people have helped me out in getting to work on some of the stuff I am now, many whom I will never be able to properly thank. So you pay it forward.
[21:12:44] <MarkX> heh
[21:13:07] <N1njAway> I honestly wish I had more time (or need to MAKE more time) to just write and document stuff. I commend Dean on here for all the awesome stuff he's done with LUFA and pushing it out there. We've developed a lot of great stuff that we want to opensource - the problem is finding the time to document it well enough for others to use.
[21:13:34] <MarkX> hmmm
[21:13:51] <N1njAway> So in the meantime, I at least like to keep this window up and help AVR folks where I can as time permits :)
[21:13:59] <MarkX> yea dean is great with that
[21:14:13] <MarkX> especially great when i added him to skype and basically said "HEEELLLPPPPP"
[21:14:18] <MarkX> even though i wasn't using LUFA
[21:14:19] <MarkX> XD
[21:14:24] <N1njAway> It would be cool if people weren't quite so spread out - a #avr meet in person would be pretty sweet
[21:15:12] <N1njAway> Oh damnit, why it is suddenly 10pm already? Time to go finish this stuff up.
[21:15:14] <Roklobsta> great. a room full of the unwashed.
[21:15:17] <MarkX> heh
[21:15:56] <N1njAway> Rok: LOL can we just shove all of the unwashed off to their own fandom allocation? Every special interest group seems to have them.
[21:16:08] <N1njAway> I suppose we just pass out soap in the registration packet
[21:16:30] <N1njAway> Atmel soap
[21:16:33] <N1njAway> To use with my shower LUFA
[21:16:59] <MarkX> soap? unwashed?
[21:17:01] <MarkX> i dont get it
[21:17:44] <MarkX> oh
[21:17:46] <MarkX> now i get it
[21:17:48] <MarkX> that took too long
[21:17:49] <MarkX> XD
[21:18:09] <Roklobsta> you know, fat and lye not some web thing.
[21:18:23] <MarkX> and now i'm lost again
[21:19:09] <tzanger> lol
[21:19:31] * Tom_itx gives MarkX an #avr channel map
[21:19:35] <bss36504> As long as the soap has lotion in it. Moisturize me.
[21:19:46] <bss36504> lol
[21:19:52] <MarkX> Tom_itx: i don't think i've been here long enough XD
[21:20:04] <bss36504> Wait, whats a channel map/
[21:20:36] <Roklobsta> puts the lotion on the skin
[21:21:20] <MarkX> puts the lotion in the basket
[21:21:24] <theBear> beat me to the punch :)
[21:21:28] <MarkX> :P
[21:21:28] <theBear> twice, bastards !
[21:37:36] <N1njAway> Rok: It puts the lotion on the stack
[21:38:33] <MarkX> i need to invent a new way to wake up
[21:38:44] <bss36504> Alarm clock
[21:38:51] <N1njAway> Caffiene, and lots of it.
[21:38:53] <bss36504> its been done before
[21:38:56] <N1njAway> Caffinated soap
[21:39:34] <MarkX> i have unnatural hatred towards my alarm clock
[21:39:45] <MarkX> and i stay away from caffiene
[21:39:50] <bss36504> Automated nerf gun alarm clock
[21:39:52] <MarkX> dont even drink pop :P
[21:40:08] <Casper> MarkX: you need a better alarm clock
[21:40:21] <MarkX> Casper: i tried various ring tones on my phone as well
[21:40:27] <MarkX> i;m on my second S3
[21:40:28] <MarkX> :P
[21:40:43] <theBear> why would a nerf gun need an alarm clock ? hehe sorry, terrible wordplay, it's gonna be another one of those days, i can tell
[21:41:00] <Casper> MarkX:
https://www.youtube.com/watch?v=kQ-l5PlDa-k
[21:41:22] <Casper> MarkX: or
https://www.youtube.com/watch?v=8zEH5GxPNO8
[21:42:13] <theBear> i had an idea for an electric shocker as a schoolkid, i was just learning about ignitioncoil/flyback kinda effects, and no alarm could wake me (since i grownup i noticed VERY loud music can do it) .... basic idea was a little cuff likely on a toe where it wouldn't get caught in the bedding too much, and of course a bit of a tickle at wakeup time
[21:43:07] <MarkX> hahahhahahha
[21:43:11] <MarkX> i was thinking something more complicated
[21:43:14] <tzanger> that world's biggest alarm clock is actually pretty funny
[21:43:19] <tzanger> but you know he's never gonna get a girl in that bed
[21:43:49] <MarkX> learning proper lucid dreaming
[21:43:55] <MarkX> and waking up based on some sort of signal
[21:43:56] <MarkX> :P
[21:45:39] <Casper> how's your progress on lucid dreaming?
[21:46:43] <theBear> i liked the giant mobile phone on that 'balls of steel' real-world prank show... dude has a mock-mobile phone maybe 2 or 3' long and a recording of the classic old nokia ringtone EVERYONE had in the 90s for a while, he'll be in a fancy restaurant or at a crowded beach or something... diddleoodoo diddle<ringtone noise, raises giant phone to head and starts shouting> "HELLO ! NAH CAN'T TALK NOW, I'M IN A REST
[21:46:43] <theBear> AURANT, I'LL CALL YOU BACK AFTER DINNER <pause> NAH, IT'S BLOODY RUBBISH AND THE WAITERS SHIT... TALK TO YOU LATER" <beep, puts away giant phone>
[21:46:50] <theBear> now that's my kinda comedy !
[21:48:42] <MarkX> Casper: haven't started real lucid dreaming
[21:48:43] <MarkX> but
[21:48:51] <MarkX> if i think about a problem real hard
[21:48:53] <MarkX> before i sleep
[21:48:58] <MarkX> i awake up with a solution
[21:49:04] <Casper> hmmmm am I over heat sensitive? I can feel the heat radiating from the heater from like 12ft away...
[21:49:44] <theBear> Casper, can you see the light from the lamp on the table next to it ? <hint hint>
[21:50:18] <Casper> theBear: actually, no, because that lamp is broken and off :D
[22:23:24] <N1njAway> http://www.youtube.com/watch?v=cK5pl6W2CFE is what I imagine the inside of the Atmel JTAG programmer to sound like whilst it's working
[22:37:26] <tzanger> hahaha
[22:37:30] <tzanger> you made me lol
[22:37:51] <tzanger> now I have to actaully make my jtag programmer play that while programming
[22:38:51] <bss36504> N1njAway: Literally the funniest thing I've seen/heard all day
[22:38:55] <bss36504> thank you
[22:39:25] <N1njAway> You are welcome :)
[22:39:53] <bss36504> New project for my JTAGICE3
[22:40:37] <N1njAway> I loaded that song on to our phone system here because it's the best on-hold music ever.
[22:41:06] <bss36504> it really would be. It makes me feel peppy, like now I have to write my scheduler tonight, and not tomorrow.
[22:41:15] <N1njAway> DOOO EETTT!
[22:41:23] <bss36504> I wonder if I can make that my ringtone at my desk...