Back
[02:34:35] <zarkone> hello all! i'm using simavr to write my first asm programs. I saw
[02:34:35] <zarkone> that people set pins by mouse in AVRStudio. Is it possible to set
[02:34:35] <zarkone> pins with avr-gdb connected to simavr somehow? thanks (avr-gcc, debian linux)
[02:37:45] <ecilop> I could not make simavr to work.. So I don't know
[02:38:52] <ecilop> gdb - uncomfortable debugger for ex-"Windows" user
[02:40:28] <zarkone> i'm not ex-windows, i'm avr newbie =) teacher shows how to debug in avrstudio, he sets the pins by mouse. I don't want to use avrstudio on linux..
[02:41:04] <zarkone> i know gdb-basic but don't know how to set pins
[02:41:36] <zarkone> and another requirement -- programs must be on asm, not C
[02:42:10] <ecilop> I did not use gdb
[02:42:39] <ecilop> wine+proteus under linux..
[02:43:25] <zarkone> thanks, i'll check it out
[02:43:28] <ecilop> gdb - is crap in contrast with proteus (in my mind)
[02:43:51] <ecilop> maybe I am wrong
[02:45:09] <zarkone> ecilop: so, you write programs w/ avr-gcc and then load it in proteus?
[02:46:38] <ecilop> yes. Or h/w at once
[02:47:00] <ecilop> I am newbie in avr too :)
[06:49:17] <trepon> @awozniak
[08:14:32] <megal0maniac> zlog: Hello
[08:15:04] <tpw_rules> hm. i was looking for a part to do usb host/otg to interface to a keyboard or mouse
[08:37:29] <woodyj21> tpw_rules: www.avrfreaks.net/forum/usb-host-mode-32u2-and-162
[08:37:41] <woodyj21> looks like the 2 series won't work for OTG
[08:37:43] <tpw_rules> hm
[08:37:53] <tpw_rules> the big big ones aren't really an option
[08:40:58] <woodyj21> i mostly play with the ATMEGA328's and arduino. I think the attiny does host usb...
[08:41:07] <tpw_rules> no?
[08:41:54] <vsync> jesus christ use ftdi then
[08:42:06] <tpw_rules> how will that help?
[08:42:15] <tpw_rules> do they make keyboard / mouse host chips?
[08:42:18] <vsync> then you can use whatever fucking mcu you want
[08:42:40] <vsync> i think they have libraries for a lot
[08:42:44] <vsync> of applications
[08:42:50] <tpw_rules> the only ftdi chips i know of are the rs232 ones
[08:43:07] <vsync> they do a lot of chips, you know?
[08:43:13] <tpw_rules> apparently not
[08:43:25] <vsync> What?
[08:43:33] <vsync> your ignorance amazes me
[08:43:41] <vsync> http://www.ftdichip.com
[08:43:42] <vsync> have fun
[08:43:43] <LeoNerd> FTDI is the name of an entire company
[08:43:53] <LeoNerd> They're verymuch not a one-hit wonder :)
[08:43:54] <tpw_rules> yeah i knew that, i just never really thought about it
[08:44:02] <vsync> well, stop being ignorant then
[08:44:20] <LeoNerd> My preferred USB company these days is Prolific, though. I'm keen to get some of their SOIC-8 USB-CDC chips
[08:44:38] <LeoNerd> So much less faff than the others, and I can hand-solder those
[08:45:02] <vsync> ftdi has a broader range of devices, i think
[08:45:22] <twnqx> ft2232 <3
[08:59:16] <tpw_rules> ft121 might be what i want but i can't find any examples where it's a host?
[09:02:04] <tpw_rules> vsync: it doesn't seem that they have what i want
[09:02:52] <KaaK> I'm attempting to make a USB device (using LUFA) that enumerates as 2 virtual serial devices (CDC-ACM?).
[09:03:06] <tpw_rules> a vinculum would be silly since i could also get some other µC with usb host support
[09:03:23] <KaaK> Will I need 4 interfaces in my configuration descriptor? 2 control, 2 with the bulk endpoints?
[09:05:21] <KaaK> Or worded more generally, what will my configuration descriptor (from a interface level) look like?
[09:07:13] <KaaK> I get the impression that CDC has been very loosely implemented ... I'm finding all sorts of conflicting information
[10:48:42] <d-rock> If I'm starting out with standalone ATMegas coming from working with Arduino boards, is the Arduino-as-ISP an OK way to program things, or would it be better to pony up some cash for a dedicated ISP? I'm seeing a wide range of ISPs around, and some boards called "JTAG/ICE/ISP" boards and it's not clear which ones would be useful and which ones are overkill
[10:49:47] <LeoNerd> Any ol' ISP board will do. You can get them for like.. $5 if you try
[10:50:08] <LeoNerd> Unless you're intending to do a full jump to JTAG or ICE (which the smaller AVR chips won't do *anyway*), those aren't required
[11:02:39] <d-rock> LeoNerd: thanks! I'd like to support people working on stuff like this, so is this a good board?
http://www.ebay.de/itm/Official-product-USBasp-programmer-green-/321651481214
[11:03:22] <LeoNerd> The good ol' USBasp
[11:03:36] <LeoNerd> Yeah, but see if you can find one that comes with a 10->6 pin adapter
[11:03:45] <LeoNerd> Basically everyone these days uses the more compact 6pin layout
[11:05:37] <d-rock> Ah, OK
[11:06:57] <d-rock> Like this?
http://9xrprogrammer.com/index.php/shop/35-programming-6-pin
[11:07:06] <d-rock> Or should I just look for an adapter?
[11:07:33] <LeoNerd> Either, really. I have a 10pin + adapter that basically never leaves the cable.
[11:07:37] <LeoNerd> It doesn't overly matter
[11:22:29] <gjm> d-rock:
https://www.sparkfun.com/products/8508
[11:23:22] <d-rock> Thanks. Looks like there are cheap adapters, too
[12:28:58] <awozniak> Is there a "right way" to specify lfuse,hfuse,efuse values in code?
[12:29:24] <LeoNerd> I just put them in my Makefile
[12:29:30] <LeoNerd> as part of the avrdude line
[12:31:59] <aandrew> i
[12:32:10] <awozniak> I always run into trouble when we go to manufacturing; the idiots don't know what fuse bytes are, much less how to use their proprietary gang programming software to set them.
[12:32:30] <awozniak> Ideally I'd love them to wind up in the .hex file with everything else
[12:33:25] <LeoNerd> WEll, they live in their own memory, not part of the main flash
[12:33:36] <LeoNerd> .hex doesn't have a mechanism to suggest multiple independent memory segments
[12:35:01] <awozniak> I *think* there's a way to get them into the .elf file.
[12:35:37] <awozniak> this looks helpful...
http://www.nongnu.org/avr-libc/user-manual/group__avr__fuse.html
[12:35:40] <LeoNerd> In the ELF, sure
[12:36:09] <awozniak> Do manufacturing folks like ELF? I guees it'll depend on the manufacturing place.
[12:38:30] <LeoNerd> Personally, no idea. I do my own burning :)
[14:28:50] <Chansdad> Anyone on the east coast?
[14:29:24] <Chansdad> or a freelancer here with expertise in embedded systems design ?
[14:29:49] <Tom_itx> east coast of what continent??
[14:29:51] <Tom_itx> :)
[14:29:59] <Chansdad> ha ha sorry Tom, US
[14:30:12] <Tom_itx> i know, just couldn't resist
[14:30:44] <Tom_itx> several here do embedded design
[14:30:58] <Chansdad> I need help with a IoT project . My expertise is on software side .. and want help on hardware design side
[14:32:01] <Chansdad> either with Avrs or launchpad.. .. for a rf mesh sensor network
[14:32:49] <Chansdad> I am ok with open sourcing the designs etc .. but it is for a commercial offering , a startup of mine
[14:33:03] <Chansdad> I am trying to get moving ....
[14:33:18] <Chansdad> ahead
[14:33:36] <Tom_itx> keep yammering... someone will reply pretty soon
[14:33:59] <Tom_itx> i'm in ks
[14:34:26] <Chansdad> I dont mind working with remote designers as well .. but someone should have the right skills - you konw what i mean
[14:34:47] <Tom_itx> there are some here.. you just gotta be patient
[14:34:54] <Chansdad> Right ..
[14:35:04] <Chansdad> so what is your speciality?
[14:35:47] <Tom_itx> do i have one?
[14:35:50] <Tom_itx> umm...
[14:36:02] <Tom_itx> nope.. i can't think of one
[14:36:36] <Chansdad> jack of all trades - that is good !
[14:36:51] <Chansdad> I skipped "master of none " for you though ;)
[14:59:47] <Bright> Chansdad: hi
[14:59:59] <Chansdad> Hi Bright
[15:01:05] <Bright> i'm on the east coast and sort of a freelancer (i'm also a student currently as well) :P
[15:27:00] <aandrew> on an arduino nano is there any significance to the amber led on PB5?
[15:27:17] <aandrew> i.e. is it something "arduinoey" that people used to working with arduinos expect?
[15:29:57] <zerowidth> aandrew: that's pin 13 in arduino?
[15:30:11] <aandrew> I'm not sure. let me check
[15:30:16] <zerowidth> aandrew: i think it's standard to have an LED on pin 13 for blinking
[15:31:31] <aandrew> yep IDE pin 13, PB5/PCINT5/SCK
[15:31:32] <aandrew> ok
[15:55:02] <Lambda_Aurigae> US Central area not too awfully far from Des Moines here and charge a lot of money.
[15:55:14] <Lambda_Aurigae> but mostly embedded stuff is a hobby for me.
[16:33:24] <Jartza> well. the homebrew-formula for avr-toolchain seems to work for other people than me, too :)
[16:34:10] <Jartza> ...if there is any mac-users
[16:34:44] <Jartza> ...with need for attny841, or just decently new avr-toolchain
[16:35:17] <Jartza> brew tap Jartza/homebrew-avr && brew install avr-libc
[16:55:31] <zerowidth> Jartza: i'm using crosspack-avr
[16:55:41] <zerowidth> which is in a brew cask thing
[16:55:48] <zerowidth> see
http://caskroom.io/
[17:06:17] <Jartza> zerowidth: I was using it too, but crosspack has very old versions
[17:06:23] <zerowidth> oh, does it?
[17:06:23] <Jartza> and no support for tiny841
[17:06:32] <Jartza> yes
[17:07:03] <Jartza> crosspack is last updated 2013
[17:09:18] <zerowidth> Jartza: what about
https://github.com/osx-cross/homebrew-avr ?
[17:09:21] <zerowidth> last updated yesterday!
[17:09:46] <Jartza> zerowidth: still no support for attiny441/841 :)
[17:10:11] <Jartza> and my tap has newer binutils :D
[17:10:35] <zerowidth> ahh
[17:10:46] <Jartza> 2.25.0 instead of 2.24.0
[17:11:45] <Jartza> but yes, basically a fork of that (or fork of fork)
[17:12:42] <Jartza> but if you need no t841, then of course any of those will do
[17:12:54] <zerowidth> yeah, cool
[17:13:02] <Jartza> :)
[17:13:03] <zerowidth> in any case avr-gcc 4.9.x is newer than 4.8
[17:13:09] <Jartza> true
[17:13:12] <LeoNerd> You -still- having trouble with the 841?
[17:13:17] <Jartza> no
[17:13:19] <Jartza> no trouble
[17:13:41] <Jartza> I made my own homebrew-tap to compile and patch the avr-gcc 4.9.2 to support attiny841
[17:13:47] <Jartza> got that already working yesterday :)
[17:13:48] <Martin90> Hello
[17:13:50] <Jartza> and blinking leds
[17:13:58] <Martin90> need your help
[17:14:08] <Martin90> I have a problem with CNY70 sensor (infrared)
[17:14:28] <Martin90> I planed to use it for line folower project
[17:14:31] <Jartza> zerowidth: I got 10 attiny841s as a sample, nice chips they are... :)
[17:15:04] <zerowidth> ah, are they the next generation of attiny84's?
[17:15:10] <Martin90> but now I am testing it and it is very very sensitive to light around and therefore my ADC has differenet values for differenet light conditions ;/
[17:15:21] <Martin90> any idea how to deal with it ?
[17:16:08] <LeoNerd> Just a single sensor?
[17:16:17] <zerowidth> Jartza: ooooh, those do look nice
[17:16:17] <LeoNerd> Any illuminator maybe?
[17:16:26] <Martin90> I test one of them but there will be more (3/4)
[17:16:35] <LeoNerd> Often the trick is to use an LED illuminator, and compare the *difference* between that being on or off
[17:16:35] <Thrashbarg> Martin90: usually the way around that is to have the IR source modulated to a frequency and have the sensor only respond to that frequency
[17:16:41] <zerowidth> Jartza: i'm building projects on the attiny84 right now, USARTs and proper i2c would be awesome
[17:16:57] <zerowidth> Jartza: wow, that would make a huge difference for me
[17:17:25] <Jartza> indeed
[17:17:39] <Jartza> I also made a project with attiny84, but I'm going to switch to 841
[17:17:41] <LeoNerd> zerowidth: Only I2C slave though, don't forget
[17:17:46] <Jartza> especially because of the uart :)
[17:17:48] <LeoNerd> tiny841 doesn't do I2C master
[17:18:03] <Jartza> luckily i2c master is quite easy to bitbang
[17:18:04] <Martin90> Thrashbarg, I don't see a case, freq has nothing to do about it
[17:18:09] <LeoNerd> True..
[17:19:00] <Martin90> The light around changes the ADC values significantly
[17:19:04] <Jartza> whereas slave is a bit harder to handle, although not that bad with pcint and stuff
[17:19:27] <Martin90> I also don't think the additional led would help
[17:19:44] <Valen> IR filter?
[17:19:53] <Valen> in the old days film negatives worked ok ;->
[17:20:18] <Martin90> IR filter ? Can you expand ?
[17:20:49] <Thrashbarg> Martin90: you're going about it a completely different way to what I was thinking so never mind
[17:21:01] <Valen> sorry, I thaught somebody was using an IR sensor and visible light was mixing stuff up
[17:22:01] <Martin90> that;s it
[17:22:11] <zerowidth> oh, i2c slave only, that's not as helpful. stll though
[17:22:17] <Martin90> but how do you want to make IR filter around ?
[17:22:20] <Valen> ahh it has a filter already
[17:22:27] <Martin90> yes it has
[17:22:41] <Martin90> datasheet says "Daylight blocking filter"
[17:23:52] <Valen> tried tuning your pullup/down
[17:27:06] <Jartza> zerowidth: yeah, the i2c-slave is a strange thing, but i2c-master is quite easy.
[17:27:24] <LeoNerd> Mhm
[17:40:53] <Jartza> attiny828 and 1634 also look nice, but they are so expensive it's a bit hard to justify them anymore, as you can then go to "mega" already
[17:43:10] <Jartza> like, atmega168pb is cheaper than attiny828
[17:46:02] <zerowidth> Jartza: if these chips were released more than a year ago, why aren't they supported in the avr toolchain yet?
[17:46:22] <Jartza> no idea
[17:46:49] <Jartza> at least I didn't find one for mac
[17:46:57] <Jartza> they are supported in atmel studio, of course :)
[17:47:01] <zerowidth> hah, naturally
[17:47:14] <zerowidth> ah well, i'll keep bashing my head against the attiny84 and driving ws2812's :)
[17:47:23] <Jartza> one of my favourite chips currently is attiny88.
[17:47:26] <Jartza> but just because of the price
[17:47:32] <Jartza> even cheaper than attiny85
[17:47:58] <zerowidth> and 32 pins!
[17:48:02] <Jartza> yep
[17:48:07] <Jartza> and spi and i2c :)
[17:48:09] <zerowidth> 85's are only something like $1.50 though
[17:48:12] <Jartza> only uart missing
[17:48:30] <Jartza> well, check the price for attiny88 :)
[17:49:07] <zerowidth> yeah wow
[17:49:21] <LeoNerd> tinies with UARTs are rare
[17:49:37] <LeoNerd> Amusingly the [24]312 have them, and I don't know why
[17:50:01] <zerowidth> Jartza: then again, $0.50 price difference is not the problem, it's my lack of knowledge and expertise about how to make anything work that's taking up all the time (and therefore "cost")
[17:50:27] <LeoNerd> No USI/I2C/SPI, no ADC, no PWM,... 2Ki of flash, yet for some reason Atmel decided the tiny2313 couldn't do without a UART
[17:50:36] <zerowidth> i mean, i could just go with an atmega328 or something, but i like having *some* constraint, hehe
[17:51:05] <LeoNerd> It's no fun if you don't end every build by eyeing the "total size" output from the linker ;)
[17:52:23] <Jartza> :)
[17:53:01] <Jartza> zerowidth: I have this "deficiency" that I want to get "most out" of any chip :D
[17:53:18] <Jartza> hence I worked long with attiny85
[17:53:29] <zerowidth> Jartza: haha, exactly!
[17:54:27] <zerowidth> Jartza: in any case i consider it a learning exercise. if i wanted to get this thing done *fast* i'd just buy an arduino pro mini and call it done
[17:54:50] <Jartza> yeah
[17:55:17] <Jartza> in "real products" there are of course multiple things to consider
[17:56:00] <Jartza> and then the chip price is of course one important thing, power consumption etc
[17:59:35] <zerowidth> good thing i'm not making a real product, then :D
[18:01:52] <zerowidth> Jartza: hm,
http://www.atmel.com/Images/avr8-gnu-toolchain-3.4.3.1072-readme.pdf says the attiny841 is supported
[18:03:16] <zerowidth> Jartza: and same for
http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.5/#__utma=51109366.430844035.1424122547.1424300041.1424302009.3&__utmb=51109366.16.8.1424302919259&__utmc=51109366&__utmx=-&__utmz=51109366.1424302009.3.3.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided)&__utmv=51109366.|1=Revenue%20Range=%241%20-%20%241M=1^2=Employee%20Range=Small=1^3=Industry=Business%20Services=1^4=Audience=SMB=1^5=Marketi
[18:03:16] <zerowidth> ng%20Alias=Dianne%20Johnson=1&__utmk=244185537
[18:03:18] <zerowidth> holy shit sorry
[18:03:37] <Jartza> zerowidth: yes, but crosspack is not "avr toolchain"
[18:04:00] <Jartza> or at least, not "pure" one
[18:04:20] <zerowidth> wow what is wrong with that url though
[18:04:35] <zerowidth> Jartza: ah, hm, the atmel site links avr-gcc 4.8.1 here
[18:04:38] <zerowidth> and libc-1.8.0
[18:05:39] <Jartza> yeah. atmel makes their own toolchain.
[18:05:52] <Jartza> but crosspack was also missing some xmegas
[18:06:00] <zerowidth> ah different from the nongnu one?
[18:06:04] <Lambda_Aurigae> it's all based on the same gcc toolchain...atmel just does their own build with their own extensions.
[18:06:20] <Jartza> sure, the base is the same
[18:06:22] <Lambda_Aurigae> extensions/patches
[18:06:28] <Jartza> yep
[18:08:58] <zerowidth> cool
[18:09:49] <Lambda_Aurigae> ok...going braindead....how to see the list of supported processors in avr-gcc?
[18:11:19] <Jartza> Lambda_Aurigae: avr-gcc -mmcu=unknown
[18:11:19] <Jartza> :)
[18:11:35] <Lambda_Aurigae> thanks.
[18:12:50] <Lambda_Aurigae> hmm...no attiny841 in the ubuntu base avr-gcc install.
[18:13:55] <Jartza> http://pastie.org/9960757
[18:14:05] <Jartza> this is what "my" avr-gcc now says
[18:14:25] <Lambda_Aurigae> is not a big deal for me.
[18:14:37] <Lambda_Aurigae> don't have any 841 chips.
[18:15:22] <Jartza> yeah. not big deal indeed, if you don't use any chips that aren't on the list :)
[18:15:31] <Lambda_Aurigae> yup.
[18:15:45] <Lambda_Aurigae> I've patched and compiled the toolchain in the past to add chips.
[18:16:04] <Jartza> I guess the "proper" way would be to make homebrew tap for "atmel toolchain" which includes all the latest patches
[18:16:08] <Jartza> but not the latest compiler
[18:16:41] <Jartza> although 4.9.x seems to make tighter code in some cases than 4.8.x