Back
[06:38:14] <Jartza> wow
[06:38:21] <Jartza> that oled display is nice looking
[06:38:24] <Jartza> even on bright daylight
[06:38:25] <Jartza> https://www.dropbox.com/s/0whgsf6ne1qg32f/20140804_001.jpg
[06:39:47] <CoolBear> Oooh, shiny!
[06:41:40] <Jartza> yes
[06:42:04] <Jartza> and few thing that sets that 16x2 oled apart from other 16x2 alphanumeric lcd displays
[06:42:17] <Jartza> smooth fade (and blink if one wants)
[06:42:23] <Jartza> pixel-level horizontal scroll
[06:42:42] <Jartza> most of the 16x2 alphanumeric displays only scroll char-by-char, not pixel-by-pixel
[06:42:54] <Valen> that is pretty damn bright and awesome looking
[06:43:14] <Valen> standard libs work for it?
[06:43:23] <Jartza> yup, just watched that in sunlight and it was really really readable
[06:43:36] <Jartza> well, almost yes, it's quite compatible, except i2c
[06:43:54] <Jartza> initializations are a bit different and of course those extra features need to be added to lib
[06:44:01] <Jartza> although, I'm using my own lcd-lib anyways
[06:44:19] <Jartza> which now supports 3 different types and either i2c or spi
[06:44:50] <Jartza> st7032, st7036 and US2066 (basically st7036 + extended commands)
[06:45:08] <Jartza> and oh, almost forgot
[06:45:09] <Jartza> http://www.buydisplay.com/default/i2c-16x2-oled-serial-character-display-module-screen-yellow-on-black
[06:45:12] <Jartza> that's the display
[06:45:15] <Jartza> also 20x2 available
[06:46:13] <Jartza> if one wants to use it with i2c, there's 3 "jumpers", or 0 ohm resistors actually, that need to be modified a bit
[06:46:20] <Jartza> by default that was in parallel-mode
[06:46:50] <Jartza> I guess when ordering, one could also ask it they can mod it at factory
[06:47:51] <Jartza> that has a power booster included in the board, but one can also order without pcb and cook their own
[06:47:59] <Jartza> http://www.buydisplay.com/default/oled-character-16x2-display-module-yellow-on-black-i2c-serial-us2066
[06:48:03] <Jartza> same display without pcb
[06:49:28] <Jartza> but without pcb the oled requires 12 volts (and 3.3v for controller)
[07:57:04] <dunz0r> /win 25
[07:57:07] <dunz0r> Gah.
[08:32:24] <Jartza> /lose 42
[08:53:01] <sabesto> anyone seen an AVR RFID Bootloader?
[08:53:38] <sabesto> using "Dynamic memory" which means RFID and I2C/SPI interface
[09:30:52] <Getty> sabesto: you mean like it loads its bootsector via RFID?
[10:01:28] <sabesto> Getty: being able to flash progmem from RFID tag contents
[10:01:48] <Getty> ah ok
[10:01:55] <Getty> i am new to this stuff ;) just asking hehe
[10:02:02] <sabesto> basicly i need a non-contact way of flashing an AVR
[10:02:44] <sabesto> should be simple enough, but the biggest chip ive found is only 8kB, which makes it a bit more complex
[10:03:13] <Getty> i tried to find a cheap way to connect an AVR to ethernet, was also very disappointing
[10:06:47] <sabesto> ethernet is a bit overkill for an atmega
[10:10:27] <Jartza> hmmh
[10:10:40] <Jartza> that OLED display is nice... there's only one "but..."
[10:10:46] <Jartza> it sucks helluva lot of current
[10:11:15] <Jartza> I measured >50mA @3.3V
[10:12:11] <CoolBear> Yeah, probably not the best choice for a portable device.
[10:13:00] <Jartza> shouldn't oleds be "energy efficient"?
[10:18:24] <CoolBear> Cheap OLEDs are probably not, while an LCD will use power constantly(backlight is always on), the OLED is individual lights, so if the display is black it's using less power.
[10:33:55] <The_Coolest> Also, OLEDs don't have ghosting problems.
[10:34:00] <The_Coolest> Very fast response time
[10:39:34] <Getty> sabesto: reality bites if you want to connect "thing" with other "thing", but yeah in the end its always more practical to just attach a raspberry and do the stuff there
[10:49:08] <Jartza> yeah, the response is fast
[10:49:19] <Jartza> and I like the ability to do pixel-by-pixel -scrolling
[11:01:54] <Jartza> although I'd like to have a display that would run >15 hours with one aaa
[11:01:59] <Jartza> I guess this oled isn't it
[11:43:12] <twnqx> :X
[11:43:29] <twnqx> if avrdude only reads 2044 bytes from an atmeg8 something is wrong, right? :X
[13:15:24] <malinus> e
[13:19:22] <rue_shop2> not neccissarily
[13:52:33] <Jartza> gnnh
[13:52:46] <Jartza> ok, basic printing works just like "standard" 16x2 lcd
[13:52:51] <Jartza> but all the other features do not
[13:53:10] <Jartza> I guess I need to modify the lib, but datasheet is a bit vague again
[13:56:20] <CoolBear> Cheap chinese engrish manual?
[13:56:33] <RikusW> chinglish ;)
[13:57:21] <Jartza> yep
[14:08:40] <Jartza> I understand that much that after sending the device address + write -bit to i2c, I need to send one byte, where there is actually only 2 bits used
[14:08:48] <Jartza> other is "co" and the other "d/c"
[14:09:28] <Jartza> the "d/c" bit is also quite clear, if it's one, then following bytes are data, if it's zero, command byte follows
[14:10:30] <Jartza> "If the Co bit is set as logic 0, the transmission of the following information will contain data bytes only."
[14:10:39] <Jartza> like wut :)
[14:16:00] <Jartza> so, when sending data, the next byte should be "0x40" and when sending command it should be "0x80"?
[14:16:06] <Jartza> or did I understand something :)
[14:16:12] <Jartza> or mis-understand
[14:16:14] <Jartza> guh
[14:17:44] <Thrashbarg> Jartza:
https://www.youtube.com/watch?v=bZe5J8SVCYQ
[14:18:13] <Thrashbarg> (it's an audio clip)
[16:09:10] <Jartza> Thrashbarg: :)
[16:09:25] <Thrashbarg> heh
[16:09:37] <Thrashbarg> the idea of an I2C manual reminded me of htat
[16:09:39] <Thrashbarg> *that
[16:09:42] <Jartza> yep
[16:10:31] <Jartza> this is full of crap this datasheet :D
[16:10:37] <Thrashbarg> heh
[16:11:28] <Jartza> 1) Since ESD Protection circuit is connected between VDD and VCC inside driver IC, VCC becomes lower than VDD whenever VDD is ON and VCC is OFF
[16:11:41] <Thrashbarg> nice...
[16:11:44] <Jartza> 2) VCC should be kept float when it's OFF
[16:12:01] <Thrashbarg> :/
[16:12:13] <Jartza> 3) Power pins (VDD, VCC) can never be pulled to ground under any circumastence
[16:12:22] <Thrashbarg> yeah absolutely
[16:12:24] <Jartza> like WTF?
[16:12:28] <Thrashbarg> hah
[16:12:43] <Thrashbarg> is that straight from the datasheet?
[16:12:47] <Jartza> yes
[16:12:47] <Jartza> :D
[16:13:27] <Thrashbarg> makes sense to me ... they're saying if you ground either Vdd or Vcc it'll conduct through the protection diodes
[16:13:33] <Thrashbarg> am I missing something?
[16:15:19] <Thrashbarg> I *was* thinking about using I2C for a multiprocessor ATmega project but I think I'll use a 9-bit SPI bastardisation
[16:15:48] <Thrashbarg> I2C is a little slow for what I'd like...
[16:17:25] <Jartza> well yeah, but the language is still bad :(
[16:18:22] <Jartza> especially when english is not my native language, it sometimes makes reading bad english quite slow
[16:19:16] <Jartza> and I still didn't quite catch the meaning of the "Co" bit
[16:19:31] <Jartza> and the pdf is also made badly, can't copypaste even
[16:19:32] <Jartza> https://www.dropbox.com/s/jujif5k2mi1jmrk/Screenshot%202014-08-04%2023.57.45.png
[16:20:56] <Jartza> :P
[16:24:30] <Jartza> and that's even wrong
[16:24:37] <Jartza> you can't send data byte after address
[16:24:43] <Jartza> it first need the control byte
[16:24:57] <Jartza> which seems to state if following bytes are command or data
[16:25:35] <Jartza> but I still don't know what's the difference between 0x00, 0x80 and 0x40, exactly
[16:29:55] <Jartza> on one picture, there is a note saying "Co - Continuation bit"
[16:30:04] <Jartza> argh
[16:32:53] <Jartza> ahh... I guess I know what it is
[16:33:38] <Jartza> if I set D/C to be command and set the continuation bit (not exactly how the datasheet describes) I can as many command bytes as I wish before signalling stop
[16:34:45] <Jartza> sort of like <addr> <control> <command> <control> <command>....
[16:34:56] <Jartza> or something like that
[16:34:58] <Jartza> have to see
[16:36:27] <Jartza> at least my i2c seems to work fine
[17:57:56] <Lambda_Aurigae> Getty, enc28j60...spi to ethernet chip...add about 4 external components and a tcp/ip stack on the avr and away you go.
[17:58:21] <Tom_itx> there's another one...
[17:58:23] <Tom_itx> i forget...
[17:58:38] <Tom_itx> better iirc
[17:59:10] <Lambda_Aurigae> enc28j60 is available in dip package and will work on a breadboard.
[17:59:22] <Lambda_Aurigae> but if you can find another that's available in dip let me know!
[17:59:40] <Getty> Lambda_Aurigae: yeah but calcing this out is like "why again do i not take a raspberry directly?"
[17:59:52] <Tom_itx> not a dip that i'm aware of
[17:59:59] <Lambda_Aurigae> Getty, because....
[18:00:07] <Lambda_Aurigae> why not just use a netbook?
[18:00:32] <Tom_itx> wiznet i think
[18:00:35] <Getty> lol ;) so to connect a .50 EUR sensor and a 1.50 EUR avr to network .......
[18:00:43] <Getty> hehe
[18:00:53] <Tom_itx> https://www.sparkfun.com/products/9471
[18:01:27] <Lambda_Aurigae> Tom_itx, much harder to use though...it's a full parallel interfaced ethernet chip.
[18:01:43] <Getty> the chip is not the problem, the complete combination makes the problem and yeah as lambda says: that chip makes it more complex as the enc28j60
[18:02:07] <Lambda_Aurigae> 3.59 in single quantity from digikey for enc28j60.
[18:02:24] <Getty> i think i found them even cheaper here in germany, but yeah the price of them is like a spit
[18:02:45] <Lambda_Aurigae> 3.64 for dip package.
[18:03:08] <Lambda_Aurigae> and tuxgraphics has a nice tcp/ip stack for them.
[18:03:22] <Lambda_Aurigae> including server and client modes.
[18:03:25] <Getty> yeah still need the jack and the 4 other external components ;)
[18:03:45] <Lambda_Aurigae> for hobby, rip apart dead devices.
[18:03:51] <Getty> yeah... production here
[18:04:17] <Getty> thats why i am so enraged that this part is so expansive, as i think its an awesome feature to offer, but in the end it will be probably so expansive that the other methods will be more accepted
[18:04:22] <Lambda_Aurigae> well, the "other components" would be under 1 us dollar.
[18:04:34] <Getty> (like the RS485 bus over Cat5 where you can "stack" them)
[18:04:55] <Lambda_Aurigae> looks like magjacks are 5 to 6 dollars.
[18:05:06] <Getty> yeah thats one of the key problems, the jack
[18:05:13] <Lambda_Aurigae> single quantity...
[18:05:22] <Getty> yeah sure in the end mass production make it cheaper
[18:05:35] <Getty> but still its the question if "everything else" is then not more wise
[18:05:40] <Lambda_Aurigae> unit 1 costs 1000 dollars. unit 1000 costs 1 dollar.
[18:05:46] <Getty> like a single raspberry pi with wifi and ethernet and then 10 devices with wifi chip
[18:06:15] <Getty> 10 jacks less ;)
[18:06:19] <Getty> you get the point
[18:06:34] <Getty> the ethernet is "just" a nice to have but in the end will be the most expansive connector
[18:06:55] <Lambda_Aurigae> well, there are wifi SD devices that have a full microcontroller in them.
[18:07:11] <Getty> yeah thats what i mean you can get for wireless like for a spit of money a "connecting device"
[18:07:12] <Lambda_Aurigae> several people have hacked them.
[18:07:38] <Getty> and then take a regular hardware even to "wire" them, like existing wifi routers
[18:07:42] <Getty> then you dont need any connector at all
[18:07:47] <Getty> configure them via mobile first
[18:07:56] <Lambda_Aurigae> all depends on what you are doing.
[18:08:01] <Getty> exactly
[18:08:19] <Getty> and we are right now not having a specific case, we are targetting a specific direction but want to keep it open to let the community decide where we go
[18:08:19] <Lambda_Aurigae> wifi is more likely to be blocked or hacked or interfered with.
[18:08:36] <Getty> so i WANT ethernet, but it looks like most far away till a use case pops up from customer side
[18:08:47] <Getty> true, more complex in softwre, thats why i want to avoid it
[18:10:10] <Lambda_Aurigae> http://www.poisonedminds.com/comics/ssddbonus20140804.jpg
[18:10:46] <Getty> what is this conscious and sober he is talking about? is that related to those things holiday and sun the people always talk about?
[18:11:36] <Lambda_Aurigae> something like that.
[18:12:25] <Getty> thats btw what we have build last week
http://homehive.tv/ since i started to involve my dad into the project the electronic parts come along hehe ;)
[18:12:26] <Lambda_Aurigae> who would want to expose themselves to a giant fusion reactor without so much as a lead shield though?
[18:12:52] <Getty> true words
[18:13:10] <Lambda_Aurigae> eeewwww...twitter!
[18:13:28] <Getty> its a sample
[18:13:36] <Getty> people understand it
[18:13:52] <Getty> let me turn off the light
[18:14:01] <Lambda_Aurigae> I avoid anything that interfaces with twitter, facebook, pintrist or other similar antisocial networking sites.
[18:14:21] <Getty> i just embed a timeline for showcasing, its all just a showcase of the idea
[18:14:21] <Lambda_Aurigae> but that's just me..others will probably love it.
[18:14:50] <Getty> has nothing todo with twitter
[18:14:55] <Getty> twitter is just example output, as said
[18:15:01] <Lambda_Aurigae> I know.
[18:15:04] <Getty> whatever i would take, someone would be offended ;)
[18:15:15] <Lambda_Aurigae> I'm not offended.
[18:15:40] <Lambda_Aurigae> I only get offended if you talk bad about my wife.
[18:15:52] <Getty> oh, i know shes good ;-)
[18:15:59] <Getty> heheheh <couldntresist>
[21:09:47] <t4nk862> Hi, where should I go to get help coding for AVR processors?
[21:09:59] <LoRez> here
[21:10:25] <Tom_itx> unless it's homework
[21:10:38] <t4nk862> Not homework
[21:11:40] <t4nk862> I need to update the firmware on a Printrboard (AVR at90usb1286, 16 MHz), without physically pressing the reset button
[21:11:59] <t4nk862> because the goal is to do remote firmware upgrades
[21:13:49] <t4nk862> The firmware upgrade needs to come from a Raspberry Pi
[21:15:10] <t4nk862> Can anyone recommend a bootloader that allows software-triggered reset, i.e. not requiring the RESET button to be pressed?
[21:16:01] <t4nk862> I have tried the LUFA BootloaderCDC and BootloaderHID.
[21:16:51] <N1njaneer> That kind of depends on your specific requirements. Bootloaders are relatively easy to code, just very detail-oriened.
[21:16:59] <Tom_itx> iirc some use the wdt for that
[21:17:16] <GuShH> Tom_itx: left ##shoptalk?
[21:17:22] <N1njaneer> If you have the LUFA/DFU bootloader, you can always just vector back to the bootloader on start.
[21:17:50] <t4nk862> That's my issue - I cannot jump from boot code to application code or from application code to BOOT code
[21:18:00] <N1njaneer> I did that with one of our products - you issue a certain command and the device resets and enters the DFU bootloader automatically so it can be reflashed.
[21:18:07] <N1njaneer> t4nk862: Why not?
[21:18:34] <N1njaneer> It's just software, or can be. Hardware is not required.
[21:18:37] <t4nk862> AppPtr_t AppStartPtr = (AppPtr_t)0x0000; AppStartPtr();
[21:19:07] <t4nk862> My understanding is that this should jump from wherever I am, to application code (which I understand resides at address 0x0000)
[21:19:30] <t4nk862> So I put this into the bootloaderHID source code so that it would jump to the application after programming
[21:19:53] <N1njaneer> t4nk862: Do NOT vector to 0x0000 with a jump command. The proper way to reset is to turn on the watchdog counter then let a while(1); infinite loop (or similar) cause the WDT to fire and reset the device. Doing a 0x0000 jump will leave a bunch of things active which can cause major problems.
[21:20:15] <t4nk862> Right, there's just one catch:
[21:20:26] <N1njaneer> You technically CAN do the jmp 0x0000 but you have to do a lot of explicit housekeeping first.
[21:20:40] <t4nk862> Let's say I do a WDT reset, right?
[21:21:08] <t4nk862> If I have the BOOT jumper (2 pins on the Printrboard) connected together, then each time I do a WDT reset I end up back in the bootloader
[21:21:22] <N1njaneer> Yes?
[21:21:24] <t4nk862> so I have no way to get to my application code without physically disconnecting the BOOT jumper
[21:21:58] <N1njaneer> Remove the jumper and/or recode your bootloader to simply time out and/or use a token passed in RAM to know if it should just move to the application.
[21:22:28] <t4nk862> But how do I move from the bootloader to the application?
[21:22:50] <t4nk862> without needing to do massive housekeeping work? because wdt reset will just bring me back to the bootloader.
[21:23:04] <t4nk862> and if I remove the jumper, then the bootloader never runs
[21:23:27] <N1njaneer> That can be done with a jmp instruction if the bootloader is written to clean up after itself, which the DFU and similar will do. They will uninitialize the peripherals that were initialized, disable interrupts, and put everything back where they should be.
[21:23:53] <t4nk862> Okay. So you are actually recommending a "jmp 0x0000"
[21:24:06] <N1njaneer> Same way you CAN use jmp 0x0000 for application reset, but it's generally not reccomended to use unless you really know what you are doing.
[21:24:41] <N1njaneer> Remember that the bootloader goes in to the top of memory - application starts at 0x0000, bootloader starts in the top few KB of flash space based on the fuse settings.
[21:25:14] <N1njaneer> When BOOTRST fuse is enabled, the device will vector over to the start of the bootloader on reset.
[21:25:29] <t4nk862> All resets, or only W
[21:25:33] <t4nk862> only WDT resets *
[21:25:46] <N1njaneer> Generally you would leave this fuse disabled IF you are going to use the hardware bootloader pin to force a vectored reset to the bootloader specifically.
[21:25:54] <t4nk862> ahh
[21:26:16] <t4nk862> but like, the software can't modify the BOOTRST fuse right? So setting it is basically equivalent to connecting the BOOT jumper and never disconnecting it?
[21:26:22] <Tom_itx> sounds like an easy way to shoot your foot off
[21:26:35] <Tom_itx> i'm pretty sure it can
[21:26:50] <Tom_itx> you can overwrite the bootloader if you want to
[21:26:57] <N1njaneer> Many bootloaders I've written run automatically at the start/reset of the device, then look for a specific hardware event (a button press, say, or "BOOT" at a specific baudrate on a comm port, etc) to trigger, else they time out within a second or two. Using this method makes it absolutely impossible to brick the device if coded correctly.
[21:26:57] <Tom_itx> pretty sure that's legal too
[21:27:37] <N1njaneer> You generally set BLB1 to "SPM DISABLE" which locks the application code from ever updating the bootloader section, etc.
[21:27:56] <N1njaneer> So unless you chip erase the entire thing it's impossible muck up the bootloader.
[21:28:03] <Tom_itx> well you should... but it's perfectly legal to overwrite it
[21:28:05] <N1njaneer> Which you cannot do from software.
[21:28:26] <N1njaneer> Tom: No, you can lock it out from software overwrite.
[21:28:30] <Tom_itx> i've never tried it
[21:29:08] <t4nk862> But basically, there's no way to get from bootloader code to application code without some variant of a jmp 0x0000 somewhere in the bootloader?
[21:29:14] <N1njaneer> Atmel was smart when they designed all the bootloader capabilities on the AVR series. Many ways to handle a variety of things.
[21:29:52] <N1njaneer> t4nk862: Depending on how the fuses are set, possibly no, you MAY need a jmp 0x0000 if you are moving from the bootloader to the application and you have BOOTRST in place.
[21:30:34] <t4nk862> So it sounds like you're saying there's some other way that involves having the bootloader overwrite fuses (something I thought was impossible actually).
[21:30:41] <N1njaneer> But generally the housekeeping is easier because the bootloader is super-lightweight, and you can easily keep track of all the peripheral registers you touch, so you can set them back to initial state as per the datasheet and clean up all of your ISR stuff.
[21:31:13] <N1njaneer> No, the bootloader cannot modify most of the fuses - or at least for the ones it can, it cannot UNSET them. You have to hit some of that through the ISP or JTAG interface to configure.
[21:31:23] <N1njaneer> BUT --
[21:32:14] <t4nk862> Yes?
[21:32:32] <N1njaneer> If you already have something like the DFU bootloader in many cases you can just leave it on the device and just run on your merry way and post-configure everything you need. But in some cases, no, it has to be set up through the ISP port, which sometimes means nuking and reflashing the bootloader and setting the fuses to get the desired behavior.
[21:33:41] <t4nk862> Yea the device will have the ISP port disconnected in the field. It will only have a USB connection for both communication and programming, unfortunately.
[21:34:14] <N1njaneer> Yes, so you factory-configure through the ISP port to get it all set up how you want, once, and then deploy :)
[21:35:46] <t4nk862> By the way - I tried using the LUFA BootloaderCDC bootloader. Using avrdude to upload firmware gives me the message "Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding""
[21:36:01] <t4nk862> Thoughts on why this might be?
[21:36:48] <t4nk862> The command I'm running is "sudo avrdude -c avr109 -v -v -v -v -v -p at90usb1286 -P /dev/ttyACM5" (the -v's are for verbose output)
[21:36:53] <N1njaneer> See which one you are using, and what the USB enumerates on the host as. Dean has some of the LUFA bootloaders as clones of the DFU, which generally required FLIP to do the programming.
[21:37:17] <t4nk862> FLIP is only for Windows right? *nix is a must for this
[21:37:24] <N1njaneer> Obviously make sure the device is enumerating on the host regardless.
[21:37:46] <N1njaneer> t4nk862: I am not sure if FLIP is Windows specific, though it's the one I've used it on in the past with no problems.
[21:37:52] <t4nk862> The device shows up as /dev/ttyACM5, which is definitely correct
[21:38:45] <N1njaneer> If you can open it as a serial port, you probably want to verify if it uses the STK500 commands and go from there. I've not used one of those, save for the bootloaders I've had to write for clients that need Arduino (!) support, which is just a reimplementation of the STK500 commands.
[21:40:00] <t4nk862> Okay. I am connecting the Printrboard directly to my laptop via USB. How do I decide whether to use STK500, avr109, STK200, etc. ? I only used avr109 based on a printrboard tutorial I found online
[21:40:23] <N1njaneer> I have only used DFU for USB bootloader support, and then completely custom-written bootloaders that use the UARTs for everything else, implementing XMODEM for firmware upload.
[21:41:20] <N1njaneer> I am unfamiliar with the Printrboard so unfortunatly I can't really tell you. I'd say to probably try the documentation or support specifically for that board if you aren't rewriting all the firmware for it from scratch :)
[21:43:43] <t4nk862> Firmware is not rewritten from scratch. It's just the bootloader :( so clearly jmp 0x0000 commands need to be handled with caution. Any reason why a jmp 0x0000 in the bootloader would cause the board to simply jump right back into the bootloader?
[21:45:10] <N1njaneer> Yes, if there is no valid application code loaded OR the vector table hasn't been moved for the application to execute.
[21:45:24] <N1njaneer> Which AVR device?
[21:47:26] <N1njaneer> AT90USB1286 I assume?
[21:48:32] <N1njaneer> Look at the datasheet in section 10.1.1 regarding moving the interrupts between application and boot space.
[21:49:27] <N1njaneer> That needs to be done in the bootloader before jumping to 0x0000 or else the first thing you'll hit at 0x0000 will be the reset vector for the (unmoved) interrupt table on the bootloader, which will vector back in to the bootloader :)
[21:50:23] <N1njaneer> Hopefully that helps.
[21:52:56] <t4nk862> OHHHHH really? wow. Yes you're right about the device.
[21:53:23] <t4nk862> Do you mean moving the location of the table in RAM, or do you mean changing the targets of the vectors in the table?
[21:53:51] <t4nk862> Okay I'm looking at 10.1.1
[21:53:59] <t4nk862> I'm really confident about this being the problem.
[21:55:07] <N1njaneer> The targets are fixed in the table since they are burned in to the flash so they really aren't alterable on the fly, but you would need to flip ISEL *before* moving to the application space, so it can remap which vector table it is referring to -- in this case switching from bootloader vectors to application vectors.
[21:56:40] <N1njaneer> This is how the AVR knows where to find the interrupt code for, say, UART0_RX when in the bootloader, vs UART0_RX when in the application. Generally you'd want (more like need) a seperate set of code for the bootloader vs the application. Mostly because you want to be able to rewrite the application from under the bootloader, and it's a Really Bad Idea(tm) to alter code in the space you are running
[21:56:40] <N1njaneer> it from :)
[21:57:56] <t4nk862> Right (: That's why I need a working bootloader for remote firmware update so badly.
[21:58:03] <t4nk862> So this is from the datasheet:
[21:58:05] <t4nk862> "To avoid unintentional changes of Interrupt Vector tables, a special write procedure must be fol- lowed to change the IVSEL bit: a. Write the Interrupt Vector Change Enable (IVCE) bit to one. b. Within four cycles, write the desired value to IVSEL while writing a zero to IVCE."
[21:58:44] <t4nk862> So this is what I will do.
[21:59:38] <N1njaneer> t4nk862: Yep, protection mechanism. You need to do this by disabling ISR's with a "cli" instruction, followed by the inline assembler instructions to whack the IVCE and then IVSEL bits guaranteed inside of 4 cycles. If you do this with interrupts on OR written in C, you risk both failing.
[21:59:55] <N1njaneer> And if you are moving the vector table, you'd BETTER have interrupts off to begin with!
[22:01:01] <N1njaneer> If you do it in C, at least look at the .lss output file and ensure it has compiled down to instructions which meet the 4-cycle requirement. There SHOULD be stuff in the AVR libraries to help handle all of this for you, though. In boot.h I beliebe
[22:01:03] <N1njaneer> believe
[22:01:20] <N1njaneer> t4nk862:
http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html
[22:01:37] <N1njaneer> Check that out, as there are functions in there which will save you a bunch of fine detail headaches.
[22:03:55] <t4nk862> A function that moves the interrupt table?
[22:05:37] <N1njaneer> I though there was one in there somewhere but I'm not seeing it.
[22:06:43] <N1njaneer> In any case the datashee shows how to do it on page 70 under 10.1.2 section
[22:07:30] <N1njaneer> 6 lines of inline assembler, or 3 lines in C :)
[22:07:59] <N1njaneer> But again, if you do it in C, look at the .lss and make sure the compiler didn't go off and smoke something in the middle of optimizing the code :)
[22:09:03] <t4nk862> sure! btw, since MCUCR appears to only have 2 bits that are accessible to me, do I really need to save its value before modifying it?
[22:09:54] <t4nk862> But yea I'm trying it in C now, and from the looks of it the .lss contains:
[22:10:35] <t4nk862> cli(); 1f112: f8 94 cli MCUCR = (1 << IVCE); 1f114: 81 e0 ldi r24, 0x01 ; 1 1f116: 85 bf out 0x35, r24 ; 53 MCUCR = 0; 1f118: 15 be out 0x35, r1 ; 53 sei(); 1f11a: 78 94 sei
[22:10:43] <t4nk862> Well look at that nice formatting :p
[22:10:46] <t4nk862> but um
[22:10:49] <Tom_itx> pastebin
[22:10:51] <N1njaneer> Nope, just the two lines are fine on that guy if you don't need to preserve things.
[22:11:08] <N1njaneer> Also, you don't want the sei() in there
[22:11:31] <t4nk862> so don't reenable interrupts until i enter the application code?
[22:11:32] <N1njaneer> You'll want to turn interrupts back on from the Other Side once you get to application land and can configure peripherals and things first.
[22:11:40] <t4nk862> Ahh wonderful :p
[22:14:07] <N1njaneer> Make sense?
[22:16:58] <t4nk862> Makes snese
[22:17:01] <t4nk862> sense*
[22:17:08] <t4nk862> so i'm giving this a whirl in my code
[22:17:10] <t4nk862> aaaaaaaaaaaaaaaand
[22:18:41] <t4nk862> I think it's working.
[22:18:47] <t4nk862> It's loading the application code :)
[22:18:52] <N1njaneer> Woo!
[22:19:13] <t4nk862> I fully expect to have to do some more work to neaten this up...right now I'm just doing a jump without doing housecleaning.
[22:19:14] <N1njaneer> #avr vindicated its existence once again
[22:19:24] <t4nk862> But this is an improvement I would not have made on my own
[22:19:28] <t4nk862> THANK YOUUUUU
[22:19:33] <N1njaneer> You are most welcome!
[22:19:33] <t4nk862> vindicated. so hard.
[22:19:44] <t4nk862> hopefully you won't hear back from me :p
[22:19:53] <N1njaneer> "Atmel help desk! Have you tried turning it off and back on again?"
[22:35:26] <t4nk862> So what's your background, N1njaneer?
[22:35:35] <t4nk862> What life story brought you here
[23:08:26] <Tom_itx> he just loves our company
[23:37:42] <N1njaneer> t4nk862: I pressed a wrong button in an elevator and wound up here and I've been trying to get back home ever since!
[23:37:58] <N1njaneer> Sorry, had a phonecall - meant to press enter like 45 minute ago X.x
