Back
[04:23:46] <RattusRattus> hi there. can anyone give me some help with a bit of porting from IAR to avrlibc please? I have under IAR the following:
[04:23:56] <RattusRattus> static STATE flash* TblPtrCommon;
[04:25:08] <RattusRattus> now I know that under IAR that flash is a keyword to indicate storage in flash (program memory) nor RAM, but I am pretty sure that
[04:25:35] <RattusRattus> static STATE * TblPrtCommon PROGMEM; will be invalid
[04:25:44] <RattusRattus> any suggestions?
[04:26:33] <RattusRattus> (basicly I don't understand how the flash keyword in IAR will work when used to modify a popinter)
[04:32:40] <malinus> RattusRattus, what is IAR?
[04:33:27] <RattusRattus> IAR in this case is an alternative (non free) toolchain
[04:33:57] <RattusRattus> avrlibc has a section on porting from IAR to avrlibc but it doesn't cover this
[04:34:04] <RattusRattus> http://www.nongnu.org/avr-libc/user-manual/porting.html
[04:34:20] <malinus> RattusRattus, is that the toolchain atmel studio uses?
[04:34:39] <Tom_itx> used to
[04:34:53] <Tom_itx> they switched to gcc in the last few years
[04:35:08] <malinus> oh i see. So that means that IAR is more or less dead?
[04:35:12] <RattusRattus> atmel studio uses gnu toolchain today (avrlibc)
[04:35:37] <RattusRattus> malinus: not dead, but non-free
[04:37:15] <malinus> Atmel studio doesn't use it, and there is a free alternative. That sounds pretty dead. Who would choose to use it?
[04:37:49] <RattusRattus> malinus: never under estimate the power of sales weasles
[04:37:54] <RikusW> RattusRattus: const char __attribute__((__progmem__)) str = "test";
[04:38:17] <Tom_itx> i think atmel used to use it
[04:38:54] <malinus> RattusRattus, neverless - good luck with it :)!
[04:39:55] <RattusRattus> RikusW: yep the issue is how do I do that with pointers: static STATE flash* foo; becomes what const static STATE * foo PROGMEM; ?
[04:40:36] <RikusW> avrlibc docs explain it exactly
[04:41:06] <RikusW> You'll have to use LPM or a avrlibc function to read the flash as well
[04:41:47] <RikusW> var = *foo; will not work
[04:43:01] <RikusW> <avr/pgmspace.h>
[04:43:21] <RattusRattus> RikusW: I understood that part.
[04:43:31] <RikusW> see Data in Program Space in the avrlibc manual
[04:43:48] <RattusRattus> where I have a problem is when I have somthing like:
[04:44:00] <Tom_itx> anybody seen Dean lately?
[04:44:04] <RattusRattus> static STATE flash* TblPtr;
[04:44:26] <RikusW> byte = pgm_read_byte(&(mydata[i][j]));
[04:44:36] <RattusRattus> here in IAR they are doing what? pointing into flash
[04:45:05] <RikusW> no idea, you'll need the IAR docs
[04:45:35] <RikusW> if you have enough RAM just put it in RAM and forget about it for now
[04:45:39] <RattusRattus> RikusW: 'K thats WHY I asked my initial question....
[04:46:15] <RattusRattus> no not got enough ram (well maybe, I have a few bytes free after compile so fully expect a stack crash!)
[04:46:30] <RikusW> ouch
[04:47:59] <clixx_IO> Hello
[04:48:11] <clixx_IO> hey has anyone here used the Atmega8 much?
[04:48:27] <RattusRattus> if I don't move anything into flash this compiles, but fails to link due to ram being 125% over available....
[04:49:00] <RikusW> seems there is even "10 Porting From IAR to AVR GCC" in the manual
[04:49:21] <RattusRattus> ack
[04:49:29] <RattusRattus> the manual has been a real help.
[04:50:51] <RikusW> use a bigger AVR ?
[04:53:17] <RattusRattus> rofl.... this is the problem. the company previously used a consultancy to do this... the product is already in the field... but $business being what it is that part of the company has been closed and I am all that is left. (and before you ask no I don't have an IAR tool chain)... and I need to fix a trivial bug. problem is I need to be able to build the project first!
[04:53:51] * RattusRattus stuch between rock and hard place
[04:54:43] <RikusW> ugh
[04:55:23] <RikusW> ask them to buy IAR ?...
[04:56:16] <RattusRattus> $cash (and yes I know my time is costing more than just buying a licance -- but managers ehh!?)
[04:57:28] <RikusW> project resurrection........
[04:57:44] <RattusRattus> ack
[05:52:51] <clixx_IO> I know you might not like this but can you hack hex?
[05:53:25] <clixx_IO> If it's a small change then you might be able to do some hex fiddles
[05:58:08] <RattusRattus> clixx_IO: I apprecate the scentiment, and it may even be possible, however that way will break any and all future versions. not to mentian any hope I may have of version control, scanity etc etc
[06:01:02] * RattusRattus is opting for port as much as I can then re-work the bits that are memory intensive (I've looked closer at some of this an dto be honest its obvious that the guys who origanaly wrote the code had know idea what Harvard architecture was, as a result there is a *lot* I can do to make this code smaller
[06:01:07] <RattusRattus> )
[06:02:14] <abcminiuser> Hi Tom_itx
[06:09:03] <clixx_IO> * never heard of a VCS that doesn't support hex
[06:09:37] <clixx_IO> I realise you ain't doing the hex editing thing
[06:10:14] <clixx_IO> but if you memory dump it in hex format to an ascii file, you can still manage it in a VSC
[06:10:18] <clixx_IO> VCS*
[06:11:38] <RattusRattus> clixx_IO: no that is not what I ment. version control becomes a night mare if your 'controlled code' becomes this binary blob with the following diff
[06:11:46] <clixx_IO> but it's better value for the coder if the codebase goes from IAR to AVR-GCC
[06:12:29] <clixx_IO> It doesn't have to be a binary blob, it can be an ascii blob
[06:12:42] <RattusRattus> rofl
[06:13:04] <clixx_IO> and you can probably decompile it into semi-readable asm
[06:13:39] <clixx_IO> of course the management price of that approach would have to be double
[06:14:07] <clixx_IO> anyway, fyi my world is a lot of legacy systems
[06:14:47] <clixx_IO> There does come a point where the client has to give up and go with what the developer wants
[06:18:36] <clixx_IO> RattusRattus: what does the program do?
[06:19:48] <RattusRattus> it's a clock. and yes I am seriously considering re-writing the entire thing...
[06:20:55] <RattusRattus> but would like not to introduce regressive bugs if I can possibly help it
[06:20:57] <clixx_IO> "Might be cheaper to refactor now, rather than maintain legacy code"
[06:21:25] <clixx_IO> "Lots of things have changed in the software world since when that was originally done"
[06:21:30] <RattusRattus> clixx_IO: ack. not entirly sure if this is a refactor or re-write :-)
[06:22:01] <clixx_IO> That depends on what the customer is expecting/needing to hear
[06:22:38] <clixx_IO> which mcu?
[06:23:16] <RattusRattus> as with most companies ours is one that doesn't do product definitions well. I am pretty sure that there is a lot of undocumented functionality that customers rely upon.
[06:23:31] <RattusRattus> MCU is a 8515...
[06:24:37] <clixx_IO> Does it have IoT (Internet-of-Things) ?
[06:25:27] <RattusRattus> hell no
[06:25:37] <clixx_IO> well it probably should
[06:25:49] <RattusRattus> it has sneaker-net updates every few years
[06:27:12] <clixx_IO> That's so yesterday
[06:27:51] <RattusRattus> clixx_IO: I am assuming you are trying to be ironic....
[06:28:08] <clixx_IO> Pretty much.
[06:28:12] <RattusRattus> phew
[06:28:25] <clixx_IO> I wasn't criticising your design/work
[06:28:57] <RattusRattus> oh it wasn't that its just that you were begining to sound like a product manager / sales troll
[06:29:03] <RattusRattus> :-p
[06:29:32] <clixx_IO> yeah - fair call.
[06:29:33] <oholiab> hello :)
[06:29:59] <RattusRattus> i.e. "look new buzz word shinny thing.... must apply it to all products in all possible applications"
[06:30:14] <clixx_IO> But I was trying to talk asm/hex - and that wasn't to be - so changed topic
[06:30:54] <clixx_IO> yeah but I like "Apply new shiny thing paint to all new products whether it helps them or not"
[06:31:21] <oholiab> So I've just been looking at I2C port expanders - Am I right in thinking that you use serial (I2C protocol) to write from your main chip over a couple of IO pins to the port expander chip which you'll then use the standard digital on/off signals from?
[06:31:31] <clixx_IO> a clock with IoT, that tells someone when the battery is heading limp - that would be handy
[06:31:52] <clixx_IO> yes, I2C expanders do that
[06:32:01] <oholiab> clixx_IO: ace, thanks :)
[06:32:13] <clixx_IO> and you can read and/or write
[06:32:18] <oholiab> nice
[06:32:30] <RattusRattus> caution - only for IO. be carfull if you are wanting to expand a 'bus' in this way
[06:33:10] <clixx_IO> I've used the I2C port on my notebook
[06:33:42] <RattusRattus> clixx_IO: agreed. in my case I can probably cope (just) with teh asm, but that would cirtainly leave me the only person in the company able to comprehend the code/make changes
[06:33:44] <oholiab> so it'd be suitable for something like having a serial lcd display that needs like, 10 pins and you don't want to use all the IO pins on the main chip?
[06:34:31] <RattusRattus> oholiab: yes providing that you are 'bit bashing' the IO and the serial display doesn't have any tight timing requirements
[06:34:34] <megal0maniac> What about I2C on the VGA port? :D
[06:34:52] <clixx_IO> most LCD's only use 4 pins. The expanders usually come in groups of 8 pins, so either 8 or 16 pins
[06:36:30] <clixx_IO> I will show a link - just looking through my old posts
[06:36:49] <oholiab> clixx_IO: yeah, I'm looking at a 16 pin expander here
[06:37:15] <clixx_IO> you should only need an 8 pin expander for an LCD
[06:37:24] <oholiab> tbf, it could well be that the display I was looking at as an example is parallel instead hence the million and 7 pins
[06:37:27] <clixx_IO> if you use four-bit mode
[06:37:42] <megal0maniac> 3 for control and 4 for data. You can use the last one with a transistor to toggle backlight :)
[06:37:51] <oholiab> :)
[06:38:21] <clixx_IO> Google says I'm not allowed to show the photo
[06:38:31] <megal0maniac> Yeah they own it now
[06:38:43] <oholiab> I'm still pretty new to all of this, I'm just looking at what I can get away with throwing in my cart when I order a £1.20 usb breakout socket
[06:39:34] <oholiab> looking at USB HID sent me down the rabbit hole of straight avr programming instead of using the arduino libraries
[06:40:08] <oholiab> which I'm extremely grateful for as it's far more interesting and I really wasn't learning anything
[06:40:09] <clixx_IO> It's a few pages down on here :
https://plus.google.com/u/0/+DavidLyon/posts
[06:44:47] <oholiab> http://www.embedds.com/programming-avr-i2c-interface/ nice
[06:44:52] <clixx_IO> https://plus.google.com/109366813998920635083/posts/F9rWpF9vjTo
[06:44:52] <oholiab> that'll do nicely :)
[06:45:12] <oholiab> clixx_IO: oh cool :D
[06:46:28] <oholiab> clixx_IO: just followed you :)
[06:47:00] <clixx_IO> cool - Thanks
[06:49:33] <clixx_IO> The latest thing I have been working on is an Event-Framework for Attiny85 -
https://github.com/clixx-io/clixx.io/tree/master/eventframework
[06:50:15] <oholiab> oh cool, I've got one of them sitting around at home :)
[06:50:44] <oholiab> I'm currently working on making a really basic usb keyboard - as in a few keys
[06:50:54] <oholiab> using v-usb
[06:51:07] <clixx_IO> I started to do normal programming on Attiny85 but quickly found out it was really hard (for me - old-timer)
[06:51:32] <clixx_IO> I've not played with v-usb
[06:52:13] <oholiab> I'll let you know how I get on with it now I've got working USART code :)
[06:52:51] <clixx_IO> I used softuart
[06:52:56] <oholiab> I think I've got most of the code that I need working but it's pretty hard to tell without decent serial debugging which I now have
[06:53:37] <oholiab> https://github.com/oholiab/avr-uart
[06:55:13] <clixx_IO> Yeah cool
[06:55:28] <clixx_IO> I'd like to use something like that when I move to the bigger AVR's
[06:56:17] <clixx_IO> This is an example of the serial debugging I use :
https://github.com/clixx-io/clixx.io/blob/master/examples_eventframework/seriallinehander/seriallinehander.cpp
[06:56:54] <oholiab> nice
[06:57:37] <clixx_IO> It's on the Attiny85, I haven't had a chance to move it to the bigger AVR's
[06:58:27] <clixx_IO> Doing it reminded me how painful serial port code can be
[06:59:31] <clixx_IO> Now it's at the point where you can just get a callback saying "Here's your line from the serial port"
[06:59:57] <oholiab> cool
[07:00:09] <oholiab> I'm mostly only concerned with output on serial at the momment
[07:00:11] <oholiab> *moment
[07:00:19] <oholiab> for debugging purposes
[07:00:29] <oholiab> so that real minimal code is perfect for me
[07:00:54] <oholiab> ugh, real work calls
[07:08:36] <RikusW> oholiab: you should get a dragon and use debugWire
[07:23:47] <Tom_itx> abcminiuser_
[07:23:51] <Tom_itx> did you get the email?
[07:28:55] <abcminiuser_> Indeed, did a quick reply
[07:29:01] <abcminiuser_> Too goddam busy these days
[07:31:34] <Tom_itx> is that a good thing?
[07:32:32] <Roklobsta> busy with new lightbulbs?
[07:33:08] <Tom_itx> anyway... i'm off now too
[11:39:18] <ColdKeyboard> I have a line that says error = target_speed - current_speed; The problem occures when the current speed is larger than target speed. error, current_speed and target_speed are signed int. But when I do debugging I get that sometimes error is 63184 or so...
[11:39:39] <ColdKeyboard> Any ideas what's wrong?
[11:55:13] <spillere> where can i get a good tutorial or a place teaching about fuses?
[11:58:51] <timemage> ColdKeyboard, you're using unsigned types?
[11:59:16] <timemage> ColdKeyboard, i mean for your result. (error)
[12:06:39] <ColdKeyboard> no, error is signed int
[12:07:33] <ColdKeyboard> spillere: You have
http://www.engbedded.com/fusecalc for the fuse calculator. They have description and they are pretty self explainatory. If you are not sure, check the device datasheet.
[12:08:48] <spillere> ok, thanks
[12:28:07] <timemage> ColdKeyboard, you'd need to show the code, i guess.
[14:43:08] <superware> is it possible to use ATmega328P timer1 (16-bit) to do both ICP and PWM?
[14:53:14] <superware> anyone alive? :|
[14:54:34] <superware> is there a way to make ATmega328P timer0 prescalar 4? documentation states no prescaling or 8, but nothing in between...
[14:54:56] <ub|k> using an atmega32, WGM13:0 = 9, CS12:0 = 1, COM1A1:0 = 1, clk = 8MHz
[14:55:07] <ub|k> shouldn't this produce a 440Hz tone?
[14:56:05] <ub|k> sorry, i forgot to say OCR1A = 9000
[14:56:14] <ub|k> (ok, 444 Hz, whatever)
[14:56:52] <superware> you're getting nothing? scope?
[15:00:29] <ub|k> superware: i have no oscilloscope
[15:00:51] <ub|k> superware: i am connecting it to a buzzer, changing OCR1A and the tone is always the same
[15:09:03] <umquant> ub|k can you make sure your ISRs are firing?
[15:16:47] <ub|k> umquant: how can i check that?
[15:16:55] <ub|k> i don't have serial communication working :/
[15:17:29] <umquant> ub|k, is it far from having serial comms going? You could also use an LED
[15:18:03] <umquant> also are you using Atmel studio?
[15:19:10] <umquant> they have a simulator and a register / bit view built in
[15:19:29] <umquant> if you are using avr-gcc use avr-gdm and set a breakpoint in the ISR
[15:20:22] <umquant> also, if you can post your code and link it
[16:11:34] <ub|k> umquant: i don't have a xtal around, so, serial is a no go
[16:11:45] <ub|k> do you mean avr-gdb?
[16:13:06] <umquant> ub|k, yup. Apparently I can't english well.
[16:13:52] <umquant> ub|k, also, if you calibrate the internal osc you can use serial with it
[16:13:56] <ub|k> umquant: i don't think "avr-gdb" counts as english :D
[16:14:03] <umquant> haha true
[16:14:33] <ub|k> umquant: tried it already... well, tried changing OSCCAL, to no avail
[16:14:42] <ub|k> https://gist.github.com/anonymous/59955dc0c256e4d66f76
[16:15:54] <umquant> and it compiles fine with no errors?
[16:16:22] <ub|k> yeo
[16:16:27] <ub|k> *yep
[16:18:01] <ub|k> so, increasing OCR1A to 18000 should cut the frequency in half, if I understood correctly
[16:18:26] <ub|k> however, the buzzer produces the same tone
[16:30:18] <ub|k> ok, just noticed i should be setting WGM10 on TTCR1A not TTCR1B
[16:30:23] <ub|k> anyway, not working
[16:31:38] <ub|k> ah, wait, that was it ;)
[16:31:39] <ub|k> n00b
[16:52:49] <Tom_itx> glad i could help.
[16:52:51] <Tom_itx> :)
[17:22:19] <ambro718> I'm just proving my square root algorithm correct by running it on the AVR for all 2^26 inputs :D
[17:23:32] <ambro718> the new version is 1 cycle shorter than my previous version, which is 138 cycles, lol
[17:25:37] <Jordan_U> ambro718: How does it compare to standard sqrt()?
[17:26:30] <ambro718> I haven't measured, probably at least 3x faster from what I remember (consider mine is integer square root, not FP)
[17:26:39] <ambro718> it's completely unrolled
[17:26:57] <ambro718> https://github.com/ambrop72/aprinter/blob/master/aprinter/avr-asm-ops/sqrt_26_large.h
[17:28:39] <Jordan_U> ambro718: Nice.
[17:29:06] <ambro718> it's not meant to be understood :P
[20:32:25] <spillere> what would be a good book to learn avr programming and c?
[20:32:44] <Valen> google?
[20:32:49] <Valen> worked for me ;->
[20:33:01] <spillere> :)
[20:33:09] <Valen> perhaps take a read of K&R for C, then just start screwing around with avrs ;->
[20:33:22] <clixx_IO> what do you want to make exactly ?
[20:34:05] <clixx_IO> also which AVR?
[20:34:17] <spillere> i'm learning from the new make book
http://shop.oreilly.com/product/0636920028161.do
[20:35:05] <spillere> clixx_IO I have been programing arduino for the past 7 years, and some C. But I want to start to learn properly C for embedded systems. I have a atmega32 dev board i'm using
[20:35:43] <spillere> i learned about fuses today, got excited
[20:35:44] <Valen> C for embedded is pretty much C for everything else isn't it? just don't use malloc ;-P
[20:36:16] <spillere> Valen i know, but i need to get better at bitwise math and code optimization
[20:36:33] <clixx_IO> I personally wouldn't recommend C for AVR. Somebody will try to hit me but I will duck. Go for C++
[20:36:42] <Valen> eh, get other people to do for it
[20:36:46] * Valen hits clixx_IO
[20:37:00] <spillere> clixx_IO thanks, i dont want to learn c++
[20:37:02] <spillere> :)
[20:37:06] <spillere> not java hehe
[20:37:07] <Valen> check out avr 35 appnote it'll do your bit maths for you
[20:37:12] <clixx_IO> clixx_IO got punched
[20:37:30] <Valen> and generally don't bother about optimisation, its generally not worth it, unless it is
[20:37:39] <spillere> Valen exactly
[20:37:55] <clixx_IO> This is my C++ framework for AVR :
https://github.com/clixx-io/clixx.io/tree/master/eventframework
[20:38:44] <Valen> (and then you just think about it, what is it you are trying to do, break it down and see if that is what your code is doing
[20:39:13] <spillere> but when you are programming µC, you should always think on optimization. like there's no reason to import math.h if you don't really need it
[20:39:29] <spillere> clixx_IO now python i find it really awesome
[20:39:52] <clixx_IO> Yeah
[20:40:18] <spillere> few years ago, when i started learning python, this song came in my head
https://www.youtube.com/watch?v=7R1nRxcICeE hahaha
[20:40:19] <clixx_IO> but I'm starting to favour C++ over Python for embedded now
[20:40:31] <spillere> python is really not for embedded
[20:40:46] <Valen> python for all the things!
[20:40:56] <clixx_IO> I wrote an AVR code generator in python, it will create makefiles and the C++ code for AVR
[20:41:13] <spillere> i was checking your website
[20:41:17] <spillere> its really cool
[20:41:33] <clixx_IO> Thanks. It's going to get even more cool soon
[20:42:38] <clixx_IO> I'm adding bluetooth and solar panels to my Attiny85's
[20:42:49] <clixx_IO> to turn them into remote sensors and switches
[20:43:06] <clixx_IO> code for remote-button :
https://github.com/clixx-io/clixx.io/blob/master/examples_eventframework/remotebutton/remotebutton.cpp
[20:43:42] <clixx_IO> code for remote-switch:
https://github.com/clixx-io/clixx.io/blob/master/examples_eventframework/remoteswitch/remoteswitch.cpp
[20:44:50] <spillere> http://www.danielandrade.net/2012/05/11/open-hardware-moodlamp/ I should do a attiny version of it
[20:44:59] <spillere> but then I would program it on C not arduino
[20:46:39] <clixx_IO> The Attiny85 is quite fun to play with
[20:47:27] <clixx_IO> It's a good deployment platform being a lot cheaper than the Arduino
[20:47:37] <spillere> if you only need few pins
[20:48:55] <clixx_IO> well I'm just focusing on simple devices
[20:49:14] <clixx_IO> constrained to four-pins
[20:49:26] <spillere> yeah, it wouldn't work for me
[20:49:35] <clixx_IO> but with Internet-of-Things, just add more cores
[20:50:13] <clixx_IO> and have them talk over your intranet
[20:50:16] <spillere> I developed a board that used atmega328 20 pins
[20:53:39] <spillere> but yeah
[20:53:44] <spillere> i will buy some attiny
[20:53:51] <spillere> would be fun to play with them :)
[20:54:01] <spillere> could make a attiny dev board
[20:55:32] <clixx_IO> Here's mine:
http://clixx.io/doc/source/Processor-Attiny.html
[20:56:06] <clixx_IO> * I'm thinking I need to revise the documentation
[20:56:34] <clixx_IO> peripherals plug directly into it
[20:56:58] <spillere> you are programmin with arduino?
[20:57:28] <spillere> do you have pics?
[20:57:29] <clixx_IO> No. I've been developing a C++ Event-Framework
[20:57:32] <clixx_IO> https://plus.google.com/u/0/+DavidLyon/posts
[20:57:44] <clixx_IO> pictures of it are there somewhere
[20:58:09] <spillere> looks very good!!
[20:58:48] <spillere> where are you making your pcbs?
[20:59:27] <clixx_IO> Mr Hackvana
[21:00:02] <Tom_itx> hah
[21:00:15] <Tom_itx> he must be doing pretty good by now
[21:00:28] <spillere> does he have website?
[21:00:44] <Tom_itx> probably but you could join #ha...
[21:00:46] <Tom_itx> too
[21:01:21] <clixx_IO> he has a #hackvana channel, otherwise orders@hackvana.com
[21:03:11] <Tom_itx> what's the water injection for?
[21:03:26] <clixx_IO> Extra power and Fuel economy
[21:04:27] <clixx_IO> That little car goes like stink..
[21:05:50] <spillere> cool
[21:05:51] <Tom_itx> i made a bunch of LM75 boards too
[21:07:02] <clixx_IO> I'd like the Attiny85 code to drive them
[21:07:18] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/temp/LM75/lm75_copper_new_batch1.jpg
[21:07:26] <Tom_itx> run from a pc parport
[21:07:32] <spillere> great!
[21:07:46] <spillere> i made my thesis board on jacohk.com
[21:07:50] <Tom_itx> it's not on right now but it's the temp at the top of my webpage
[21:07:57] <spillere> i dont have it here yet
[21:08:11] <spillere> cool
[21:08:18] <spillere> is it that cold?
[21:08:19] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/temp/LM75/lm75_msop1.jpg
[21:08:20] <spillere> hehehe
[21:08:26] <Tom_itx> no it's not on
[21:08:38] <Tom_itx> i should take the code out
[21:08:42] <spillere> http://cl.ly/image/2c1r0H0V1K1i/Screen%20Shot%202014-04-13%20at%209.00.09%20PM.png
[21:09:16] <Tom_itx> is that eagle3d?
[21:09:24] <Tom_itx> or something else
[21:09:27] <spillere> atmega328 with DHT22 and nrf24l01+ board for home automations
[21:09:30] <spillere> it's altium design
[21:09:42] <Tom_itx> student discount
[21:09:57] <Tom_itx> wait till you gotta buy it
[21:10:15] <spillere> hahaha
[21:10:18] <spillere> i know o.O
[21:10:23] <spillere> but i really like the software
[21:10:24] <Tom_itx> i've used eagle for years
[21:10:33] <Tom_itx> i looked at pads too
[21:10:43] <Tom_itx> it's as much as altium i think
[21:11:38] <clixx_IO> I just use Fritzing, although when I was working at the University as a PCB designer we used Altium
[21:12:08] <Tom_itx> ever etch your own?
[21:12:17] <spillere> i only use fritzing to make schematics for people that can't read regular ones :)
[21:16:09] <hackvana> I've etched my own:
http://capnstech.blogspot.com/2011/05/playpause-making-pcbs-at-home.html
[21:17:15] <spillere> hackvana i used to etch, but now im lazy huauha
[21:20:48] <hackvana> Me too, I haven't done it in years.
[21:56:11] <clixx_IO> I'm totally not interested in etching. Firstly it's a big time sink, but more importantly no home made board can ever be saleable
[22:01:15] <Casper> wrong
[22:01:15] <clixx_IO> All the hackvana boards I've received have been totally 'shiny' and work way beyond what I know I could make personally
[22:01:38] <Casper> I've seen some very well sellable home made board
[22:01:50] <Casper> but you don't want to do that
[22:01:59] <Casper> you home fab to prototype
[22:02:04] <Casper> then send the final board to be fabbed
[22:02:35] <clixx_IO> I'm not saying more skillful people than me can't do it. Just saying my attempts at pcb making would suk
[22:03:11] <Casper> that is more like it :D
[22:05:33] <tzanger> for anything realistic you won't be making boards at home beyond extremely low volume hobbyiest stuff
[22:05:48] <tzanger> nothing wrong wtih that but it's folly to try to save money by making boards at home
[22:06:20] <clixx_IO> right
[22:06:59] <spillere> buenas noches all!
[22:11:40] <Tom_itx> clixx_IO, maybe not saleable but definitely prototypeable
[22:13:07] <Tom_itx> and you can do fairly fine work with good results:
http://tom-itx.no-ip.biz:81/~webpage/temp/tiny/tinyboard1.jpg
[22:13:17] <Tom_itx> that's a SOT23-6
[22:13:29] <Tom_itx> attiny10 with 3 traces under it
[22:13:44] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/temp/tiny/tinyTPI1.jpg
[22:13:50] <Tom_itx> just a test board..
[22:16:23] <clixx_IO> It's good etching. I just know I personally can't do that well
[22:18:15] <clixx_IO> plus I prefer to spend the time designing not fighting with my wife because I spilt the chemicals in the kitchen and burnt through the floor or table or sink
[22:18:53] <clixx_IO> other people can
[22:19:34] <clixx_IO> and it is a good skill to have.
[22:42:50] <tzanger> haha
[22:53:38] <clixx_IO> my wife wouldn't see the funny side
[22:54:01] <rue_more> YOU ARE SILLY FOR USING 6 PIN ISP!
[22:54:03] <rue_more> :)
[22:55:46] <clixx_IO> why?
[22:56:02] <clixx_IO> I want to use a serial bootloader
[22:56:54] <clixx_IO> my friend has it
[22:57:57] <clixx_IO> At the time I had nothing else for the Attiny85
[23:01:48] <rue_more> 10 pin is cool
[23:02:49] <clixx_IO> in what layout?
[23:05:25] <rue_more> 10 pin isp
[23:08:15] <clixx_IO> what difference does it make?
[23:21:46] <rue_more> there has never been confusion over what pins were what on 10 pin, and it has an led.
