#avr | Logs for 2015-07-14

Back
[01:03:13] <postmodern> is there a ili9341 library for plain AVR? i tried using the one from avrfreaks but the LCD refuses to acknowledge it's commands
[01:07:42] <postmodern> http://www.avrfreaks.net/projects/ili9341-library-drive-22-tft-displayderived-adafruit-tft-library-ili9340-type-controller
[07:51:55] <MasterChief8964> Hello, ATMEGA64A ADC prints always 0xFF even if I connect input pin to GND. what I wrote wrong in code? http://www.pasteall.org/59569/c
[08:14:56] <Haohmaru> "ATXMEGA32A4U-AU" - does it _really_ have 5 USARTS? like.. you can have 5 USARTS simultaneously..?
[08:15:31] <Haohmaru> and same question goes for the SPI.. does it really have 7..?
[08:15:50] <Haohmaru> cuz in the datasheet i only see SPIC and SPID .. that's two..
[08:16:00] <LeoNerd> The XMEGAs are built in a more modular blockwise fashion than the tiny/mega chips
[08:16:10] <LeoNerd> They typically have multiple repeated identical units
[08:16:31] <LeoNerd> E.g. the standard 8bit port comes with it a USART/SPI/I2C controller set
[08:16:57] <Haohmaru> hmmm
[08:17:11] <Haohmaru> i read that the USART can function as an SPI
[08:17:24] <LeoNerd> That's also true, yup
[08:17:38] <LeoNerd> Though *generally* a bit of a waste of the hardware
[08:17:45] <LeoNerd> I've never quite worked out why you'd want to do that
[08:17:53] <Haohmaru> could it be that there are just 2 SPIs and then 5 USARTs which can function also as another 5 SPIs (2+5=7) ?
[08:18:28] <LeoNerd> Again, plausible
[08:18:40] <LeoNerd> You never reall yneed more than one or *maybe* two SPI controllers even on a busy board, though
[08:18:46] <LeoNerd> SPI is a bus-based system
[08:32:16] <Haohmaru> been looking around at the different documents related to XMEGAs and i'm still quite confused
[09:54:12] <Hexum064> good moring all
[09:54:20] <Hexum064> morning
[09:55:06] <Strangework> Good morning! :)
[09:57:55] <Hexum064> I was just doing a search over on avrfreaks about a chat room. Stackexchange implemented a great one but avrfreaks never implemented one, even though people have been asking since 2002. Did this become the unofficial (or official) chat room for avrfreaks?
[09:58:18] <LeoNerd> *shrug* ?
[09:58:32] <LeoNerd> Also, "chatroom" sounds very 90s...
[09:59:07] <Tom_itx> we chat here, and that is official
[09:59:22] <LeoNerd> Ohyeah, one '#'
[09:59:33] <Hexum064> lol
[09:59:48] <Tom_itx> i've received crap for that too
[09:59:58] <Hexum064> great line to start off the morning. We chat here, and that is official
[10:00:28] <Tom_itx> wtf do you want before the first cup of coffee?
[10:01:17] <Strangework> I certainly don't know of any other chat
[10:01:26] <Hexum064> as far as "chatroom" goes, as long as it functions very similar to this, we could call it a live discussion space
[10:01:29] <Tom_itx> there's #avr32
[10:01:31] <Strangework> This one's got good activity though, so it's a good place to stay.
[10:01:34] <Tom_itx> or maybe ##
[10:02:11] <Hexum064> I wonder though if any of the atmel folks pop in to help
[10:02:43] <Tom_itx> there are (were) employees in #avr32
[10:02:46] <Tom_itx> not sure about here
[10:03:20] <Tom_itx> i'm sure they're aware of it
[10:03:32] <Hexum064> I'd imagine they'd have to be
[10:04:04] <Strangework> Shit, that place is deserted
[10:04:15] <Tom_itx> always was
[10:04:18] <Hexum064> #avr32?
[10:05:01] <Strangework> Yah ^ 32-bit ghost town
[10:05:17] <Hexum064> I'm guessing the 8 bit avr community is a lot bigger than the 32 bit
[10:05:42] <Tom_itx> makes more sense to use arm
[10:05:45] <LeoNerd> Probably just because it takes four times more of us to get the same amount of work done
[10:05:46] <LeoNerd> ;)
[10:06:05] <Hexum064> *rimshot*
[10:06:18] <Hexum064> lol
[10:06:25] <LeoNerd> But also, yeah... AVR32 is a bit of a dead-end. The ARM Cortex did tht
[10:07:37] <Strangework> Where's the hip spot for ARM chat? Would it be on Freenode as well?
[10:07:53] <LeoNerd> #arm at a random guess
[10:08:18] <Tom_itx> #stm32 is one
[10:08:31] <Hexum064> Ya. I was always curious about that. Did atmel kill it's own 32 bit line with the introduction of ARMs?
[10:08:42] <Tom_itx> #edev is another
[10:08:50] <LeoNerd> Partly, I'd imagine
[10:09:04] <LeoNerd> The moment ARM Cortex became a thing, it was fairly clear AVR32 wasn't going anywhere
[10:09:07] <Hexum064> why is @stm32 invite only...
[10:09:14] <LeoNerd> If anyone's going to kill your product, it might as well be yourself, right? :)
[10:09:26] <Hexum064> That's one way to look at it.
[10:09:37] <Tom_itx> sty, ## stm32
[10:09:42] <Tom_itx> sry*
[10:09:45] <Strangework> No one makes me bleed my own blood
[10:11:20] <Hexum064> heh
[10:29:27] <bss36504> I have always had the opinion, or maybe the impression, that the AVR32 line still fills a niche role that is less complex than an ARM but more powerful than an AVR8. Though I suppose with chips like the D20 series, they may well be truly dead soon.
[10:30:35] <LeoNerd> I honestly don't see a gap. ATtiny -(some overlap)- ATmega -- XMEGA -- ARM Cortex
[10:31:00] <Strangework> Never used an Xmega before - what's the deal with them over ATmegas?
[10:31:14] <Hexum064> faster
[10:31:17] <Hexum064> has DMA
[10:31:26] <LeoNerd> DMA, events,... many more IOs
[10:31:35] <Hexum064> more prog/sram
[10:31:41] <LeoNerd> They also tend to have multiple copies of peripherals, ATmegas are usually individuals
[10:31:57] <LeoNerd> E.g. the good ol' mega328 has one UART, one SPI, one I2C, one ADC, one AC,...
[10:32:23] <LeoNerd> xmegaA4 has one UART/SPI/I2C combo *per* 8bit port, two ADCs, two anacomps attached to the ADCs,...
[10:32:31] <Hexum064> I was always confused why the 328 had less sram than the 128
[10:32:36] <LeoNerd> Mmm
[10:32:37] <Strangework> Oo. :o sexy little thing.
[10:32:47] <LeoNerd> The xmegas also have fancier PORT modules.
[10:33:03] <Strangework> What do you mean by 'fancier', LeoNerd?
[10:33:06] <LeoNerd> On an xmega you can set/clear/toggle any arbitrary combination of bits on a single port with a single write
[10:33:20] <LeoNerd> Whereas on regular attiny/atmega, that's a read/modify/write operatoin
[10:33:57] <Hexum064> I think there may also be some other port options as well, in the realm of driving a pin, either as an input or output.
[10:34:23] <LeoNerd> Ohyeah.. the output is a lot more flexible. You can configure the hardware in many more modes
[10:35:42] <LeoNerd> attiny/atmega have a controllable pullup, and can be active push/pull or tristate. xmega has controllable pullup or pulldown, can do pushpull, opencollector, openemittor, buskeeper. Also has a read-time invert configuration
[10:36:12] <LeoNerd> So if you have pushbuttons to ground with weak pullups, you can set the invert bits so that a read on the port input register reads as zeros when the buttons aren't pressed
[10:37:30] <Strangework> Gosh, that's pretty darn fancy. :o
[10:37:42] <LeoNerd> Mmmhm :)
[10:37:51] <Hexum064> Also, the xmega can support USB full speed mode
[10:38:02] <LeoNerd> I thought the 32U4 can too?
[10:38:04] <Hexum064> not sure if the handful of atmegas can do that.
[10:38:21] <LeoNerd> The {16,32}U* can; they have a fullspeed USB controller on
[10:38:48] <Hexum064> yep. just read that
[10:39:23] <Hexum064> It's kinda funny, both the mega and xmega require you to basically overclock one of the peripheral clocks to support USB full speed.
[10:39:47] <LeoNerd> Oh the PLL?
[10:39:56] <Hexum064> ya
[10:40:03] <LeoNerd> That's fairly standard in modern CPU hardware
[10:40:47] <Hexum064> Wouldn't it have been great, though, if the xmega could have just been stabilized at 48mhz instead of still capping it at 32?
[10:41:10] <LeoNerd> Perhaps? But then maybe it would have been more expensive? and/or impossible?
[10:41:27] <Strangework> To have a straight USB controller means you don't need to hook up an FTDI breakout, yeah?
[10:41:31] <Hexum064> For the fun of it, I actually set the CPU clock to 64mhz and it ran for a full night without any issues.
[10:41:42] <LeoNerd> Strangework: among the benefits, yes. You can also talk any arbitrary USB protocol, not just CDC
[10:41:43] <Hexum064> Strangework:Correct
[10:41:50] <LeoNerd> E.g. I've used a 32U4 to pretend to be a USB-HID keyboard
[10:41:52] <Strangework> Funkyy
[10:42:11] <Hexum064> I did a HID for a mouse, but I only had one button hooked up
[10:42:11] <LeoNerd> We did a quiz show on stage, with some contestant buttons with big LEDs in them
[10:42:28] <LeoNerd> The 32U4 acted as a keyboard to drive the flash-based software runing the video screens
[10:43:36] <Hexum064> that sounds fun
[10:44:45] <Hexum064> Though I never did it, a while back I was going to convert an "Easy" button from staples into a one-button keyboard for the shipping dep of the company I was working for
[10:45:03] <Strangework> That's damn cool
[10:45:04] <Hexum064> They had a situation where they had to hit some F key for every shipment
[10:45:13] <Hexum064> I'm bummed I never did that.
[10:45:32] <LeoNerd> Strangework: butyeah; so much more than just a USB serial port :)
[10:46:51] <Hexum064> Strangework: I'm currently building an art project for burning man where I'm using a bunch of xmegas to control video screens, and that's all being fed via USB using a bulk mode endpoint. No CDC.
[10:48:25] <Hexum064> That reminds me, that's kinda why I popped on here in the first place.
[10:49:01] <Strangework> I've been wanting to make a single-button keyboard to use while i play games. Add some drama to particular actions :)
[10:49:23] <Strangework> Hexum064 - that's dope, do you have a blog where you document your progress or I can read an abstract?
[10:50:13] <Hexum064> It probably won't be done before BM, but a friend of mine said he'd help me do some videos. It'll probably be a few months, but it will happen.
[10:50:31] <Hexum064> Anyway, I do plan to start one.
[10:50:51] <Strangework> Excellent! Please keep me updated. I hardly know a thing about your work, but I wanna change that. ;)
[10:52:29] <Hexum064> Strangework: to be honest, the quick start code for Atmel's ASF and one of these cheep xmega128a4u dev boards allowed me to make a one button mouse in like 10 minutes.
[10:52:57] <Hexum064> I'd say check those out too. ASF is a bit bloated but it makes things super easy for the normal stuff.
[10:53:19] <Hexum064> BTW, ASF = Atmel Software Framework
[10:54:25] <Hexum064> But I will def keep you updated :)
[10:54:39] <Strangework> Hexum064 - Killer. I'll certainly stick it on my next shopping list. :)
[10:55:09] <Hexum064> I feel like I've learned a ton over the last few weeks.
[10:56:28] <Hexum064> The xmegas that support USB have a DFU bootloader built in. So if you do a reset on one with the appropriate pin tied high (maybe low), your computer will see it.
[10:56:39] <Hexum064> Then you can use FLIP to push a HEX file to it.
[10:56:45] <Hexum064> No external programmer needed!
[10:57:06] <LeoNerd> But you need the button ;)
[10:57:17] <LeoNerd> The Arduino bootloader + CDC driver for those has the autoreset trick
[10:57:21] <LeoNerd> So you don't :)
[10:57:59] <Hexum064> eeh, a quick tap of the reset button before programming isn't a big enough deal to replace the bootloader
[10:58:07] <Hexum064> IMHO
[10:58:44] <Hexum064> Now what's great is those $2.50 Arduino Nano clones you can find on EBay
[10:59:06] <LeoNerd> The reset button might not be accessible, though
[10:59:13] <LeoNerd> In the unit I built, it wasn't. Whereas USB is
[11:00:28] <Hexum064> Using avrdude (and then an external tool set up in AS6) I can program straight gcc or asm and push it to the Nano as if it were a generic mega328p with an FTDI chip.
[11:01:22] <LeoNerd> Yes.. that's the nano
[11:01:31] <LeoNerd> The nano is a mega328p with an FTDI chip :)
[11:02:09] <Hexum064> LeoNerd:I just grabbed a cheap dev board with the xmega128a4u on it, and it has the button and a jumper for the pin. Then FLIP automatically resets it in user mode instead of DFU mode.
[11:02:26] <Hexum064> Right. About the Nano
[11:03:00] <Hexum064> It was just cool to be able to program it without needing to use the Arduino IDE and their bloated framework.
[11:03:39] <LeoNerd> Sure
[11:03:43] <LeoNerd> I do that all the time :)
[11:04:19] <LeoNerd> straight avrdude on an ISP-attached mega328p, or my avrdude-micro wrapper for the Micro board or clones, with autoreset
[11:04:43] <LeoNerd> The genuine Arduino Micro bootloader supports it, the one that Adafruit ship on their 32U4 breakout board does not. :/
[11:04:59] <LeoNerd> Which is a shame as that breakout board is otherwise very nice, having an ISP port and *all* the IO pins
[11:05:40] <Hexum064> bummer
[11:06:00] <LeoNerd> Hence needing to reburn the bootloader
[11:06:16] <Strangework> I'm actually trying to work without dev boards, it's messier but it's somehow quite rewarding
[11:06:21] <Hexum064> Have you had a lot of cases where you needed most or all of the IOs?
[11:06:51] <Strangework> I've got an attiny24a hooked up to my Beaglebone. Use the linuxgpio programmer in avrdude - bitbangs the lines so I don't need to get an external ISP
[11:06:52] <Hexum064> Strangework: I kinda know what you mean. I was doing that with the tinys for a while
[11:07:09] <Strangework> Then one day you decided you needed more power? ;)
[11:07:20] <Strangework> Do they have Xmegas in DIP?
[11:07:27] <bss36504> nope
[11:08:31] <Hexum064> Strangework:Well kinda. And I wanted to learn about the xmegas
[11:09:11] <Hexum064> Strangework: for a DIP version of the xmegas, you could just use a breakout board. It's not really "cheating" as with a full dev board.
[11:09:28] <LeoNerd> Just get a real devboard
[11:09:37] <LeoNerd> Then you get ISP and XTAL and PSU and so on for free
[11:09:54] <Hexum064> But the dev board I'm using is pretty bare bones. Just the usb connector, power, xtal, reset button, and jumper for programming mode.
[11:10:12] * LeoNerd nod
[11:10:13] <LeoNerd> Sounds fine
[11:10:15] <Hexum064> I agree with LeoNerd
[11:11:46] <Hexum064> There's no electrical engineering tallent needed to connect those parts, so nothing is really learned by doing it yourself and, therefore, not lost by getting it for free, except less components to fall off your breadboard.
[11:12:05] <Hexum064> or accidentally connect incorrectly.
[11:12:22] <bss36504> Could also just skip the breadboard entirely, and make a PCB. PCBs are cheap these days.
[11:12:42] <LeoNerd> I usually breadboard a prototype at .1" pitch still, and then PCB out when I have the hardware mostly working
[11:12:55] <Hexum064> yep
[11:14:27] <Hexum064> Here's a question for you all. In my current situation, I want to push data from a 32mhz xmega to a 16 (or maybe 20) mhz mega via SPI
[11:14:47] <Hexum064> The xmega being the host means that the mega's SPI port is clocked by the xmega right?
[11:18:36] <Hexum064> damn... killed the room again with a serious question
[11:18:41] <LeoNerd> HEhe
[11:18:53] <LeoNerd> But yes, your statement is correct
[11:20:24] <Hexum064> That I killed the room or about the clock?
[11:20:32] <Strangework> LOL
[11:20:50] <Hexum064> :)
[11:22:01] <Strangework> I was just heating up some lunch is all. Though I can go with that line of thought. I would like to begin getting into PCB design, though I really want to get the most bang for my buck. I've been looking into a variety of methods. I think I might want to check out using presensitized copper boards.
[11:23:03] <Hexum064> Just so there's some better understanding of what I'm doing (in case anyone is interested). I am connecting an xmega, via usb, to my computer. The computer is pushing out video data in the form of 225x45 pixel images as fast as possible (~30fps).
[11:23:54] <Hexum064> The xmega in turn pushes the data out among 15 megas via spi, one at a time. Each mega drives (draws) a section of the screen.
[11:24:45] <Hexum064> At the end of each frame, the computer sends a sync command to the xmega and the xmega sends a sync pulse to all the megas. The megas then all draw their portion of the screen.
[11:25:29] <LeoNerd> Sounds like a fun orchestration exercise
[11:26:03] <Hexum064> The reason for the elaborate setup is, I am using ws2812b LEDs in strips as the display and you can only write to about 1024 of them in one shot before the latency screws them up. (They act as a long shift register).
[11:26:11] <Strangework> A tastefully heavyweight project. Would you mind telling me what it is you are drawing?
[11:27:13] <Hexum064> I'm a section of the computer screen with a program I wrote in C#. That capture (which can be any size, anywhere on the screen) is scaled (if necessary) and sent to the xmega.
[11:27:24] <Hexum064> So I can "draw" whatever is on the screen.
[11:27:45] <tpw_rules> that sounds like a scary size project
[11:28:12] <Hexum064> Where's a good place to post a vid. I did a small 16x16 PoC if anyone want's to see it.
[11:28:32] <Strangework> Would definitely watch. Why not YouTube?
[11:28:39] <Hexum064> OK
[11:28:41] <tpw_rules> http://www.adafruit.com/products/420 these are neat
[11:28:45] <tpw_rules> they're complex to drive though
[11:29:09] <LeoNerd> Mmmmm them
[11:29:20] <tpw_rules> i got a neato plasma running with a propeller
[11:29:51] <Strangework> I got a shitload of RGB LEDs cheap off Alibaba. Gonna drop them in mason jars and make lamps
[11:30:16] <tpw_rules> https://pbs.twimg.com/media/BmMgjgSCcAArSX2.jpg:large
[11:30:57] <tpw_rules> https://www.youtube.com/watch?v=Da-vBaGrNZ8 this is it calculating in real-time. i significantly speeded it up
[11:31:10] <martinus> Not microcontroller related but I finished my headphone amp. Needs some tweaks but it's working well.
[11:31:53] <Strangework> Heh, that refresh rate is lovably quaint, tpw_rules. :)
[11:31:55] <martinus> Was an excuse to play around with valves (tubes)
[11:32:06] <tpw_rules> Strangework: it was doing ieee754 floating point math ;P
[11:32:12] <tpw_rules> full 32 bits
[11:32:27] <Hexum064> rrrg. phone issues
[11:32:48] <tpw_rules> i parallelized it across four processors, sped up the math engine, and chopped it to like 14 bits for things like multiply and divide and it runs at like 15fps
[11:32:56] <Strangework> Sounds like a true gut punch. That's some good eye candy :)
[11:32:59] <tpw_rules> (propeller, it has 8 cores)
[11:33:13] <Strangework> Why is the propeller board so intense?
[11:33:21] <tpw_rules> because propeller is amazing
[11:33:22] <Strangework> Clearly, you've made good use of it, it seems
[11:33:23] <Strangework> LOL
[11:33:33] <Hexum064> glad someone has
[11:33:40] <tpw_rules> the problem is that since it's based on a time variable, once it gets too big the calculation precision goes to shit and the display gets all wrong
[11:33:49] <tpw_rules> so you have to reset it every few minutes :P
[11:34:08] <Strangework> What do you mean by the time variable?
[11:34:27] <tpw_rules> a plasma effect is generated by layering multiple equations with time as a parameter
[11:35:00] <Hexum064> I like that Adafruit kit but it really is way to expensive an overly complex
[11:35:15] <tpw_rules> it requires a good processor to drive it
[11:35:57] <Hexum064> and it really shouldn't
[11:36:21] <tpw_rules> they're from those big jumbotrons and they're designed to be driven by a large asic
[11:36:32] <Hexum064> AAAAH!
[11:36:37] <Hexum064> now that makes sence
[11:36:39] <Hexum064> sense
[11:36:42] <Hexum064> whatever
[11:36:55] <LeoNerd> The propeller is about 15 levels of crazy though ;)
[11:37:11] <tpw_rules> it's not
[11:37:11] <Hexum064> lol
[11:37:16] <tpw_rules> until you do shit like i did
[11:37:35] <LeoNerd> Oh I mean crazy in a good way
[11:37:50] <LeoNerd> It's very powerful, but good *god* is it totally unlike anything else you've ever even thought of
[11:37:53] <Hexum064> ya. right. like all my ex gfs
[11:38:02] <tpw_rules> hardware peripherals are for loser
[11:38:02] <tpw_rules> s
[11:38:18] <Hexum064> tpw_rules bit-bangs everything
[11:38:40] <tpw_rules> well i am using the propeller video shift registers
[11:39:03] <tpw_rules> but the propeller doesn't have anything like a hardware uart
[11:39:11] <Hexum064> so you ARE using hardware though
[11:39:13] <Strangework> hrm?
[11:39:40] <Strangework> I figured on anything greater than attiny, hardware UART was kind of a given?
[11:39:41] * tpw_rules is a propeller expert
[11:39:50] <tpw_rules> it also doesn't have
[11:39:52] <tpw_rules> INTERRUPTS
[11:39:59] <LeoNerd> I repeat my earlier claim ;)
[11:40:11] * Strangework furrows eyebrows
[11:40:19] <tpw_rules> the philosophy is you have 8 cores so dedicating one to a software uart is no big deal
[11:40:26] <LeoNerd> The propeller has 8 hardware CPUs in a sortof barrel-like configuration, with lots of concurrency control stuff
[11:40:28] <tpw_rules> but you can also have two uarts. or eight uarts
[11:40:49] <LeoNerd> All 32 GPIO lines are controlable by all 8 cores.. so in practice you can make a UART with whatever features you like, on it
[11:41:09] <Strangework> ah :P Muscle-man simulate everything
[11:41:35] <Strangework> Propeller board doing finger push ups
[11:41:36] <tpw_rules> each core gets 2 timer/counter sort of dealios and a shift register controllable by one of such
[11:41:37] <LeoNerd> The idea is that generally you'll take some software defitions of the perpipherals you want
[11:42:47] <Strangework> Pretty dope. Anyone here mess around with FPGAs?
[11:42:50] <tpw_rules> i want to
[11:42:59] <Hexum064> OK, got the vid up. PLEASE excuse the bad lighting. https://youtu.be/wrt-nmHtwvM
[11:43:09] <Strangework> Unforgivable, Hexum064
[11:43:28] <Hexum064> I know :<
[11:43:32] <LeoNerd> Yeah, at times it seems more like an FPGA than a CPU
[11:43:37] <LeoNerd> It's sortof.. somewhere between the two
[11:43:57] <Strangework> Ahhh Hexum064, this is damn cool!
[11:44:05] <Strangework> So pardon, how big is the final product gonna be?
[11:44:08] <LeoNerd> Other weird things about it: The native way to program it isn't via writing C or assembly, and uploading a compiled binary.
[11:44:13] <LeoNerd> It has a scriptign language
[11:44:49] <tpw_rules> sort of. it's like java; the high-level language compiles to bytecode
[11:44:53] <tpw_rules> https://www.youtube.com/watch?v=6gEMKYnUADE a demo by somebody who is crazy
[11:45:04] <tpw_rules> he has several on AVRs and stuff too
[11:45:06] <Strangework> I kinda figured actually. I've heard that it's used often-enough in educational context, and such explicit software control would want, at the very least, a higher-level library
[11:45:29] <Hexum064> So, the final will be two mirrored displays (right side and left side) of 3 panels of 75w by 45h pixels
[11:45:38] <Hexum064> so 225x45
[11:46:14] <Hexum064> I went with multiples of 15 instead of 16 because the strips of LEDs come in 60/meter
[11:47:27] <Strangework> Do you plan on having any audio component to go alongside your project?
[11:47:32] <Hexum064> Oh I've seen that. Pretty crazy
[11:47:35] <Strangework> tpw_rules, that guy is clinically disturbed
[11:48:21] <Hexum064> I need to look into that kinda stuff. I feel like I have some major inefficiencies in the way I am processing the video.
[11:50:57] <Hexum064> a few other vid that make me feel like a total noob: https://www.youtube.com/watch?v=CXFOTpM2Jn4
[11:51:16] <Hexum064> https://www.youtube.com/watch?v=_RBuwNPYEZM
[11:52:02] <tpw_rules> Hexum064: what sort of code do you have?
[11:52:24] <Hexum064> c for the MCU, c# for my computer
[11:52:37] <Hexum064> and asm to drive the leds (because of the timing)
[11:52:39] <tpw_rules> you might be able to drive multiple strings in parallel
[11:52:53] <Hexum064> very very bad asm at the moment
[11:52:58] <martinus> Hexum064: Awesome. :)
[11:53:07] <martinus> Refresh rate looks pretty good.
[11:53:34] <Hexum064> And you're right. I MIGHT be able to drive up to 4 strings at a time at 32mhz
[11:53:39] <Hexum064> problem is memory really
[11:54:17] <Hexum064> 75x9x3 (3 bytes per led) = 2025 bytes
[11:54:31] <tpw_rules> how much memory does the xmega have?
[11:54:38] <Hexum064> bbl, meeting
[11:57:07] <martinus> Does anyone have any strong feelings on c++ usage on UC's? All of the tutorials I've brosed through on AVRFreaks are labelled C, on the other hand quite a few of the arduino libraries seem to use C++. I guess I'm wondering if I should stick with pure C while I'm learning?
[11:57:19] <martinus> *browsed
[11:58:17] <LeoNerd> Personally I dislike it. you're never going to have a program large enough on an ATmega to take advantage of anything C++'ish, so you're *basically* using it as a C with slightly different syntax
[11:58:21] <LeoNerd> Might as well just write straight C
[11:58:43] <martinus> Is there additional overhead in using C++?
[11:59:15] <Strangework> I am actually looking to use C++ in my work on atmega2560s
[11:59:17] <LeoNerd> There's overhead in my having to *write* C++
[11:59:23] <martinus> Heh
[11:59:29] <antto> i would really like to have structures with constructor/destructor and methods.. that would be pretty much enough
[11:59:45] <Strangework> So I've been some research into it. The only real overhead comes from using templates - a construct I avoid anyway
[12:00:00] <LeoNerd> Huh?
[12:00:08] <LeoNerd> Templates are entirely compiletime. Runtime knows nothing about them
[12:00:22] <LeoNerd> (this is in fact half of the *problem* with them)
[12:00:33] <Strangework> Otherwise the object-oriented concepts compile with very little, if any, overhead
[12:00:55] <Strangework> I'm clearly misinformed, though there's a lot of discussion about this on avrfreaks
[12:01:25] <Strangework> The general consensus that I have gathered is that C++ has the possibility to produce lousier code if not used properly
[12:01:48] <Strangework> and since a lot of the community are comfortable with C, there is very little incentive to use C++
[12:02:10] <martinus> following Linus' opinion. :D
[12:02:29] <Strangework> And what's that?
[12:02:56] <LeoNerd> To be fair, Linux vs. AVR code are quite different targets
[12:03:38] <LeoNerd> A byte here or there, an extra memory fetch deref,... in Linux that doens't make a massive difference. On AVR that could be the distinction between working and not-working
[12:03:49] <martinus> I was being facetious, Linus went on a rant against C++ claiming it allows people to write terrible code.
[12:04:23] <LeoNerd> Also, IMHO C++ has had its day. It needs to realise there's other things now. Java, C#, Rust, ... Go even.. at a push.
[12:04:26] <LeoNerd> (Though seriously, don't Go)
[12:04:48] <martinus> "C++ is a horrible language. It's made more horrible by the fact that a lot "
[12:04:50] <martinus> of substandard programmers use it, to the point where it's much much
[12:04:52] <martinus> easier to generate total and utter crap with it. Quite frankly, even if
[12:04:54] <martinus> the choice of C were to do *nothing* but keep the C++ programmers out,
[12:04:56] <martinus> that in itself would be a huge reason to use C.
[12:04:59] <martinus> sorry, thought that would paste in one line!
[12:05:24] <martinus> (from http://article.gmane.org/gmane.comp.version-control.git/57918)
[12:17:55] <Hexum064> I have to agree. c++ is basically obsolete at this point (and it pains me to say that because, for a very long time, I believed that you were only a true programmer if you new c++)
[13:02:48] <moobase> Can I use DDR2 memory with my AVR? Trivial?
[13:04:32] <LeoNerd> I would imagine not trivially so, no. There's all the dynamic refresh to account for
[13:05:31] <moobase> screw that then :3. What if you're getting one of those "simpler" rams from an electronics store? Onse that you just need to read the datasheet and quickly know how to use.. are they just as simple as I/Oing with them?
[13:05:37] <moobase> no need to refresh them etc?
[13:06:00] <LeoNerd> Static RAM, yes
[13:06:44] <Hexum064> was old EDO memory dynamic?
[13:37:24] <Lambda_Aurigae> Hexum064, yes, EDO is dynamic. everything back to 30pin sipp and simm modules were dram...and even the dip package chips on the old 8086 and 80286 boards were dram. those systems had memory management chips to handle the refresh and all.
[13:38:00] <Lambda_Aurigae> I have use d 30pin simm and sipp modules with AVR and PIC in the past though.
[13:38:12] <Lambda_Aurigae> doing ddr with an avr would be,,,,horrid.
[13:38:40] <Lambda_Aurigae> moobase, what are you wanting/needing more memory for exactly?
[13:41:18] <Hexum064> Oh wow. I didn't realize those old chips for the 86 and 286 were dram!
[13:42:13] <Strangework> Hey, what did I miss?
[13:42:23] <Lambda_Aurigae> heck, the c64 used dram.
[13:42:39] <Lambda_Aurigae> Strangework, you missed Tom_itx doing a striptease for us.
[13:43:04] <Lambda_Aurigae> Hexum064, on the 386 and 486 boards, the cache chips were srams. I have stacks of those here.
[13:43:56] <tpw_rules> dram was popular on z80 because it could refresh it transparently
[13:44:11] <Hexum064> didn't know that
[13:44:24] <LeoNerd> DRAM has *always* been popular.
[13:44:28] <Lambda_Aurigae> yeah...z80 has the ability to handle dram nicely.
[13:44:37] <Lambda_Aurigae> dram is fast, cheap, and low power.
[13:44:38] <tpw_rules> well i mean a 6502 based system can't do it automatically
[13:44:42] <Lambda_Aurigae> sram sucks a lot more power.
[13:44:47] <LeoNerd> From the very first Williams tubes and mercury delay lines, computer memory has historically *always* needed dynamic refresh
[13:44:49] <tpw_rules> the z80 has such a slow bus time that throwing in a dram cycle was no probalo
[13:44:59] <Lambda_Aurigae> tpw_rules, yeah,,,the c64 used some magic to do the dram thing.
[13:45:14] <tpw_rules> does it halt the cpu?
[13:45:21] <tpw_rules> or is it somehow specially dual-ported
[13:46:23] <Lambda_Aurigae> the video chip did the refresh,,,the vic-II chip.
[13:46:37] <Hexum064> I think the xmegas have a dram interface
[13:46:54] <tpw_rules> does it just stop the cpu for x cycles?
[13:47:04] <Hexum064> I've never looked into it but that may mean they refresh the ram automatically
[13:47:33] <Lambda_Aurigae> not sure how it did it.
[13:47:48] <Lambda_Aurigae> I know the vic-II chip was part of a multi-bus master setup.
[13:48:19] <tpw_rules> ah ok, it looks like it just uses the vic spare cycles since they alternate bus cycles. but the vic will hold the cpu during some portions of the display if it needs more cycles
[13:48:40] <Lambda_Aurigae> it has full access to the address and data bus.
[13:49:06] <Lambda_Aurigae> that system was awesome...even the vic-20 was an awesome piece of work.
[13:49:19] <Lambda_Aurigae> multi-processors throughout even back in the 80s.
[13:49:32] <Lambda_Aurigae> video, sound, and cpu were all separate processors.
[13:49:52] <tpw_rules> i want to see one of those fabled unix systems before the 68k pushed a sensible amount of state on exception
[13:49:55] <Lambda_Aurigae> they carried it even farther with the copper and blitter units on the amigas.
[13:50:03] <LeoNerd> Mmmmm copper
[13:50:05] <tpw_rules> it would run one cpu slightly ahead of the main cpu and interrupt the main cpu if the sub cpu faulted
[13:50:07] <Hexum064> That's kinda the way it was for most video game consoles as well
[13:50:30] <tpw_rules> nah, most video game console things can't do anything for themselves. well sort of
[13:50:42] <Hexum064> The NES's proc had built-in sound (Actually replaced the fpu I believe) but the video was a separate proc
[13:50:46] <tpw_rules> the genesis vdp has dma and the sound cpu is a z80 (though you don't need to use it for sound)
[13:50:53] <tpw_rules> well the ppu doesn't proc ess anything
[13:50:54] <Lambda_Aurigae> tpw_rules, I've heard of those unix systems....system II or system III, not sure.
[13:50:56] <FL4SHK> the NES had an FPU?
[13:50:57] <FL4SHK> er
[13:50:59] <FL4SHK> the 6502
[13:51:12] <tpw_rules> FL4SHK: what
[13:51:18] <Hexum064> Well, it's been a very long time but
[13:51:24] <FL4SHK> 13:25 <Hexum064> The NES's proc had built-in sound (Actually replaced the fpu I believe) but the video was a separate proc
[13:51:27] <Lambda_Aurigae> 6502 was not a n FPU.
[13:51:38] <tpw_rules> oh no. Hexum064. mostek or whoever had a patent on a mode to calculate BCD numbers
[13:51:40] <Hexum064> What I read is that proc was modified specifically for the NES
[13:51:54] <FL4SHK> Yeah but the original thing definitely didn't have an FPU
[13:51:56] <Hexum064> Ooooh. it was for BCD
[13:51:57] <Lambda_Aurigae> Hexum064, that happened a lot back then.
[13:52:15] <tpw_rules> nintendo never got the licnese, so the gate that enables the mode is hardwired to off in silicon. but the sound engine and a couple other bits are also on the die
[13:52:20] <Lambda_Aurigae> like the 6510 in the c-64.
[13:52:23] <Hexum064> sry. BCD then. But the point was that NES had a separate vid proc
[13:52:43] <tpw_rules> but it doesn't process anything
[13:52:53] <tpw_rules> the copper and blitter could handle instructions and operate independently
[13:53:09] <tpw_rules> http://www.visual6502.org/images/RP2A/Nintendo_RP2A03G_die_shot_1a_6500w.jpg the 6502 is the bottom right area from the rectangle with 8 sub-rectangles down
[13:53:26] <Lambda_Aurigae> tpw_rules, yeah...you could literally pull the 68000 cpu out of an amiga and have it still displaying moving 3D graphics and playing music at the same time.
[13:53:31] <Hexum064> coool
[13:53:34] <tpw_rules> Lambda_Aurigae: really? that's cool
[13:53:44] <tpw_rules> well can't you cheat with bitplanes
[13:53:45] <Lambda_Aurigae> yeah...there was a demo program that did that.
[13:53:52] <tpw_rules> the copper just switches between like 4 frames
[13:54:14] <tpw_rules> snes can do that
[13:54:16] <tpw_rules> though only sound
[13:54:29] <Hexum064> those resistors on almost all of the pads?
[13:54:31] <Lambda_Aurigae> problem was the copper and blitter were limited to amount of memory they can use. massively expanding the ram was useless for a lot of things.
[13:55:02] <tpw_rules> i'm not a silicon expert, but it's probably a part of the input buffers
[13:55:24] <tpw_rules> Lambda_Aurigae: but not for spreadsheets!!!!!
[13:55:41] <LeoNerd> tpw_rules: There's a most interesting substructure in the top right corner in there - it looks like another die that's been embedded wholesale into this one. It still has the bonding pads on it, labeled and everything
[13:55:57] <Lambda_Aurigae> tpw_rules, yeah...office apps used lots of ram...games, not so much.
[13:56:18] <Lambda_Aurigae> running compiler on the amiga could use lots of ram too.
[13:56:24] <tpw_rules> that's a verbatim 6502 die in the bottom except for the transistor for bcd mode.
[13:57:19] <tpw_rules> i think the things on the top are just big transistors for the audio amp
[14:04:18] <Jartza> greetings from Riga, Latvia
[14:06:03] <Lambda_Aurigae> Latvia is a real place?
[14:06:11] <Lambda_Aurigae> :}
[14:08:49] <Hexum064> lol
[14:43:41] <Emil_> Hi!
[14:43:49] <Emil_> Is there something like interrupt stack?
[14:43:56] <Emil_> Or do I need to emulate it myself
[14:44:06] <Emil_> talking about attinys and atmegas
[14:48:54] <Strangework> Disclaimer: Relative newbie speaking. I am reading my atmega2560 datasheet. When an interrupt occurs, the global interrupt enable bit is cleared and all interrupts are disabled. This can be changed in the routine to enable the nesting of interrupts.
[14:49:54] <Strangework> I assume you can have each interrupt routine re-enable global interrupts and thus form a stack.
[14:50:34] <Strangework> I am checking out the datasheet for my attiny24a - it seems to be the same situation there.
[15:03:52] <Hexum064> I'm looking at the xmega datasheet
[15:16:56] <LeoNerd> Emil_: Explain what you mean by "interrupt stack" and we'll tell you if such an entity exists
[15:35:20] <Hexum064> Emil_: You still here?
[15:35:31] <Strangework> RIP :(
[15:35:36] <Hexum064> He died?
[15:36:02] <Strangework> He must've drowned himself in nested interrupts
[15:36:07] <Strangework> That's not a nice way to go
[15:36:48] <Hexum064> Especially if Round-Robbin is not enabled...
[15:37:10] <Hexum064> it's like interrupt inception
[15:37:19] <Hexum064> ... intception
[15:37:30] <bss36504> Interception? wait, thats not right...
[15:37:39] <Hexum064> lol
[16:45:47] <Jordan_U> I want to have a structure containing a pointer to an area of eeprom which will contain a uint32_t value. I have multiple declarations like "uint32_t EEMEM foo;" and "uint32_t EEMEM bar" and I will be setting this eeprom pointer eventually like so: my_struct.eeprom_pointer = &foo
[16:47:57] <Jordan_U> What type should I declare eeprom_pointer to be? Based on the function prototypes in avr/eeprom.h I'm guessing that it should be "const uint32_t *eeprom_pointer;". Is that correct? Is there any way to have the compiler enforce that code never tries to dereference this pointer as if it were an area in SRAM?
[16:52:31] <Emil_> LeoNerd Hexum064 Sorry I was out, there was a fireworks show. Nice is kind of nice ;)
[16:52:36] <Emil_> In any case
[16:53:35] <Emil_> Okay so I might be a bit affected by the nonsese that is node.js but anyways
[16:56:32] <Emil_> And spesifically from it the async non blocking part
[16:56:42] <Emil_> And the event loop
[16:57:22] <Emil_> so let's say I need to use as little power as possible
[16:58:13] <Emil_> but I also need my code to be responsive
[16:58:22] <LeoNerd> Async nonblock is a useful and easy thing to do on AVR
[16:58:24] <Emil_> >Do you even interrupt, mate
[16:58:36] <Emil_> Of course, interrupts are the way to go
[16:58:41] <LeoNerd> All of my programs run on a little micro scheduler/OS/thing I have
[16:58:54] <Emil_> But let's say I happen to receive a lot of interrupts
[16:58:58] <Emil_> but I want to capture them all
[16:59:10] <Emil_> Or at least acknowledge them
[16:59:22] <Emil_> so I can do something with them as time goes on
[16:59:43] <Jordan_U> Looking again I guess it should be just "uint32_t *eeprom_pointer" rather than "const uint32_t *eeprom_pointer". Still it seems a little odd that there isn't a type specifically for pointers to SRAM, and having someone confirm that this is correct would give me some peace of mind.
[17:00:05] <Emil_> So I need to register all my interupts into a queue and then process them as they have arrive
[17:00:06] <Jordan_U> s/pointers to SRAM/pointers to EEPROM/
[17:00:08] <Emil_> d
[17:00:16] <Emil_> of course we can have a maximum queue size
[17:00:16] <Hexum064> Jordan_U:Or maybe uint32_t const * eeprom_pointer
[17:00:22] <bss36504> Jordan_U: As far as I know, there isnt a type or compiler extension method to enforce that you only pass valid EEPROM pointers. The whole point of those utility functions is to calculate the correct memory offsets before actually dereferencing.
[17:00:23] <LeoNerd> So... it depends on what the interrupt is, but very rarely does the *count* of interrupts matter
[17:00:40] <LeoNerd> How I write all my things is that any interrupt handler simply marks a task for being scheduled. It sets a flag and returns. Very lightweight
[17:01:01] <Emil_> In which case we do what we want, mostly drop the latest interrupts and process what we have on the queue
[17:01:02] <LeoNerd> The main OS simply does while(1) { wait_for_an_interrupt(); run all the tasks that are runnable; }
[17:01:08] <Hexum064> I was just reading up on the interrupts on the atmegas
[17:01:22] <Hexum064> They differ from the xmega. There is no MIC
[17:01:22] <LeoNerd> I don't need to queue up the interrupts *themselves* - each of the tasks is represented by a data structure, and that structure has a flag
[17:01:34] <LeoNerd> Try to remain constant-size in memory
[17:01:36] <Emil_> LeoNerd: okay sounds nice! Can you share code?
[17:01:40] <LeoNerd> queues suggest something wrong
[17:01:43] <Jordan_U> bss36504: Thanks.
[17:01:45] <bss36504> Jordan_U: Further, I would say that if the eeprom access functions dont take a special type, then no such type exists.
[17:01:46] <Emil_> LeoNerd: yeah flags are enough
[17:02:07] <Emil_> but I'd like to use as little power as possible
[17:02:22] <LeoNerd> I've run this thing for over a week on a single Li-ion cell
[17:02:28] <LeoNerd> talking bidirectional radio :)
[17:02:43] <bss36504> Emil_: Conisder sleeping and waking only on interrupts. Do the task, go back to sleep
[17:02:44] <Emil_> LeoNerd: Sounds exactly what I'm looking for
[17:02:47] <Jordan_U> bss36504: Indeed, that was my thought as well. Thanks for the sanity check :)
[17:02:57] <Emil_> bss36504: that's what I'm thinbking
[17:02:58] <bss36504> Jordan_U: My pleasure
[17:03:14] <bss36504> Emil_: How many interrupt sources are we talking here? How long does each task take?
[17:03:14] <Emil_> Why I'm here is for validation and examples of how to do it best
[17:03:29] <Emil_> only 3 interrupt sources, really
[17:03:50] <Emil_> but one of them is more urgent than the other two
[17:04:01] <LeoNerd> Yup., this code structure makes that ideal :)
[17:04:12] <LeoNerd> See, all the tasks sit in an array. That gives them inherent ordering and priority
[17:05:04] <Emil_> Can you share an example or point to an existing implementation?
[17:05:06] <bss36504> Emil_: I would say, set up a timer to wake from sleep, use LeoNerd's idea of setting a flag in the interrupt routines. The external sources will asynchronously set the flags, the timer starts the arbiter function that decides which task needs servicing first.
[17:05:20] <Emil_> bss36504: I can't sleep for a fixed amount of time
[17:05:35] <bss36504> if you need a way to actually preempt one task with another, then you basically want an RTOS. Why cant you sleep for a fixed time?
[17:06:04] <Emil_> bss36504: because it's radio communications
[17:06:07] <LeoNerd> Emil_: I could indeed... there's no docs though... just C code
[17:06:15] <Emil_> LeoNerd: C code is enough
[17:06:34] <Emil_> Just don't give me anything arduino, please
[17:07:05] <LeoNerd> Hah.. hellno
[17:07:06] <bss36504> Jordan_U: You know, you could make an enum with all valid eeprom addresses in it....
[17:07:08] <LeoNerd> This is nice small C :)
[17:08:26] <Emil_> LeoNerd: Alright! Shoot me a link/query :)
[17:09:54] <bss36504> Jordan_U: Actually I take it back. What youre looking for is basically a "ranged integer" which has no such meaning in C. Your best bet, if you want automatic bounds checking, is to make an actual object (ala C++) and implement the behavior there. Also, you'd never be able to enforce the range at compile time, so you would still have the problem of calculated addresses potentially being out of
[17:09:56] <bss36504> range.
[17:10:43] <LeoNerd> Emil_: http://pastie.org/10292842 <== this is the core of the OS itself. You then make the actual 'tasks' array somewhere and populate it with function pointers to your routines. interrupt handlers then make simple calls to task_schedule(). I usually keep a toplevel .h file containing an enum {} of task IDs
[17:11:26] <LeoNerd> Emil_: At some point I keep meaning to copy out the regular ticker timer code out of a project of mine into the OS as well, so it has ticking timers
[17:11:32] <LeoNerd> and maybe also countdown style ones.. delays
[17:13:29] <LeoNerd> Actually *one* project of mine went as far as almost having sysvinit-style startup/shutdown/runlevel controls...
[17:13:35] <DKordic> Jordan_U: How about ``struct EEPROM {byte _ptr;}''? Now it will have different type but ``sizeof(struct EEPROM)'' should be just 1 byte. Enough to address 4 byte data for up to 4 KiB EEPROMs.
[17:13:40] <LeoNerd> It has a special low-power mode that it can switch into, where some of the tasks get shut down
[17:13:57] <LeoNerd> I'm also considering adding a messagepassing semantic to it - so each task would take a uint16_t data instead of void
[17:14:03] <LeoNerd> But that's getting fancy now :)
[17:16:30] <Jordan_U> bss36504: I'm trying to avoid future developers working on this code making the mistake of treating the variable as an SRAM pointer. I feel like that solution makes things more complicated to the point of increasing the likelyhood of misuse and misunderstanding rather than decreasing it. I think consistent naming (all eeprom and pointer to eeprom variable names end in "eeprom") and warnings in comments is the best I'm going ...
[17:16:36] <Jordan_U> ... to get (and is sufficient).
[17:18:26] <bss36504> Jordan_U: Well sure, but youre asking for something that wont exist in the language, unless you make it, which is the whole point of a class. Just my two cents though. You could always make a typedef to alias the uint32_t to something like eeprom_addr_t. Then at least it would be somewhat clear in the function protorypes what you meant.
[17:19:07] <DKordic> Jordan_U: So You structure will be ``struct example {EEPROM addr1; EEPROOM addr2; /* etc. */}''.
[17:20:01] <DKordic> bss36504: Exactly.
[17:22:01] <Jordan_U> bss36504: I'm sticking to pure C (no C++) in this project. I may go the typedef route, but then it would look a little odd to someone looking at the declarations in my code and the function prototypes in avr/eeprom.h. I was mostly hoping that there was a canonical solution to this problem, and it appears there isn't.
[17:22:31] <Emil_> Nothing wrong with typedefs :)
[17:25:28] <FL4SHK> ^
[17:26:33] <FL4SHK> Jordan_U: C++ works fine on AVR if you're worried about speed and/or program size issues
[17:26:39] <FL4SHK> At least if using avr-gcc
[17:27:04] <FL4SHK> Oh but there are caveats... since some parts of C++ are best NOT used on an AVR
[17:27:49] <FL4SHK> If you were to just use C++ as a C with classes (but no inheritance or virtual functions) it's fine
[17:28:15] <FL4SHK> I understand that some people have philosophical reasons for not using C++, which is fine too :P
[17:28:19] <Emil_> Why'd you then use C++?
[17:28:49] <FL4SHK> I mostly know what parts to avoid... and I like classes
[17:29:03] <Strangework> FL4SHK, what is the exact reason against inheritance and virtual functions?
[17:29:20] <FL4SHK> I don't really have anything against them in general
[17:29:43] <FL4SHK> Uh
[17:29:55] <FL4SHK> Truth be told, I was repeating what I"ve been told about C++ on embedded platforms :V
[17:30:15] <Emil_> Don't they create memory/cpu overhead?
[17:30:24] <Strangework> That's fair - I've been trying to look into it for a while now and haven't found a single resource that's completely conclusive
[17:30:34] <FL4SHK> Yeah
[17:30:39] <Strangework> I think virtual functions are sorted out at compile time, which should make them OK
[17:30:42] <FL4SHK> Oh really
[17:30:46] <FL4SHK> They're implemented like function pointers
[17:30:50] <bss36504> Jordan_U: You could make your own lib that just aliases the avr eeprom functions. The optimizations from the compiler would make it totally transparent from a speed perspective. Obviously the signature would use your typedef insted. If you wanted to get real wild, you could even tag it with the "always inline" attribute.
[17:31:00] <FL4SHK> At least as far as I know
[17:31:39] <FL4SHK> I use C++ on the GBA actually
[17:31:53] <FL4SHK> (ARM7TDMI CPU)
[17:31:55] <bss36504> FL4SHK: Strangework: The only parts of C++ you should avoid in an embedded system (or rather, something with limited memory) is heap storage. If you statically allocate your objects, you should be fine. And yes, the virtual pointers are compile time
[17:32:14] <FL4SHK> Oh really, I didn't know that about virtual functions
[17:32:26] <FL4SHK> As for avoiding malloc, new [], etc... I was aware of that too
[17:32:37] <FL4SHK> static allocations are fun!
[17:32:54] <Strangework> That's all good news! I have always been anxious about using malloc/new - free/delete
[17:33:05] * Strangework hi-fives FL4SHK
[17:33:11] * FL4SHK hi-fives
[17:33:22] <Emil_> "What you mean there's no malloc?"
[17:33:26] <Emil_> >Allocate all the memory
[17:34:07] <bss36504> FL4SHK: Consider this: The compiler knows at compile time how many virtual pointers there are, and how big they are, so you wont run into heap stuff or runtime determination of where they point to. since a subclass essentially is "surrounded" by the features of the superclass, it too, has a definite size known at compile time.
[17:34:32] <FL4SHK> Right
[17:34:44] <bss36504> Emil_: Heap storage can be risky and wasteful on an AVR since you need to use memory up just to maintain a table. Not impossible, but not usable in all situations.
[17:34:57] <bss36504> if you are already memory constrained, malloc might well put you over the limit.
[17:34:58] <Emil_> bss36504: was a joke
[17:35:07] <bss36504> Emil_: My apoligies :P
[17:35:13] <FL4SHK> My largest AVR thing is an Arduino Mega 2560 actually
[17:35:13] <bss36504> apologies*
[17:35:20] <Emil_> np :D
[17:35:23] <FL4SHK> All my AVR things are Arduino boards, actually :V
[17:35:34] <bss36504> FL4SHK: Are you using the Arduino IDE?
[17:35:38] <FL4SHK> Only to upload code
[17:35:42] <FL4SHK> I code within Vim
[17:36:07] <bss36504> dear lord. Bless your soul
[17:36:19] <Emil_> inb4 editorwar
[17:36:23] <FL4SHK> Er, uh
[17:36:24] <bss36504> id rather gouge my eyes out than use vim for coding
[17:36:33] <Hexum064> wow
[17:36:33] <bss36504> But then again, I do love love love IDEs.
[17:36:39] <FL4SHK> I don't want to cause an editor war :V
[17:36:51] <Emil_> FL4SHK: too late, mate
[17:36:53] <FL4SHK> It doesn't matter to me what editor/IDE one uses
[17:36:54] <Emil_> It has begun
[17:36:54] <bss36504> Oh no! no war here, im impressed
[17:37:04] <FL4SHK> It took me
[17:37:08] <Emil_> nano -c ftw
[17:37:14] <FL4SHK> *Admittedly, it took me a while to learn how to use Vim
[17:37:27] <FL4SHK> I'm not at all an expert at it either lol
[17:37:30] <FL4SHK> I've been using it for a year
[17:37:34] <Emil_> I should probably start to learn vim
[17:37:46] <Emil_> it has too many good features
[17:37:56] <Strangework> Vim is the shit
[17:38:00] <Jordan_U> Emil_: I highly recommend "vimtutor" as an introduction to vim.
[17:38:09] <FL4SHK> I learned with vimtutor
[17:38:12] <Strangework> I am so down for a race, pardon, editor war
[17:38:12] <bss36504> I just like being able to right click a variable or function and say "go to declaration". IDEs make large quantites of source files a little easier to manage, IMO.
[17:38:25] <FL4SHK> bss36504, I use something like that
[17:38:25] <bss36504> Strangework: lol
[17:38:33] <FL4SHK> Which I can use with Vim
[17:38:36] <Strangework> IDEs really are worth it, though - I just never got into any
[17:38:49] <FL4SHK> I can jump to the declaration
[17:38:53] <Strangework> Just a few weeks ago I broke out of the Arduino IDE
[17:39:01] <Emil_> Strangework: I have this thing
[17:39:03] <Strangework> I am now one of the avrdudes 8)
[17:39:10] <FL4SHK> I'd like to become one of the avrdudes
[17:39:22] <Emil_> it's called fbpuukottaja
[17:39:27] * Strangework hands FL4SHK his official avrdude card
[17:39:36] <FL4SHK> YES
[17:39:36] <Strangework> Did you just fart at me, Emil_? ;)
[17:39:41] <Emil_> Strangework: No!
[17:39:48] <Strangework> (no racist humor intended)
[17:40:03] <Emil_> *I farted in your general direction
[17:40:03] <FL4SHK> bss36504: I use a plugin called Taghighlight
[17:40:15] <bss36504> The more you know
[17:40:33] <Emil_> In any case Window systems and DEs are for sissies
[17:40:39] <FL4SHK> wow
[17:40:46] <Emil_> real men only manage servers and use cli
[17:40:47] <bss36504> I personally use Atmel Studio.
[17:40:59] <bss36504> Emil_: I'll fight you, mate
[17:41:10] <FL4SHK> I use cli for many, many things, but I still use a DE
[17:41:17] <Emil_> But because we can
[17:41:22] <Emil_> We stab the framebuffer itself
[17:41:35] <Strangework> Emil_, what IS fbpuukottaja?
[17:41:35] <Emil_> Who needs X anyways when you can make your own
[17:41:46] <Emil_> Linux framebuffer stabber
[17:42:09] <Strangework> o.o
[17:42:43] <Emil_> "What you mean I need to learn OpenGL to draw pixels on the screen"
[17:42:50] <Emil_> "What you mean I need X for that!?"
[17:43:17] <Lambda_Aurigae> openGL won't run on my atmega1284p.
[17:43:25] <Emil_> One hackathon later:
[17:43:36] <bss36504> I feel as though the conversation has drifted into non-embedded programming...
[17:43:43] <Emil_> bss36504: shhhhhh
[17:44:32] <Strangework> Loop back to embedded world and discuss jamming Quake onto my avr
[17:44:38] <Emil_> Nono
[17:44:40] <bss36504> Lambda_Aurigae: Have you seen the linux on an AVR thing? Some guy first wrote an ARM emulator for the AVR, then strapped a RAM dimm onto it, loaded linux and called it a day. Took like 11 minutes to boot to the command line.
[17:44:44] <Emil_> we can change it to avr controlled screen
[17:45:02] <Emil_> bss36504: only 11 minutes?
[17:45:12] <Lambda_Aurigae> bss36504, yes...I built one.
[17:45:13] <Emil_> Wasn't it more like 11h to boot bash
[17:45:24] <Emil_> and after that a couple of minutes to respond to keypresses
[17:45:32] <Lambda_Aurigae> took 6 hours to boot to bash command prompt on mine.
[17:45:51] <DKordic> Emil_: ``framebufer stabber''?!
[17:45:52] <Lambda_Aurigae> not enough ram to run X though.
[17:46:01] <Emil_> DKordic: Yes.
[17:46:18] <bss36504> Lambda_Aurigae: Wait are you *that guy* i read about? Neat-o, even if youre not.
[17:46:22] <DKordic> I have no idea what that might be.
[17:46:34] <Emil_> Stabbing memory has never been this fun. Not even stabbing databases directly is as fun
[17:46:39] <Lambda_Aurigae> no...I'm not him.
[17:46:41] <Lambda_Aurigae> I just built one.
[17:46:46] <bss36504> as for 11 minutes, I was going by memory. Apparently my memory isnt big enough either.
[17:46:48] <Lambda_Aurigae> copied his and made some changes.
[17:47:02] <Emil_> bss36504: eh, overflows are good timers
[17:47:11] <Emil_> "there's a register for that"
[17:47:27] <bss36504> Lambda_Aurigae: gotcha. Very neat. The fact that he wrote an arm emulator first is pretty amusing to me also.
[17:47:43] <Emil_> bss36504: it was a subset if I recall correctly
[17:47:57] <Emil_> an extensive one, though
[17:48:00] <bss36504> Emil_: Yes I believe you are correct.
[17:48:03] <Lambda_Aurigae> bss36504, that's the best part of the whole thing.
[17:48:17] <Lambda_Aurigae> and it can be relatively easily ported to other processors,,,including x86 if you really wanted to.
[17:48:58] <Emil_> Strangework: let's parallelise it and remove floating point calculations
[17:49:08] <Emil_> then we can just softclock attinys and call it a day
[17:49:13] <Lambda_Aurigae> I have it mostly working on a pic32 chip with similar external memory attached, although I had to do some 74xx magic to multiplex the ram address and data.
[17:49:54] <Emil_> Do you know the absolute clock limit for attinys by the way?
[17:50:02] <DKordic> Emil_: So how may I do graphics without blasted ****GL and *11?
[17:50:12] <Lambda_Aurigae> Emil_, depends on the chip.
[17:50:21] <Emil_> DKordic: #include <linux/fb.h>
[17:50:28] <Lambda_Aurigae> Emil_, I've overclocked atmega32 from 16MHz max to 24MHz..
[17:50:43] <Emil_> Lambda_Aurigae: softclocked or crystal?
[17:50:45] <Lambda_Aurigae> and overclocked an atmega1284p from the 20MHz max to 33MHz
[17:50:47] <Lambda_Aurigae> crystal.
[17:51:01] <Lambda_Aurigae> only problem I ran into with either was the ADC didn't want to behave.
[17:51:02] <Emil_> Nice
[17:51:08] <Hexum064> I got an xmega running at 64 off the pll
[17:51:21] <Hexum064> Didn't even get hot
[17:51:22] <Emil_> Hexum064: no you di... ah xmega
[17:51:32] <Emil_> But doesn't it halve the clock?
[17:51:33] <Hexum064> yes, xmega, not atmega
[17:51:53] <Lambda_Aurigae> I have a 28pin dip package pic32 running at 50MHz which pushes 83DMIPS from a 10MHz crystal and the onboard PLL.
[17:51:59] <Hexum064> 16mhz xtal and 4xPLL
[17:51:59] <Emil_> Did you just dump the pll to pin and directed that to clock input?
[17:52:15] <Lambda_Aurigae> Emil_, it has a built in pll.
[17:52:19] <Hexum064> yep
[17:52:30] <Emil_> Lambda_Aurigae: yes?
[17:52:33] <Lambda_Aurigae> takes the clock or crystal input and can multiply inside.
[17:52:46] <Lambda_Aurigae> xmega, pic32, and some attiny chips have such a thing built in.
[17:52:55] <Lambda_Aurigae> many pic chips have it actually.
[17:53:15] <Emil_> Lambda_Aurigae: I'm not sure what's your point?
[17:53:33] <Lambda_Aurigae> you were asking if they fed the pll into the microcontroller, yes?
[17:53:54] <Lambda_Aurigae> thought you meant an external pll.
[17:54:15] <Emil_> Lambda_Aurigae: If you take the internal pll the clock is usually halved though you can still dump it to a pin directly
[17:54:42] <Hexum064> You can set the prescaler to 1
[17:54:45] <Emil_> So if you set the clock source to external and dump the internal pll to a pin you "can" have the full pll freq instead of the halved one
[17:54:46] <Lambda_Aurigae> oh...you mean feed the clock out to an output pin?
[17:54:48] <Emil_> not on attinys
[17:54:58] <Emil_> Lambda_Aurigae: yah
[17:55:13] <Lambda_Aurigae> that's usually only available on one of the xtal pins I thought.
[17:55:19] <Hexum064> I have an idea for a project. Let's see what it will take to get an attiny running at 100mhz
[17:55:41] <Lambda_Aurigae> Hexum064, liquid nitrogen cooling.
[17:55:46] <Emil_> Hexum064: I can get cheap LN
[17:55:48] <Hexum064> That was my first thought
[17:55:51] <Emil_> 1€/l
[17:56:00] <Lambda_Aurigae> it will overheat way before you hit 50MHz.
[17:56:18] <Emil_> But it won't stand the extreme clock nor will it stand the frequency
[17:56:32] <Hexum064> We might have to run it at like 10v
[17:56:41] <Emil_> Lambda_Aurigae: attinys run cool at 28MHz softclock
[17:56:50] <Lambda_Aurigae> the chip won't run at the high frequencies...it's just not meant to run at such high switching frequencies.
[17:57:10] <Lambda_Aurigae> Emil_, what's the rated max speed of that chip though?
[17:57:14] <Lambda_Aurigae> 20MHz?
[17:57:15] <Hexum064> I'm sure Lambda_Aurigae is right. Just a fun thought
[17:57:20] <Emil_> Lambda_Aurigae: 20 yah
[17:57:27] <Emil_> but that's "industry"
[17:57:32] <Lambda_Aurigae> so, 40% overspeed isn't that big a deal.
[17:57:33] <Emil_> They take much more than that
[17:57:53] <Lambda_Aurigae> I bet it won't run stable at 40MHz.
[17:58:08] <Emil_> Flash will fail first if I remember correctly
[17:58:08] <Lambda_Aurigae> the core might
[17:58:18] <Lambda_Aurigae> but the peripherals won't and the memory definitely won't
[17:58:22] <Emil_> then ram
[17:58:29] <Emil_> and peripherals
[17:58:32] <Emil_> but the core is okay
[17:58:47] <Lambda_Aurigae> as I said, a 20MHz rated atmega1284p will run at 33MHz but I noticed that the ADC was flaky as hell.
[17:59:10] <Lambda_Aurigae> I even got the USART to work at that speed.
[17:59:12] <Emil_> Lambda_Aurigae: what prescaler did you use for it?
[17:59:16] <Lambda_Aurigae> no prescaler.
[17:59:20] <Emil_> ....
[17:59:24] <Lambda_Aurigae> oh, on the ADC?
[17:59:27] <Emil_> ADC expects 125-200KHz :D
[17:59:30] <Emil_> Yeah ADC
[17:59:34] <Lambda_Aurigae> I don't remember...I futzed with it for about 10 minutes then gave up.
[17:59:54] <Lambda_Aurigae> I know I slowed it way down but something wasn't talking right.
[18:00:09] <Lambda_Aurigae> but couldn't say what speed exactly...it's been something like 5 years or so.
[18:00:14] <Emil_> There was an extensive comparison on ADC accuracy cs clock speed
[18:01:00] <Emil_> http://www.hilltop-cottage.info/blogs/adam/avr-adc-2-experiments-in-operating-the-adc-at-its-extremes-attiny85/
[18:01:23] <Emil_> In that link there should be more links also
[18:01:31] <Emil_> that lead to an even more comprehensive look at it
[18:02:10] <Lambda_Aurigae> I don't overclock AVRs much these days.
[18:02:26] <Emil_> Lambda_Aurigae: yeah it's mostly a curiosity
[18:02:27] <Lambda_Aurigae> maybe to 25.125ish MHz
[18:02:34] <Emil_> but that link isn't about overclocking
[18:02:35] <Lambda_Aurigae> but that's for playing with VGA timing.
[18:02:43] <Lambda_Aurigae> and I don't do a lot with ADC anyhow.
[18:02:46] <Emil_> it's just how the adc reacts to running at higher frequencies
[18:02:53] <Lambda_Aurigae> I have plenty of offboard ADC chips that are much better.
[18:03:03] <Lambda_Aurigae> yeah...got it marked for later reading.
[18:03:12] <Emil_> I wonder if the measurements stay stable at higher clocks
[18:03:23] <Emil_> You could calibrate the adc
[18:03:52] <Lambda_Aurigae> could.
[18:03:59] <Emil_> I know
[18:04:03] <Emil_> highly unlikely
[18:04:14] <Emil_> but it could be used for something like burst communications
[18:04:32] <Lambda_Aurigae> I have some adc chips here that can give me 1Msps.
[18:04:36] <Emil_> you know how bluetooth is actually a really cool hack
[18:04:43] <Lambda_Aurigae> problem is, my AVRs can't accept them that fast.
[18:04:51] <Lambda_Aurigae> well, bluetooth is a hack.
[18:04:55] <Lambda_Aurigae> I'll give it that.
[18:04:56] <Emil_> a cool one!
[18:06:21] <Lambda_Aurigae> a cool hack is using a pll and an avr as an AM receiver and an AVR by itself as an AM transmitter and doing FSK over that connection.
[18:06:38] <Emil_> But I mean like, even if it only worked as a comparator
[18:06:54] <Lambda_Aurigae> well, you have comparators onboard too.
[18:06:55] <Emil_> Lambda_Aurigae: why stop at radio when you can do video ; )
[18:07:02] <Lambda_Aurigae> I am doing video.
[18:07:17] <Emil_> Lambda_Aurigae: but are they fast?
[18:07:41] <Emil_> probably faster than adc hacks :D
[18:07:42] <Emil_> True
[18:07:48] <Emil_> Lambda_Aurigae: what kind of video?
[18:07:53] <Lambda_Aurigae> I like Jartza's video idea better than mine so far...but mine is giving me better resolution and full 400x300 resolution on an 800x600 vga display.
[18:08:12] <Emil_> Oh no I meant video transmission :D
[18:08:14] <Lambda_Aurigae> mine is far from stable though.
[18:08:18] <Emil_> actualy NTSC video
[18:08:27] <Lambda_Aurigae> I could transmit video...it would be a bit slow on the refresh side.
[18:08:38] <Emil_> Check CNLohr on youtube
[18:08:47] <Lambda_Aurigae> as my baud rate on the AVR AM radio system was something like 4800bps.
[18:09:10] <Lambda_Aurigae> I avoid youtube for technical stuff... pretty much everybody on there bugs the shit out of me.
[18:10:03] <Emil_> Your loss ; )
[18:10:08] <Lambda_Aurigae> give me text and diagrams,,,and maybe a video of the functionality.
[18:10:25] <Emil_> He has diagrams and all the code available
[18:10:27] <Lambda_Aurigae> but the voiceovers just,,,,no thanks.
[18:11:09] <Lambda_Aurigae> I have to deal with people talking all day long...when I'm playing I want quiet.
[18:11:54] <Lambda_Aurigae> I have make-the-world-go-away headphones that I wear quite a bit at home...most of the time they aren't even turned on...
[18:12:01] <Lambda_Aurigae> just to keep the voices from the tv out.
[18:12:10] <Lambda_Aurigae> because the wifey likes her tv on all the time.
[18:13:27] <Lambda_Aurigae> I'm not really a people person though.
[18:17:49] <Emil_> The guy also bitbangs ethernet
[18:17:53] <Emil_> on attiny
[18:18:02] <Lambda_Aurigae> that was done years ago by igor.
[18:18:10] <Lambda_Aurigae> although he was using an atmega8.
[18:18:36] <Lambda_Aurigae> can he receive ethernet or is it still just packet transmission?
[18:19:55] <Lambda_Aurigae> igor being also the first guy to bitbang usb on an avr.
[18:20:03] <Lambda_Aurigae> from which code v-usb was derived.
[18:20:35] <Emil_> both
[18:21:20] <Emil_> he also references igor
[18:22:39] <Emil_> In any case all of his stuff is on github
[18:23:00] <Emil_> https://github.com/cnlohr
[18:26:51] <Lambda_Aurigae> aahh,,he is doing transition detection.
[18:27:08] <Lambda_Aurigae> nice way of picking data out of the stream.
[18:29:42] <Emil_> .......... I'm just watching his video
[18:29:46] <Emil_> one of his*
[18:29:55] <Emil_> and he's doing ajax* on attiny
[18:30:54] <Emil_> as in asnwering to requests
[19:04:30] <Hexum064_2> Damn. All the chat history went away cause I logged in again.
[19:04:55] <Emil_> Hexum064_2: >not using a server
[19:05:04] <Emil_> I can paste what I have if you are interested
[19:05:26] <Lambda_Aurigae> I have xchat logging everything from this end.
[20:01:07] <Hexum064_2> OK, this feels like a noob question. Can anyone confirm that USARTD0 in SPI master mode would use pin D1 as clock and D3 as MISO?
[20:02:02] <Lambda_Aurigae> what does the datasheet say?
[20:03:12] <Hexum064_2> Have you tried to find that in the datasheet? I have been and, if it's in there, either I am just not being patient enough or I am just dumb.
[20:03:20] <Lambda_Aurigae> what chip?
[20:04:32] <Hexum064_2> xmega128a4u
[20:05:23] <Lambda_Aurigae> never read through an xmega sheet...never had an xmega to play with.
[20:05:49] <Lambda_Aurigae> let me download and see what I can find.
[20:06:08] <Hexum064_2> I'm going to go back and look as well. Thanks Lambda_Aurigae
[20:06:21] <Lambda_Aurigae> download gonna take a bit though.
[20:06:38] <Lambda_Aurigae> have multiple netflix streams going on here.
[20:06:43] <Lambda_Aurigae> and only a 5Mb/s connection.
[20:08:24] <Emil_> How do you survive is beyond me
[20:08:38] <Hexum064_2> lol
[20:08:54] <Hexum064_2> AND he's chatting on IRC
[20:09:02] <FL4SHK> that doesn't use very much bandwidth
[20:09:17] <Hexum064_2> ... :/
[20:09:27] <Hexum064_2> that was kinda the joke
[20:09:33] <FL4SHK> lol
[20:09:35] <Strangework> lol
[20:09:46] <Strangework> I giggled, Hexum064_2, no need to feel completely defeated.
[20:09:56] <Hexum064_2> aaah. thanks Strangework
[20:10:49] <Lambda_Aurigae> wifey is watching property brothers
[20:10:59] <Lambda_Aurigae> mother-n-law is watching some show in her apartment
[20:11:05] <Lambda_Aurigae> and I'm watching farscape.
[20:11:17] <Lambda_Aurigae> I'm surprised they all run simultaneously.
[20:11:20] <Strangework> AND you're chatting on IRC
[20:11:32] <Lambda_Aurigae> specially mine because it's running netflix on linux.
[20:11:41] <Lambda_Aurigae> yeah...in like 17 chat channels on 3 servers even!
[20:11:42] <Hexum064_2> really getting his money's worth out of that 5mbs
[20:13:54] <Hexum064_2> Hmm. I wonder if one of my problems could be that I never called my init function for the USART setup...
[20:17:14] <Lambda_Aurigae> Hexum064, page 59, table 32-4
[20:18:14] <Lambda_Aurigae> TXD is same as MOSI I do believe...
[20:18:24] <Lambda_Aurigae> txd = transmit
[20:18:37] <Lambda_Aurigae> MOSI = master out slave in...which says transmit to me.
[20:19:03] <Hexum064_2> but that's for USART1
[20:19:32] <Emil_> You can define the pins however you like usin USI?
[20:19:43] <Lambda_Aurigae> xck0, pd1
[20:19:59] <Lambda_Aurigae> xck1, pd5
[20:20:42] <Lambda_Aurigae> so, usartd0 is on d1,2,3...usartd1 is on d5,6,7
[20:21:54] <Hexum064_2> I believe that is correct as well but I'm verifying the signal now
[20:24:38] <Hexum064_2> Gawd. loving having a ethernet connection to the internet at home
[20:25:03] <Lambda_Aurigae> I've had that for a while.
[20:25:10] <Lambda_Aurigae> but it's only 5Mb/s
[20:29:18] <Emil_> Wait MB or Mb?
[20:29:38] <Hexum064_2> bits or bytes
[20:29:57] <Hexum064_2> (though ethernet is usually measured in bits because it's serial)
[20:30:06] <Lambda_Aurigae> bits.
[20:30:08] <Lambda_Aurigae> Mb
[20:30:15] <Lambda_Aurigae> I know the difference.
[20:31:39] <Emil_> HOW DO YOU SURVIVE
[20:31:55] <Emil_> I read MB first and I thought that's okayish
[20:31:58] <Emil_> but bits
[20:32:00] <FL4SHK> >okayish
[20:32:07] <Emil_> Well
[20:32:09] <FL4SHK> 5 MB/s is good
[20:32:11] <Emil_> I'm 1Gb up/down
[20:32:15] <Emil_> So :)
[20:32:15] <FL4SHK> wow
[20:32:20] <Lambda_Aurigae> I do my big downloads at times when I'm not at home.
[20:32:20] <FL4SHK> Where do you live
[20:32:31] <FL4SHK> like what country
[20:32:35] <FL4SHK> So I can move there
[20:32:41] <Emil_> Being a student has its benefits :D
[20:32:50] <FL4SHK> Oh
[20:33:04] <FL4SHK> I guess maybe I Can go for a business class speed when I'm out of school and have a job...
[20:33:32] <Emil_> Business class internet is usually just about reliability and static ips
[20:33:41] <FL4SHK> So no more speed?
[20:33:44] <Emil_> you could very well have a faster connection as consumer
[20:33:55] <FL4SHK> I have 50 Mbps download at home
[20:33:56] <Emil_> Well, you can ask for that :D
[20:34:11] <FL4SHK> We're paying $60 a month for it...
[20:34:11] <Lambda_Aurigae> there is 100Mb/s connection available in town.
[20:34:15] <Lambda_Aurigae> I live 20 miles from town.
[20:34:27] <FL4SHK> but like
[20:34:29] <Lambda_Aurigae> however, it reads as "up to 100Mb/s"
[20:34:37] <Emil_> Internet is included in my rent :D
[20:34:43] <FL4SHK> Emil_ how does one attain such high speeds?
[20:34:46] <Lambda_Aurigae> when all the kids get home it drops to bear whiz.
[20:35:01] <Lambda_Aurigae> mine is 5Mb/s up and down and never varies.
[20:35:02] <FL4SHK> Like
[20:35:05] <Emil_> FL4SHK: by having a student union of technical people who care
[20:35:08] <FL4SHK> Eventually I will be in a position to pay for it
[20:36:20] <FL4SHK> And for crap's sake I'm not moving to a bigger city
[20:37:43] <Emil_> Aalto University( Student Union) is the place to be :D
[20:38:19] <Emil_> If I made some arrangements I could even have access to 10Gb backbone
[20:38:29] <Emil_> for a server
[20:40:23] <Emil_> Did I brag too much?
[20:40:51] <Lambda_Aurigae> hehe.
[20:41:28] <Lambda_Aurigae> I used to have access to a full OC3 back in around 2003 to 2007.
[20:42:10] <FL4SHK> in 2003 I was in third grade (or fourth grade depending on which half of the year)
[20:42:53] <Lambda_Aurigae> I was the IT department for a software development company writing core software for telecoms.
[20:42:57] <FL4SHK> ...in 2007 I was in either seventh or eigth grade, depending on which half of the year
[20:43:03] <Lambda_Aurigae> verizon provided us with an OC3 for testing
[20:44:18] <Emil_> But really
[20:44:54] <Emil_> if you are a student and your apartment doesnt have at least 100Mbit up/down then you have to put more pressure on your school/student union
[20:45:28] <Lambda_Aurigae> I haven't been a student since 1987 when I graduated tech school.
[20:46:16] <Lambda_Aurigae> and we didn't have internet back then.
[20:46:46] <Lambda_Aurigae> my modem was only 9600baud at the time too.
[20:46:55] <Lambda_Aurigae> BBSs rocked!
[20:54:32] <garfong> LORD Tradewars!
[20:54:48] <Lambda_Aurigae> vga planets
[20:55:45] <Lambda_Aurigae> and fidonet!
[20:55:56] <Lambda_Aurigae> I was a fidonet node for a while waaay back when.
[20:56:24] <garfong> yah, always wanted to run a bbs
[20:56:31] <garfong> I kinda caught the tail end of things unfortunately
[20:57:16] <ferdna> recommend me a HDTV outdoor antenna
[20:57:23] <ferdna> 50miles or more range
[20:57:26] <Lambda_Aurigae> I ran one on a c-64 for about a year.
[20:57:38] <Lambda_Aurigae> ferdna, whatever works for your area.
[20:58:03] <ferdna> Lambda_Aurigae, what do you mean for my area?
[20:58:09] <ferdna> doesnt all antennas work the same?
[20:58:12] <ferdna> digital channels
[20:58:16] <Lambda_Aurigae> different antennas work better for different areas.
[20:58:19] <ferdna> digital-over the air channels
[20:58:35] <ferdna> Lambda_Aurigae, hmm... can you recommend me one then?
[20:59:45] <Lambda_Aurigae> the one I have was a cheapy from walmart...powered flat antenna strapped to the chimney on top of my house...it's 7 years old and works fine, picks up signals from 60 to 70 miles away.
[21:00:16] <ferdna> Lambda_Aurigae, can you post link?
[21:00:30] <Lambda_Aurigae> previous one was an old antenna from analog days...worked even better...only reason it got replaced was wind blew it over.
[21:00:47] <Lambda_Aurigae> I could go take a picture but you couldn't see much as I'm not climbing up on the roof to get a closeup.
[21:03:45] <Lambda_Aurigae> I'm not seeing anything on walmart.com now that looks like mine...
[21:03:50] <Lambda_Aurigae> as I said, it's 7 years old.
[21:04:23] <Lambda_Aurigae> but, as I said, whatever works for your area....older style antennas work great for hilly or mountainous areas.
[21:04:36] <Lambda_Aurigae> the newer ones are more line of sightish.
[21:05:22] <Lambda_Aurigae> and I'm off to bed, so, nighters.
[21:11:02] <ferdna> Lambda_Aurigae, good night :)
[22:05:03] <ferdna> which one?
[22:05:04] <ferdna> http://www.digitalhdsource.com/outdoor-hdtv-antennas.html