Back
[00:07:17] <N1njaneer> Hello AVR folks :)
[00:09:13] * Casper sneaks behind N1njaneer, use a 20ft pole and tap N1njaneer on the back with it
[00:09:23] <N1njaneer> Hiyas!
[00:12:13] <Thrashbarg> me branezzz
[00:31:25] <oscar__> Hi everybody
[00:32:06] <oscar__> I want to learn how to programming with C atmel microprocesors
[00:32:26] <oscar__> Can anybody recommend some thing to start wit this?
[00:32:49] <Casper> the datasheet for the chip you want to use
[00:33:01] <Casper> avoid arduino code
[00:33:10] <oscar__> I want to use atmega 328p
[00:33:11] <Casper> arduino board is ok...
[00:33:33] <oscar__> Yes, I'll avoid arduino IDE
[00:34:11] <oscar__> I want to learn to programming this micro with C
[00:35:30] <N1njaneer> Use Atmel Studio if you are on Windows. It's one of the best IDE's you will ever find or ever buy for any amount of money :)
[00:35:36] <N1njaneer> And free.
[00:36:45] <malinus> oscar__: start by learning C. Then you can just look trough a couple of examples, read the datasheet, and you are golden.
[00:38:03] <oscar__> I know a little of C, but is very basic
[00:38:30] <Casper> oscar__: basically you want to learn to make an hello world program
[00:38:45] <Casper> then the datasheet mostly tell you how to use it, it have code example for almost every functions
[00:38:54] <Casper> both in C and ASM
[00:39:37] <oscar__> Ok, great, I will see the datasheet
[00:39:39] <N1njaneer> Oh yes, in that case, definately start by learning C. You may want to skip the micro for a bit as well to get the language down, as it's much easier to interactively debug and experiement when you don't have a ton of other microcontroller gotchas on top of it all. Though honestly Arduino's IDE is a good starting point for starting to do C stuff on a micro, though you'll completely lack all
[00:39:39] <N1njaneer> code-stepping debug.
[00:43:03] <oscar__> Thanks, I'll be back soon. :) Hasta luego parceros
[00:45:07] <oscar__> One more question
[00:45:22] <oscar__> Which is the best book of C?
[00:46:58] <Casper> the one you can follow and understand? :D
[00:47:51] <oscar__> jejejeje nice
[00:50:27] <N1njaneer> I suggest Deitel & Deitel if you want a solid learning and reference book. It's very common here at university in the US, and you can find used copies of previous editions very inexpensively online.
[00:57:41] <oscar__> What you think abut this
http://www.amazon.com/Programming-Language-Brian-W-Kernighan/dp/0131103628/ref=sr_1_1?ie=UTF8&qid=1431062832&sr=8-1&keywords=C+programming
[01:52:47] <megal0maniac> oscar__: It's good as a reference book
[02:08:00] <megal0maniac> But I wouldn't use it as the sole source of information to learn from. Most of what I've found in there I've found on the internet as well, and with more examples. Still a good book but not the "holy grail" some people make it out to be, imho
[05:33:05] <Ecco> Hi!
[05:33:26] <Ecco> Quick question: a datasheet I'm reading says "Default value : 8'h00h"
[05:34:00] <Ecco> What the hell does that mean?
[05:34:25] <EI24> in what context?
[05:34:27] <Ecco> (apparently that's the value for a byte, and it would make sense for it to mean 0x00, but I'd like to understand their notation
[05:34:36] <Ecco> (that's the datasheet for an LCD controller
[05:34:46] <Ecco> and that's the default value for a register that can be read)
[05:35:29] <Ecco> Other uses of this notation include "3'b000", and "32'h00610000h"
[05:35:31] <Ecco> Oh
[05:35:44] <EI24> no idea, maybe to you can test what the default value is?
[05:35:48] <Ecco> could it be "number_of_bits'hvalue_in_hex"?
[05:36:07] <Ecco> or "number_of_bits ' base value"
[05:36:11] <twnqx> it's verilog
[05:36:23] <Ecco> so 3'b000 means "3 bits whose value in binary are "000"
[05:36:30] <twnqx> 32'h means "a 32bit value in hexadecmal notation"
[05:36:33] <Ecco> ok
[05:36:35] <Ecco> excellent
[05:36:36] <Ecco> thanks!
[05:36:39] <twnqx> 3'b "a 3 bit value in binary" etc
[05:36:46] <Ecco> yeah, ok
[05:36:55] <Ecco> Damn that's weird, I had never seen this before
[05:37:03] <twnqx> verilog HDL syntax
[05:37:15] <Ecco> well… technically I should have though, I did have a VHDL course back then
[05:37:41] <Ecco> oh wait, apprently those arent the same thing
[05:37:58] <Ecco> anyway, thanks twnqx :)
[05:38:19] <twnqx> yeah, VHDL is the other one ;)
[05:38:38] <Ecco> While I'm at it
[05:38:49] <Ecco> I'm trying to drive an LCD panel that has an ILI9341 controller
[05:39:14] <Ecco> the datasheet says that there's a command to retrieve the display identification (manufacturer ID, driver version ID, module ID)
[05:39:21] <Ecco> This command always return 0
[05:39:32] <twnqx> someone would have to set those
[05:39:40] <twnqx> no surprise some don't ;)
[05:39:43] <Ecco> ok
[05:39:48] <Ecco> that was precisely my question
[05:40:04] <Ecco> is it common for manufacturer to just don't give a shit and not set those values in the silicon?
[05:40:40] <Ecco> (It's been driving me mad because I've been using that command to see if communication with the controller was working…)
[05:40:41] <twnqx> just like any other optional value, yes
[05:40:58] <Ecco> Well, the datasheet doesn't say it's optional
[05:51:24] <Ecco> Pfffff
[05:51:25] <Ecco> ok
[05:51:36] <Ecco> *THANK YOU MOTHERF*CKIN STMicro*
[05:51:37] <Ecco> :-D
[05:51:53] <Ecco> Deep, deep deeeeeep down in some of their crappy source code for my platform
[05:51:59] <Ecco> " /* On STM32F429I-DISCO, it is not possible to read ILI9341 ID because */
[05:51:59] <Ecco> /* PIN EXTC is not connected to VDD and then LCD_READ_ID4 is not accessible. */
[05:52:00] <Ecco> "
[06:53:57] <Lambda_Aurigae> oscar__, the predecessor to that book is what I learned to program C with back in the late 80s. I have a copy signed by both of the authors.
[06:55:02] <Lambda_Aurigae> you can learn a lot about the basics of C with it but there are so many extensions since they wrote it that you would want additional documentation as well...
[07:36:29] <twnqx> so
[07:36:48] <twnqx> there are tons of ICs that allow 3.v/5v logic to drive 5-24V
[07:37:11] <twnqx> but really, there are no ICs that allow 5-24V input to 5V/3.3V logic?
[08:08:54] <Devilholk> comparators?
[08:52:39] <twnqx> Devilholk: 8+ bits, logic level output
[08:54:27] <Devilholk> Quite often you can just us a buffer with an octal resistor divider I believe
[08:54:41] <twnqx> in theory, yes
[08:55:10] <twnqx> but i want to register arbitrary voltages in the range of ~5V - 24V (preferably 3.3V - 24V) as "high"
[08:55:29] <twnqx> oh well, so i'll live with my current design
[08:56:48] <twnqx> resistor divider -> p-channel mosfet + pulldown
[08:57:15] <twnqx> with +-20V gate/source survival capability :P
[10:41:43] <FatalNIX> is there a pin on the atmega's usually that let you get the clock pulse from the internal clock?
[10:42:43] <FatalNIX> I don't have a fast enough 7404 on me to create a clean enough square wave for a chip I'm trying to wire up and remembered that the Atmega I got runs at 1 Mhz which is right at the operating speed of this other chip
[10:43:17] <Lambda_Aurigae> depends on how you are clocking the AVR and other things, but, yes, it is possible to do.
[10:43:42] <Lambda_Aurigae> output would be on one of the xtal pins
[10:43:56] <FatalNIX> I thought that was a clock input
[10:44:03] <FatalNIX> but it also is tied to the internal clock?
[10:44:14] <Lambda_Aurigae> have you read the datasheet?
[10:44:47] <Lambda_Aurigae> I suggest reading the datasheet, specially the part on the clocks. It is in there.
[10:44:58] <Lambda_Aurigae> I would read it and copy/paste it for you but I'm at work at the moment.
[10:47:31] <FatalNIX> that's fine
[10:47:42] <FatalNIX> I have a copy of it on my phone and on my desktop / laptop
[10:47:57] <FatalNIX> you know what
[10:48:14] <FatalNIX> I can just hook my meter's fequency mode up to the XTAL outputs
[10:48:30] <FatalNIX> or hook it up to an osciloscope
[12:21:16] <Jartza> hmmh
[12:21:42] <Jartza> has anyone ever noticed on attiny85 strange behaviour if writing to eeprom and right after that writing to flash?
[12:22:07] <Jartza> seems the flash writing fails even if using the "safe" versions of the functions, unless putting a short delay in between those two
[12:23:17] <Jartza> and even if manually calling boot_spm_busy_wait() in between
[12:23:46] <Jartza> or eeprom_busy_wait()
[12:26:05] <Jartza> but adding delay with _delay_ms() works
[12:33:00] <malinus> Jartza: try checking the datasheet. Some functions require specific timing and such. Would be interesting to hear more.
[12:33:08] <malinus> functions = instructions
[12:33:55] <Jartza> didn't find anything from datasheet but I'm now checking if there might be a bug in avr-libc
[12:34:27] <Jartza> or anything that could explain this, of course, datasheet said flash writing takes certain amount and eeprom writing certain amount etc..
[12:34:35] <Jartza> but those waits should take care of that
[12:34:53] <Jartza> boot_spm_busy_wait() should wait for flash and eeprom_busy_wait() for eeprom
[12:35:07] <malinus> Yeah, could be a bug, wouldn't be the first time :D
[12:35:12] <Jartza> yep
[12:45:08] <Jartza> hmmh
[12:45:12] <Jartza> updated avr-libc to 1.8.1
[12:45:15] <Jartza> now it works
[13:12:14] <FL4SHK> Hi. I use Arduino boards specifically for my AVR stuffs, but I already don't really use the Arduino IDE for much besides uploading code (I use Vim for programming).
[13:13:17] <FL4SHK> I wanted to try doing some stuff with AVR assembly, and from my small amount of Googling, I could use avrdude to upload compiled code. I don't really know what .hex files are, though.
[13:15:00] <FL4SHK> I might have questions later if I feel like I can't find answers by Googling.
[13:19:21] <FL4SHK> What I want to do in assembly is mainly stuff that requires very tight timing, such as communicating with an SNES controller.
[13:21:45] <LeoNerd> FL4SHK: I tend to do that by adding small assembly-based functions in a mostly-C program
[13:21:54] <LeoNerd> Such as talking to WS2812 LEDs as I'm doing currently
[13:22:16] <EI24> FL4SHK: hex files are what comes out of the assembler, if you use atmelstudio you have a built in assembler, i use avra for linux
[13:22:25] <FL4SHK> I was going to use gcc-avr probably
[13:22:28] <FL4SHK> Since I'm on Linux
[13:22:48] <EI24> you upload the hex code to the mcu with avrdude
[13:23:00] <FL4SHK> Right
[13:23:13] <oal> My professor says he's a hardware person, and not primarily a programmer. I've noticed he writes (somestruct->number)++ etc. Aren't the paranthesis redundant?
[13:23:42] <FL4SHK> It's probably easiest to just keep the parentheses if you're not sure what the order of operations is
[13:23:47] <FL4SHK> I end up doing that a lot
[13:24:44] <FL4SHK> ...though that said I don't know if they're redundant in this case
[13:24:44] <EI24> avr-gcc is for C programming avr mcu's
[13:24:50] <oal> I guess so. It's just something I noticed
[13:24:55] <FL4SHK> AVR binutils, then, EI24 :P
[13:25:41] <EI24> yes they contain assembler, linker, object file handler, i dont know, but i doubt you could use it as a avr assembler
[13:26:37] <FL4SHK> I've used arm-none-eabi-gcc for producing plain old binaries for the Gameboy Advance
[13:26:54] <FL4SHK> the .hex files are mostly alien to me :V
[13:28:37] <EI24> I use avra for assembly it works great and is really straightforward. then you just upload the code
[13:28:58] <EI24> like: sudo avra asmfile.asm
[13:29:47] <malinus> FL4SHK: was there a arm in the GBA?
[13:29:50] <FL4SHK> Yes
[13:29:54] <FL4SHK> The GBA has an ARM7TDMI in it
[13:30:13] <malinus> nice
[13:30:16] <FL4SHK> Every successor to the GBA has at least one ARM in it
[13:30:34] <FL4SHK> I'm pretty sure it's at least two if you're going from the DS and up
[13:30:41] <malinus> lol it still had the Z80 inside too
[13:30:42] <malinus> tf
[13:30:43] <malinus> wtf
[13:30:46] <FL4SHK> Yeah it did
[13:30:50] <FL4SHK> That was for the GB/GBC stuff
[13:30:53] <malinus> could it run the old DB stuff?
[13:30:55] <malinus> *GB
[13:31:00] <FL4SHK> The GBA? Yeah
[13:31:05] <malinus> Oh, that's pretty neat then
[13:31:59] <FL4SHK> The CPU that was used in the GB/GBC was actually inbetween an Intel 8080 and a Z80
[13:32:04] <FL4SHK> It was closer to an 8080 though
[13:32:42] <EI24> but dont nintendo usually modify their chips a bit, but they are based on things like arm etc
[13:32:43] <EI24> ?
[13:33:00] <FL4SHK> For the GBA it was barely any different from a stock ARM7TDMI
[13:33:05] <FL4SHK> If not exactly an ARM7TDMI
[13:33:10] <FL4SHK> As far as I know, it WAS just a stock one
[13:33:46] <EI24> cool, maybe you could build you own gba then
[13:34:20] <FL4SHK> Well, they had other custom stuff though, such as the graphics hardware.
[13:34:48] <FL4SHK> And for that matter, the sound hardware.
[13:37:20] <malinus> nothing stops you from implementing something that acts like it, on an fpgaa
[13:37:23] <malinus> or in software
[13:38:48] <EI24> do gba have a gpu? and a dedicated mcu for sound?
[13:39:23] <malinus> looks like it had a dac, and a custom IC for graphics, yes.
[13:39:31] <FL4SHK> The DAC was 8-bit
[13:39:39] <FL4SHK> Well, the sound is 8-bit
[13:40:10] <EI24> hmm, im actually interested in making games on my arduino, maybe i will have to use fpga or other chip dedicated to graphics
[13:40:29] <malinus> EI24: no need for that. But sure
[13:40:39] <FL4SHK> You might consider using something like an LED Matrix for output instead
[13:40:50] <FL4SHK> Or perhaps composite video
[13:41:19] <FL4SHK> You're already doing stuff in assembly :V
[13:41:42] <malinus> wouldn't composite push it quiet a lot? IIRC the timing gets pretty tight on an avr8 running at 20Mhz
[13:41:47] <EI24> LED matrix seems boring x) i want a real screen
[13:42:10] <EI24> im actually programing a screen right now, outputed my first sprites moments ago
[13:42:14] <malinus> "real screen"?
[13:42:21] <FL4SHK> malinus, the timing is tight, yes. Doing stuff in assembly is basically a necessity.
[13:42:35] <EI24> malinus:yes, yes, you know what i mean ^^
[13:42:42] <malinus> not really, no :D
[13:42:56] <malinus> FL4SHK: imagine how little time you had for logic, placing the sprites.
[13:43:04] <FL4SHK> I didn't even get to that yet :V
[13:43:12] <EI24> ok TFT-LCD display thats a "real" screen :)
[13:43:15] <FL4SHK> What would you suggest I do instead?
[13:43:44] <malinus> FL4SHK: I don't know what you want to do, so it's hard to suggest :).
[13:43:58] <FL4SHK> I want to generate grayscale composite video
[13:44:51] <malinus> If that is your goal, I guess it's possible. But if you want your mcu to do that AND more, you should go for something faster, probably.
[13:47:06] <EI24> uzebox uses composite out, maybe there are some examples on how to do it
[13:47:42] <EI24> http://belogic.com/uzebox/index.asp
[13:47:54] <EI24> composite*
[13:48:19] <EI24> composite video*
[13:51:59] <FL4SHK> EI24, you use an Arduino?
[13:52:24] <EI24> FL4SHK: yes, arduino nano m328p
[13:53:02] <EI24> what do you use?
[13:53:45] <FL4SHK> I have three Arduinos, each a different type. One of them is dedicated for use as a USB adapter for Gamecube controllers
[13:54:01] <FL4SHK> It has a different .hex loaded onto it
[13:54:42] <N1njaneer> Would anyone have any interest in a small board that would output directly to VGA/DVI and be able to be programmed via SPI bus or similar for display applications? I
[13:54:51] <EI24> cool, might look into that, have a gamecube collecting dust
[13:55:01] <N1njaneer> I've seen a lot of interest from folks wanting to connector monitors on to their microcontroller applications.
[13:56:18] <FL4SHK> EI24 it took very little effort, honestly.
[13:56:27] <FL4SHK> I wanted it for the Dolphin emulator.
[13:56:43] <EI24> ahhh, now im even more interested!
[13:57:54] <FL4SHK> http://hunt.net.nz/users/darran/ I used this
[13:58:22] <FL4SHK> That's the Arduino side of things. I used
[13:58:30] <FL4SHK> other stuff for the Gamecube controller side.
[14:02:48] <EI24> thanks! ill bookmark that
[14:03:00] <aandrew> N1njaneer: that's the direction my MIPI controller core is going
[14:03:17] <aandrew> not driving monitors but LCDs via SPI
[14:08:28] <N1njaneer> Cool. I've been thinking of doing a SPI->VGA/DVI/HDMI board for a while now. Could make it tiny and use an FPGA, open-source the thing. Just have to figure out if there would be interest :)
[14:08:40] <FL4SHK> I'd be interested
[14:08:45] <N1njaneer> New pick and place shows up in a week, need moar stuff to build on it! :D
[14:08:45] <FL4SHK> ANYTHING Like that interests me :P
[14:08:54] <N1njaneer> Cool, glad to know!
[14:11:57] <Jartza> well
[14:12:27] <Jartza> now that tagsu firmware update works via modem it's time to finally clean that up to bootloader for attiny :)
[14:13:22] <Jartza> tagsu "bootloader" contains lcd-lib and i2c and unnecessary stuff (as it also "emulates" tagsu user data) and that did fit into 2kB
[14:13:38] <Jartza> so I'm pretty sure the "plain" audio-bootloader fits into <1kB
[14:14:22] <FL4SHK> I wish to make a custom bootloader for an Arduino
[14:15:40] <EI24> n1njaneer: would you play videos/pics on the arduino?
[14:16:49] <Jartza> talking about pick'n'place... tagsu finally entering into production.
[14:16:54] <FL4SHK> EI24: have you done any mixing of C and assembly with your Arduino stuff?
[14:18:09] <EI24> no, i have only done assembly myself, though i've run some C examples, and used them as refrence. Not many seem to use assembly x)
[14:24:06] <EI24> FL4SHK: how do you mix assembly and C?
[14:26:34] <FL4SHK> I normally do it via my custom makefile
[14:27:01] <FL4SHK> I don't know how to do it outside of what's built into GCC
[14:27:48] <malinus> N1njaneer: what kind of pick and place did you get?
[14:28:34] <FL4SHK> Oh so you can use avr-objcopy
[14:28:36] <FL4SHK> http://www.atmel.com/webdoc/AVRLibcReferenceManual/group__demo__project_1demo_ihex.html
[14:29:01] <FL4SHK> That's good. I could easily adjust my makefiles for this.
[14:29:56] <FL4SHK> That said, I will need to learn more about how to create a bootloader for an Arduino. I'm gonna look that up too, right now.
[14:33:15] <N1njaneer> malinus: Yamaha YS12F
[14:33:43] <N1njaneer> Was a split between that or a Universal. And now I have three older Quads and feeders I need to find a good home for!
[14:37:59] <FL4SHK> I suppose I don't need to make my own bootloader
[14:43:55] <malinus> FL4SHK: no matter what your question is, the answer is "you probably don't need to make your own bootlooader" :D
[14:44:31] <malinus> N1njaneer: oh, a proper one. I thought you got a "hobby" one. You have your own shop?
[14:44:54] <malinus> You need a fucking big volume to justify a monster like that, haha.
[14:45:35] <FL4SHK> :P
[14:45:58] <FL4SHK> I might need to disable interrupts or something though.
[14:46:01] <N1njaneer> malinus: All of ours have been "proper" thus far, but just exceeding the capabilities for what we need to run has forced us to continuously upgrade. Started on a brand new Manncorp MC384V1V, then moved to the used Quad QSV1, and now dumping all of that for the new Yamaha. Change-over time was killing us between jobs. :)
[14:46:45] <N1njaneer> The useful thing about owning equiptment is getting to learn the right questions to ask about the next one you want to move to. Else you start out pretty blind.
[14:46:49] <EI24> i dont like bootloader either
[14:46:56] <EI24> bootloaders*
[14:47:07] <EI24> though i havent really used any, but i dont like the idea of it
[14:47:19] <N1njaneer> But yeah, we run many thousands of boards here a year currently, hopefully more with the upgrade.
[14:47:57] <malinus> N1njaneer: is it really cheaper than having them all done in china?
[14:47:59] <N1njaneer> EI24: AVR bootloaders are pretty straightforward, just a couple gotchas. If written well they make it impossible to ever "brick up" your micro :)
[14:48:21] <N1njaneer> malinus: In the fact that our field failure rate of boards is currently well less that 0.002%, yes.
[14:48:40] <N1njaneer> Because we have ultimate control over quality :)
[14:48:59] <N1njaneer> That and the problem is we have to turn very complex board very fast - sometimes in a number of days
[14:49:38] <malinus> Oh okay
[14:50:07] <malinus> N1njaneer: so your probably use some fast+quality+expensive local pcb house?
[14:51:20] <EI24> yes, perhaps you are right, im not informed enough to say anything about them really
[14:53:00] <N1njaneer> malinus: Often, yes :)
[14:53:49] <N1njaneer> Everything needs to be panelized and have rails to go through the SMT line
[14:57:02] <Periodic1911> How could a bootloader brick an avr anyway? Fuse bits can't be altered by software.
[14:57:34] <Periodic1911> Or am I missing something?
[14:58:05] <N1njaneer> Periodic1911: The bootloader can't per-se, but if it's written to not check an application for integrity or allow force-override for new application upload you can get in a bad state where you have a corrupt application and no way to upload a new one.
[15:08:28] <aandrew> N1njaneer: the biggest issue would be frame buffer. text and simple stuff wouldn't me too bad though
[15:09:02] <N1njaneer> aandrew: Yep, you just stick on some SDRAM or similar :)
[15:10:05] <N1njaneer> I've had to write char gens for OLED displays and things in the past on AVR which was pretty straightforward. Would good to roll all this in to an FPGA that can just synthesize the signals directly out to the DVI/HDMI framer :)
[15:10:47] <N1njaneer> Would +be good to roll
[15:13:54] <aandrew> yep
[15:18:20] <N1njaneer> The new pick and place will do down to 01005's all day long, but unfortunatly the stencil printer won't. :(
[15:21:54] <N1njaneer> Generally we only go down to 0402's though, since they're still easy to build boards with by hand.
[15:23:57] <aandrew> you really wouldn't need a lot of paste for an 01005
[15:24:51] <N1njaneer> Nope, but the problem is you need a fully automated stencil printer to reliably print them, as you're talking only a few balls of type-4/5 paste per pad. Expensive printer necessary! :/
[15:26:11] <aandrew> yeah I imagine that is a challenge in its own right
[15:26:25] <aandrew> can you even use a stencil for that or would you move to more of a point to point paste dropper
[15:26:53] <N1njaneer> It's tricky enough reliably printing QFNs for the volume stuff we run here on a semi-automated printer. That will be the next thing to get upgraded.
[15:27:22] <aandrew> we've got an automatic stencil paster but it still requires the stencils
[15:27:33] <N1njaneer> Unless you're jet-printing the paste (which has its own challenges) you're always using stanless stencils.
[15:27:36] <aandrew> when I first saw it I got all excited, I thought it was the equivalent of an inkjet printer for paste
[15:28:07] <N1njaneer> You CAN jet-print paste for fine-pitch, but it's expensive and has some occasional reliability problems over using traditional stencils.
[15:28:34] <N1njaneer> MyData has some nice video of how it's SUPPOSED to work, when the machines run reliably. But... more complicated mechanical process and more to go wrong. And slower.
[15:28:41] <aandrew> :-)
[15:29:03] <aandrew> we've got a mydata P&P and two (three) siplace systems. the siplaces do the bulk of the work by far
[15:29:13] <N1njaneer> Which Mydata?
[15:29:21] <aandrew> I can't remember offhand
[15:29:58] <N1njaneer> Looking forward to this Yamaha YS12F since it's a brand new machine, after suffering these Quads for the past two years. Which were a nice step up from the Manncorp. Progression!
[15:30:29] <N1njaneer> The Quads work, but need constant babysitting. The Yamaha is sexy, and actually smaller footprint than our existing machine.
[15:31:45] <N1njaneer> Plus being able to do all of the offline programming for everything will be nice. You can fly in the Geber data or even a flatbed scan of the blank PCB and set up the job at your desk ratehr than laboring in front of the machine.
[15:33:13] <N1njaneer> +Gerber
[15:33:19] <aandrew> *nods*
[15:34:52] <Jartza> hmm
[15:34:55] <Jartza> talking about gerber
[15:35:07] <aandrew> they make excellent baby food
[15:35:14] <Jartza> anybody knows any _good_ free tool to convert gerber to dxf?
[15:35:25] <aandrew> I do not, no, sorry
[15:35:43] <N1njaneer> Jartza: If you wanted to send me your files I can do it here quite easily if you run out of options :)
[15:35:44] <aandrew> I wonder how much trouble that would cause hads to do with gerblook though
[15:39:12] <Jartza> N1njaneer: I'll do that if the laser cutter company tells they can't open gerber :)
[15:39:12] <aandrew> I don't think it'd be trivial but it might be a direct shot
[15:39:49] <Jartza> I know they can open pdf, svg, dxf and dwg at least
[15:40:08] <HBElectric> Hi, I want to know if it is possible to have incoming serial data on a software serial driven by an interrupt and then write that to external eeprom (i2c). The issue is that there is no pausing the flow of data from serial, so it has to be written as it comes in, since the buffer is to small too keep all the data.
[15:40:18] <Jartza> I tried dxf export from eagle, but it did something funny
[15:40:40] <aandrew> eeproms usually can only accept a few bytes before they will stop accepting new data to write
[15:40:52] <aandrew> so if you can buffer, great. but I doubt you'll be able to buffer it
[15:40:54] <Jartza> depends of the i2c eeprom, though
[15:40:58] <N1njaneer> We fly our stuff out to our laser cutters in DXF - if we're doing really short runs with large parts I export the paste masks to DXF then cut them out of paper and hand-stencil. Works well if you're not going much below 0805 passives, etc
[15:41:26] <HBElectric> The serial is slow, 9600bpa
[15:41:29] <HBElectric> *bps
[15:41:36] <aandrew> oh, that's 1ms per character
[15:41:44] <aandrew> what's the write time for a page on your eeprom?
[15:41:55] <HBElectric> more or less, my problem is, it is keeping the avr busy, so when do I write to i2c?
[15:42:03] <HBElectric> 6ms for 128 bytes
[15:42:08] <aandrew> and does it have any ability to accept the entire page before writing/
[15:42:12] <HBElectric> yes
[15:42:21] <HBElectric> good old atmega512 eeprom
[15:42:25] <N1njaneer> HBElectric: At that speed you can FIFO the serial in via interrupts, then shuffle it off over I2C
[15:42:40] <aandrew> it shouldn't be keeping the AVR busy; you can do serial reception in an ISR and let I2C get interupted as often as needed
[15:43:03] <HBElectric> Remember it is software serial, not one of the UART ports.
[15:43:37] <N1njaneer> Why not use an actual UART?
[15:43:49] <HBElectric> connected to other devices.
[15:43:50] <Jartza> N1njaneer: well yeah, this is company that just does plastic stuff, so they'll be cutting acrylic
[15:44:17] <HBElectric> would have been easy if it was uart.
[15:44:18] <N1njaneer> Heh, too bad you're not stateside else I'd be happy to do it for you. We cut laser acrylic all day long here. :)
[15:44:39] <aandrew> N1njaneer: I mean use the UART with interrupts of course
[15:44:55] <N1njaneer> aandrew: Of course!
[15:49:17] <Jartza> N1njaneer: yeah, I need around 400 pieces :)
[15:49:40] <Jartza> tagsu cases
[15:50:01] <Jartza> I think I use the local supplier :)
[15:50:49] <N1njaneer> Bummer. We just brought another laser cutter in to keep up with demands - always happy to find things to keep the busy, but international shipping would kill the cost :(
[15:52:46] <N1njaneer> We also get a fantastic price on acyrlic since we work directly with a local supplier and move pretty good volumes though.
[15:58:23] <Jartza> N1njaneer: yeah... shipping... and customs... and taxes
[16:44:40] <koolatron> hi guys. quick (easy) question. in this code i wrote (
http://paste.ee/p/589cb), it behaves erratically unless i initialize the two bitfields. obviously i'm missing something here
[16:45:19] <koolatron> is there a better way to do that? ignoring for the moment the fact that i'm doing a lot of work i don't need to be doing just to get the data in the right format/order to clock out
[16:50:52] <Xark> koolatron: Since those uint8_t variables are local (on the stack) they contain garbage unless initialized, so seems as expected.
[17:17:45] <DO9XE> Anyone familiar how to send and recieve feature data in LUFA? :) Right now I'am working with HID-Reports, but those are not easy to talk to from C# on a WindowsVM :P