Back
[02:27:46] * _ami_ reads avrdude code to just understand how usbasp works!
[02:41:37] <eszett> I have no idea how usbasp works, i just use it to flash my Atmel =)
[02:45:13] <_ami_> best documentation is actually the code. :)
[02:58:06] <eszett> not for stupids like me
[03:26:21] <_ami_> eszett: well written code is easier to understand. avrdude is code is also well written.
[03:26:58] <_ami_> It can be extended also. like i can write my own version bootloader protocol support in avrdude easily.
[04:22:20] <l9> _ami_: why would you need too have a bootloader support in avrdude?
[04:45:59] <twnqx> l9: so acrdude can uplaod new firmware using that bootloader
[05:05:45] <_ami_> l9: umm?
[05:10:26] <l9> i cant see any reason why a bootload is used unless you are on a arduino
[05:13:55] <twnqx> because it allows to program the usb enabled AVRs without any extra hardware, for example
[05:14:11] <twnqx> or ANY avr with a usable external config
[05:14:36] <_ami_> yeah, indeed.
[05:15:32] <_ami_> its annoying for me to connect programmer cable to chip whenever i want to program.
[05:15:51] <_ami_> also using bootloader, i can upload firmware remotely.
[05:16:14] <_ami_> its just like whenever u do update your mobile firmware.
[05:17:45] <l9> ssh host & avrdude ? remote
[05:18:30] <l9> using raspberry zero with avrdude
[05:19:02] <_ami_> brb! tea time
[05:30:00] <l9> still dont think it is a must have, and that it is a huge security issue. using your model anyone with an usb can reprogram your device
[05:32:20] <twnqx> noone says that you can't have cryptographic signatures on the uploaded code
[05:33:18] <l9> yeah thats true, and by adding that you are using space that should be used too the code ...
[05:33:21] <twnqx> and i don't think it makes much of a difference if you can program via usb or jtag or isp or can or...
[05:33:38] <twnqx> physical access is physical access
[05:36:15] <l9> true but why add that when you could use a programmer that works over wifi? that way you could have a good debugger table
[05:37:51] <l9> i have no need too actually code the avr inside the circuit i know what my avr should do if there is a error i need too have that tested
[05:38:09] <l9> not the avr
[05:39:05] <twnqx> so wired connections are insecure, but wireless is fine?
[05:39:11] <twnqx> wow.
[05:39:20] <l9> inside my lab YES
[05:40:38] <l9> if a avr needs too leave outside my lab it is soildered into the circut with no programming possibility
[05:41:32] <DKordic> l9: I think it is obvious that bootloader makes sense only in development.
[05:42:03] <twnqx> or in anyting that you WANT to be field updateable
[05:42:20] <DKordic> twnqx: Exactly.
[05:42:53] <DKordic> But small computers, like AVR, make that difficult :) .
[05:43:10] <twnqx> personally, i think i that the era of avr/pic should be over
[05:43:33] <twnqx> with factor 100 or more worce price/performance than other embedded chips...
[05:43:38] <twnqx> worse*
[05:44:17] <DKordic> Uh, there are a lot of factors involved.
[05:45:07] <l9> morning DKordic
[05:45:34] * l9 still see no reason too have bootloaders inside the avrdude
[05:45:47] <DKordic> Morning.
[05:45:55] <twnqx> you don't want bootloaders in there
[05:46:02] <twnqx> you want code that can talk to bootloaders
[05:46:42] <l9> no i dont
[05:47:02] <l9> i dont give a crap in boot loaders or support of it
[05:47:13] <twnqx> like i don't give crap about raspis
[05:47:29] <DKordic> twnqx: +1
[05:48:05] <twnqx> just because YOU don't want them doesn't mean noone should want them, and they should not be supported
[05:48:23] <l9> did i say that ?
[05:48:39] <l9> you said i wanted it
[05:48:45] <twnqx> where?
[05:48:54] <l9> 12:19:04 twnqx:�� you want code that can talk to bootloaders
[05:49:02] <l9> no i dont want that
[05:49:55] <l9> and what a raspberry had todo with it i have no idea
[05:49:58] <twnqx> i think your grasp of english is too weak to continue this discussion if you can't differenciate between a directly addressing "you", and a "you" referring to the general public
[05:50:01] <twnqx> EOD
[05:50:23] * l9 nods
[05:53:19] <twnqx> especially as you turned the original point upside down, from _ami_ liking the structured code of avrdue because it allows them to add support for their bootloader, which obviously implies they want bootloaders, to "that's pointless because i don't want bootloaders"
[05:55:06] * l9 goes of too deep state meditation too have a look into that might be important
[06:31:54] <_ami_> twnqx: :)
[06:39:12] <_ami_> l9: btw, it was an opinion abt how good avrdude code is. :)
[06:39:52] <_ami_> i am not going to add support of another bootloader protocol into avrdude. :) it was just abt how good and well structured avrdude code is.
[06:40:42] <_ami_> and you know things do get change overtime. CHANGE is inevitable.
[06:44:14] <Lambda_Aurigae> _ami_, just a heads up, alan_o over on that OTHER channel is the one who wrote m-stack.
[06:44:38] <Lambda_Aurigae> change is inevitable except from the coke machine.
[06:54:30] <DKordic> Lambda_Aurigae: Perhaps You meant _abc_?
[07:00:15] <LeoNerd> twnqx: English really does need a 2/3rd person plural pronoun
[07:10:41] <Haohmaru> i'm talking to a RTC over spi (MCP795W) and it doesn't seem to tick.. i thought i've burnt it but i noticed it returns 01 for "day" "date" and "month", zero for the seconds, minutes, hours.. etc
[07:19:31] <LeoNerd> I'm not familiar with the MCP chip. I've done DS1307 and PCF8563
[07:54:13] <LeoNerd> Hrm.. is it just me or do mouser not actually have *anything* by Linear Technology?
[07:54:28] <LeoNerd> They literally don't list them in the manufacturers list. I want an LTC1634
[07:54:34] <LeoNerd> Er.. LT1634
[07:59:46] <Haohmaru> they are in their blind spot maybe
[08:00:22] <LeoNerd> Annoying, because several other parts I want are only on mouser, and not Farnell..
[08:00:48] <LeoNerd> But both Farnell and Mouser have minimum order levels. If one vendor had all the bits, it would reach the required level. But if I split my order, it doesn't. :(
[08:02:09] <eszett> minimum order? for free shipping, but you can order 1 diode and pay like 30€ shipping, isn tit?
[08:02:23] <LeoNerd> Yah.. that's what I mean. I -can- order but then pay shipping
[08:02:28] <eszett> ok sure.
[08:02:38] <LeoNerd> Though up until recently, Farnell literally did not let you order <£20, to a non-trade account
[08:03:15] <eszett> i prefer mouser or digikey anyway, for broader range of products and prices are "ok" anyway
[08:03:43] <LeoNerd> Mouser has larger "free shipping" limit than Farnell
[08:03:48] <eszett> ye
[08:04:00] <LeoNerd> Doubly so annoying because most of the component prices seem to be sliiiightly cheaper there
[08:04:07] <LeoNerd> So yo have to order even more :)
[08:04:11] <eszett> Thats why im attending group orders
[08:04:34] <eszett> Are you in Europe?
[08:04:37] <LeoNerd> UK
[08:04:42] <LeoNerd> So... complicated questoin ;)
[08:05:08] <eszett> hmm good. Maybe we can organize a GO now and then
[08:59:58] * LeoNerd decides to buy it all from Farnell except one part that comes from eBay, because.. :/
[09:00:19] <LeoNerd> I even bought the *second* cheapest one on eBay, because I wonder if the cheapest one is actually a cheap off-brand knockoff
[09:00:32] <LeoNerd> And I don't want an offbrand precision voltage reference
[09:18:46] <twnqx> WormFood: i asked you if you know how to get baidu bucks for cash, right?
[09:19:15] <twnqx> if not, do you? :>
[10:09:52] <_ami_> i think barewolf is managing this project actively.
https://github.com/baerwolf/USBaspLoader. is it the official one? i have a patch to improve this a bit.
[10:14:16] <skz81> _ami_,
https://www.obdev.at/products/vusb/usbasploader.html
[10:14:26] <skz81> << Stephan Bärwolf maintains a fork of USBaspLoader on Github which is actively maintained. >>
[10:14:33] <skz81> So yes, kinda official
[10:16:13] <_ami_> cool
[10:16:17] <_ami_> skz81: thanks
[10:21:25] <WormFood> twnqx, I don't know anything about baidu bucks.
[10:22:26] <WormFood> If you did ask me, I didn't see it. I went away on Saturday, and just came back today. And while I was gone, there was another power failure (it never happens when I'm fuckin' here), so if you sent me a message while I was gone, I wouldn't see it when I got back.
[10:24:07] <twnqx> nah, more like weeks/months ago :P
[10:24:16] <WormFood> I didn't see it
[10:24:44] <WormFood> 2 weeks ago I had another power failure (while I was gone), so if you asked me in the right (wrong) window of time, I would have missed it.
[10:27:12] <_ami_> guys, which of the seller you trust or had good buying experience on aliexpress?
[10:27:50] <LeoNerd> I've only bought one thing ever there
[10:27:59] <LeoNerd> because none of Farnell/RS/Mouser/eBay/... had it
[10:28:47] <WormFood> I don't buy electronics online. I just walk to the market and get nearly anything I want.
[10:29:07] <LeoNerd> ... hah
[10:29:22] <LeoNerd> I don't know a physical shop anywhere in the world where I could get most of the things I just ordered this weekend
[10:29:44] <twnqx> i do :3
[10:29:51] <WormFood> LeoNerd, like what?
[10:30:04] <LeoNerd> Random example: LT1634BIS8-1.25
[10:30:06] <twnqx> but probably "SEG Plaza, Shenzhen, PR China" doesn't help much :D
[10:30:10] <WormFood> If it's sold in high volumes, I can almost guarantee I can get it within walking distance.
[10:30:38] <twnqx> WormFood: i might skype you a shopping list in the relatively near future :3
[10:30:54] <twnqx> that has mostly obscure parts though, i guess
[10:31:25] <WormFood> obscure parts are harder to find, obviously. I can't get everything here, but if it's in mass produced electronics, then nearly positive I can get it.
[10:31:28] <twnqx> so obscure i'd have to head over to arrow and future electronics, because noone else lists those parts
[10:31:45] <twnqx> well, taobao lists them :3
[10:33:15] <twnqx> cavium, microsemi (ex-vitesse), sk hynix, ...
[10:33:52] <twnqx> not sure yet about the power regulation stuff. that seems even worse
[10:34:49] <twnqx> maybe lattice for that
[10:35:05] <Ashleee> https://www.kickstarter.com/projects/creoqode/2048-the-diy-open-source-game-console/description
[10:35:07] <Ashleee> only atmega2560?
[10:35:13] <Ashleee> for 2048 LEDs? for "games"?
[10:35:26] <Ashleee> .. I just realized i have not spoken here in years :)
[11:01:52] <bss36504> Anybody have any lluck using the asf functions to configure the analog comparator? I can't seem to make it work. Another related question is: What special setup (if any) is necessary in order to make the ACOUT pin active? I assume I need to set it as an output, but still, not working.
[11:02:32] <LeoNerd> I think there's a config bit to enable it
[11:02:36] <LeoNerd> What chip?
[11:02:40] <bss36504> Currently I have the voltage scaler on one input, and the DAC on another input. The DAC is being set higher and lower than the (expected) scaled voltage so it should be working.
[11:02:44] <bss36504> XmegaE
[11:03:10] <bss36504> I followed the example in the ASF document pretty much exactly, except for the reference settings.
[11:03:27] <LeoNerd> Ah; I don't know the xmegas. But I presume there probably is a config bit, if only because the similar parts on the ATmegas have such a config big
[11:03:30] <LeoNerd> bit
[11:03:44] <bss36504> Like an enable config bit? I do believe I am setting that
[11:04:04] <bss36504> Dont have code with me at work, unfortunately. Just looking for ideas to check later when im home
[11:04:37] <LeoNerd> As in, a particular enable bit for the ACOUT pin
[11:04:52] <bss36504> OH!
[11:04:57] <bss36504> ok...good to know
[11:05:36] <bss36504> I've been trying to embrace the new ASF and ASF wizard. Unfortunately, it makes me lazy and I don't have the same level of scrutiny of the registers that I usually have.
[11:07:09] <bss36504> Oh well duh, just looked and CTRLA has an "AC1OUT enable bit"
[11:07:13] <bss36504> Thanks LeoNerd!
[11:08:11] <bss36504> Interesting that the ASF library doesn't have a function to abstract that for you. Seems kind of silly...
http://asf.atmel.com/docs/3.0.1/xmega.drivers.ac.example.xplain/html/group__analog__comparator__group.html
[11:08:14] <LeoNerd> :)
[11:09:09] <bss36504> Other than this, ASF worked great for setting up the DAC. Much easier than writing all my own functions to set it up, much easier than looking at every bit in each register.
[11:11:31] <LeoNerd> I've been building my own set of support functions for AT{tiny,mega} chips at least
[11:11:46] <LeoNerd> I tend to find most premade things don't ever consider nonblocking abilities
[11:12:05] <LeoNerd> ... same is just as true for tiny AVR libraries as for huge perl things, and any other size in between.. :/ Story of my life it seems
[11:12:24] <bss36504> I know what non-blocking is, but can you give an example?
[11:13:36] <LeoNerd> E.g. ADC reads
[11:14:09] <bss36504> Oh like you want a function to just kick off the conversion and you'll check it later? I guess I can see that as helpful
[11:15:55] <LeoNerd> Yes; I often do them in pairs if it's something like that
[11:17:01] <bss36504> Well this is where a class based API would be good. Atmel could do all the grunt work of making the bit defines and most of the blocking functions, then we could just add functionality by extending classes or *shudder* adding friend functions
[11:18:01] <LeoNerd> Ohsure.. a sufficiently competent upstream could do that just fine
[11:18:10] <LeoNerd> I find that in practice, none of them do. So I make my own stuff
[11:18:45] <bss36504> Well, FWIW, might be worth your while to rip out the bit defines and such at least. May save you some work on the boilerplate stuff.
[11:18:58] <LeoNerd> I use the <avr/io.h> set
[11:19:04] <LeoNerd> So most of the time, that's already taken care of
[11:19:29] <LeoNerd> That doesn't help *that* much in practice... e.g. consider the split nature of the WGnx bits of 16bit ATmega timers
[11:19:39] <LeoNerd> WG10 and WG11 are in one register, WG12 and WG13 are in another
[11:20:15] <bss36504> True true
[11:20:32] <bss36504> I never understood that particular decision.
[11:20:51] <LeoNerd> Extension
[11:21:10] <LeoNerd> This is only the "current" generation of an older design
[11:21:45] <bss36504> Oh i guess that does make sense. The 16 bits were added after the 8 bits I presume.
[11:22:33] <LeoNerd> You can track the various versions of timers and so on through older to newer ATmega/ATtiny chips
[11:23:05] <LeoNerd> Also the UARTs... some of the very newest chips have a control register D for the UART, which has control bits and flags for the "interrupt on receive start" interrupt, which is a new addition
[11:23:18] <LeoNerd> That's why the interrupt flag and enable control bit are both shared in the same register
[11:33:40] <WormFood> weird. my irc client just locked up for no apparent reason.
[11:34:27] <WormFood> Ashleee, I looked at that kickstarter, and ugh. Why do people do this? The ATmega2560 is not a suitable mcu for a game machine.
[11:35:08] <WormFood> I mean, not the type of system they're building. They really need to be able to execute from ram.
[11:35:24] <Ashleee> WormFood, oh hey I remember your name :) yeah, honestly even xmega or preferably some small 32bit ARM Cortex M<whatever> would be much more suitable for the same costs heh
[11:35:31] <bss36504> WormFood: BECAUSE ARDUINO
[11:35:34] <Ashleee> and that
[11:35:44] <Ashleee> everybody loves arduino!
[11:36:17] <WormFood> I agree, the ARM would be a much more suitable machine for that type of system.
[11:36:31] <WormFood> er, mcu...you know what I mean.
[11:36:49] <bss36504> Literally, the board is an Arduino Mega just slightly tweaked. Its easy to design products when you copy an open source schematic/layout exactly
[11:36:58] <Ashleee> yeah
[11:37:04] <Ashleee> and cheap LED matrix board :)
[11:37:09] <Ashleee> and then 99 pounds pricetag
[11:37:14] <Ashleee> ok they do have custom chassis
[11:37:36] <Ashleee> when I was finishing secondary school I did 48x32 bi-color (+ shades) LED array, fully run off computer via USB and Atmega128a :D
[11:37:42] <bss36504> Seriously, the most innovative thing is the chassis, and the fact that they suckered 91 people into backing it.
[11:37:43] <Ashleee> colour* (british, please)
[11:37:47] <Ashleee> haha
[11:38:20] <Ashleee> one day I might get back to embedded dev
[11:38:33] <Ashleee> heck we're looking at custom ARM64 powered servers at work, but there's no good ones :(
[11:39:05] <bss36504> Sorry, not trying to sound really salty, I just get irrationally upset when every third project on kickstarter or hackaday is "Powered by Arduio/RPi/Processing OSHW #OpenSource #TechHippy"
[11:39:54] <bss36504> It's a lot of inexperienced people pretending to be disciplined engineers who leverage the work of people who know a lot more than them.
[11:39:56] <Ashleee> hehe
[11:40:12] <Ashleee> but they have code sharing website!!111oneonecos(0)
[11:40:22] <Ashleee> project sharing*
[11:40:27] <Ashleee> where you can share your games!
[11:40:48] <Ashleee> I can't imagine how much CPU will be eaten just by screen refreshing, unless there's a dedicated controller on that
[11:41:10] <bss36504> Yeah, well maybe they matched their refresh rate to the super low resolution
[11:41:19] <WormFood> You have to reprogram the flash for every game (unless you have a mutl-game)
[11:41:26] <WormFood> multi-game*
[11:41:27] <Ashleee> if they want shades of colours they need quite high refresh rate
[11:41:27] <bss36504> Also, that LED display surely costs more than an LCD
[11:41:45] <bss36504> (In quantity*"
[11:41:53] <WormFood> It's not about being efficient or cool. It's about what this person figured out.
[11:42:09] <Ashleee> heh
[11:42:18] <Ashleee> I wanted to do arduino clone but with atxmega
[11:42:22] <Ashleee> but then ARM became cheap
[11:42:23] <Ashleee> :(
[11:42:40] <LeoNerd> It's hard to see what the future of xmega is currently, given ARMs being as they are
[11:42:47] <bss36504> It's too bad, really. Xmega is what the original AVRs should have been
[11:42:49] <Ashleee> xmega is still alive?
[11:42:50] <LeoNerd> Hell; some of the larger ATmegas even
[11:42:50] <Ashleee> yeah
[11:42:51] <WormFood> they're totally different things
[11:42:56] <Ashleee> I did some things with xmega
[11:43:00] <LeoNerd> AVR32 died a while ago
[11:43:04] <Ashleee> :)
[11:43:09] <Ashleee> AVR32 was replaced by ARM
[11:43:21] <bss36504> No way AVR32 could compete with supercorporation ARM
[11:43:34] <WormFood> With the ARM core being so damn cheap, it makes sense to use that.
[11:43:41] <bss36504> But Xmega could have had a chance to be the mainstay of 8bit, for which there continues to be a market.
[11:43:58] <bss36504> But I think the development was late. Atmel should have refreshed the portfolio with them like 5 years ago
[11:44:07] <bss36504> not like it wasnt technically possible
[11:44:22] <Ashleee> I messed with xmega ... 5 years ago? huh, before I went to uni the first time
[11:44:24] <Ashleee> so 4 years
[11:44:29] <LeoNerd> It would be nice to see the ATmegas gaining a few more bits and pieces lately... I'm not sure if the totally different structure of Xmega would make much sense
[11:44:34] <Ashleee> still remember xmega128a1u with SDRAM controller :)
[11:44:46] <bss36504> I should have said "5 years sooner than they did"
[11:44:52] <Ashleee> I am more about price point and size comparison of small ARMs vs xmega
[11:44:53] <Ashleee> ah
[11:45:05] <bss36504> LeoNerd: How are they "totally different"
[11:45:16] <Ashleee> for C programmer they are the same really
[11:45:18] <bss36504> It's the same core/instruction set, just more advanced peripherals
[11:45:26] <Ashleee> for ASM mostly as well
[11:45:32] <Ashleee> just more features, more registers
[11:45:34] <LeoNerd> The periphs are quite different though
[11:45:41] <Ashleee> more things to take care of
[11:46:00] <bss36504> Well I guess that begs the question: What makes the Micro, the core or the periphs?
[11:46:01] <Ashleee> I probably still have a box of some xmega32a4u and 256a3u somewhere :D
[11:46:19] <LeoNerd> You can generally move between any of the ATtiny and ATmega chips and the same peripheral, if present, will behave in the same way (give or take the 20-billion different timers around :/) But then the Xmega periphs, while quite similar between Xmegas, are different to the ATtiny/ATmegas
[11:47:03] <LeoNerd> I can take some code on some ATtiny/ATmega and if I decide I've run out of IO pins or flash or periphs or whatever, I can just find a bigger chip and things will generally be fine. But I couldn't swap up to an Xmega without large amounts of rewrite
[11:47:21] <bss36504> I guess I see your point there, but that's why I said they should have pushed them sooner. They are objectively better 8-bit processors than almost all other 8-bits on the market, as far as I know
[11:47:54] <bss36504> You have the same level of code portability on the xmega platform, even though it's not backwards compatible to regular mega
[11:48:06] <Ashleee> but is there a reason for 8bit micros in this package and sizes and prices?
[11:48:12] <LeoNerd> They still don't have IO crossbar matrix though ;)
[11:48:16] <LeoNerd> (*ahem* PIC2$)
[11:48:18] <LeoNerd> PIC24
[11:48:23] <bss36504> Ugh Fuck pics man.
[11:48:33] <bss36504> lol
[11:48:54] <bss36504> Ashleee: I imagine price is mostly driven by demand
[11:49:03] <LeoNerd> Ohsure; I generally dislike them, but the PIC24 series does have hat crossbar going for it; in a way that I've not seen on *any* Atmel chip; from the smallest tiny right up to the biggest Xmega
[11:49:20] <Ashleee> xmega at least has a LOT of peripherals around
[11:49:30] <bss36504> Everyone and their brother is an ARM programmer, not so much for the little 8-bit and 32-bit lines from other vendors
[11:49:35] <LeoNerd> Yah; having multiple copies of the peripherals can mitigate the lack of crossbar
[11:49:39] <LeoNerd> To a point
[11:49:51] <Ashleee> sometimes swapping rx and tx would help...
[11:49:59] <WormFood> I'd still rather program a motorola cpu in asm, than anything else.
[11:50:06] <LeoNerd> Case in point: the 32U4 chip is *terrible* for IO pins
[11:50:13] <LeoNerd> The four INT pins are muxed on the I2C and UART pins.
[11:50:20] <Ashleee> heh
[11:50:29] <bss36504> That is a bad choice I suppose haha
[11:50:35] <LeoNerd> Meaning: if you're talking to I²C sensors, which likely have an interrupt output.. er... you lose two of the interrupt pins
[11:50:41] <LeoNerd> Or all four if you're using UART as well
[11:50:58] <bss36504> Somebody once tried to sell me on PIC because some of them have a HW RS latch. I laughed all day long
[11:51:06] <LeoNerd> But that's OK because the 32U4 has 8 PCINT-capable IO pins. Oh but wait - 3 of those are on the SPI port.
[11:51:07] <LeoNerd> Oops
[11:51:13] <LeoNerd> ... so basicalyl you're screwed however you do it
[11:51:18] <LeoNerd> If only there was a goddamned crossbar
[11:51:26] <bss36504> LeoNerd: Well it does only have 32 pins
[11:51:32] <LeoNerd> Right
[11:51:33] <Ashleee> "only"
[11:51:37] <bss36504> and atmel has always had analog and digital separately.
[11:51:39] <LeoNerd> Most PIC24s are about that size
[11:51:51] <LeoNerd> But PIC24s dont' have this problem because they have a fully arbitrary IO crossbar
[11:51:53] <bss36504> maybe they should have done a half port of analog and put some interrupts on it too
[11:52:10] <LeoNerd> PIC24 chips have basically power, ICSP, xtal, ... and then every other pin is just "GIO[number]"
[11:52:30] <LeoNerd> Then all the peripherals are attached to that crossbar; so you can in software (possibly even dynamically) assign any peripheral function to any GIO pin
[11:52:35] <LeoNerd> I would /really/ love that on an AVR
[11:52:52] <Ashleee> yup we had PIC24 at my first uni
[11:52:54] <bss36504> Maybe microchip will let atmel do that on the next xmega lineup
[11:52:56] <Ashleee> last semester before I got kicked out :D
[11:53:12] <LeoNerd> Some of the ATtiny chips are starting to get a *hint* of that ability. tiny841 has a two-bit REMAP register, which lets you move UART0 or SPI port to *an* alternate location
[11:53:24] <WormFood> kicked out? how'd that happen?
[11:53:33] <Ashleee> maths theory :)
[11:53:36] <Ashleee> and definitions
[11:53:43] <Ashleee> then I switched unis, hated it there
[11:53:55] <LeoNerd> tiny1634 has started that way with the timer output pins. On the tiny1634 the assignment of timer units to OC pins is somewhat flexible.
[11:53:56] <LeoNerd> That's still nowhere near a full crossbar, but it's a start. I hope they continue. I'd like to see a lot more
[11:54:00] <Ashleee> had some personal issues, deleted all my history online and partially IRL, changed identity and other things and now I am a fulltime sysadmin :)
[11:54:40] <LeoNerd> Oh other use of having a crossbar - you can route periph->periph connections *internally* without needing IO pins.
[11:54:44] <LeoNerd> You can do some funky things with that
[11:54:50] <bss36504> Oh LeoNerd, Xmega has interrupts on all pins
[11:54:57] <bss36504> at least xmegaE
[11:55:09] <LeoNerd> bss36504: Yes; most ATmega and ATtiny chips have basically PCINT capability on any pin
[11:55:16] <LeoNerd> I don't know why the 32U4 has only a single 8-bit PCINT bank
[11:55:18] <bss36504> Also, inter-periph comms is handled with the Event System
[11:55:55] <LeoNerd> But then the 32U4 is a strange beastie in many ways. Such as that RAM size - 2.5Ki ??
[11:56:03] <LeoNerd> Two *and a half* kibibytes??
[11:56:25] <Ashleee> because USB buffers
[11:56:27] <LeoNerd> Because, what... 2Ki wasn't *quite* big enough for everyone so they added a bit more, but thought that 4Ki would be excessive??
[11:56:28] <Ashleee> eat a chunk
[11:56:33] <Ashleee> but yeah
[11:56:42] <Ashleee> I still remember me writing USB stack for xmega :)
[11:56:46] <bss36504> It might be that the USB takes up die space, and the marketing guy told the designers to make the die fit in a certain size so he could sell it for $xx
[11:56:56] <LeoNerd> I mean, it's nice that ATmega finally has some native USB support, but the 32U4 is *not* a nice chip to work with
[11:57:16] <Ashleee> xmega ^_^
[11:57:19] <LeoNerd> And I still have no idea why it has the PORTs that it has
[11:57:56] <bss36504> LeoNerd: Just ask _ami_, VUSB all the way ;)
[11:58:19] <LeoNerd> It has two ports that only have 2 bits populated each; PORTC has only PC6/PC7; and PORTE has only PE2/PE6
[11:58:27] <Ashleee> I remember RikusW doing software USB on atmegas :)
[11:58:38] <LeoNerd> Oh and PORTF is also missing two bits; it lacks PF2/PF3
[11:58:42] <WormFood> VUSB
[11:58:42] <LeoNerd> ... whatthefuck guys?
[11:58:54] <Ashleee> LeoNerd, reusing things from other chips?
[11:59:00] <WormFood> VUSB sucks, but it works.
[11:59:01] <Ashleee> easier compat?
[11:59:14] <LeoNerd> I remain convinced that the 32U4 was designed in a weekend by a couple of drunk interns who got left behind at some party
[11:59:21] <Ashleee> haha
[11:59:45] <LeoNerd> The engineers left the office drunk on Friday, came in on Monday and there was this scribble on the whiteboard, so they went "Eh, lets do it" and committed it to silicon
[12:00:03] <_ami_> LeoNerd: :P
[12:00:27] <LeoNerd> Anyhow.. In summary: Dear Atmel: GIVE ME A GODDAMNED CROSSBAR MATRIX ALREADY!
[13:35:51] <inkjetunito> good evening
[13:37:00] <_ami_> inkjetunito: yo
[13:38:16] <inkjetunito> what's a nice component for switching larger currents?
[13:39:11] <LeoNerd> Some sort of FET?
[13:39:16] <LeoNerd> How large are we talking?
[13:39:48] <inkjetunito> a few amps. i'm using transistors atm, but the larger one is surprisingly slow. maybe it's just too old
[13:44:22] <_ami_> inkjetunito: how much is the delay?
[13:45:26] <inkjetunito> 0,25 µs rise, 0,4 µs fall, 3 µs storage
[13:48:07] <_ami_> few nS is okay. but you get >250ns
[13:49:20] <_ami_> did u put some capacitor at base side? over resistor for speed up?
[13:49:56] <inkjetunito> _ami_: nope, i didn't. nice to know that the old junk is slow though :)
[13:50:57] <_ami_> if u put capacitor, it should improve the rise for sure.
[13:51:13] <inkjetunito> _ami_: ok. i will look into it
[13:53:50] <_ami_> damn.. both read and write flash code for bootloader goes over 2kb {data + text}
[13:53:54] * _ami_ sighs
[13:55:49] <_ami_> Guys, i can have more than 2kb size bootloader? under 4k of course?
[13:55:56] <_ami_> i think i read it somewhere..
[13:56:44] <LeoNerd> only powers of 2 I believe
[13:58:50] <_ami_> LeoNerd: i can choose any value between 0x3000 to 0x3800? this is what u meant?
[13:59:31] <_ami_> and that should be 2 to power K
[13:59:36] <_ami_> where k is an int
[14:01:05] <LeoNerd> The size of the bootloader region can only be a power of 2
[14:01:13] <LeoNerd> 0.5k 1k 2k 4k
[14:01:35] <LeoNerd> it ends at the top of flash, so it begins wherever would put it
[14:07:21] <_ami_> LeoNerd: but we give .text section of bootloader to be 0x3800 for 16kb total flash
[14:07:47] <_ami_> ah, i got ur point.. u meant the region size
[14:07:49] <_ami_> sorry
[14:07:50] <_ami_> :P
[14:09:23] <_ami_> so 0x3000 for me if bootloader size > 2kb
[14:09:47] <_ami_> 16kb - 0x3000 = 4096
[14:14:42] <Lambda_Aurigae> _ami_, alan_o is live on ##pic if you want to chat with him.
[14:15:35] <_ami_> Lambda_Aurigae: sure
[14:15:45] <_ami_> he is the one wrote m-stack?
[14:17:06] <Lambda_Aurigae> yup.
[14:17:26] <inkjetunito> _ami_: without any measuring equipment, i can't tell whether the cap helps or not, but it's good to know about such a trick :)
[14:20:10] <_ami_> inkjetunito: i think there is a term for this kind of caps use. speed up caps
[14:20:48] <_ami_> i read it somewhere abt this long time back when i was wondering/searching abt when to use which types of transistors
[14:28:19] <_ami_> LeoNerd: i need to change fuse settings too for using 4k size bootloader.
[14:29:18] <Ashleee> without checking out datasheets, how many write cycles can these AVRs survive on average? :)
[14:29:27] <_ami_> generally i realize this when i test the code and it does not work.
[14:29:36] <_ami_> 10000 Ashleee
[14:29:39] <Ashleee> thanks
[14:31:19] <_ami_> Ashleee: its actually very long. i flash 10 times in a day so it would wear out about 2.5 years
[14:31:27] <Ashleee> yeah was wondering about that :)
[14:32:37] <_ami_> Ashleee: i got few avr mcus from UK, so i am assuming that it would last longer than mcus from china :P
[14:32:44] <Ashleee> :D
[14:33:23] <Ashleee> checking out what Atmel is offering.. there are exactly the same xmegas I seen 4 years ago
[14:33:42] <_ami_> before it is close to die, i will make sure to use it in some permanent gadget :D Ashleee ^
[14:33:49] <Ashleee> :D
[14:34:26] <Ashleee> was wondering aobut those "portable consoles", how feasible it would be to stick some 2MB flash on the board and allow reflashing from bootloader to switch "cartridges" :D
[14:34:38] <Ashleee> or maybe 16MB flash for those 256/384kB xmegas :D
[14:36:11] <Ashleee> but then again ARM...
[14:57:59] <_ami_> a lot less people hangout at pic channel. is it less popular among hobbyists?
[14:58:09] <LeoNerd> Possibly so
[14:58:29] <LeoNerd> Arduino is probably responsible a fair amount for the newer "hobbiest"-types around here
[14:59:06] <_ami_> make sense.
[14:59:12] <_ami_> makes*
[14:59:49] * LeoNerd is hoping to get the mega328PB board done in a week or so :)
[15:01:06] <_ami_> LeoNerd: is there any limit on bootloader region size on avr ?
http://www.engbedded.com/fusecalc/ -> this only shows fuse settings for bootloader size up to 2kb
[15:01:18] <_ami_> for mega16a
[15:01:22] <LeoNerd> It depends on the chpi
[15:01:23] <LeoNerd> chip
[15:01:28] <LeoNerd> You can only set what the fuses allow
[15:01:34] <_ami_> aha, ok
[15:01:35] <_ami_> got it.
[15:02:23] <_ami_> mega328p allows 4kb boot loader.
[15:03:00] <LeoNerd> Yah; given as the bootloader eats into application space, I wouldn't be surprised if larger chips allows larger bootloaders
[15:03:45] <_ami_> LeoNerd: is this one
http://www.atmel.com/tools/MEGA328PB-XMINI.aspx you making?
[15:05:08] <LeoNerd> Ish.. mine's a lot smaller
[15:05:11] <LeoNerd> Mine's arduino nano sized
[15:06:14] <_ami_> you got the mcu only and you are making a board for it.
[15:06:15] <_ami_> nice.
[15:06:20] <bss36504> Ashleee I think the xmega E is fairly new. It has the XCL peripheral which is pretty much the only remarkable thing on it. I'm using one because I specifically wanted the XCL
[15:06:55] <LeoNerd> Well, a bare QFP chip is hardly much use on its own. So I'm making breakout boards for the
[15:06:55] <LeoNerd> m
[15:07:56] <_ami_> time to crash though. 1 am here
[15:07:59] <_ami_> nn
[15:33:46] <bss36504> Anybody remember N1njaneer? I haven't seen him around here in a looooong while
[15:35:23] <LeoNerd> Yah; not been in
[15:35:25] <LeoNerd> I'll poke him sometime