#avr | Logs for 2016-04-21

Back
[00:53:28] <WormFood> So, what the fuck do I need to do, to move interrupts to the bootloader area of the flashrom? I've read the datasheet, and done what they said, but it don't fuckin' work.
[00:54:30] <WormFood> MCUCR = (1 << IVCE); MCUCR = (1 << IVSEL); <-- this is what they say to do, but it sure as fuck doesn't god damn work.
[01:14:36] <WormFood> Is this fuckin' shit just busted? Did it ever fuckin' work?
[01:32:07] <Mr_Sheesh> I could see |= on the 2nd of those, but just = ????
[01:32:23] <Mr_Sheesh> MCUCR = (1 << IVCE) | (1 << IVSEL);
[01:32:57] <Mr_Sheesh> long day, tired, but I know just using = isn't going to set the IVCE bit at all...
[01:34:31] <WormFood> Mr_Sheesh, read the datasheet. You have to set IVCE first, then within 4 cycles set IVSEL. It's sort of a lock, to prevent accidental changes to the interrupt vectors.
[01:34:59] <Mr_Sheesh> Oh, OK, I'm rusty, RL has been annoying!
[01:35:25] <Mr_Sheesh> maybe contact an Atmel FSE?
[01:57:53] <WormFood> I use the *exact same code* in Atmel's example, and it STILL doesn't fuckin' work!
[02:47:20] <Mr_Sheesh> Thats why I'm saying talk with an Atmel FAE, they'd be experts pretty much - You're seeming pretty knowledgeable, nice calcs on your site I've seen :)
[03:04:11] <WormFood> Thanks ;)
[03:04:43] <WormFood> I just did a major overhaul of my bit rate calculator. I fixed a few bugs, and made it a lot more flexible.
[03:05:23] <WormFood> I also have a nifty IP subnet calculator, that isn't popular at all.
[03:17:54] <cehteh> port it to ipv6 :D
[03:19:56] <WormFood> heh
[03:20:02] <WormFood> not in this decade
[04:16:11] <WormFood> Fuck! None of these bootloaders work! Absolutely fuckin' nothing! I've come to the conclusion that the ATmega88 is fuckin' busted. It simply does not work as advertised.
[04:16:36] <WormFood> You can not change the interrupt vectors, no matter what you do. Nothing works.
[04:16:47] <WormFood> The examples in the datasheet, doesn't work.
[04:16:58] <WormFood> What the fuck!
[04:18:47] <WormFood> ALL of the v-usb examples work, as long as they're not a bootloader.
[04:24:34] <cehteh> huh
[04:24:58] <cehteh> that sux, but still i think you overseen something
[04:29:21] <WormFood> What?
[04:29:26] <WormFood> I've set everything properly.
[04:30:40] <WormFood> I've literally spent 2 days going over and over and over everything. I've read the datasheet until my eyes bleed. I've done the code *exactly* the same way the examples show it. I've inspected the generated asm code, to make sure it's doing what it's supposed to. Everything is right. And even other avr bootloader projects won't work. I've cone to the conclusion that the ATmega88's bootloader interrupt support is fuckin' busted.
[04:32:56] <cehteh> or your mega88 is busted somehow
[04:33:08] <cehteh> (are there counterfeits?)
[05:20:37] <GeneralStupid> Hi, i use the atmel ASF usb cdc and i want to implement RTS/CTS Flow Control.
[05:20:44] <GeneralStupid> But there is no CTS signal...
[05:50:55] <LeoNerd> What do you mean "CTS signal"?
[05:57:36] <vespakoen> Oh great! didn't know the avr community was this big =)
[05:58:05] <GeneralStupid> LeoNerd: Clear To Send (rs-232)
[05:58:44] <vespakoen> Let me introduce myself a little, I am Koen, live in Berlin, have been playing with an arduino recently and have filled up my atmega328p (arduino nano) with code, so I moved to a make file and "bare c"
[05:59:47] <vespakoen> so far I have been able to get a couple of things working (LCD, Serial) but am now stuck implementing SoftwareSerial, I found a couple of libraries on the net, one of them seems to have the right constants in there (for the interrupts) for my processor, but I cannot get my GPS module to talk back to me
[06:00:09] <vespakoen> the project I am working on is open source and on github, perhaps someone can give me some pointers? github.com/vespakoen/dwaler
[06:00:30] <LeoNerd> GeneralStupid: Yes I know what the concept of CTS is :)
[06:00:55] <LeoNerd> GeneralStupid: Do you mean you don't get access to the logical CTS state via the USB-CDC code, or you don't have a physical pin for it, or...?
[06:01:19] <GeneralStupid> LeoNerd: the signal is not there. There are dcd and dsr signals...
[06:01:20] <cehteh> vespakoen: why not HW serial? needing 2 ports?
[06:01:32] <vespakoen> I am using hardware serial for my bluetooth connection
[06:01:45] <cehteh> ok
[06:01:47] <GeneralStupid> LeoNerd: logical, in udi_cdc.h there is no udi_cdc_ctrl_signal_* function for that
[06:01:47] <vespakoen> and think there is only one on there, right? (the atmega328p)
[06:01:51] <cehteh> yes
[06:01:56] <LeoNerd> Ah also, for those of us wanting an ATmega328PB on a breakout board, I found this: http://www.watterott.com/en/Wattuino-pro-mini-PB-5V-16MHz It's an Arduino Mini-shaped board with an 328PB on and some extra IO pins for the new signals
[06:02:11] <cehteh> cool
[06:02:20] <LeoNerd> vespakoen: You're in the same boat as me then. See my above link in fact. :)
[06:02:26] <LeoNerd> mega328PB has two hardware UARTs
[06:02:26] <vespakoen> hah, cool
[06:02:28] <cehteh> oh halt wattenrottt .. german .. nice .. but expensive
[06:02:39] <LeoNerd> €6.50 is expensive?
[06:02:42] <cehteh> only 6,50 EUR instead 10,00 EUR
[06:02:45] <cehteh> .. lucky
[06:02:47] <cehteh> *order*
[06:03:11] <cehteh> well so far i havnt payed more then $3.50 for nanos
[06:03:16] <LeoNerd> Haha
[06:03:33] <LeoNerd> Looking at the pin silkscreening.. they've labeled ardunio names on all the pins except PE0 and PE1
[06:03:37] <cehteh> but shipping 3.50
[06:03:45] <vespakoen> so here are my findings so far, there is a software uart library here: http://siwawi.bauing.uni-kl.de/avr_projects/#softuart
[06:03:56] <cehteh> ok i wait for china
[06:04:01] <vespakoen> which somebody forked and made some modifications to over here: https://github.com/blalor/avr-softuart
[06:04:25] <cehteh> vespakoen: a lot people use sw serial, it works
[06:04:29] <vespakoen> then there is some guy at a university that put this softuart online: https://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2009/awl9_hc352/awl9_hc352/src/softuart.c
[06:04:38] <cehteh> i havent used it yet, maybe i'll add it someday
[06:05:03] <vespakoen> I am sure it will work, I have it working with arduino's SoftSerial in C++
[06:05:09] <cehteh> but, i honestly, i'd rather think about getting a chip with 2 uarts when i need that
[06:05:20] <vespakoen> mehhh, don't give up so fast! =P
[06:05:30] <LeoNerd> I tend to rewrite these things myself
[06:05:38] <cehteh> me too :D
[06:05:38] <LeoNerd> Easier than trying to work out how to drive someone else's code/makefile/..
[06:05:48] <LeoNerd> It's not as if UART is that hard a signal to produce or parse ;)
[06:05:57] <cehteh> but i like to do my cycles doing useful things
[06:06:01] <vespakoen> yeh that's what I did with the LCD library as well (made the 2000'th lib for it it seems)
[06:07:09] <cehteh> mhm .... i found an easy way to double the size of the documentation for mµOS ...
[06:07:18] <cehteh> just include the GPL as appendix :D
[06:08:05] <vespakoen> so did anyone here implement software serial, and if so, is willing to share their code?
[06:08:38] <cehteh> some here did, forgot who told about that yesterday, was that WormFood?
[06:10:25] <LeoNerd> vespakoen: I'll be doing it literally this weekend
[06:10:44] <cehteh> WormFood: 504 Host wormfood.net lookup failed: Permanent name server failure
[06:10:51] <LeoNerd> It'll be straight C (not C++), on avr-gcc/avr-libc
[06:10:59] <vespakoen> cool, that's what I need as well
[06:11:22] <LeoNerd> Fixed at 8bits,noparity,1stop
[06:11:24] <cehteh> no C++ here either
[06:11:35] <LeoNerd> Baud rate set by the timer. I haven't decided which timer unit to use yet
[06:11:35] <vespakoen> unfortunately I am going to the country side, plant trees and camp out so I cannot join you on your mission =)
[06:12:52] <vespakoen> so I read that you can go with a interrupt based timer or a polling technique and that they both have a use? how would one figure out which one to use for a certain application? (or do I have this all mixed up)
[06:13:25] <LeoNerd> Not sure what I should call it yet. I can't just call it "uart_*" because that collides with the real hardware one
[06:13:34] <LeoNerd> Eh..
[06:13:50] <LeoNerd> polling tends to be used by beginners or when you're literally doing nothing else of interest
[06:14:02] <vespakoen> other people seem to use a "sw" or "soft" prefix
[06:14:31] <vespakoen> here is the simplest one I found so far (with interrupts) https://github.com/vespakoen/dwaler/blob/master/chips/nanoc/softuart.c
[06:14:40] <LeoNerd> Given that you have a need for two serial ports, it sugests that you *are* doing other things
[06:14:46] <flyback> eww
[06:14:49] <flyback> softuart
[06:14:51] <LeoNerd> Yah; mine will be interrupt-based, given I'm doing all the other things in the world :)
[06:14:57] <flyback> *CANUCKED**CANUCKED**CANUCKED**CANUCKED*
[06:15:05] <vespakoen> haha
[06:15:05] <LeoNerd> flyback: Yeah, well.. 328P-notB. Only one hardware module. :/
[06:15:21] <LeoNerd> Besides... you should see the Propeller.
[06:15:22] * flyback rubs rue_house against softuart.c
[06:15:36] <cehteh> polling sux :D ... sometimes it unavoidable when you have some fast and very timing critical protocol, but try to avoid it as most as possible
[06:15:40] <LeoNerd> That's an 8core MCU with almost no interesting hardware peripherals. All the "hardware" comes in software form anyway
[06:15:50] <flyback> yeah I heard
[06:16:05] <LeoNerd> It's an interesting idea. Very flexible.
[06:16:14] <flyback> awesome track btw
[06:16:15] <flyback> https://soundcloud.com/andrew-sega/copper-sky-demo
[06:16:23] <LeoNerd> You don't have the problem that I hate about AVRs, where two different peripherals collide wanting the same physical IO pin
[06:16:36] <LeoNerd> But then PIC24s don't have that problem either what with having a crossbar... *grumble*
[06:16:59] * flyback still hasn't had time to learn to code, mabye next year :/
[06:17:34] <flyback> I defintely want to play with ble
[06:17:39] <flyback> ble owns your "canuck"
[06:17:47] * flyback attaches a JATO unit to rue_house
[06:18:25] <flyback> I love mcu's and wireless radios that will clock down to almost nothing to survive on low battery power
[06:18:29] <cehteh> LeoNerd: this wattenrott 328PB looks a bit hasty designed .. :D ... just stash the PE pins wheres some space, uses smaller mcu than it was designed for (hey now you have solder pads for each pin, not that bad)
[06:18:45] <flyback> anyone played with ble yet
[06:18:53] <flyback> bluetooth low energy
[06:19:01] <LeoNerd> cehteh: It is designed to fit the existing Arduino Mini footprint. So the external pins are in fixed locations. That doesn't leave much room to add PE0/PE1
[06:19:12] <flyback> btw looks like wifi accoaciation is making a ulp wifi as well
[06:19:20] <cehteh> yeh
[06:19:26] <LeoNerd> cehteh: Personally I don't care about the footprint.. I'm looking for a specific 328PB breakout.. ideally with proper Atmel pin names
[06:19:33] <cehteh> yes its fine
[06:19:38] <LeoNerd> And Iwant a real ISP6 header.. not this FTDI crap
[06:19:49] <flyback> I want to play with 300 baud modems also
[06:20:03] <cehteh> just make a isp6 adapter
[06:20:03] <flyback> bitch mode, finger point to being outdated all you want
[06:20:22] <flyback> but at the end of the day a 300 baud modem will still move data over even the worst 3rd world phone line
[06:20:33] <LeoNerd> Mmmm
[06:20:43] <LeoNerd> My 5kHz I²C link moves data over the worst line too...
[06:20:54] <LeoNerd> 95m of unshielded untwisted unbalanced alarm cable
[06:20:58] <flyback> nice
[06:21:05] <LeoNerd> Around a busy stage.. straight over the main 3phase dist board
[06:21:36] * LeoNerd is currently rebuilding that to RS-485 instead ;)
[06:21:36] <cehteh> LC-filter on AVCC of the AVR
[06:21:40] <LeoNerd> Hence needing my second uart
[06:21:46] <cehteh> .. thats at least a good idea finally
[06:21:47] <LeoNerd> cehteh: Yes.. I saw that. Cute. :)
[06:21:48] <LeoNerd> Yah
[06:21:52] <flyback> you know they make i2c, spi uart chips
[06:21:53] <LeoNerd> Finally *someone* appreciates these things
[06:22:00] <cehteh> i hate arduinos analog treatment
[06:22:05] <cehteh> (aka, none at all)
[06:22:26] <vespakoen> what are you connecting?
[06:22:31] <LeoNerd> flyback: Yes, they do. I don't have one. If I was going to go with the time-and-cost of adding a second chip, I'd stick a tiny841 in the middle, talk to it via SPI, and have it drive my RS-485 line, doing all the CRC/packeting/retries/etc... itself
[06:22:48] <LeoNerd> I don't have the resource to implement that right now. I have to have this working by end-of-may
[06:22:49] <flyback> rs-45 nice
[06:22:54] <flyback> read up on 485 before
[06:22:58] <flyback> still used in a lot of industral
[06:23:03] <flyback> cause it's simple and rock solid
[06:23:12] <LeoNerd> vespakoen: stage cueueing system. FoH - backstage link. Basically, Go and Stop signals, with also some other aux channels
[06:23:53] <vespakoen> cool
[06:24:12] <LeoNerd> 485 is a nice component, yes.. But all it specifies is a robust half-duplex logic-level link. So you still have to define something over the top. I'm going with (probably 25kBaud) UART, and some sort of packetisation over the top of that
[06:24:34] <vespakoen> nice
[06:24:36] <cehteh> LeoNerd: you are in uk? i just seen you have to pay 11.90 for shipping :D
[06:25:01] <LeoNerd> cehteh: I am. And yeah; I'm not interested in this exact board. I was merely highlighting that such things are available...
[06:25:11] <cehteh> ah ok
[06:25:15] <LeoNerd> I'm not in a hurry to get a 328PB; if I don't find a board to my liking I'll just make one
[06:25:18] <cehteh> well i can wait for china
[06:25:29] <LeoNerd> I'm one board away from needing "Page 2" on my OSHpark projects list... ;)
[06:25:42] <flyback> LeoNerd, you played with ble yet?
[06:25:51] <cehteh> otherwise i could make a deal .. order a few, slap some of them into a enveople and send them to you :D
[06:26:10] <cehteh> you pay shipping and its still cheaper for both of us
[06:26:42] <vespakoen> ohhh mailman came, with a package... =) let's see what china sent me today
[06:26:57] * flyback bites LeoNerd
[06:27:12] <LeoNerd> vespakoen: I just had the same. Today I received a baggie of heatshink, described on the customs label as "Gaming Parts"
[06:27:13] <vespakoen> GPS modules =D
[06:27:22] <vespakoen> oh let's see what mine says
[06:27:40] <vespakoen> clothing and apparel >.<
[06:27:50] <stephe_> i got some led matrices with label "digital tubes"
[06:27:52] <LeoNerd> flyback: Not BLE, no. For radio purposes I'm a fan of the Nordic Semi nRF24 chips. You can get the nRF24L01+ in a looovely little SPI breakout. Tiny little thing
[06:27:55] <vespakoen> really inventive over there
[06:28:05] <flyback> nordic makes ble modules also now
[06:28:13] <flyback> around 13.5ma tx/rx
[06:28:23] <flyback> mabye less on some
[06:28:26] <LeoNerd> stephe_: One time I got BNC connectors claiming to be "Mobile Phone Accessories". Idon't know when was the last time a mobile phone used a BNC connector
[06:28:28] <LeoNerd> Probably 1980
[06:28:38] <flyback> I mean how cool is that
[06:28:39] <stephe_> :D
[06:28:43] <flyback> data comm less power than a led
[06:28:57] <LeoNerd> The nRF24 is similar power, yea
[06:29:21] <LeoNerd> I prefer those for microcontroller stuff... Simpler and easier to manage... Also they're custom frequency, so you can tune them away from bluetooth/wifi
[06:29:34] <LeoNerd> Exactly what you want in a theatre stage with an audience full of a thousand mobile phones :)
[06:29:36] <flyback> oh cool
[06:29:42] <flyback> but how do you do security on them
[06:30:13] <LeoNerd> If I cared enough I could apply some sort of crypto to the packet payloads
[06:30:15] <vespakoen> NRF51, NRF51822, or NRF52: https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF51822-Development-Kit
[06:30:31] <vespakoen> some nice ble chips
[06:30:43] <LeoNerd> Given this contains stop/go signals for an am.dram. theatre production, using a custom 2.4GHz radio signal... I'm not sure I care enough
[06:30:54] <LeoNerd> My hypothetical adversary in this scenario is a very strange person
[06:31:52] <LeoNerd> If he cares enough to disrupt a amateur dramatic event put on one time ever for a charity convention, he'd find something far easier than hacking my radio system
[06:36:11] <LeoNerd> Oooh.. I hadn't noticed this before... the 328PB's rated clock speed goes up to 20MHz... as compared 328P's 16
[06:36:57] <vespakoen> yeah, that bit me, I made the assumptions that the 328p had 20mhz clock speed, rendering my serial unusable, took me a while to figure that out =)
[06:37:18] <vespakoen> now I use the actual datasheet as a reference in stead of blog posts on the net
[06:37:40] <LeoNerd> *grin*
[06:37:53] <LeoNerd> "Never believe anything you read on the internet" -- Abraham Lincoln
[06:38:16] <vespakoen> so, time to solder this gps module to my software serial ports and try to make it talk and spend another day playing instead of working =D
[06:38:20] <vespakoen> hahahaa
[06:38:32] <stephe_> i kind of want to print out the whole 328p datasheet
[06:38:47] <LeoNerd> Nah; it's too big
[06:39:08] <vespakoen> for me it's quicker to download it again then to open my downloads folder and find it in there
[06:39:18] <vespakoen> so right now the postfix is something like (20).pdf =P
[06:39:55] <LeoNerd> What I want, but Atmel don't do, is a little 1-page reference saying "The 328P has this pinout, this current draw, this max speed, etc... It has a version-1 UART, a version-1 8bit Timer0, a version-2 16bit Timer1, a version-1 8bit-async Timer2, a version-1 SPI, ..." and then /separate/ documents for describing those peripherals generally
[06:40:13] <LeoNerd> Atmel waste *soooooo* many pages duplicating the exact same description of the SPI module on every chip. or the timers, or whatever
[06:40:42] <LeoNerd> It's useful to me to know which chips use the /same/ timer, or the same uart, or whatever.. and that information doesn't fall out of their datasheets
[06:42:21] <stephe_> yea, that would be useful
[06:42:26] <cehteh> timer?
[06:42:42] <stephe_> TI has smaller datasheets for each chip, and then if you want the full info you check the family user guide
[06:42:52] <LeoNerd> cehteh: Take a selection of AVR chips, and read the datasheets, specifically the timers.
[06:42:57] <LeoNerd> There's lots of subtle variations.
[06:43:03] <cehteh> yes
[06:43:16] <LeoNerd> E.g. which ones can do fast PWM, which are async-capable... which have the third PWM channel, which have ICP... or CTC
[06:43:21] <cehteh> and its not even consistent across the same family
[06:43:28] <cehteh> yes
[06:43:28] <LeoNerd> I want a summary chart of little tickyboxes
[06:43:28] <cehteh> ok
[06:43:47] <LeoNerd> I may have to make this myself :/
[06:43:51] <cehteh> that would be massive, because all this little details
[06:44:03] <stephe_> i want a full txt datasheet, with ascii art diagrams
[06:44:04] <cehteh> but moment i think i found one recently
[06:45:57] <cehteh> https://www.mikrocontroller.net/articles/AVR_Typen https://www.mikrocontroller.net/articles/AVR_Assembler_-_Vergleichstabelle for some things
[06:46:01] <cehteh> yes german :D
[06:46:25] <stephe_> ha
[06:46:28] <LeoNerd> Hm... the latter there has instructions
[06:46:30] <cehteh> on another note: they could just design their chips more consistent and orthogonal
[06:46:39] <cehteh> yes might be useful
[06:46:41] <LeoNerd> cehteh: Hah.. yes.. that would be nice ;)
[06:47:01] <LeoNerd> I have an ideal shape for what I think an AVR chip should be...and it's a little different to these ones
[06:47:24] <cehteh> for example which ones have a input capture seems to be decided by trowing some coins :D
[06:47:37] <LeoNerd> cehteh: Yah; those two charts both look interesting, but not the information I had in mind.
[06:47:52] <cehteh> you find some more on mikrocontroller.net
[06:48:03] <cehteh> stash of a lot useful information
[06:48:09] <stephe_> i wish i spoke german
[06:48:17] <flyback> still
[06:48:19] <stephe_> ive seen this site in a lot of google queries
[06:48:30] <flyback> that's gotta be one of my favorite aspects of microcontrollers
[06:48:34] <flyback> power scaling
[06:48:47] <flyback> go down to a few hz
[06:48:49] <flyback> it runs like shit
[06:48:56] <LeoNerd> My ideal shape: 1) disassociate the peripheral lines from hardware pins; use a programmable crossbar matrix. 2) split the timer-counters apart from the PWM units. Route their signals via crossbar. 3) remove the baud timer from the UART, the bit timers from the SPI and I²C modules. Put those timers in the general "timer pool" and route them via crossbar.
[06:48:57] <flyback> but it will survive on low power for a while
[06:49:39] <LeoNerd> 4) Allow "burried connections" on the crossbar; peripherals linked to other periphs directly without needing an IO pin
[06:50:46] <LeoNerd> Suddenly portions of what are custom control bits in registers, now become just assignments on the crossbar
[06:50:55] <LeoNerd> Things like CTC, or the various ADC trigger modes
[06:51:23] <LeoNerd> I'm aware I'm starting to describe an FPGA here... but that's OK. I think the world is ready for more customisable chips
[06:52:08] <flyback> fpga are nice for some things
[06:52:10] <LeoNerd> It's less a ready-to-use MCU, and more a chip containing lots of MCU components and customisable fabric between them. But still much simpler than making yourself a true FPGA-based design, because all the actual peripheral units and the CPU core are real hard silicon
[06:52:14] <flyback> like a cpu that counts in 17's etc
[06:58:54] <cehteh> i always want a 80bit cpu
[06:59:43] <Lambda_Aurigae> bah.
[06:59:49] <Lambda_Aurigae> 1Kbit cpu with 1Kbit wide ram!
[07:01:51] <cehteh> 80 bit would be nice, 16 bit wide instructions, plus a float, 64bit int or 2x 32bit .. also long double in one register
[07:02:04] <LeoNerd> Hah...
[07:02:15] <LeoNerd> you know that 79 bits is sufficient for long double? There's a bit in them that's always 1
[07:03:00] <cehteh> depends on the platform
[07:03:59] <cehteh> anyway .. most often i avoid floats
[07:04:12] <LeoNerd> Definitely
[07:04:20] <LeoNerd> I've never needed one on AVR
[07:05:14] <cehteh> that for sure
[07:08:08] <Lambda_Aurigae> an avr that can execute from ram would be nice...
[07:08:18] <Lambda_Aurigae> guess I'll have to do that with an fpga someday.
[07:20:45] <cehteh> Lambda_Aurigae: that wont happen, avr architecture is all about execute from flash
[07:30:12] <vespakoen> So I have a much better setup now, I connected a bluetooth module to the "software serial pins" (digital 2 & 3) and made a simple arduino sketch that sends some bytes to it, which I can read from my android phone, so now I should be able to see when bytes are successfully sent to the serial device (the bluetooth chip)
[07:30:57] <vespakoen> I know I have the right pins setup now, so I think the issue I am having is timing related
[07:31:27] <vespakoen> I noticed the hardware serial uses this prescaler: BAUD_PRESCALER (((F_CPU / (BLUETOOTH_BAUDRATE * 16UL))) - 1)
[07:32:01] <vespakoen> but the software serial lib uses: SWUART_TIMEROP (F_CPU / SWUART_PRESCALE / SWUART_BAUD_RATE / 3) - 1
[07:32:21] <vespakoen> can anybody explain why they use a different approach here?
[08:05:49] <vespakoen> another question, does anyone know if there is a table that puts all the interrupt names of all avr chips next to each other? for easy translation from one chip to another?
[08:08:45] <RikusW> vespakoen: if you have atmel studio you can query the xml partdescription files directly
[08:08:54] <RikusW> even the old avr studio 4
[08:09:05] <vespakoen> I am running linux, as far as I know the studio is only for windows, right?
[08:09:11] <RikusW> yes
[08:09:25] <vespakoen> another question I had about that, does the studio include samples?
[08:09:31] <vespakoen> if so, can they be downloaded somewhere?
[08:09:55] <RikusW> You can download samples and appnotes from atmel.com
[08:10:10] <vespakoen> cool, will look around there
[08:11:41] <RikusW> vespakoen: https://sites.google.com/site/megau2s/home/supporting-software/RavrProg20111201.tbz?attredirects=0&d=1
[08:11:56] <vespakoen> aha, interesting
[08:12:00] <RikusW> I've extracted most of the relevant information using xslt
[08:12:29] <RikusW> I intended it as an avrdude replacement, its partly functional
[08:12:52] <RikusW> the fuse calculator works well, just select the avr and click the fuses tab
[08:13:05] <RikusW> you'll need Qt libs to compile
[08:13:11] <vespakoen> well, my make file is working pretty well (avr-gcc and avrdude), was just wondering if this studio might have some built in libraries (especially looking for software uart)
[08:13:20] <vespakoen> I see
[08:13:39] <RikusW> there are appnotes and software for soft uart on atmel.com
[08:14:04] <vespakoen> allright, guess I will have to bite the bullet and plow through that website (it's pretty huge =) )
[08:14:26] <RikusW> appnote AVR304
[08:15:06] <vespakoen> yeh I found those, but an actual implementation (in C preferably) is what I am looking for
[08:15:18] <vespakoen> and I actually found a bunch of implementations as well but I cannot get them to work
[08:15:20] <RikusW> and AVR305, AVR306 for hw uart, AVR307 for USI
[08:15:44] <RikusW> there should be a AVR304.zip with the source code
[08:15:58] <vespakoen> but that's pure assembly, right?
[08:16:44] <RikusW> http://www.atmel.com/Images/AVR304.zip
[08:17:07] <vespakoen> wauw, that's awesome =D
[08:17:20] <RikusW> I can't remember whether its C or asm
[08:17:42] <RikusW> http://www.atmel.com/Images/AVR305.zip
[08:17:44] <vespakoen> well, tere is a c file in there
[08:17:58] <vespakoen> 304 is the one i want I think (interrupt based)
[08:18:44] <RikusW> I have the Atmel 2005 lib cd, seems the contents is dumped into the images dir on the webserver :)
[08:20:57] <vespakoen> =D
[08:21:01] <LeoNerd> Atmel AVR notes tend to be both C and asm
[08:21:06] <LeoNerd> They often give two copies
[08:21:15] <vespakoen> it's useing some old school things in there, but I think I can convert that to newer style code
[08:21:26] <LeoNerd> I only tend to read them over for rough guidance, rather than actually /use/ them
[08:22:11] <vespakoen> yeah, I just want to see a character on my monitor and then I can take it from there
[08:22:20] <vespakoen> but as long as I am "in the dark" i don't have a lot to work with
[08:22:21] <LeoNerd> Mmm
[08:22:27] <LeoNerd> Ah you're doing this soft serial thing now?
[08:22:32] <vespakoen> yip
[08:22:44] <LeoNerd> It'll likely be end of the weekend before I get around to mine
[08:23:01] <vespakoen> cool, I'll report back here with my findings
[08:23:31] <vespakoen> well, actually, I think my findings will be useless to you as this is my first C project =P
[08:26:15] <vespakoen> haha, that c file blew up when I tried to compile it =P seems to be made for IAR, but it's nice to add it to my collection of software uart libs for comparison
[08:27:16] <vespakoen> actually, the asm implementation looks quite simple / readable: https://github.com/cdavidshaffer/Mon1/blob/master/software_uart/avr305.asm
[08:27:34] <vespakoen> is there a way to "wrap" that into some C calls?
[08:32:44] <RikusW> you could use inline asm
[08:32:57] <inflex> why not just use C instead of ASM?
[08:33:07] <RikusW> there are other ways to link asm and C though I've never tried
[08:33:14] <LeoNerd> Typically you arrange that the calling convention matches, write a prototype in a .h file, and just link it
[08:33:28] * RikusW just wrote it all in asm instead :-D
[08:33:33] <vespakoen> well, that would be ideal, but I think my knowledge of electronics (& the serial protocol) lacks to much
[08:33:43] <vespakoen> I guess I have to read up more on that first
[08:34:14] <LeoNerd> I prefer to write in C instead of asm because I recally can't be bothered to do my own register allocation in my head
[08:34:17] <LeoNerd> That's what gcc is for
[08:34:33] <vespakoen> yeh, cool to know that it is possible though
[08:44:02] <RikusW> LeoNerd: eventually I had to document the register use of each function in a 1500 line project ;)
[08:44:12] <LeoNerd> Yah see I wouldn't bother ;)
[08:44:32] <RikusW> its listed as parameter/return/changed
[08:44:33] <LeoNerd> Most of the code isn't fast/tight enough to need asm. If there are small bits that are, they can be inlined by the C compiler
[08:44:43] <LeoNerd> Even then, gcc will allocate registers
[08:45:11] <RikusW> AVR asm is so simple its nearly like coding in C :-P
[08:45:27] <LeoNerd> Yes but I still don't want to have to allocate registers myself
[08:45:43] <LeoNerd> Even really simple things like int d = a + (b * c >> 2); or whatever
[08:45:55] <LeoNerd> that is Decidedly Nontrivial to write in asm
[08:47:31] <vespakoen> so here is my new approach, I basically want to transmit a single char, here is what I go so far: http://hastebin.com/ufalomijeg.c
[08:48:04] <vespakoen> does anyone know the "high / low" combination for a char, and what timeouts I should use to get it on the 9600 baudrate?
[08:48:06] <LeoNerd> There's no timing delay in there
[08:48:20] <vespakoen> yeh, that's next up =)
[08:49:02] <RikusW> simply do char c = 'x'; and transmit c
[08:49:02] <LeoNerd> 9600 baud is a little awkward. But you'll be wanting 1sec / 9600 = 104.167µsec
[08:49:22] <LeoNerd> If your CPU is at 16MHz that's not an integer division
[08:49:22] <vespakoen> cool
[08:49:39] <LeoNerd> I'm intending to run my thing at 25kHz, because that -is- a neat division of 16MHz :)
[08:49:46] <vespakoen> so _delay_us(104); ? or 105, guess it doesn't support floats, right?
[08:50:04] <LeoNerd> Indeed it doesn't. 104 should be fine as you'll need a little extra time to process the other bits around it
[08:50:07] <vespakoen> I think my bluetooth chip wants 9600 (at mode)
[08:50:14] <vespakoen> cool
[08:50:22] <LeoNerd> Ohyes, in your situation the rate is fixed, so you'll just have to hit it
[08:50:37] <vespakoen> so now I just need the right sequence of high * lows for a character
[08:50:40] <LeoNerd> UART format is 1 start bit, n data bits, 1 stop bit
[08:51:01] <vespakoen> I guess a start bit, 8 bits (all 0 for a 0 maybe?) then a stop bit
[08:51:03] <LeoNerd> Line idles high; start is low; data is transmitted "as it is", LSB first; stop is high
[08:52:27] <vespakoen> so, could I make it low, wait 9 times the 104 us delay, then make it high for the stop bit?
[08:52:56] <LeoNerd> That would transmit a 0, sure
[08:53:01] <LeoNerd> Though harder to see if it worked
[08:53:28] <LeoNerd> 'U' is a useful byte to send, because it's 0x55 hex, which results in an alternating bit pattern
[08:53:38] <vespakoen> ah I see
[08:53:41] <vespakoen> let's give that a shot
[08:53:47] <LeoNerd> 0(start), 1, 0, 1, 0, 1, 0, 1, 0, 1(stop)
[08:54:05] <LeoNerd> Plus it's visible ASCII so easy to see on a terminal on the other end
[08:55:16] <vespakoen> http://hastebin.com/lujimiwega.c
[08:55:21] <vespakoen> no luck with it though
[08:56:19] <LeoNerd> How are you testing it? I'd be pointing my LA at it currently, to see if I got some sort of output.. maybe the baud rate is just wrong?
[08:56:33] <LeoNerd> 99% of UART problems are that :)
[08:57:18] <vespakoen> yeh I really think it's a timing issue, (I set the F_CPU compiler flag (to 160000...))
[08:57:40] <LeoNerd> I'm forever typoing that
[08:57:45] <vespakoen> I guess that's not a bad idea, although my logic analyzer needs windows =P
[08:57:50] <LeoNerd> At least twice now I've missed a zero and been an entire 10 times too slow
[08:57:50] <vespakoen> and I don't have that around at the moment
[08:57:54] <LeoNerd> Ah; try sigrok?
[08:57:59] <LeoNerd> I like sigrok. :)
[08:58:10] <vespakoen> could I analyze it with another arduino?
[08:58:21] <LeoNerd> http://sigrok.org/wiki/Supported_hardware#Logic_analyzers see if your device is listed here
[08:58:42] <LeoNerd> My cheap Saleae clone Justworks in this. Lovely
[08:58:43] <vespakoen> I got some cheap china remake, and I think I have to flash it's chip to make that work
[08:58:57] <vespakoen> hmmz, will check it out!
[08:59:59] <vespakoen> OHHH!!! I got UUUUUUU's on my terminal =D =D
[09:00:02] <LeoNerd> :)
[09:00:05] <LeoNerd> Progress
[09:00:09] <vespakoen> yeah!
[09:00:48] <vespakoen> only after wrapping the whole bit sending in a for (;;) so I guess I need some initial delay in there
[09:00:56] <LeoNerd> Yah
[09:01:11] <LeoNerd> You might find it useful to have a void send_bit(bool val); function to call from there
[09:01:14] <LeoNerd> which does the delay
[09:01:38] <vespakoen> right
[09:04:02] <LeoNerd> Then, in your for loop you want to do, 8 times: send_bit(the byte & 1); the byte >>= 1;
[09:04:51] <vespakoen> I did it like this: http://hastebin.com/bekizejubu.c
[09:05:06] <vespakoen> ohh I see
[09:05:45] <vespakoen> I am still trying to figure out why it doesn't work with a single "series of bits" and does work with the for loop around it
[09:05:56] <vespakoen> the initial delay (_delay_ms(1000)) didn't help there either
[09:06:11] <vespakoen> maybe I have to pull the line high "on start"
[09:07:43] <vespakoen> no luck =)
[09:08:16] <theBear> someone gotta tow that line ;-]
[09:10:56] <vespakoen> LeoNerd, I tried to write the thing you suggested but I guess I am doing it wrong =) http://hastebin.com/lonoliqoqi.c
[09:11:51] <LeoNerd> you might want to pause longer after the stop
[09:12:01] <vespakoen> cool
[09:12:03] <theBear> how you mean series of bits ? just single consecutive-lines like leo last described ? you bitbanging one assumes ? hmm, actually, how does your series of bits vs your for loop compare with the grabbing single bits outta your byte, and i am going somewhere with this, but not worth confusing matters if i'm way off
[09:12:06] <LeoNerd> Oh also, use uint8_t rather than char
[09:12:14] <LeoNerd> in case of "negative" values
[09:12:30] <theBear> and i assume from your sensible file extension you ain't using stupid-libs and c++ cos i got a theory for that too
[09:12:41] <theBear> LeoNerd, what is the t?
[09:13:55] <LeoNerd> <stdint.h>
[09:14:01] <theBear> also good practice to use int types for number values and char for char's i always felt, tho unless yer programming for a lotta different arch/envs it probly never an issue, noting the neg number 7+- or 8+ bits kinda deal
[09:14:08] <vespakoen> ok that works!
[09:14:57] <twnqx> i always use the aliasing to u8, s8, u16, s16, ...
[09:14:59] <cehteh> hurr
[09:15:39] <RikusW> twnqx: I like those as well
[09:16:00] <twnqx> the only problematic one is s128/u128. that's not really universal.
[09:17:49] <cehteh> apropos has anyone of you increment/decrement functions for 32 and 64 bit? .. gcc just calls the lib for x+1 that sux, its on my todo list but if anyone here has that already, possibly in asm i could use that
[09:18:07] <cehteh> (yeah i know, thats simple, but i am lazy)
[09:18:11] <twnqx> even for X++ / X--?
[09:18:19] <cehteh> looks like that
[09:19:35] <RikusW> cehteh: its simple, just add 1 and adc for remaining bytes
[09:20:03] <vespakoen> current state of affairs: http://hastebin.com/fibubapune.c
[09:20:05] <cehteh> i know
[09:20:18] <vespakoen> seems like the delay needs to be a multitude of 104 (which makes sense)
[09:20:42] <cehteh> could be a bit glitching this way
[09:21:00] <cehteh> also when using that in a real program you have to disable interrupts around that
[09:21:46] <vespakoen> yeah, I am approaching it "incrementally", at least I can print some stuff to it now, next up is making it a bit more stable (playing around), then move to a interrupt timer
[09:22:20] <LeoNerd> Well, I think less "move to" and more "fundamentally rewrite as" :)
[09:22:27] <vespakoen> =D haha ok
[09:23:12] <cehteh> twnqx: just checked it, for 16 and 32 bit it uses adc .. for 64 bit it calls the library
[09:23:26] <vespakoen> So how would one get an interrupt to be called every 104us ? or do we keep some kind of count and only execute when the count === something ?
[09:23:32] <LeoNerd> Use the timer module
[09:23:36] <LeoNerd> s/the/a/
[09:23:46] <LeoNerd> Pick one, arrange for some interrupt to be fired at that rate... put code in ISR for that
[09:24:04] <vespakoen> cool, will give that a shot
[09:24:12] <cehteh> there are plenty ways to do it better than using _delay --- and no much worse ways :D
[09:24:13] <LeoNerd> For simplicity you probably want to pick one of the timers that can do CTC and use that. I always find that easier than preseeding
[09:24:30] <LeoNerd> cehteh: asm("nop"); asm("nop"); asm("nop"); ...
[09:24:41] <cehteh> even that is sometimes superior
[09:25:02] <cehteh> no bias/setup cost, no loop and so on
[09:26:00] <cehteh> otherwise for a busy loop something while (TCNT < end); just works (mostly, its becoming bit more complicated sooner or later)
[09:26:45] <WormFood> [18:44:54] <cehteh> WormFood: 504 Host wormfood.net lookup failed: Permanent name server failure <-- I'm trying to work on it, but I can only connect to my server for a few minutes at a time.
[09:27:01] <vespakoen> Ok, going into the rabbit hole, will report back when I have something useful
[09:27:02] <cehteh> WormFood: where is your nameserver hosted?
[09:27:13] <WormFood> linode
[09:27:19] <cehteh> ok
[09:27:30] <WormFood> but my server is the master, they're all slaves. Never had a problem before now. Something weird is going on.
[09:27:38] <cehteh> i could offer you a secondary, but i guess that wont help much
[09:28:05] <cehteh> guessed so
[09:28:05] <WormFood> I need to track down where the actual problem is.
[09:28:21] <WormFood> And since my ISP blocks all DNS queries, except to their servers, it makes it a little tricky.
[09:28:23] <cehteh> changed anything?
[09:28:30] <WormFood> nope
[09:28:42] <WormFood> I can't login to my server to change anything.
[09:28:54] <cehteh> sounds like fun :D
[09:29:09] <cehteh> no ssh to the outside at all or only your server?
[09:31:11] <WormFood> It's very flaky. Sometimes works, most of the time now
[09:31:15] <WormFood> not*
[09:31:33] <WormFood> I'm running my ssh server on like a dozen different ports, and 2 different IPs...still spotty connections at best
[09:31:52] <WormFood> They know people use ssh to hide VPNs
[09:32:01] <vespakoen> this is where I am at: http://hastebin.com/ofipohulop.c
[09:32:13] <cehteh> i know some people who redirect *any* port on a given IP address to ssh :D
[09:32:15] <vespakoen> I guess the the timer is not configured correctly
[09:32:16] <WormFood> So, they fuck with SSH now. Even tho the traffic pattern should be obvious that I'm not using a vpn
[09:32:39] <cehteh> vespakoen: blink a led :D
[09:32:40] <vespakoen> and my way of sending a "test" bitstream, (010101010101 forever) is probably incorrect?
[09:32:51] <cehteh> yes you need start and stop bits
[09:32:51] <vespakoen> cehteh, good idea actually
[09:33:09] <cehteh> vespakoen: get a logic analyzer .. 15Eur saelae clone
[09:33:12] <vespakoen> cehteh, if I am correct, a stream of 0's and 1's should handle that?
[09:33:31] <LeoNerd> There has to be some line idle time after the stop bit
[09:33:32] <vespakoen> yeh, I will look into hooking up my logic analyzer later
[09:33:38] <cehteh> mhm yes it should but its really hard for the receiver to sync to it then
[09:33:40] <LeoNerd> Otherwise the receiver doesn't know where each bit stats
[09:33:41] <vespakoen> ahh you are right
[09:33:41] <LeoNerd> starts
[09:34:06] <cehteh> many people useing "U" which gives a 50% duty square wave
[09:34:11] <vespakoen> so something % 9 == 0 -> do nothing?
[09:34:36] <vespakoen> or 10 I guess
[09:34:43] <LeoNerd> https://en.wikipedia.org/wiki/Asynchronous_serial_communication might be worth a read too, as general introduction
[09:34:49] <cehteh> 8n9 :)
[09:35:02] <vespakoen> cool! thanks
[09:36:07] <rue_house> 9?
[09:36:21] <rue_house> why do you have 9 stop bits?
[09:36:27] <vespakoen> 9 stop bits?
[09:36:30] <cehteh> that was a joke
[09:36:37] <cehteh> *but* then you always get a sync
[09:36:39] <rue_house> oh good
[09:36:43] <rue_house> haha
[09:37:11] <vespakoen> when the day comes that I understand it ill come back in here and laugh =P
[09:37:18] <rue_house> are you having framing problems?
[09:37:43] <cehteh> can one do manchester coding over uart .. i think the start/stop bits are in the way or?
[09:38:50] <cehteh> vespakoen: http://public.pipapo.org/logic_analyzer.png .. helps a lot when one has a logic analyzer
[09:38:59] <rue_house> you would end up, best case, with a locked bit
[09:39:04] <rue_house> and half the baud rate
[09:39:28] <cehteh> 8n9 is half the baudrate
[09:39:29] <rue_house> tho
[09:39:44] <cehteh> manchester coding is a bit more compact or?
[09:40:01] <cehteh> anyway there are digital modulations which are
[09:40:04] <rue_house> no
[09:40:20] <cehteh> you dont need to sync each bit
[09:40:21] <RikusW> I once played audio over a 115k uart :-P
[09:40:32] <RikusW> sounded recocnizable
[09:40:39] <rue_house> the advantages of manchester are that you have a built in clock signal
[09:40:39] <LeoNerd> Mmm... deltasigma
[09:40:56] <cehteh> yes but you dont need a clock for evey bit
[09:41:08] <vespakoen> I just copy pasted some interrupt code from the net so I expect it not to work yet =)
[09:41:35] <vespakoen> looking for the right baud prescale and a way to send a stream of bits as simple as possible (using interrupts)
[09:42:00] <rue_house> if you use the i2c usart, I think you can do anything you want
[09:42:16] <cehteh> USI too
[09:42:26] <rue_house> heavy maintenance to keep it going tho
[09:42:30] <cehteh> yes
[09:42:41] <cehteh> but he playing with software serial :D
[09:43:05] <rue_house> mmm banging the bits
[09:43:22] <inflex> i like banging bits
[09:43:42] <vespakoen> I am trying to make sense of it all =P
[09:43:46] <vespakoen> so I do it step by step
[09:44:08] <vespakoen> (normally I just throw spaghetti at the wall and see what sticks and move on with my life) but in this case, that didn't work =)
[09:44:14] <rue_house> so do 9600 with nop delays
[09:45:06] <vespakoen> I am trying to use interrupts at the moment (or would that work with an interrupt as well?)
[09:46:04] <rue_house> nop nop nop sbs foo sbi bar cbi bar (cycle compensation) nop nop nop nop
[09:46:32] <vespakoen> but that wouln't work with my interrupt, would it?
[09:46:39] <rue_house> no
[09:46:53] <rue_house> if you have NO interrupts you can get better timing from the main loop
[09:47:03] <rue_house> one less cycle of jitter
[09:47:15] <vespakoen> which is what I am trying to achieve at the moment, I was able to send chars / string using a simple loop and delays
[09:47:32] <vespakoen> now trying the interrupt approach
[09:47:49] <LeoNerd> Hint: static variables in ISR
[09:48:08] <rue_house> you see, the avr needs to finish the instruction its on, and if thats a jump, branch, or return, it'll take two cycles, and so the interupt maybe be able to fire after the nect cycle, or have to wait one more
[09:48:43] <cehteh> input capture is nice for that
[09:48:52] <rue_house> what why main: jmp main is a bad loop to use for an interrupt driven system
[09:49:16] <cehteh> depends on your timing constraints
[09:49:19] <rue_house> main: nop nop nop jmp main will give better performance on average
[09:49:45] <rue_house> <-- old cycle counter
[09:50:17] <vespakoen> this was my approach: http://hastebin.com/figurubawi.c
[09:50:28] <vespakoen> but I think I have to setup the timer correctly before even trying to send anything
[09:50:29] <cehteh> vespakoen: anyway .. timer is certainly a good idea, interrupt for software serial, maybe optional
[09:50:52] <rue_house> I need to set up a serial library for the t13
[09:50:57] <cehteh> forget about the comparator
[09:51:10] <cehteh> just let the timer freely spin
[09:51:13] <LeoNerd> I forget which timer has the highest interrupt prio.
[09:51:16] <LeoNerd> 0 probably
[09:51:19] <cehteh> yes
[09:51:47] <vespakoen> cehteh, 1s and 0s all the way?
[09:52:05] <vespakoen> =no extra delay after the stop bit, correct?
[09:52:18] <cehteh> irrelevant
[09:53:24] <vespakoen> ok
[09:54:06] <LeoNerd> Hrmm.. I don't see in the datasheet where it talks about interrupt priority
[09:54:36] <LeoNerd> Oh I see.
[09:54:46] <LeoNerd> Huh.. it says lower address == higher priority
[09:55:09] <LeoNerd> At which point I make timer2 compA the highest priority timer interrupt
[09:55:18] <LeoNerd> Still lower than all the external ints, pcints, and wdt
[09:58:53] <cehteh> if interrupt driven i'd prefer input capture
[09:59:07] * theBear softly sings under his breath "at the compa, compa cabana"
[09:59:09] <cehteh> gives at least some relax with the timing
[09:59:36] <cehteh> (but not too much, since input capture triggers only on one edge)
[09:59:42] <theBear> i refuse to do any timing unless i can also relax a bit
[09:59:52] <vespakoen> timer whoes part deux: http://hastebin.com/umidowaraq.c
[10:00:00] <theBear> whose :)
[10:01:00] <cehteh> vespakoen: i dont understand for what you need the comparator .. replacing the _delays ?
[10:01:22] <vespakoen> the "lastOne" thingy?
[10:01:41] <vespakoen> the idea is that it will send a stream of 0101010101010's
[10:01:42] <cehteh> OCR0A
[10:01:44] <vespakoen> ohh
[10:01:51] <vespakoen> I am not sure at all
[10:01:59] <vespakoen> throwing spaghetti at the wall at this point =)
[10:02:23] <vespakoen> (copy paste job basically)
[10:02:43] <cehteh> well having a timer for the timing would be the first part .. making it interrupt driven another
[10:02:55] <vespakoen> I see
[10:02:56] <cehteh> (at least thats the way i see it)
[10:03:14] <vespakoen> is there some example somewhere to setup a "timer" on the atmega328p ?
[10:03:17] <cehteh> so start a timer, freely spinning, let it overrun at MAX
[10:03:25] <cehteh> plenty :D
[10:03:33] <vespakoen> haha, you are right, should use my google-fu
[10:03:46] <cehteh> well mine here is a bit too much for an example
[10:06:17] <cehteh> in the simplest way you just set the prescaler .. timer runs
[10:06:27] <cehteh> maybe reset the TCNT first to 0
[10:06:40] <vespakoen> ohh, so the way I read it now, I take a timer, set the prescaler that matches the baudrate most closely, then "sync it up" by adding some nop's ?
[10:06:51] <LeoNerd> nops won't help
[10:07:02] <vespakoen> oh I see
[10:07:14] <LeoNerd> If the prescaler doesn't exactly match (hint: it almost certainly won't), then you either need to preseed the counter, or use one of the CTC modes
[10:07:20] <cehteh> nops can help ..depending where you put them
[10:07:32] <LeoNerd> I prefer CTCs because they're neater, more reliable, and don't work in the backwards-inverted way that preseeding does
[10:08:06] <cehteh> halt whats the plan? bang a bit on each interrupt?
[10:08:11] <vespakoen> and how would a CTC mode help with this?
[10:08:19] <vespakoen> bit banging indeed =)
[10:08:28] <LeoNerd> It lets you arbitrarily set the repeat period of the counter
[10:08:36] <vespakoen> pretty neat
[10:08:47] <LeoNerd> In non-CTC modes, the counter just counts up until it overflows at 2^8, or 2^16 on the 16bit counters
[10:09:01] <LeoNerd> preseeding says on overflow, you write some number that is already above 0 in there, so it has less far to count
[10:09:13] <cehteh> ok that way will work *but* think about a short busy loop to match the timing
[10:09:22] <vespakoen> ahh, makes sense
[10:09:27] <LeoNerd> In CTC modes, the counter only counts up until a match of (either OCRA or ICP, depending on mode), and then resets
[10:09:45] <cehteh> since the interrupt most likely get triggerd a bit late
[10:09:48] <LeoNerd> I find that more direct, because you write in the number you want it to count to, and also you don't have to reset the counter in the overflow interrupt
[10:09:54] <cehteh> at least entering your code will be late
[10:10:01] <LeoNerd> cehteh: you're talking about latency. latency doesn't matter
[10:10:07] <LeoNerd> As long as the latency is _fixed_
[10:10:19] <cehteh> LeoNerd: i am talking about getting this fixed
[10:10:33] <cehteh> even when other interrupts may be enabled
[10:10:34] <LeoNerd> The /period/ of the counter must match the baud rate. The relative phase of the counter's interrupts vs. the transmitted bitstream is irrelevant
[10:10:46] <cehteh> yes thats clear
[10:10:51] <LeoNerd> nops inserted into the interrupt handler will not change the period; only the phase
[10:11:21] <cehteh> yes, not nops there .. while (TCNT < small_value); ....
[10:11:41] <LeoNerd> That's still phase adjustment
[10:11:44] <cehteh> then it doesnt matter if the interrupt gets called a bit off or not
[10:12:09] <cehteh> sure
[10:12:53] <cehteh> just enouh to make this latency constant in most cases
[10:13:26] * LeoNerd forgets if 328P timer2 has CTC
[10:13:31] <LeoNerd> If only I had my chart.... ;)
[10:14:23] <cehteh> makes me almost want to implement softserial for mµOS just to test it :D
[10:14:36] <LeoNerd> Do it :)
[10:14:44] <LeoNerd> Everyone can implement one, and we can compare the results :)
[10:14:46] <cehteh> will do
[10:14:52] <cehteh> its somewhere down the todo list
[10:15:13] <cehteh> other things are more important
[10:15:35] <cehteh> mhm softserial on the same pins as uart, disable uart, just for debugging
[10:19:27] <vespakoen> should be close now: http://hastebin.com/lajaxajule.c
[10:20:04] <vespakoen> guess the this line needs some work: TCCR1B |= (1 << CS11)|(1 << CS10);
[10:20:41] <LeoNerd> http://go.leonerd.org.uk/avr-timers there. I've started it
[10:20:45] <cehteh> thats just the prescaper
[10:20:53] <cehteh> prescaler
[10:21:07] <cehteh> if that is off you wont get nice results :D
[10:21:35] <cehteh> LeoNerd: hah so much data :D
[10:21:54] <cehteh> and i cant edit
[10:22:26] <vespakoen> yeh I am having a hard time figuring out.. how to figure out... how to get the right prescaler set, when my clock speed is 16mhz and I want a baudrate of 9600 or 104us delay in my "callback" if I may call it that
[10:22:42] <cehteh> can you make that public editable w/o google account?
[10:23:00] <LeoNerd> I'd prefer not. I'm going to fill in all the chips I regularly use, and then I'll accept suggestions on more
[10:23:06] <cehteh> lol
[10:23:15] <cehteh> too much fuss
[10:23:32] <cehteh> i could add some little bits i know, but nothing complete
[10:23:53] <LeoNerd> vespakoen: At 16MHz, a delay of 104us takes 16E6 * 104E-6 = 1664 counts
[10:24:04] <LeoNerd> vespakoen: So if you use a 16bit counter, you can use a prescale of 1 and count ot this exact number.
[10:24:15] <cehteh> tiny 13,25,45,85 have no ICP .. tiny 44 has ICP for example
[10:24:18] <vespakoen> cool
[10:24:19] <LeoNerd> Or you could prescale by 8 and count to 208, using either the 8 or a 16bit counter
[10:24:42] <cehteh> tiny 25,45,85 have the 64Mhz PLL for timer1
[10:25:11] <cehteh> have fun filling that in
[10:25:14] <LeoNerd> Yah
[10:25:24] <LeoNerd> I'll just add a new column. I am fully expecting to hve to add more columns for weirder chips
[10:26:50] <cehteh> is there any mega with a pll?
[10:31:05] <cehteh> also sometimes can the analog comparator selected as input comparator trigger, dunno if thats always the case
[10:31:37] <cehteh> and next are there more options in triggering than just either rising or falling edge?
[10:31:56] <cehteh> ^input capture
[10:41:34] <vespakoen> I am going to read up on timers outside in the sun
[10:41:44] <vespakoen> will catch you guys after the weekend to let you know how it went ;)
[10:41:55] <vespakoen> (or tomorrow maybe)
[10:42:02] <vespakoen> have a nice day all! thanks so much for the help!
[10:44:30] <WormFood> [18:44:54] <cehteh> WormFood: 504 Host wormfood.net lookup failed: Permanent name server failure <-- try it now.
[10:47:11] <cehteh> WormFood: nope
[10:47:22] <cehteh> but could be my cache
[10:47:40] <cehteh> http://dnscheck.iis.se/ << try that
[10:52:33] <cehteh> WormFood: shitload of brokenness
[10:58:21] <LeoNerd> Ohdeargod the ATmega128A's timers are weird
[10:58:34] <LeoNerd> /every/ other AVR chip I've seen has an identical timer0.. but not this chip
[10:59:15] <cehteh> also add the 328PB i expect we'll see it often soon
[10:59:41] <LeoNerd> Ohman yes I should.. that's huuuge
[11:09:08] <LeoNerd> Done
[11:09:42] <LeoNerd> four tinies, four megas. Basically, every chip that I use (or at least have in my physical posession and so might use)
[11:10:06] <LeoNerd> Oh.. well, I own some tiny2313s but I have no plan what to do with those. They're ancient and tiny and have hardly any periphs
[11:10:13] <LeoNerd> Though, they do have a real UART; unusual for a tiny chip
[11:14:11] <cehteh> they are frequently used
[11:14:57] <WormFood> I just stumbled across a random comment on some website, that said microchip tried to buy atmel like 8 years ago.
[11:17:21] <WormFood> LeoNerd, I have some of the original at90s2313 back in usa. They're very handy for some things.
[11:17:31] <WormFood> That uart is handy
[11:19:33] <LeoNerd> Hmm.. SPI, UART, AC; .. wow. one of the timers has literally no output compare pins
[11:20:31] <LeoNerd> Well anyhow. I think this chart is sufficient for my purposes; I'll take suggestions from anyone on more chips or more columns to add
[11:20:48] <LeoNerd> I might pop the tiny1634 in sometime actually.. I plan to use that soon
[11:21:00] <cehteh> ask Jartza about the tiny6 :)
[11:21:21] <LeoNerd> Fairly standard.. typical timer0 and timer1
[11:21:56] <cehteh> which one was the avr with pwm on every pin?
[11:23:08] <LeoNerd> I might have to start inventing version names for the standard timer units... so as to distinguish differences
[11:25:16] <cehteh> (ok tiny6 possibly has pwm on every pin, it has only 4 I/Os)
[11:25:20] <LeoNerd> Hehe
[11:25:31] <cehteh> but there was some bigger one with a lot pwm
[11:25:49] <LeoNerd> RikusW: You usually have useful things to say... any particular input on my chart?
[11:28:48] <stephe_> hmm, what debounce technique do you guys prefer?
[11:29:00] <LeoNerd> I usually go for timers
[11:29:08] <cehteh> depends
[11:29:16] <stephe_> but what do you do in the timer?
[11:29:17] <LeoNerd> (PC)INT triggers a delayed start of my button(?) handling task.
[11:29:32] <LeoNerd> After that timeout, I read the state of the pin, and compare it to what I read last time
[11:29:35] <cehteh> thats the correct and elaporate way
[11:29:40] <twnqx> deboucne is for whimps.
[11:29:43] <LeoNerd> So effectively I'm implementing the pinchange algorithm a second time
[11:29:46] <twnqx> \o/(
[11:30:14] <LeoNerd> Let me find you an example...
[11:31:30] <LeoNerd> http://pastie.org/10807055 <== my buttons are on PORTC, which is PCINT1
[11:31:38] <cehteh> button to ground, enable internal pullup and capacitor parallel to the button
[11:31:52] <LeoNerd> Mm.. you could do that too.. solve it in a purely analog way
[11:32:00] <cehteh> ah resistor to limit discharge current
[11:32:07] <LeoNerd> I usually find I have much spare flash, whereas I want to keep the physical board small
[11:32:21] <cehteh> yes, i usually do it in software too
[11:32:22] <LeoNerd> Also if I'm making lots of these I prefer to keep the BOM down.. writing more code doesn't cost extra per-unit
[11:32:46] <LeoNerd> This box has 6 buttons. So I don't fancy soldering 6 caps and 6 resistors * 10 boards ...
[11:32:50] <cehteh> even delay(1ms), read again is ok in many cases (while ugly)
[11:33:15] <LeoNerd> Hah
[11:33:29] * LeoNerd <== happens to be the author of one of the nonblocking/async events frameworks for Perl...
[11:33:37] <LeoNerd> You won't find a blocking delay in any of /my/ AVR code :)
[11:33:41] <cehteh> another thing, we scoped some buttons and most didnt bounce :D
[11:33:50] <LeoNerd> Yah.. sometimes you get lucky
[11:33:59] <cehteh> yeah i am going for no delays in mµOS either
[11:34:01] <LeoNerd> My buttons are these huuuuuge 40mm arcade machine buttons
[11:34:18] <LeoNerd> They bounce around like nothing else alive. Sometimes I can get 3 or 4 PCINT firings out of that
[11:34:35] <cehteh> but i have a very small busy loop ... this while(TCNT<something); thing
[11:34:56] <LeoNerd> Oh another advantage of my technique with the alarms is that while the button state keeps bouncing, it just keeps resetting the alarm time
[11:35:06] <cehteh> usually i schedule wakeups with compare-match, but if the time is to short to schedule a compare match, i go into that busy loop
[11:35:07] <LeoNerd> Only after it's settled down does it eventually check the state
[11:35:16] <bss36504> LeoNerd: " writing more code doesn't cost extra per-unit " well, only if your time costs nothing :-)
[11:35:26] <LeoNerd> bss36504: per /unit/
[11:35:38] <LeoNerd> Writing extra code costs me the same time if I'm making 1 unit or a thousand
[11:35:48] <LeoNerd> But soldering extra caps on costs me more for a thousand units
[11:36:12] <cehteh> you dont give every unit a personal touch by coding a unique easter egg for each one?
[11:36:30] <LeoNerd> Well.. OK strictly speaking, avrdude might take a few extra msec to burn my extra debounce code onto the chips... but that's peanuts :)
[11:37:07] <cehteh> on another note: you payed for every bit in that flash
[11:37:13] <cehteh> would be a waste not to use it
[11:37:18] <LeoNerd> Yah.. but if it's going spare *anyway*
[11:37:20] <LeoNerd> hehe.. exactly
[11:37:49] <cehteh> now caclulate the ecological footprint of unused bits
[11:38:14] <stephe_> LeoNerd: is this some kind of custom framework youre using? ALARM_SET, Task stuff
[11:40:51] <RikusW> LeoNerd: I wonder whether the chart can in whole or in part be generated from the xml files that comes with studio
[11:41:09] <RikusW> I used xslt in the past to get a great deal of stuff from it
[11:41:13] <cehteh> http://www.spiegel.de/politik/deutschland/hohenfels-gelaendewagen-fallen-ungebremst-aus-flugzeug-a-1088464.html LAWL
[11:41:24] <cehteh> humvee drop with failing parachute
[11:41:26] * RikusW was AFK
[11:41:58] <LeoNerd> stephe_: Oh.. ish. It's my usual collection of code. I can add that in too; one moment.
[11:42:05] <LeoNerd> RikusW: Hmmmmmyes.. maybe
[11:48:09] <LeoNerd> stephe_: http://pastie.org/10807088 now with the alarm stuff
[11:51:01] <stephe_> LeoNerd: ahh, makes more sense now :)
[11:51:24] <LeoNerd> I can't easily extract the underlying task loop into this .c file because that comes from other places...
[11:51:46] <LeoNerd> But basically it's just a "while(1) { sleep waiting for interrupts; execute all the scheduled tasks; }"
[11:51:53] <LeoNerd> most interrupt handlers just schedule tasks
[11:55:34] <cehteh> sounds familar :D
[12:09:18] <Shavik> So I have two variables that I store in EEPROM, Valid FW CRC (16 bit) and a device type (8 bit). I use EEMEM for both but I was curious as to whether the bootloader I'm writing will use same locations. Since the compiler? will assign eeprom addresses how do I know that DeviceType EEMEM address will be the same in my bootloader as in my application code?
[12:09:42] <stephe_> LeoNerd: its best to keep the button handling part quite simple though right?
[12:09:55] <LeoNerd> stephe_: Well, it's best to keep anything simple. :)
[12:13:55] <stephe_> LeoNerd: im wondering if it's better to just do just the debouncing in the interrupt and handle the buttons in the main loop, or do both in the interrupt :)
[12:15:39] <Shavik> Ah, I always forget that forgetting an ISR causes a "reboot"
[12:17:37] <LeoNerd> stephe_: debounce requires waiting. waiting would be bad. at least, bad for me
[12:17:43] <LeoNerd> I didn't want to delay handling of my LEDs, for example
[12:18:21] <Lambda_Aurigae> Shavik, for eeprom storage like that I just write directly to a memory location of my own choosing.
[12:18:36] <stephe_> LeoNerd: true
[12:19:10] <stephe_> LeoNerd: so you handle your leds in the mainloop or are they also one of the tasks?
[12:19:20] <LeoNerd> Everything is a task
[12:19:40] <LeoNerd> Well, actually LED management is just a matter of twiddling some dedicated in-memory bits, and plain port writes, so that is done in the timer ISR itself
[12:19:50] <LeoNerd> But most of everything else is a task :)
[12:20:59] <stephe_> do the other tasks use the same kind of Alarm structure?
[12:21:14] <LeoNerd> Most of them aren't alarmed
[12:21:31] <LeoNerd> These alarms are just delays on task_schedule
[12:22:07] <Shavik> Lambda_Aurigae, I did see clawson's post about for bootloader purposes he uses the end of the eeprom but currently, I'm ONLY using the EEPROM for bootloader purposes. I thought my reset loop was because somehow an EEPROM value I was reading was crossing variable boundries or something but after adding in my two missing ISRs (Just did some refactoring between static libraries for targeting multiple devices) it all works now :)
[12:22:33] <Jartza> evening
[12:22:42] <Lambda_Aurigae> morning Jartza
[12:22:50] <Lambda_Aurigae> and, later...I gotta get back to worky.
[12:23:01] <Shavik> Writing this bootloader for a total 10 different devices that share 5 different PCB's
[12:23:07] <Shavik> all 324PA and one 328P
[12:23:53] <stephe_> LeoNerd: i see
[12:25:42] <WormFood> I've narrowed down the smallest piece of code I can get to exhibit this problem of the ATmega88 not enabling interrupts.
[12:37:07] <WormFood> But the odd thing is, if I'm running from application memory, and enable the bootloader interrupt table, and enable interrupts, it quits working. If running from the bootloader section, and I move the interrupt table to bootloader memory, and enable interrupts, it doesn't work.
[12:37:40] <WormFood> so, no matter if I move the interrupt table or not, if I boot from the bootloader, interrupts don't fuckin' work, at all.
[12:45:44] <theBear> don't think of it as waiting, think of it as re-checking
[12:45:58] <theBear> what the ? woops, i musta been a bit scroled up
[12:47:31] <theBear> the umm, there is seperate memory for bootloader and normal now ? wait, you mean ram i assume ?
[13:21:18] <WormFood> theBear, yes, but it's flash memory
[13:21:49] <WormFood> When the proper fuses are enabled, there is a boot loader area that is created. The size of it, depends on the fuses.
[13:22:09] <WormFood> The BOOTRST fuse, will cause the AVR to boot into that address.
[13:24:11] <WormFood> Hmmm, I didn't realize the pinout of the at90s8515 is the same as the 8051
[13:28:13] <eszett> BOOTRST has the disadvantage that it even resets when you have a power cycle
[13:30:25] <WormFood> huh
[13:30:27] <WormFood> ?
[13:30:37] <WormFood> what do you mean it resets?
[13:32:04] <eszett> well the AVR goes into bootloader mode
[13:34:05] <theBear> the umm, i don't think flash can reasonably be called ram in any situation really
[13:34:29] <theBear> 8515 wow, i ain't seen one of them for a few years
[13:37:38] <RikusW> eszett: you simply put some code in the bootloader to check whether it should go to the app or bootloader
[13:37:56] <RikusW> eg: some pin is high or low
[13:38:38] <RikusW> or the arduino way, timeout if no valid commands are received
[13:39:27] <RikusW> so its not a disadvantage, its a foolproof way to prevent bricking
[13:41:55] <WormFood> [02:06:13] <eszett> well the AVR goes into bootloader mode <-- that's the entire idea of a bootloader. If it didn't boot to the bootloader, it wouldn't be much of a bootloader at all then.
[13:43:55] <eszett> yes
[13:44:31] <WormFood> When you have a reset, you want the bootloader code to run.
[13:47:47] <eszett> the thing is, i want to have access to the bootloader mode, without using the HWBE pin. BOOTRST is an alternative. And I dont like it jumping to the bootloader code after a power-reset
[13:48:26] <eszett> a solution would be to start the app code from bootloader mode
[13:48:41] <WormFood> If you don't want it jumping to the bootloader code on startup/reset, then simply don't program that fuse.
[13:50:39] <eszett> WormFood: my keyboards are sold to people without electronic knowledge. they want to upload their own firmware (app code). So i think about giving them a simple method to access the bootloader mode..
[13:51:21] <eszett> a reset pushbutton is possible but not the most simple method.
[13:51:54] <RikusW> holding down hwbe while powering on will do the trick
[13:52:01] <WormFood> That's a great idea...until your app code gets hosed. Then you're fucked, and you can't even use the bootloader at all then.
[13:52:35] <RikusW> that can be used as a last resort if flashing fails...
[13:52:47] <eszett> its difficult... @RikusW sure, but not user friendly method
[13:52:48] <RikusW> so the app code can jump to the bootloader
[13:53:25] <RikusW> it would be as simple as holding down a button while plugging in the keyboard
[13:53:51] <eszett> my idea is to activate BOOTRST, and after a power cycle the keyboard is in bootloader mode. Then, if "any" key is pressed it jumps to app code. if not it stays in Bootloader mode.
[13:54:11] <WormFood> I think this sums it up best...“I simply do not see the point of a bootloader without BOOTRST being used. My opinion is that a bootloader is a piece of code that you write once and is the ONLY piece of code in the entire system that must be proven faultless on day one (especially because it’s difficult/impossible to update the bootloader in an AVR). You program it into the AVR once using ISP at which time you also program the fuses for clocks and
[13:54:12] <WormFood> so on. At the same time you also program the protection bits so that nothing can ever change the bootloader and you program BOOTRST. You now have an AVR that always starts into the immutable bootloader and it doesn’t matter what happens in the app section as you have something safely stored in NRWW that can always dig you out of a hole.”
[13:54:58] <eszett> ok..
[13:55:31] <eszett> but how do you jump from bootloader mode to app mode?
[13:55:43] <RikusW> jmp 0
[13:56:09] <RikusW> the other way round jmp boot section address
[13:56:26] <WormFood> yeah, jmp 0000
[13:56:28] <RikusW> you might need to disable usb beforehand
[13:56:32] <eszett> i mean practically, by a naive user? I guess have to write my own bootloader code with "jmp 0" on a certain condition, e.g. if any key is pressed..
[13:56:40] <WormFood> asm("jmp 0000");
[13:57:05] <RikusW> eszett: which AVR will you be using ?
[13:57:10] <eszett> Atmega32U4
[13:57:33] <RikusW> 32u4 got a builtin FLIP bootloader
[13:57:54] <eszett> RikusW you mean delivered with bootloader from factory?
[13:57:58] <RikusW> yes
[13:58:09] <eszett> that was in the past, yes. but my ones were empty
[13:58:24] <eszett> Atmel was bought my another company
[13:58:33] <RikusW> you can still get the FLIP fw
[13:59:27] <eszett> RikusW i flashed my Atmegas with the official bootloader from atmel i downloaded from their website. ok. but how can i jump to app code when im in bootloader mode?
[14:00:06] <RikusW> for the FLIP code you need the PC sw to send the command to do it
[14:00:15] <RikusW> so you'll need to use HWBE
[14:00:22] <eszett> hmm yes
[14:00:56] <eszett> and my original plan was to avoid using HWBE :-)
[14:01:16] <RikusW> you can still do it
[14:01:31] <RikusW> just jump to the bootloader from app code
[14:01:52] <RikusW> then you'll need to power cycle to get back to the app code, or use the FLIP sw
[14:02:28] <eszett> "sw" = ?
[14:02:34] <RikusW> software
[14:02:37] <eszett> ahh, right
[14:02:43] <RikusW> fw = firmware, hw =....
[14:02:58] * eszett is thinking..
[14:03:44] <Strangework> ... headwear
[14:03:58] <RikusW> some unusual key combination can be used to activate the bootloader
[14:04:13] <RikusW> maybe in combination with a button underneath the keyboard
[14:05:00] <WormFood> make is so the keyboard accepts the application. Then you can just instruct the user to type in everything ;)
[14:05:01] <eszett> RikusW this sounds pretty good. but there is one downside isnt it? When the app code crashes its not that easy to enter bootloader mode anymore?
[14:05:38] <RikusW> use hwbe, it can be used to enter the bootloader as well from app code
[14:05:38] <WormFood> That's what I said. If the application programming get interrupted, and you can't enter bootloader mode, then you're fucked. You'd have to use an ISP to reprogram it.
[14:05:39] <eszett> e.g. someone flashes with a faulty firmware (app code)
[14:06:02] <eszett> WormFood: exactly
[14:06:30] <WormFood> The whole idea of a bootloader is being able to dig yourself out of a hole.
[14:06:38] <eszett> now i see why a reset-pushbutton in combination with HWBE pulled down to GND, is the preferred method used on custom keyboards
[14:06:48] <RikusW> so pressing the hwbe switch while plugging in the keyboard jumps to bootloader mode, or pressing the hwbe switch with another key in app code
[14:07:11] <RikusW> should be foolproof
[14:07:44] * eszett is thinking again ... oO((ooooOOOo)oo
[14:07:59] <RikusW> returning to app code would require a power cycle or command from the PC
[14:08:04] <WormFood> You can make it foolproof, but you can't make it idiotproof
[14:08:13] <eszett> hrhr
[14:08:35] <RikusW> the power cycle would only be a last resort
[14:08:41] <eszett> RikusW returning to app code is no problem as Atmel FLIP does it
[14:08:54] <RikusW> IF you have the FLIP sw
[14:08:59] <eszett> anyone can download and use Atmel Flip
[14:08:59] <WormFood> You want to boot into the bootloader first, and if some condition isn't met (a switch or something), then jump to application mode. The only issue I see with using the bootloader, is you have to make sure you initialize all your hardware properly (which you should be doing anyways)
[14:09:52] <WormFood> Does anyone have an ATmega88, they'd be willing to test my code with, and see if you get the same thing I do?
[14:10:20] <eszett> WormFood, no Atmega88 here
[14:10:31] <LeoNerd> I /have/ a mega88 but only in QFN form, which I have yet to successfully solder to a board ;)
[14:10:56] <WormFood> 4 tests. application mode, with interrupts. Application mode with interrupts. Bootloader mode, with and without interrupts. Everything works, except for interrupts in bootloader mode.
[14:11:26] <WormFood> and, in application mode, if I move the interrupts to the bootloader, it won't work. so it seems it is moving the interrupts.
[14:12:08] <LeoNerd> I have plenty of 328s though
[14:14:21] <RikusW> WormFood: do you have any lockbits set ? those can mess up interrupts
[14:22:42] <liwakura> god
[14:22:46] <liwakura> i think i burned my retina
[14:22:53] <liwakura> ws2812 are so fucking bright
[14:24:24] <LeoNerd> Mmmmyah
[14:24:37] <liwakura> i feel like lighting a bacon for gondor
[14:24:44] <LeoNerd> LEDs are small area, so much flux density for a given light output
[14:24:59] <LeoNerd> I usually put some sort of diffuser over them
[14:27:34] <WormFood> RikusW, yes. I have all my fuse and lock bits, set as I understand they should be set. I have no restrictions on them.
[14:29:05] <cehteh> the problem might be that you are in china, in reality you got a 8051 with some emulator on it to behave like a avr
[14:29:27] <cehteh> someone there found a way to got 1 cent profit by doing so
[14:35:43] <theBear> is this a continuation of a mental discussion some weeks back involving bootloaders and encryption and stuff, cos it feels frighteningly similar.... and before i disappear, if i bought a keyboard and it ignored the first key i pressed, i'd be asking for my money back
[14:36:37] <cehteh> nope
[14:36:49] <cehteh> that was nicohood
[14:37:09] <theBear> ooh, last word, i'm in china ? i don't think that's athe problem, but err, how would i check ? it's dark outside so looking fer i dunno, upside down trees or something ain't gonna worm
[14:37:10] <theBear> work
[14:37:32] <theBear> both of those, worm or work
[15:37:18] <WormFood> theBear, he was referring to my AVR problems.
[16:32:59] <vespakoen> Hey guys, I am back
[16:33:43] <vespakoen> read about the timers, all makes sense now, however, my implementation doesn't seem to work (made it flash a led, that works, so I guess it's a timing issue).
[16:34:18] <vespakoen> (I am trying to implement software serial for the atmega328p / bit banging)
[16:34:30] <vespakoen> http://hastebin.com/johajujaye.c
[16:35:01] <vespakoen> I tried without prescaler and with a prescaler, no luck with both though (trying to get the timer to run every 104us)
[16:51:45] <vespakoen> here is the latest variant, where I put the "sei()" and "while(1);" calls back in, without it I didn't get a flashing led: http://hastebin.com/tarerusipu.c
[16:52:08] <vespakoen> thing I note here, when I use the 1:8 prescaler, the led flashes visibly slower as to when I use no prescaler
[16:52:26] <vespakoen> but in theory they should run at the same rates, so something is off here, just not sure what
[17:23:14] <WormFood> What happens when an AVR reaches the end of it's address space? Does it wrap around to address 0?
[17:23:57] <theBear> that's what almost everything ever does, but while i had this conversation before i don't remember anyone ever getting aorund to checking
[17:24:16] <WormFood> Some CPUs halt at the end of their address space.
[17:24:56] <WormFood> I remember, that was one of the original xbox hacks. They originally designed it for an AMD CPU, which halts at the end of the address space, but ended up using an Intel CPU, which wraps around (IIRC)
[17:26:51] <WormFood> What does opcode FFFF decode into?
[17:28:43] <WormFood> in other words, if I try to execute blank flash, what will happen?
[17:37:45] <theBear> didn't we agree a couple days ago that noone ever learned intel since about the earliest time of 286 machines, or perhaps right thru up to when mmx stuff started coming in, and the opcode count just got waaaaaaay outta hand
[17:39:06] <theBear> and i'm tempted to say i can't even imagine up an opcode function i never heard of before that would do more than a handful of reps like that before it things just got all silly and jammed or spinning or something the would be far from interesting
[17:40:03] <theBear> crazy amd .. a cpu ain't sposed to do that kinda thing, that's thinking for itself :)
[17:40:32] <theBear> on reflection tho, that's kinda what microcode on remotely modern x86/64 cpus can do/is for innit
[17:41:46] <Casper> WormFood: avr will roll over afaik, and FFFF is a nop
[17:48:32] <WormFood> That's that I thought. because no matter how I have the bootloader programmed, and where my code is, it always executes.
[17:50:28] <WormFood> How can I be positive that my AVR's reset is actually taking me to the application or bootloader section of the flashrom? If it's not programmed, it will just NOP it's way to actual code.
[18:03:27] <theBear> the huh ? make at least one show some kinda unique signal, actually i suspect that's kinda standard practice... just thought about the only one i got wiht a bootloader (only fancy or remotely modern avr i got, native usb and all.) and that's fancy, does from memory a kinda rapid led fade repeatmaybe5seconds[up,down] while bootloader doing the bootloader thing, then if it gets to the end of that, hmm, i was gonna say turns on some other colour led (little
[18:03:28] <theBear> tricolour tiny thing comes stock with the board that matches that bootloader,) but now thinking about it, i pretty sure it just turns the led off and basically leaves everything like a fresh boot for the main program to run
[18:03:49] <theBear> i shoulda just plugged it in anc checked, woulda been done quikcer than that explanationery
[19:30:17] <LeoNerd> Mm.. success :) I just made myself a pair of custom BNC-BNC patch cables...
[19:30:41] <LeoNerd> Heatshrunk nicely together to hold them as a pair, and with coloured markings on. I might have to sell these along with my current probe
[20:54:29] <theBear> oooh, i was gonna beg to differ (gently) but with pretty colours and stuck into a pretty pair, i'll go with custom
[20:56:18] <theBear> and eff selling them ! just now, well even while i type, i'm using a kickass little similar pair with nana plug ends that i made wow, almost 20 years ago at my first job, jeez i'm gettin old, but it's so awesome and pretty and noone else anywhere got one the same, tho likely some fairly similar ones, but man, you'd be paying close to i dunno, what a small house costs before you would get me to sell it
[20:56:54] <theBear> and yes, i DO have a price these days, but when i don't wanna sell i gonna make it hurt the buyer more than it hurts me :)
[20:58:54] <LeoNerd> Eh.. *shrug* it's only a BNC patch cable. Didn't take me long to make. I think they'd sell quite well alongside my current probes.. given those have two BNC sockets on and you probably want to hook it up to a 'scope anyway
[20:59:41] <LeoNerd> RG174, straight plug one end, RA plug the other. So it fits on the scope better at that end, on the bench