Back
[04:31:48] <Levitator> Ok, so let me get something straight about the atmega328p...
[04:32:30] <Levitator> There is not atomic set-fetch for flipping interrupt enable bits, so you have to use CLI to do that stuff atomically, right?
[04:35:15] <Levitator> So how do you restore GIE after a set, if you can't set/fetch it atomically either? It looks like the AVR libc does it non-atomically and simply assumes that there is no interrupt handler which would leave GEI altered after exit.
[04:36:24] <Levitator> Because then if you fetch it, and it's off, then it's going to stay off and you're always fine. However, if it's on, then an interrupt handler could flip it off right after you fetch it.
[04:36:52] <Levitator> However, based on the design of the library, it looks as though that behavior needs to be treated as undefined behavior in order for the MCU to work.
[04:38:47] <Levitator> So, if we assume that interrupt handlers always return with IRET, or whatever it's called, then this all works, and I guess that must be the assumption which is made.
[06:06:55] <GeneralStupid> Hi -.- i have a xmega device and i want to connect to a flash memory via SPI...
[06:07:30] <GeneralStupid> i use ASF but my problem is, i need to use custom pins for SPI (is this a problem?!)
[06:10:35] <Lambda_Aurigae> I'm guessing you want to use the hardware spi direct memory interface?
[06:10:53] <Lambda_Aurigae> so you can map the SPI flash directly to memory.
[06:11:02] <Lambda_Aurigae> if so, you have to use the specified pins....
[06:11:08] <Lambda_Aurigae> have you read the datasheet?
[06:11:11] <GeneralStupid> Lambda_Aurigae: Hm, i dont need that actually...
[06:11:35] <GeneralStupid> Lambda_Aurigae: its not really time critical if i want to fill the SPI flash memory.
[06:11:58] <GeneralStupid> Lambda_Aurigae: i have the datasheet but i did not design the board so i cannot change the pin assignment
[06:13:16] <Lambda_Aurigae> if you just want to access the flash then you can use any pins you like
[06:13:24] <Lambda_Aurigae> you will just have to bitbang the spi interface.
[06:14:22] <GeneralStupid> Lambda_Aurigae: so i cannot use ASF libs i have to write the complete SPI interface by myself?
[06:14:39] <Lambda_Aurigae> I have no idea if you can or not.
[06:14:53] <Lambda_Aurigae> I know nothing about ASF libs
[06:15:33] <Lambda_Aurigae> if you do not use the hardware SPI interface then you will have to write code to use regular gpio pins to create an spi interface..
[06:15:35] <GeneralStupid> Lambda_Aurigae: (i can tell you one thing about ASF, it's really bad documented)
[06:16:21] <Lambda_Aurigae> you will likely have to hang around for a while and ask again once someone who uses xmega shows up.
[06:16:36] <Lambda_Aurigae> xmega is not used much from what I see.
[06:17:35] <Lambda_Aurigae> and ASF requires atmel studio from what I've seen...or at least is written for atmel studio and would need some work to use outside it.
[06:17:45] <Lambda_Aurigae> and atmel studio won't run on my computer without major changes.
[06:19:51] <GeneralStupid> Lambda_Aurigae: i started with atmel studio and asf because lufa is not well supported on xmega... and... i thought i could switch to linux or smthg. but now i have to use AtmelStudio.
[06:23:24] <GeneralStupid> Lambda_Aurigae: we only need two of these boards... i dont know why we did not chose one 32 bit processor
[06:24:01] <Lambda_Aurigae> xmega seems to be a problem in many ways from what I see.
[06:24:19] <Lambda_Aurigae> a couple of people here like them but not many.
[06:24:49] <Lambda_Aurigae> I've mostly shifted to pic32 chips these days myself.
[06:26:30] <GeneralStupid> Lambda_Aurigae: We develop a processor and i develop some algorithms for that processor... But now they need me to develop the evaluation board for that processor... And i need to write code for Blackfin and Atmel processors i never used before...
[06:26:50] <Lambda_Aurigae> have fun
[06:27:06] <GeneralStupid> in theory ASF is a good choice to get a quick, working solution. If it was well documentated
[06:28:30] <GeneralStupid> Lambda_Aurigae: it's just depressing... i "single stepped" over so many lines of ASF code... dosnt make much fun
[06:29:09] <GeneralStupid> i just want some person who says:" i have developed the exact SPI lib you need, " :D
[06:30:55] <LeoNerd> Levitator: That is the usual practice to leave with IRET yes, so the assumption about the I bit is valid
[06:31:50] <Levitator> Makes sense. Never seen it laid out explicitly.
[06:36:59] <Levitator> Hrm. Any reason to put asm volatile("": : :"memory"), as a memory fence, in a hideous macro, or should it suffice to stick it in a function and call it?
[06:52:39] <GeneralStupid> if i follow
http://asf.atmel.com/docs/3.27.3/xmegaa/html/spi_master_xmega.html i get "implicit declaration of function 'ioport_set_pin_high'"
[07:25:35] <Levitator> Blah. Why is the compiler not catching references to pure virtual? I'm getting undefined reference to __cxa_pure_virtual
[07:25:53] <Levitator> At link time, when it can't tell me where it happened.
[09:28:04] <rue_house> are you trying to do c++ on an 8 bit microcontroller?
[09:28:36] <LeoNerd> Many people try to :/
[09:28:48] <LeoNerd> They tend to be Arduino users
[09:29:14] <rue_house> hmm, there must be a good analogy about using a car as a boat
[09:31:51] <LeoNerd> Now I'm thinking about leaks
[09:42:06] <jben1> Speacking of that (C++ on 8bit micro), do we have to use the same toolchain ?
[09:43:24] <jben1> I don't think using C++ is a good idea, except for templates
[09:44:42] <jben1> generally for doing things as template, I use token concatenation with the preprocessor, and templates could be a good idea
[09:49:29] <rue_house> DO NOT USE C++ ON AN 8 BIT MICROCONTROLLER NOMATTER WHAT BRAND IT IS
[09:50:23] <rue_house> or, take a roll of duct tape and turn your car into a boat
[09:50:42] <rue_house> ugh, late for work
[09:52:14] <rue_house> trying to use c++ on an 8 bit microcontroller just shows you know nothing about what your doing...
[09:57:38] <learath> rue_house: welcome to modern software development
[09:57:44] <skz81> rue_house, I don't agree. You can produce as efficent code as C using C++ (providing you know what you're doing). BUT, there is probably few code were the "syntax sugar" of C++ is *really* valuable.
[09:58:06] <skz81> <troll>Futhermore if you do C99, you're doing mostly C++ without classes</troll>
[09:58:39] <LeoNerd> You *can* write nicely efficient C++ on an 8bit micro, but only by throwing out basically so much of what makes C++ C++, that you're basically writing straight C anyway
[09:58:46] <LeoNerd> At which point... why not just write C?
[10:05:19] <jben1> rue_house: Could you provide some real facts?
[10:05:51] <GeneralStupid> jben1: you need waterproof duck tape
[10:06:31] <jben1> LeoNerd: Yes, I am thinking of NOT using "that makes C++ C++", except one thing, templates
[10:06:36] <GeneralStupid> jben1: and its easier if you drive a cabriolet :D
[10:06:55] <LeoNerd> jben1: at which point you're writing C with a templated preprocessor
[10:07:04] <skz81> LeoNerd, namspaces, (possibly virtual) class methods and templates. But as stated before, there is probably few code where this is *really* valuable.
[10:07:09] <LeoNerd> if I wanted a templating preprocessor on my source code (and occasionally I do), I think I'd find a nicer one than C++
[10:08:19] <jben1> LeoNerd: if you have other template preprocessor which could be applied, I will be happy to use it.
[10:08:22] <GeneralStupid> iam no c fanboy and i think iam a modern developer who would program stuff like python embedded if it would be possible
[10:08:44] <GeneralStupid> But if you really want to use c++, because of development performance then buy bigger hardware
[10:09:03] <skz81> GeneralStupid, have a look on micropython :)
[10:09:33] <jben1> I do not usr C++, and I do not want really to use C++, but I dreams of templates, so if you have other template preprocessor, help me for my dreams
[10:09:43] <GeneralStupid> skz81: nice
[10:11:04] <jben1> Doing things as I do now, template-like things with token concatennation with the CPP is a PITA
[10:38:25] <GeneralStupid> is it possible to use a bus pirate or bus blaster as jtag debugger with the atmel studio?
[10:38:52] <LeoNerd> Personally, I wouldn't really say it's possible to use BS as a JTAG debugger *at all*
[10:38:58] <GeneralStupid> any experiences?
[10:39:14] <LeoNerd> The builtin firmware doesn't have an understanding of JTAG, so either you bitbang it reeeeeeally slowly, or you replace it with one of the thirdparty ones
[10:39:33] <LeoNerd> You'd be much better off with an FT232H - they can do JTAG much nicer (and a lot faster than a BP can)
[10:39:49] <GeneralStupid> LeoNerd: but what does that mean… i like the GUI and the possibility to step through my c code...
[10:39:55] <LeoNerd> ?
[10:40:05] <LeoNerd> I didn't make any statement about GUIs
[10:40:14] <GeneralStupid> i know, thats why i asked.
[10:40:20] <LeoNerd> I simply said I don't consider the Bus Pirate a suitable JTAG interface at all
[10:40:34] <GeneralStupid> using pure gdb would cost me a lot of time
[10:40:50] <LeoNerd> We seem to be holding entirely cross-purposes conversations here
[10:41:06] <GeneralStupid> and i would like to use that jtag debugger for atmel AND analog devices blackfin
[10:41:16] <LeoNerd> Yes. That sounds useful
[10:41:20] <LeoNerd> Dont' use a Bus Pirate to do it :)
[10:41:23] <LeoNerd> Get some real JTAG hardware
[10:42:33] <GeneralStupid> LeoNerd: we dont have the money for a blackfin jtag debugger
[10:42:44] <LeoNerd> So find some other device
[10:42:55] <LeoNerd> I already mentioned the FT232H
[10:43:12] <GeneralStupid> LeoNerd: its really cheap -.- that thing works?
[10:43:29] <LeoNerd> The MPSSE will talk, among other things, JTAG
[10:43:48] <LeoNerd> I mostly use it for SPI and I²C but it'll do JTAG too
[10:44:31] <GeneralStupid> LeoNerd: so that thing is just usb <-> serial and everything else is done by software (correct?)
[10:44:58] <LeoNerd> Yes; same as if you'd used the Bus Pirate
[10:45:08] <LeoNerd> Only whereas the FT232H natively talks USB, the Bus Pirate doesn't.
[10:45:24] <LeoNerd> The Bus Pirate is a PIC24 chip attached to an FT232R USB-UART bridge, talking at 115.2kBaud
[10:45:39] <LeoNerd> The FT232H can natively achieve upwards of 2Mbit/sec
[10:45:42] <GeneralStupid> Hm, ok. That looks like a nice solution.
[10:46:04] <LeoNerd> In addition, the Bus Pirate is intended primarily for human interface on a text console.
[10:46:16] <LeoNerd> The binary IO mode is verymuch an afterthought, and not very well implemented in my opinion
[10:46:27] <LeoNerd> It's full of bugs, stalls and lockups, many missing features,...
[10:47:23] <GeneralStupid> they told me that i dont really neet a blackfin JTAG debugger, because we can debug that thing with GPIO pins connected to my atmel device...
[10:47:49] <LeoNerd> Wellsure, you *can*. JTAG is really just SPI with a slightly odd shaped CS line
[10:47:55] <GeneralStupid> i actually think that could work… but if it does not work… i have a problem
[10:48:19] <GeneralStupid> LeoNerd: i started working on spi today, really miss i²c…
[10:48:24] <LeoNerd> Hah
[10:48:43] <LeoNerd> I wouldn't for a second. I²C is a cute hack if you want to read temperature sensors or the like, but it's not for /real/ data
[10:49:27] <GeneralStupid> LeoNerd: i have audio codecs which are configured by i²c and i flash 512kB over i²c for our processor. It works great :D
[10:50:01] <LeoNerd> I really wouldn't want to flash half a MiB over I²C
[10:50:02] <GeneralStupid> hopefully SPI works at the end of the week…
[10:50:13] <GeneralStupid> why not? i mean… its slow
[10:50:17] <GeneralStupid> but it works :D
[12:16:40] <Emil> Yo
[12:16:48] <Emil> Do any of you have a i2c decoder?
[12:16:54] <Emil> That just listens to i2c traffic and decodes it?
[12:17:09] <Emil> out through serial for example
[12:19:40] <Emil> Just the code
[13:18:16] <Chillum> Emil: a logic analyzer can record the data and software can decode it
[13:18:43] <Chillum> though I suppose an avr could be programmed to do what you describe
[13:21:08] <_ami_> yup, logic analyzer can do that job.
[13:34:01] <Emil> A continuously sniffing avr would be waaaay better
[13:34:04] <Emil> Anycase
[13:34:33] <Emil> Anyone have experience with the various i2c scanners reporting a different address than the spec says?
[13:35:04] <Emil> And looking at known good protocol, it says another address, which however doesn't work when I use my own avr on it
[13:37:15] <LeoNerd> Remembered about the bitshift?
[14:16:17] <Emil> Okay so
[14:16:26] <Emil> If I use the 7 bit addressing mode
[14:16:43] <Emil> THe known good input uses 0x5A
[14:16:55] <Emil> and with the same settings the avr sends 0x2D
[14:17:21] <Emil> But if I switch to 8 bit addressing mode the avr transmits 0x5A but the address is still wrong
[14:17:31] <Emil> Or rather, the device doesn't respond then
[14:18:35] <Emil> The avr starts to transmit too late
[14:18:42] <Emil> This is seriously cancer
[16:32:53] <|DM|> why did the i2c creators not make the stop/start signal have to be across clock cycle boundries
[16:33:06] <|DM|> Then non-hardware supported implementations wouldnt have to waste so much time polling ;-;
[16:34:38] <specing> its 2016 and you still cannot afford hardware i2c?
[16:45:31] <|DM|> No, I'm just wondering
[16:45:40] <|DM|> I think even the attinys have it
[16:50:18] <LeoNerd> Hrm?
[16:50:29] <LeoNerd> Start/stop are the only times the D lines ever change when the clock line is high
[16:50:48] <LeoNerd> You don't need polling, use pinchange
[17:51:58] <inflex> some nice i2c software implementations on AVR around the place
[17:52:54] <LeoNerd> I have a curious hybrid sw/hw I²C master implementation for the USI ATtiny chips
[17:53:09] <LeoNerd> A curious feature of it lets you use a different pin than the usual USI clock as the SCL pin
[17:53:29] <LeoNerd> I had a case where I wanted to talk to an SPI chip and an I²C chip at different times. This let me do both
[17:56:38] <joebobjoe> LeoNerd: how is that possible to use a different pin than SCL?
[17:57:05] <joebobjoe> Are you toggling USICLK?
[17:57:25] <joebobjoe> Also does anyone know what the GPIO registers are for in the register summary?
[17:57:38] <joebobjoe> They aren't explained anywhere on the spec sheet. Can you use them for storage or something?
[17:57:45] <joebobjoe> GPIO0,1,2
[17:57:52] <joebobjoe> (ATtiny85)
[17:57:55] <LeoNerd> Yes - I use direct bit banging of the actual IO pin that is SCL, combined with software clocking of the USI by using USICLK
[17:58:04] <LeoNerd> The GPIOn registers are not mapped direct to hardware
[17:58:17] <LeoNerd> They're just normal RAM cells, they just happen to be the the IO register address space
[17:58:27] <LeoNerd> So you can use the fancy IO-register instructions on them
[18:03:11] <joebobjoe> LeoNerd: so it is like bonus RAM in addition to the amount of RAM specified by the device overview summary?
[18:03:18] <LeoNerd> Yes
[18:05:35] <joebobjoe> sweet
[18:42:36] <joebobjoe> Weird to me that writing 1 to interrupt flags clears them instead of writing 0
[18:44:40] <LeoNerd> It's considered less likely to do it accidentally
[18:46:40] <joebobjoe> LeoNerd: by what logic?
[18:46:55] <joebobjoe> oh nvm I think I can imagine
[18:47:24] <Casper> register = (1<<asd) | (1<<dfg) | (1<<dfhg);
[18:47:29] <Casper> instead of |=
[18:48:02] <Thrashbarg> or worse IREG &= ~((1<<asd) | (1<<dfg));
[18:49:16] <joebobjoe> Casper: thanks for the example
[18:49:26] <joebobjoe> Thrashbarg: I don't get your example... don't know what asd and dfg are
[18:49:41] <Thrashbarg> asd and dfg are the same as Casper's example
[18:49:46] <joebobjoe> What is the use of USITC = 1 when USICS1 = 1? "
[18:49:47] <joebobjoe> When an external clock source is selected (USICS1 = 1) and the USICLK bit is set to one, writing to the USITC strobe bit will directly clock the 4-bit counter. This allows an early detection of when the transfer is done when oper- ating as a master device."
[18:50:08] <joebobjoe> Thrashbarg: oh, gah, right
[18:50:23] <Thrashbarg> hehe
[18:50:28] <joebobjoe> Thrashbarg: I just saw the IREG and didn't know what that meant, so I didn't know if you were implying something special
[18:50:40] <Thrashbarg> okay
[18:51:37] <joebobjoe> Anyway, how would directly clocking the counter with USITC when USICS1 = 1 enable "early detection" of when a transfer is done?
[18:52:03] <joebobjoe> Does USITC still toggle the SCL pin PORTx register?
[18:54:13] <joebobjoe> LeoNerd: do you know? you said you used USI
[18:54:38] <LeoNerd> The docs aren't very well worded
[18:54:42] <LeoNerd> it takes a while to get used to it
[18:56:37] <joebobjoe> LeoNerd: I just don't see the point yet of having Clock Source: External, positive edge, and 4-bit Counter Clock Source: Software clock strobe (USITC)
[18:56:54] <joebobjoe> LeoNerd: might as keep the 4-bit COunter Clock Source; External, both edges
[18:56:55] <LeoNerd> external clocking is essential for being a slace
[18:56:57] <LeoNerd> slave
[18:57:13] <LeoNerd> Software strobing is useful for asynchronus serial
[19:01:45] <joebobjoe> LeoNerd: I guess what I'm saying is that for Shift/Counter, External/External is the same thing as External/USITC
[19:01:59] <joebobjoe> LeoNerd: USITC toggles the external anyway
[19:02:04] <joebobjoe> which will in turn toggle the counter
[19:02:25] <LeoNerd> It's all somewhat odd, yes.. the inter-relations between software counting/shifting and the external pin
[19:02:32] <LeoNerd> I haven't quite worked out all the details
[19:02:39] <LeoNerd> I just know particular settings that seem to work for me
[19:04:35] <joebobjoe> I wish the AVR simulator worked on mac so I could try it
[19:06:28] <LeoNerd> Eh; I don't care for simulator when I have to talk to real hardware. I.e. all the time
[19:06:38] <LeoNerd> Can't easily connect a real I²C or SPI chip up to that
[19:06:52] <LeoNerd> I much prefer real hardware and a logic probe
[19:08:16] <joebobjoe> Wish I had a logic probe haha
[19:08:26] <joebobjoe> Can't you set up external signal definitions in the simulator?
[19:09:59] <LeoNerd> Perhaps. but that's a lot of effort. and requires a very complete model of the chips I'm working with
[19:10:08] <LeoNerd> That could just as well be buggy
[19:10:42] <LeoNerd> anyway, bedtime. =>
[19:17:04] <Lambda_Aurigae> joebobjoe, you have a spare avr and some LEDs? make your own logic probe.
[19:18:02] <Lambda_Aurigae> logic analyzer is a bit more difficult but still easily doable.
[19:18:46] <Lambda_Aurigae> a chip with 8 i/o pins...read the pins and feed the reading out the USART fast as you can.
[19:19:18] <Lambda_Aurigae> helps if they are all on the same port so you can do one read and send.
[19:36:58] <joebobjoe> Lambda_Aurigae: my avr doesn't have usart, but I guess the USI will suffice?
[23:07:42] <joebobjoe> The USI Buffer Register doesn't seem useful for I2C. It fills on USI timer overflow, right? But USI timer is also used to stretch the clock after the ACK bit... filling the buffer with ACK, 1 bit after the previous byte.
[23:10:19] <joebobjoe> hm