Back
[03:17:43] <aczid> hey guys, I'm trying to organise some EEPROM data through pointers in an array stored in ram, but it's not really working. anybody got an example of how to put numbers to named eeprom symbols?
[03:41:23] <LeoNerd> aczid: How I do it is define a struct that's initialised in eedata and then at the start of the program, copy it into a struct in RAM
[03:41:42] <LeoNerd> That works best for just a few settings, it means using up the RAM to shadow it
[03:42:03] <aczid> yeah I'm sure that will work, but I would prefer to only store pointers to the eeprom data in ram
[03:42:42] <aczid> I can imagine gcc gets confused about such things on avr
[03:43:01] <LeoNerd> You can't have a "pointer" to eedata
[03:43:11] <aczid> well, its address
[03:43:36] <LeoNerd> Well, you can surely have a number that represents its location in the EEPROM, but accessing it as a pointer won't work
[03:44:09] <aczid> ok then how do I store eeprom addresses in ram?
[03:46:57] <LeoNerd> They're just numbers
[03:51:04] <aczid> yeah, so just using uint16_t to store them would work? but I don't see why that's better than a pointer of any type or even void
[03:51:35] <aczid> is it because pointers get special treatment?
[03:51:46] <aczid> to reside in ram space?
[03:54:26] <aczid> it appears to make no difference in the end, because eeprom_read_block is typed to use pointers
[03:54:31] <aczid> which just confuses me more
[05:38:02] <redspl> Hi again :)
[05:38:07] <redspl> 2000000UL is 2mhz, right?
[05:40:03] <Lambda_Aurigae> well, assuming "UL" is Unsigned Long, and you set F_CPU to that, it could designate such, yes.
[05:40:38] <Lambda_Aurigae> otherwise it is 2 liters.
[05:41:13] <redspl> :P
[05:41:21] <redspl> avr-gcc -w -Os -DF_CPU=2000000UL -mmcu=atmega8 -c -o main.o main.c
[05:41:23] <redspl> i found this
[05:41:29] <redspl> and i wondered
[05:41:44] <Lambda_Aurigae> NOW we have some context.
[05:41:51] <Lambda_Aurigae> see, context really helps.
[05:42:15] <redspl> :P
[05:42:17] <Lambda_Aurigae> yes, that is setting a variable to define a specific cpu frequency...
[05:42:24] <redspl> ok, thx
[05:42:31] <Lambda_Aurigae> also, google is your friend.
[05:42:41] <redspl> i googled,
[05:42:46] <redspl> guess what i got
[05:43:04] <redspl> litres to something!
[05:43:05] <redspl> :PP
[05:43:29] <redspl> next question: can i use crystal without capacitors?
[05:43:32] <Lambda_Aurigae> so you googled one part of one entry.
[05:43:38] <redspl> yup
[05:43:45] <Lambda_Aurigae> how about searching for avr gcc f_cpu
[05:43:54] <redspl> that could be good idea
[05:43:56] <Lambda_Aurigae> or, maybe, the entire line you posted.
[05:44:03] <redspl> even better
[05:44:04] <Lambda_Aurigae> it's all there...hehe
[05:44:05] <redspl> thatks
[05:44:16] <Lambda_Aurigae> as for using crystal without capacitors....usually not a good idea.
[05:44:25] <Lambda_Aurigae> the crystals are part of the startup circuit.
[05:44:36] <Lambda_Aurigae> needed to get the crystal vibrating.
[05:45:13] <Lambda_Aurigae> now, that being said, if you are working on a solderless breadboard, often times a 16 or 20mhz crystal will work with the capacitance just from the solderless breadboard strips.
[05:45:29] <Lambda_Aurigae> not sure about a larger slower crystal.
[05:47:57] <redspl> now i am working on a breadbord
[05:48:31] <Lambda_Aurigae> so, it MIGHT work without caps.
[05:49:14] <redspl> caps must be equal 22pf? idk i have some
[05:49:27] <Lambda_Aurigae> 13 to 22 or thereabouts...kinda depends on the crystal
[05:49:52] <Lambda_Aurigae> the larger they are the longer it takes to start the oscillations and for it to stabilize.
[05:54:03] <redspl> 10pf will do the trick, or i must make bigger from two?
[05:54:41] <Lambda_Aurigae> try it and see.
[05:54:43] <redspl> ok
[05:55:01] <Lambda_Aurigae> sheesh...experiment and learn....hehe
[05:55:50] <Lambda_Aurigae> if you have 10pf and it calls for 22pf, parallel two together to get 20pf....
[05:56:30] <Lambda_Aurigae> basic electronic training of some kind is probably a good thing to do.
[05:56:39] <Lambda_Aurigae> Getting Started In Electronics is an awesome book to read.
[05:58:09] <redspl> Lambda_Aurigae, i know about that, but i wanned to know i could do this without that technique
[05:58:21] <redspl> mine english is for A+, right?
[06:04:39] <Lambda_Aurigae> umm...no clue what that question means.
[06:08:59] <redspl> nevermind
[06:39:21] <redspl> program does not work -.-
[06:41:20] <redspl> ok, flashing error
[06:41:21] <redspl> sry
[06:52:58] <LeoNerd> Weeelll.. my first attempt at a QFN-szied chip hasn't gone too well. I have a grounding short on VCC :(
[07:10:40] <redspl> crapp
[07:10:58] <redspl> mine program does not work
[07:12:26] <redspl> it compiles: OK. It flashes: OK, but it does not run
[07:13:10] <redspl> http://wklej.org/id/1757866/
[07:13:13] <redspl> heelp ;/
[07:17:44] <twnqx> lol
[07:17:48] <twnqx> -ECHAT
[07:30:36] <Lambda_Aurigae> redspl, and, what are your fuses set to?
[07:31:05] <redspl> idk, i havent setted it
[07:31:24] <redspl> idk why but i dont have power on 5v 0.0
[07:31:27] <redspl> sec
[07:32:25] <redspl> idk;(
[07:32:32] <redspl> ok, i must go for now..
[07:32:43] <Lambda_Aurigae> ok. have you changed the fuses or is this a fresh chip from atmel?
[07:47:56] <Jartza> afternoon
[09:03:54] <LeoNerd> While it's quiet, I have a solderpaste-related question. I tried my first attempt at QFN32 soldering this morning. I'm not sure if the paste I have for it is quite right.. It didn't seem to "stick" easily to the board while I was trying to apply it
[09:04:08] <LeoNerd> It mostly just stayed in a blob around the nozzle of the syringe
[09:04:44] <LeoNerd> Does anyone know of a good video (youtube?) showing what it *should* look like to apply it, so I can compare?
[09:07:19] <LeoNerd> Also I think my nozzle is way too big for this work... :/ The paste only came with one and it's huuuuge
[09:23:46] <Lambda_Aurigae> no clue on videos.
[09:23:53] <Lambda_Aurigae> but it sounds like you need to clean your copper pads.
[09:23:58] <Lambda_Aurigae> I use acetone to do so.
[09:23:59] <LeoNerd> They're clean and new
[09:24:09] <Lambda_Aurigae> when were they last cleaned?
[09:24:11] <LeoNerd> Fresh board from OSHpark, ENIG coated. Arrived 2 days ago
[09:24:12] <Lambda_Aurigae> did you touch them?
[09:24:28] <Lambda_Aurigae> so, at least 4 days old....copper oxides forming...clean them.
[09:24:42] <LeoNerd> I gave it a good rubbing with the flux pen
[09:24:55] <Lambda_Aurigae> clean and new and fresh means cleaned within the last half hour to me.
[09:25:06] <LeoNerd> Yah - this was like.. 5 minutes before
[09:25:10] <Lambda_Aurigae> I use acetone and a superfine steel wool.
[09:25:19] <Lambda_Aurigae> then the solder paste sticks to mine.
[09:25:25] <LeoNerd> hmm
[09:25:37] <Lambda_Aurigae> any oils at all and no go...even touching it with your finger...specially that.
[09:25:45] <LeoNerd> I still suspect the paste, though. It's not as free-flowing as videos I've seen
[09:25:59] <LeoNerd> Usually it looks about the consistency of honey.. it'll flow. Mine doesn't.. mine's more like blutak
[09:26:15] <Lambda_Aurigae> have you kept it cool in the fridge?
[09:27:11] <LeoNerd> Hmm... no. But it's relatively new too
[09:27:19] <LeoNerd> A week or so
[09:28:22] <Lambda_Aurigae> I know most of that stuff should be kept cool. I keep mine in the fridge beside the mustard.
[09:28:45] <LeoNerd> Don't confuse the two ;)
[09:33:28] <Lambda_Aurigae> one is in a bright yellow package
[09:33:48] <Lambda_Aurigae> the other is wrapped in a heavy duty red ziplock with DO NOT EAT written on it.
[09:34:00] <Lambda_Aurigae> shouldn't be a problem
[09:34:08] <Lambda_Aurigae> anyhoo..time to go do some worky.
[09:34:10] <Lambda_Aurigae> latersl.
[09:35:43] <Hexum064> morning all
[10:01:09] <bss36504> LeoNerd: I've not had that experience with solderpaste, and I dont refridgerate mine or really worry about crap on my enig pads. the gold should prevent most oxidation. If your paste isnt' sticking well, maybe it's no good. I buy this stuff:
http://www.amazon.com/Kester-EP256-Solder-Syringe-Dispenser/dp/B006UTCYM2/ref=sr_1_3?ie=UTF8&qid=1437057487&sr=8-3&keywords=solder+paste+syringe&pebp=14370574
[10:01:29] <bss36504> Seems to have a good shelf life.
[10:22:06] <redspl> jestem z powrotem..
[10:22:16] <redspl> ktoś oprócz mnie słucha ModFM?
[10:22:56] <redspl> http://radio.modules.pl:8500/
[10:26:27] <redspl> whoops, not that channel. sorry!
[10:26:33] <LeoNerd> :)
[10:26:36] <LeoNerd> I was beginning to wonder
[10:26:38] <redspl> xDD
[10:26:58] <Hexum064> lol
[10:29:43] <Strangework> Morning, #avr! :)
[10:29:52] <bss36504> Greetings, pal
[10:30:13] <Hexum064> hey
[10:30:39] <Strangework> Anyone have anything cool to report this morn?
[10:31:16] <LeoNerd> Strangework: I soldered my first attempt at a QFN32 today. First time with paste+heatgun
[10:31:20] <LeoNerd> So.. really more hot, than cool
[10:31:26] <LeoNerd> Sad to report it doesn't work yet though
[10:32:14] <Strangework> Oh gosh. :o What other form factors have you used prior?
[10:32:42] <Strangework> I gather that SOIC is pretty comfortable, though most chips I see seem to be QFNs.
[10:33:01] <LeoNerd> I've done plenty of SOICs now
[10:33:28] <bss36504> Is your paste in a jar or a syringe?
[10:33:31] <LeoNerd> This board didn't *strictly* need to be QFN, I could have used a leaded QFP and hand-soldered it, except that the timing crystal I could only find in little 6x3.5mm
[10:33:34] <LeoNerd> syringe
[10:33:48] <LeoNerd> And it seems too goopy and dried-up... I'm not sure it's very good stuff :/
[10:34:12] <bss36504> I find that applying it in the smallest amount possible is a good approach. If it doesnt extrude well, it might be no good.
[10:34:27] <LeoNerd> It -extrudes- out of the syringe, it just doesn't stick to the board
[10:34:38] <LeoNerd> It stays attached to the metal nozzle, not on the board pad
[10:36:22] <LeoNerd> I also put too much on the first time and it squirted out around the edges and made way too many bridges.. so I took the thing off entirely and tried a second time
[10:36:27] <LeoNerd> So all that reheating might have cooked it :(
[10:36:58] <LeoNerd> Problem is: it's my first attempt at QFN, first trial with this board, first use of paste.. The chip doesn't work, but I'm not sure if the chip's dead, or just attached wrongly. Hard to tell
[10:37:00] <twnqx> > 6x3.5mm
[10:37:01] <twnqx> > little
[10:37:03] <twnqx> ...
[10:37:13] <LeoNerd> twnqx: The only other size is HC49 and those things are *huuuuuge*
[10:37:49] <twnqx> pfff
[10:37:53] <twnqx> there's always smaller
[10:40:29] * twnqx loves the CSCTE series
[10:40:48] <twnqx> "muRata CERALOCK series CSTCE_V resonators with integrated load capacitors"
[10:41:07] <LeoNerd> Ooh.. integrated caps
[10:41:20] <redspl> rotfl. i switched some cables and now i have power. interesting. BTW: Thanks for all help :PP
[10:41:23] <LeoNerd> Yeah I've often wondered why people don't do that more... 3-lead device with xtal + 2 caps
[11:02:35] <redspl> guys.. i got that
http://www.pocketmagic.net/wp-content/uploads/2012/07/enc28j60-board-schematics.pdf
[11:02:57] <redspl> i am curious: do i need to program enc28j60 chip?
[11:04:00] <twnqx> the chip itself? no
[11:04:09] <twnqx> you need to write code to communicate with it though
[11:04:28] <redspl> that i know
[11:04:50] <redspl> i thinked the chip is programmable
[14:32:52] <redspl> hi again :P
[14:33:28] <avrgh> I'm using atmel studio. Is there a way to change the endianess on atmegas?
[14:39:17] <aandrew> avrgh: why would you need to do this (on any processor) ?
[14:39:51] <LeoNerd> ATmega is a purely 8bit CPU. It doesn't really have a notion of endianness
[14:39:59] <LeoNerd> Any multibyte values are the invention of the compiler
[14:40:33] <avrgh> Because i need to send data to big endian to a processor
[14:40:52] <LeoNerd> Well, for serialisation purposes you should serialise appropriately
[14:41:02] <avrgh> Then is there a way to get the compiler to change the endianess?
[14:41:09] <LeoNerd> E.g.. uart_put(v >> 8); uart_put(v & 0xff); would serialise a uint16_t v
[14:43:13] <avrgh> I want to take a certain address, but I want my data to be interpreted as big endian. *(unsigned long*)(address)
[14:51:28] <bss36504> Copy it from the original address and store it in a different endianness. But no, there isnt a baked in way to do this.
[14:53:16] <avrgh> That sucks
[14:53:45] <bss36504> You could make a templated C++ union with a swap method. One member is the integral data type of type T, the other is an array of bytes of sizeof(T). Swap then just reverses the ordering (or whatever you need) by acting on the array of bytes. Then just pass the pointer to the integral type.
[14:54:22] <bss36504> Thats very polymorphic though. You could also just make a union of an unsigned long and an array of sizeof(unsigned long). Make a free function that will swap the bytes.
[14:54:25] <avrgh> Or is there a setting to set in the gcc that atmel studio uses?
[14:54:50] <redspl> what is the difference between ATmega8L and ATmega8A-PU?
[14:55:20] <bss36504> No the whole point/problem is there is no such concept as endianness in an 8 bit processor. So the compiler reads and writes the multi-byte types however it wants and you wont really see it ever.
[14:55:35] <bss36504> redspl: My guess is packaging options
[14:55:55] <redspl> so, i could do THIS
http://www.electroons.com/electroons/images/rs232_ckt.jpg
[14:56:03] <redspl> on 8A-Pu?
[14:56:53] <bss36504> I dont see why not. Theoretically you could do it on most AVRs with minimal code changes, so long as you used the same pin mappings (or the pin mappings were the same, however you look at it)
[14:57:11] <redspl> ok, thx :)
[14:57:19] <Jartza> evening
[15:02:05] * bss36504 waves to Jartza
[15:46:18] <Emil_> Hi again
[15:46:24] <Emil_> A random question popped into my mind
[15:47:11] <Emil_> Could you, in theory, make avr edit it's code on the fly by jumping into a memory location and execution the data there as instructions?
[15:47:24] <Emil_> And practise would be even cooler
[15:53:39] <Hexum064> You can't write to program flash from within normal program memory, only from bootloader memory
[15:54:08] <Hexum064> And you can't point the instruction pointer to SRAM
[15:55:12] <Emil_> Can you jump into bootloader memory?
[15:55:29] <Emil_> And can't from a standards point of view or a physical barrier?
[15:55:36] <Hexum064> I don't think so.
[15:55:50] <Emil_> To which?
[15:55:54] <Emil_> Oh yeah the first
[15:56:10] <Emil_> But you can reset the device
[15:56:24] <Emil_> so if you save all the shit into eeprom
[15:56:33] <Emil_> can you read from the eeprom while in bootloader
[15:56:34] <Jartza> some tinies can program their flash from "normal program"
[15:56:36] <Hexum064> You could do something like that
[15:56:45] <Jartza> as they don't have bootloaders
[15:56:47] <Hexum064> and then do a software reset
[15:56:54] <Emil_> Jartza: oh cool, nice
[15:56:58] <Emil_> which tinies?
[15:56:59] <Hexum064> And that, about the tinies, I didn't know
[15:57:09] <Jartza> most of them I think
[15:57:13] <Emil_> Uhah
[15:57:28] <Emil_> Then it becomes a question of how to jump into that memory location
[15:57:32] <Jartza> just burn the "self programming enabled" fuse
[15:57:51] <Emil_> I wonder if someone has done this before
[15:58:00] <Jartza> jumping to memory location is easy
[15:58:05] <Emil_> Probably yes
[15:58:20] <Emil_> and executing that memory as instructions also?
[15:58:37] <Jartza> you just need to remember that atmel promises program flash to last for 10000 writes
[15:58:57] <Emil_> Yeah that's true
[15:59:09] <Jartza> you can't execute from ram with avr
[15:59:12] <Emil_> damn
[15:59:16] <Jartza> only from flash
[15:59:21] <Emil_> hmm
[15:59:26] <mudkip908> Emil_: you might find this interesting
http://oneweekwonder.blogspot.com/2014/07/bootjacker-amazing-avr-bootloader-hack.html
[15:59:39] <Emil_> is that like an internal restriction?
[15:59:57] <bss36504> Emil_: Youre basically describing an OS that does context switches from the bootloader. Not impossible, in fact, I think I read about a guy that made an SD Card based RTOS. Scheduler resides in the bootloader and loads contexts from the SD into program flash
[15:59:57] <Emil_> I mean, I think you can read and execute from an external location, no?
[16:00:18] <Jartza> my electronic nametag/badge updates it's firmware using two-step process
[16:01:05] <Emil_> bss36504: so, it can execute from program flash?
[16:01:06] <Jartza> firmware is 6kB, then you load firmware updater (sort of bootloader) into the upper 2kB which is left of 8kB
[16:01:21] <bss36504> Emil_: Yeah. Let me see if I can find a link...
[16:01:30] <Jartza> that code then updates the lower 6kB again
[16:01:36] <Emil_> then why'd you need the external sd?
[16:02:03] <Jartza> for data?
[16:02:06] <bss36504> Emil_: Oh I think it was just a design goal to have external "program images" on the sd that could more or less be hotswapped.
[16:02:10] <Emil_> ah
[16:02:13] <Emil_> I see
[16:02:22] <Emil_> Well, it does make life a lot easier, I think
[16:02:23] <Jartza> or reflashing the firmware
[16:02:55] <Emil_> Do you know if there's a site (or sub in reddit) dedicated to component golfing?
[16:04:15] <Emil_> bss36504: but yeah, shoot me a link if you find it!
[16:05:58] <bss36504> Will do!
[16:06:59] <Emil_> mudkip908: that's very interesting!
[16:07:50] <bss36504> Emil_:
http://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2005/acl34/kaos/index.html
[16:07:53] <bss36504> There you go
[16:08:27] <Emil_> Nice!
[16:08:38] <Emil_> Now let's get rid of that sd card :D
[16:09:29] <bss36504> I wanted something that would allow me to run pseudo-applications on a more realistic OS. So that you could compile a full application separate from the OS and have the OS auto-enumerate all the applications on the SD card.
[16:11:33] <Emil_> mudkip908: "The interrupt routine pops the bootloader address and then returns to the previous code"
[16:12:04] <Emil_> What does this mean?
[16:13:25] <Emil_> So if I understand correctly the problem is not knowing where the bootloader resides exactly and popping it means getting the address into userspace?
[16:13:32] <mudkip908> nope
[16:13:45] <Emil_> Can you explain?
[16:13:54] <mudkip908> it's about returning back into your code instead of the bootloader
[16:14:11] <mudkip908> basically after the interrupt fires the stack contains a return address that's in the bootloader
[16:14:20] <mudkip908> because that's where the instruction poitner was when it fired
[16:15:13] <mudkip908> you need to get this address off of the stack so that the top-most value on it is the return address of where you called the bootloader from
[16:15:18] <Emil_> Ah
[16:15:23] <Emil_> I see
[16:15:30] <mudkip908> so it goes like this: your code -> bootloader -> timer interrupt vector -> your code
[16:15:39] <mudkip908> instead of your code -> bootloader -> timer interrupt vector -> bootloader
[16:15:56] <Emil_> I just saw push address; pop eax and that would make eax address
[16:16:33] <Emil_> Hmm
[16:16:47] <Emil_> I wonder how the spm instructions are disabled
[16:16:50] <Emil_> On what level
[16:17:06] <mudkip908> probably in silicon :p
[16:17:22] <Emil_> But as described you can get around that
[16:17:47] <Emil_> So obviously one could write a library that permanently enables them?
[16:18:14] <Emil_> Or are they refresh every 4 cycles?
[16:18:29] <Emil_> resetted*
[16:18:36] <mudkip908> you aren't enabling SPM from application region
[16:18:56] <mudkip908> you're jumping into the bootloader to execute SPM there which is allowed
[17:29:15] <Hexum064> I have an interrupt question for you all.
[17:29:56] <Hexum064> If I have USB data coming in and the transaction completes, I jump to that interrupt handler. Pretty normal stuff so far.
[17:30:36] <Hexum064> The question is, does control return to the USB hardware as soon as I clear the int flag or only after I return fro the handler?
[17:31:24] <Emil_> What platform?
[17:31:31] <Hexum064> xmega
[17:33:31] <Emil_> Can't you make that decision yourself?
[17:34:10] <Hexum064> what do you mean?
[17:34:21] <Emil_> That you can decide the functionality in the handler
[17:34:34] <Emil_> But I think by default it's the latter
[17:36:06] <Hexum064> How would I decide that clearing the flag returned control to the USB hardware but continue executing the handler?
[17:36:31] <Hexum064> I mean, I think it either works that way or it doesn't
[17:41:58] <Emil_> I'm trying to understand what you mean by control returning to the usb hardware
[17:42:23] <Hexum064> Ya, good point. I didn't make that very clear.
[17:42:52] <Hexum064> What I mean is, if I cleared the INT flags for the USB, would it go on its merry way in the background, receiving the next transaction?
[17:43:27] <Emil_> Ah, I was right on track then :D
[17:43:32] <Hexum064> Or does it wait till I return from that INT handler before it continues to receive?
[17:43:46] <Emil_> So
[17:43:46] <Hexum064> (I think it's the latter)
[17:44:30] <Emil_> I think it's the first one, actually
[17:46:42] <Emil_> If the usb controller exists independently of the cpu it should only care about the registers
[17:46:57] <Emil_> doesn't xmega have dma?
[17:47:05] <Hexum064> yes
[17:47:09] <Emil_> If it does it most certainly should be the first one
[17:47:43] <Emil_> I'm just not sure how the interrupts would be handled, if you have them disabled while in interrupt
[17:47:43] <Hexum064> dma is not automatically active and it's not part of the USB hardware by default.
[17:48:04] <Hexum064> What I mean is that it doesn't just use DMA in that way
[17:51:37] <Emil_> which xmega is it?
[17:52:06] <Hexum064> 128a4u
[17:55:14] <Emil_> inThe event system enables direct peripheral-to-peripheral communication and signaling. It allows a change in one
[17:55:17] <Emil_> peripheral’s state to automatically trigger actions in other peripherals. It is designed to provide a predictable system
[17:55:20] <Emil_> for short and predictable response times between peripherals. It allows for autonomous peripheral control and
[17:55:23] <Emil_> interaction without the use of interrupts, CPU, or DMA controller resources, and is thus a powerful tool for reducing the
[17:55:26] <Emil_> complexity, size and execution time of application code. It also allows for synchronized timing of actions in several
[17:55:29] <Emil_> peripheral modules.
[17:55:41] <Emil_> It seems it should function independently of what code runs
[17:57:03] <Emil_> The ATx devices have five software selectable power saving modes. The idle mode stops the CPU while allowing the
[17:57:06] <Emil_> SRAM, DMA controller, event system, interrupt controller, and all peripherals to continue functioning.
[17:58:33] <Emil_> Built-in direct memory access (DMA) to internal SRAM for:
[17:58:33] <Emil_> z Endpoint configurations
[17:58:33] <Emil_> z Reading and writing endpoint data
[17:58:36] <Hexum064> I'm not sure that the event system applies here (and I really wish I could just use the event system but I cant)
[17:59:13] <Hexum064> Right, but DMA is not attached to USB automatically. You have to set it up for that.
[18:00:39] <Emil_> I think they are different DMAs
[18:01:56] <Emil_> But in any case, can't you easily test this with a timer?
[18:03:47] <Emil_> do I seem rude? By "can't you" I mean "I think you can..."
[18:05:15] <Emil_> And by "I think you can" I don't mean that you should go test it now :D Just that I think you can test it with a timer
[18:08:08] <Jordan_U> I'm pretty sure that the answer is "yes", but I'll ask anyway: I have a global variable that is written to when the chip first starts (based on contents of eeprom), before interrupts are enabled, and then only read from from that point on (from both the main loop and interrupts). Does this variable still need to be declared volatile since it's technically not const and is read from in interrupts?
[18:10:19] <Emil_> Isn't that purely a question on the compiler?
[18:10:54] <Emil_> Does it hurt to always label it as volatile?
[18:11:32] <Jordan_U> Emil_: It might make things a little slower, but I haven't benchmarked it to find out yet.
[18:11:55] <Emil_> Compile it both ways and check what the instructions say
[18:12:47] <Emil_> if it's optimised away if not declared as volatile you can either change the instructions yourself after or just go with always declaring it as volatile
[18:13:31] <Jordan_U> I'll go with always declaring in volatile. Thanks.
[18:13:32] <Emil_> Or do it with inline assembly
[18:13:44] <Emil_> You can do it with inline assembly and the optimiser wont touch it
[18:15:46] <Emil_> But I mean, if the code changes dynamically the compiler can't optimise it anyway and it shouldn't make the code less efficient
[19:57:42] <Hexum064_2> sup all
