Back
[05:52:38] <ENHering> mornin'
[06:14:00] <Lambda_Aurigae> merninish.
[06:56:07] <avrdude> do peripherals run independently from the main "cpu", sort of as its own thread? For example if you write to the SPI tx buffer, the SPI peripheral will start clocking out bits in parallell with the main program still running, correct?
[06:57:48] <specing> usually
[07:25:17] <ENHering> stupid question: m4f is different from stm32f4?
[07:25:28] <specing> m4f is an achitecture
[07:25:46] <ENHering> Thanks.
[07:25:58] <ENHering> Is there a m4f with, say, 32 pins?
[07:26:13] <ENHering> Or all of them are big, leggy things?
[07:26:27] <malinus> ENHering: they have a page to look that stuff up you know
[07:26:38] <ENHering> didn't malinus
[07:26:43] <malinus> where you can sort for everything
[07:26:52] <malinus> pins/package/adc's/timers
[07:26:55] <malinus> etc. etc.
[07:27:08] <ENHering> that would be useful, indeed
[07:27:13] <specing> even atmel has such a page
[07:27:21] <malinus> even atmel ;)
[07:27:22] <specing> and others too
[07:27:23] <ENHering> I'll google that
[07:27:33] <ENHering> atmel was bought, wasn't it?
[07:27:54] <specing> yes
[07:28:43] <specing> it is now wholly owned by AT&T. It is expected that in a few months they'll start charging $90 subscription for programmer license
[07:30:17] <twnqx> i feel like specing is the new channel troll
[07:31:15] <ENHering> the smallest m4 from atmel is 48 legs.
[07:31:45] <malinus> haha specing, you will also have to pay to unluck peripherals
[07:31:50] <ENHering> I wonder how those things coordinate so many of them. I would not be able to stand up.
[07:32:48] <sabor> see! that's why they do not move! ;)
[07:33:12] <ENHering> But even the attiny is static.
[07:33:26] <ENHering> Maybe it is too dumb.
[07:33:33] <sabor> haha
[07:37:56] <Lambda_Aurigae> atmel was bought by microchip
[07:38:08] <Lambda_Aurigae> pic owns avr,,,,it was the only way they could ever say that.
[07:38:26] <ENHering> That is what i vaguely remembered...
[07:40:05] <Lambda_Aurigae> they have put out one new chip series so far, an attiny, that has an avr core and pic-like peripherals...
[07:40:15] <Lambda_Aurigae> supposed to be a really mega-ish tiny
[07:40:33] <Lambda_Aurigae> ok..off to break things..err..off to work.
[07:41:22] <ENHering> good luck, Lambda_Aurigae
[07:55:46] <daey> Lambda_Aurigae: what does pic like peripherals mean?
[07:56:23] <daey> do they require special incantations for initialization?
[08:18:34] <skz81> <carabia> while i was disgusted by the documentary, perhaps there's an analogy. the people grew them in captivity in a makeshift forest, and they went among them dressed as pandas not to attach them to humans >> Saw the very same images, made myself the EXACTLY same observation !! :p
[09:27:22] <Lambda_Aurigae> daey, the are like pic peripherals. It has a combination of avr and pic peripherals...attiny871 or something like that.
[09:28:49] <daey> Lambda_Aurigae: i was just curious how they differ from atmega peripherals from the user perspective, as ive only played with avr and some arm
[09:29:15] <Lambda_Aurigae> read the datasheet
[09:47:31] <daey> lol
[10:22:22] <malinus> I love the car industry, blower motor control was just an resistor array until like 2010's... car enginers :V
[10:22:25] <malinus> e
[10:23:15] <Chillum> some people say if it ain't broke don't fix it
[10:23:25] <Chillum> car manufacturers are like if the number of fires it causes are less than the cost of the recall, don't fix it!
[10:24:38] <malinus> yeah why use one of the 13mcu's
[10:24:50] <malinus> and it's a free heating element :)
[10:25:11] <learath> that's everyone.
[10:42:20] <ENHering> rfd. read the fu*king datasheet... :)
[10:43:12] <ENHering> I'm curious too. I'll search for the datasheet.... :)
[10:46:59] <ENHering> could not find that. Bout found a very interesting bridge between CAN and SPI:
http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf
[10:47:14] <ENHering> But...
[10:49:16] <skz81> root
[10:49:20] <skz81> oopds
[10:49:46] <ENHering> Don't type the password here!
[10:49:48] <ENHering> :)
[10:50:56] <Chillum> password is "oopds"
[10:51:09] <ENHering> Ah, ok.
[10:51:28] <skz81> no that's a 'oops' with an extra d
[10:51:48] <skz81> the host (erm emdeded device) I was trying to log to has no password anyway
[10:51:51] <ENHering> Extended oops.
[10:52:05] <skz81> (dev release, prod one don't even have a shell/ console)
[10:52:43] <skz81> yup, or some kind of oops that startup at system boot and then keeps running in background
[10:52:55] <skz81> ha no that's oopsd, not the same ! :p
[10:53:45] <ENHering> Somebody should make that...
[10:57:34] <ENHering> You may find this interesting:
https://pt.aliexpress.com/item/Free-Shipping-1pcs-lot-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduin0/32498344057.html?spm=2114.13010608.0.0.BFvYwo
[11:35:52] <muldover> can someone recommend dev board like on this image
http://i.ebayimg.com/images/g/7f8AAOSw-kdXzapV/s-l1600.jpg
[12:10:05] <carabia> < specing> it is now wholly owned by AT&T. It is expected that in a few months they'll start charging $90 subscription for programmer license
[12:10:08] <carabia> ^ :D
[12:15:44] <ENHering> One question. Stupid another. Is there a hardware reason for the SPI to lock, like a grounded clk line?
[12:16:01] <ENHering> And then it locks waiting for transmission to end?
[12:16:31] <ENHering> But if that was the case then the IC could not be programmed by ISP, right?
[12:16:45] <carabia> mmm
[12:17:17] <carabia> i think you can screw it up if you don't set it in master and then pull the cs low
[12:17:57] <carabia> it won't clock the line cause it's a slave, and you gotta re-enable the module, afaik
[12:18:32] <ENHering> This behavior is predicted
[12:19:01] <carabia> or if it's floating, I guess
[12:19:12] <ENHering> If in master CS is input, then if cs low, module drops to slave
[12:19:52] <carabia> muldover:
http://www.ebay.com/itm/NEW-Stm32f4-Discovery-Stm32f407-Cortex-m4-Development-Board-ST-link-V2-/311499640085?hash=item4886d34d15:g:T9cAAOSwp5JWYrZK ... thank me later
[12:20:08] <bss36504> ENHering: If your SPI module is in master mode, the CS line is a regular GPIO.
[12:20:30] <carabia> bss36504: yeah but there's a gotcha like that
[12:20:49] <bss36504> What is that gotcha?
[12:20:57] <ENHering> bss36504: It is in the datasheet. Wait.
[12:21:06] <carabia> if you use the SS pin
[12:21:25] <carabia> ...I think
[12:22:04] <ENHering> ATMega328pp Datasheet, page 172: If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a Master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it. To avoid bus contention, the SPI system takes the following actions:
[12:22:24] <bss36504> Huh no shit
[12:22:30] <bss36504> guess I missed that point
[12:22:42] <bss36504> It's never really been an issue for me I guess
[12:23:42] <carabia> never for me, either
[12:24:32] <carabia> but that shouldn't be the case anyway
[12:25:02] <ENHering> It is a good defense against master competition
[12:25:35] <ENHering> carabia: seen this?
https://pt.aliexpress.com/item/Free-Shipping-1pcs-lot-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduin0/32498344057.html?spm=2114.13010608.0.0.BFvYwo
[12:26:43] <carabia> i have similar ones off hotmcu
[12:28:39] <carabia> oh wait i rechecked that muldover link, i have to revise my suggestion
[12:28:55] <carabia> http://www.atmel.com/tools/atatmel-ice.aspx here, muldover :)
[12:30:35] <muldover> for hobby is a bit too expensive :)
[12:30:52] <muldover> also beginner
[12:31:12] <ENHering> try USBtiny from adafruit. 23 dollars only.
[12:31:34] <carabia> :D
[12:31:47] <carabia> try usbasp from ebay. only 3 dollars
[12:31:48] <ENHering> Works well.
[12:32:03] <ENHering> 3 dollars? better. Much better.
[12:32:41] <muldover> i thought to buy this
[12:32:42] <muldover> http://www.ebay.com/itm/Programmer-MKII-AVR-PRO-support-ATMEL-STUDIO-6-7-BETTER-FROM-USBASP-/262623273748?hash=item3d25912314:g:BSIAAOSwFe5Xzao9#shpCntId
[12:33:14] <carabia> yes, i like the shit(clone)-makers' business model of outsourcing technical support to #avr
[12:34:05] <specing> muldover: stm32 discovery
[12:35:00] <ENHering> looks good this one muldover sent
[12:35:07] <carabia> $17?? Way too expensive!!
[12:35:12] <carabia> you can get like 5 usbasps!
[12:35:23] <carabia> maybe one will work! resell the rest on ebay for $$
[12:38:04] <specing> muldover: official stm32 devkits with full programmer and DEBUGGER included start at $7
[12:38:48] <bss36504> Do you people buy Dollar Tree socket wrench sets too?
[12:40:34] <carabia> yeah, or just get cheap $1-2-3 boards and a few dollar stlink clone
[12:40:46] <carabia> they just. work.
[12:41:17] <carabia> ENHering: let me go over that code now that i'm a bit fresher than yday
[12:41:28] <specing> carabia: I have discoveries already, cheap enough
[12:41:33] <ENHering> Thanks, carabia.
[12:41:46] <carabia> specing: they're cool too, as you can just break off the stlink
[12:41:52] <carabia> oh wait no that's nucleo.
[12:42:50] <carabia> but yeah, same shit. but he wanted an avr programmer
[12:42:56] <carabia> his loss, i s'pose
[12:44:13] <ENHering> carabia, I have just commented all USART code and tested again. Same shit.
[12:44:25] <carabia> ENHering: shouldn't matter
[12:44:57] <ENHering> Shouldn't. But in case of a segfault or a tack overflow, that would make a difference.
[12:45:01] <ENHering> stack
[12:45:49] <specing> carabia: discovery seems breakable as well
[12:46:08] <ENHering> I bought a discovery from mouser at $14 a long time ago
[12:46:09] <carabia> alright, not all of them though
[12:47:10] <carabia> ENHering: are you still using cbi(SPSR, SPI2X); sbi(SPCR, SPR1); sbi(SPCR, SPR0); ?
[12:47:22] <LeoNerd> *shudder*
[12:47:29] <carabia> I know, right
[12:47:43] <ENHering> yep, carabia. fsc/16
[12:47:57] <carabia> that's /128
[12:48:40] <ENHering> sorry. cbi, cbi, sbi. I changed it yesterday
[12:48:48] <carabia> ok
[12:50:18] <ENHering> This seems so weird. I commented all the ReadFloatViaSPI, then uncommented the _delay_ms(1) and it hanged.
[12:51:47] <ENHering> This looks so much like the problem is completely elsewhere. Like an unitialised pointer. But there is nothing on the heap, I believe.
[12:52:33] <carabia> in that case, you could try running it through a simulator
[12:52:45] <ENHering> No... The led switched off. It is just a m a z i n g l y s l o w...
[12:53:20] <carabia> really the only thing I can come up with is that F_CPU is wrong
[12:53:37] <carabia> but it seemed not to be... div/8 is off...
[12:54:02] <ENHering> yep.
[12:54:14] <ENHering> I believe I'll change that IC.
[12:56:00] <carabia> you should verify delay working properly just by setting a led blink 1hz or so
[12:56:36] <carabia> and nothing else
[12:56:45] <ENHering> That programmer link muldover sent still looks good. It can power up 3.3v ICs from USB. I need an external power supply to power up those 3.3V ICs
[12:57:30] <ENHering> I'll try that, carabia. But even if I comment the delay and uncomment the transfer, it still slows down.
[12:59:26] <carabia> sure, let's take one at a time
[13:01:52] <carabia> ENHering: stlinkv2s will have 3v3 out
[13:02:06] <ENHering> Nope. What I said before is wrong. When only SPI transfer is uncommented, it hangs.
[13:02:29] <carabia> oh wait you're powering avrs 3v3 too...
[13:02:56] <carabia> so, with nothing but a blink it hangs?
[13:05:28] <ENHering> not tested yet. In a few minutes. I have to leave the room for a while
[13:39:57] <ENHering> Carabia, _delay_ms() is working fine. A program with 500 delays with led on and 500 delays with led off is almost 1Hz
[13:40:33] <ENHering> Sorry: carabia, _delay_ms() is working fine. A program with 500 delays with led on and 500 delays with led off is almost 1Hz
[13:43:48] <ENHering> I'll try a SPI only test now.
[14:23:34] <carabia> ENHering: yes?
[14:23:43] <ENHering> TEsting now...
[14:36:08] <ENHering> carabia: Test code:
http://pastebin.com/L06H51g8
[14:40:30] <ENHering> carabia: Better code:
http://pastebin.com/2J9QctZJ
[14:41:42] <carabia> mmm, and?
[14:41:58] <ENHering> Hanging when test transfer is on
[14:42:10] <ENHering> I'll upload the same code in anothe module
[14:42:14] <ENHering> another
[14:45:20] <ENHering> Hangs in another module too.
[14:45:32] <ENHering> It is a problem with SPI class.
[14:45:38] <ENHering> In Master mode.
[14:46:33] <ENHering> Hey everybody. This testcode can be useful for your AVR too... You can help to increment the code.
[14:46:57] <ENHering> If you wish...
[14:47:08] <carabia> c++ makes me a sad panda
[14:47:28] <ENHering> Don't be...
[14:48:06] <carabia> is the spi stuff still the same as yesterday save for the prescaler?
[14:48:14] <ENHering> yep
[14:50:12] <carabia> Don't know, i'd probably move writing one to SPE as the last operation
[14:50:33] <carabia> not sure if it makes a difference
[14:50:45] <ENHering> This is what I run on the arduino, to test the sensor module:
http://pastebin.com/f2J3BJUS It puts the arduino into SPI MAster mode and everything works.
[14:51:29] <carabia> meh
[14:51:29] <specing> > pastebin.com
[14:51:32] * specing cringes
[14:51:47] <carabia> hey it's not that bad with adblock
[14:53:41] <carabia> ENHering: well logic states that this code shouldn't run on the arduino board either
[14:54:18] <ENHering> It seems to be an identical master init in both cases
[14:54:19] <carabia> just can't see the culprit. perhaps it's in plain sight and i'm overlooking it. Often happens with me
[14:54:28] <ENHering> To me also.
[15:14:00] <Emil> Hmmm
[15:14:03] <ENHering> Found.
[15:14:08] <ENHering> Shit.
[15:14:13] <Emil> God damn I'm beginning to suspect something is wrong with the compiler
[15:14:23] <ENHering> Maybe it is.
[15:14:32] <specing> no Ada support?
[15:14:50] <ENHering> uint8_t nIgnore = g_cSPI.Transfer(0); DON'T HANG
[15:14:59] <ENHering> g_cSPI.Transfer(0); HANGS
[15:15:59] <Emil> Your spi is probably fucked because you are not enabling pullup
[15:16:08] <Emil> On the CS pin
[15:16:14] <ENHering> Nope.
[15:16:19] <ENHering> The problem was found
[15:16:36] <ENHering> g_cSPI.Transfer(0) returns a value
[15:16:57] <ENHering> if I do not collect it, the microcontroller hangs
[15:17:04] <Emil> ehwat
[15:17:12] <ENHering> That is it.
[15:17:19] <Emil> What kind of shit is that?
[15:17:35] <ENHering> The kind that I found here
[15:17:42] <Emil> What was the cli argument to generate assembly?
[15:17:51] <ENHering> Wait...
[15:18:34] <ENHering> http://pastebin.com/wLVfZ46H
[15:18:54] <ENHering> line 76
[15:19:23] <ENHering> Line 51 too
[15:19:59] <Emil> Might also want to define wrapping and such there
[15:20:12] <ENHering> Don't know how
[15:22:43] <ENHering> carabia: ?
[15:26:12] <ENHering> Anybody knew about this?
[15:45:52] <carabia> Aaahhh
[15:46:57] <carabia> does the compiler optimize the spdr access away when you discard the value and hence the SPIF flag never gets cleared...?
[15:47:56] <ENHering> Maybe
[15:48:03] <carabia> can't really figure out another reason
[15:48:18] <ENHering> I could never see this coming
[15:48:33] <ENHering> Nor I would
[15:48:43] <carabia> i think that has to be it
[15:50:41] <ENHering> I have to leave now. I'll be back in three hours. Carabis, if it were not for your suggestion to write a simple test program I would have taken many days more to find this bug. Thanks a lot!
[15:50:51] <carabia> it usually helps
[15:50:51] <ENHering> Carabia*
[15:51:09] <carabia> you could go around it by doing something like volatile uint8_t ret = SPDR; return ret; I guess
[15:51:39] <ENHering> Could work
[15:53:38] <carabia> at least to test
[15:53:46] <ENHering> I will
[15:54:42] <ENHering> I 'll be back later
[15:54:44] <Emil> I'm seriously suspecting something shit is going on with the compiler
[15:54:54] <ENHering> Thanks a lot everybody
[15:55:02] <Emil> I should fucking code in asm
[15:57:03] <bss36504> Emil: Have you inspected the code generated by the compiler?
[15:58:35] <Emil> bss36504: tried and compared with a functioning one
[15:58:42] <Emil> bss36504: what tool would you recommend?
[15:58:50] <Emil> I just used avr-objdump but it is not very effective
[15:59:05] <bss36504> no idea, I've never felt the need to do it
[16:00:11] <Emil> But seriously, how come printing min, avg and max values every 1024 trigger of that interrupt kill everything
[16:00:17] <Emil> when printing just the avg works just fine
[16:00:47] <bss36504> stack overflow?
[16:01:27] <Emil> It should warn of that since I'm not loading anything dynamically
[16:01:38] <Emil> Hngnghnghhg this is fucked up
[16:01:56] <bss36504> Not necessarily. A super deep call depth could cause a SE without being "warn-able"
[16:02:22] <bss36504> I dunno what your code looks like so it's just speculation anyway
[16:02:40] <Emil> I'm not doing recursive calls, either
[16:04:04] <bss36504> Well then, hard tellin not knowin
[16:04:29] <Emil> Yeah
[16:04:36] <Emil> Hmm, should I just share the code
[16:06:08] <bss36504> I'll look at it if it's not super long
[16:07:09] <Emil> Only 161 lines long, so nothing, really
[16:07:20] <bss36504> Alrighty
[16:07:21] <Emil> Just setup functions and ISRs
[16:09:39] <Emil> aaaah
[16:09:42] <Emil> Could it be that
[16:09:44] <Emil> It probably is that
[16:09:52] <bss36504> Glad I could help
[16:10:41] <Emil> Booyaa
[16:10:49] <Emil> I could still share the code, though
[16:11:04] <bss36504> Does it work now?
[16:11:15] <Emil> The effect of the issue was quite apparent, a steadily rising number
[16:11:19] <Emil> It seems to be working
[16:11:24] <bss36504> That will do it
[16:11:51] <Emil> Okay
[16:12:03] <Emil> Lemme just quickly check if here's anything I wouldn't want to let out, probably not
[16:12:06] <Emil> anycase
[16:12:21] <Emil> the issue was simple, let me demonstrate it quickly
[16:13:22] <bss36504> The root-cause-analysis indicates that this was a "PEBKAC" situation.
[16:14:08] <Emil> I had an ISR like this ISR(INT0_vect){unsigned int t=TCNT1; TCNT1=0; lp=8*lp+t; lp>>3; uart_write_n16(lp); uart_write('\n);}
[16:14:17] <Emil> Can you tell me what is wrong with that?
[16:14:51] <Emil> Where lp is a global unsigned int
[16:15:33] <Emil> But yeah, it was a PEBKAC error
[16:16:14] <Emil> Let me know if you'd like to hear what the problem is here
[16:16:30] <bss36504> So you were obviously overflowing lp eventually
[16:16:36] <bss36504> how did that break everything?
[16:16:46] <CORDIC> ``lp>>3'' is nop.
[16:16:52] <Emil> Sorry
[16:16:55] <Emil> it was lp>>=3;
[16:17:00] <Emil> I just wrote it wrong here
[16:17:13] <Emil> ISR(INT0_vect){unsigned int t=TCNT1; TCNT1=0; lp=8*lp+t; lp>>=3; uart_write_n16(lp); uart_write('\n);}
[16:17:18] <CORDIC> Then ``+t'' is nop.
[16:17:34] <Emil> What do you mean +t is a nop?
[16:17:38] <bss36504> yeah, how?
[16:18:25] <CORDIC> ``lp=8*lp+t; lp>>= 3;'' is optimized to nop.
[16:18:59] <CORDIC> And I guess TCNT1 is 0 when ISR is called.
[16:19:09] <bss36504> Why? It's a global variable?
[16:19:27] <Emil> CORDIC: it is not optimized away, why would it be
[16:19:37] <CORDIC> Ah, ``lp'' should be `volatile'?
[16:19:53] <Emil> CORDIC: it actually works even if it not named volatile, I tried both ways
[16:19:54] <bss36504> and this ISR is called based on an external pin, Emil is just using TCNT1 in the ISR
[16:20:07] <Emil> TCNT1 is correct when entering the ISR
[16:20:08] <Emil> anycase
[16:20:18] <bss36504> yeah the volatile is more about making it so that successive reads to a global aren't optiimized away
[16:20:29] <CORDIC> xD
[16:20:30] <bss36504> the compiler still generates the code to write to it in the ISR
[16:20:37] <Emil> The point is that I'm doing low pass filtering (fixed point version)
[16:20:47] <bss36504> I mean, it's good habit anyway, so theres that
[16:20:51] <Emil> And in the working example I had lp=15*lp+t
[16:21:09] <Emil> and of course lp>>=4;
[16:21:22] <Emil> So obviously if I use 8 instead of 7 it grows
[16:21:37] <bss36504> Right, that's what I was thinking
[16:22:42] <bss36504> cause it's like a
[16:22:43] <Emil> So just changing it to 7 made it work
[16:23:00] <Emil> CORDIC: but, are you sure that lp=7*lp+t; lp>>=3 would be optimised away?
[16:23:01] <bss36504> times 8 + t divide by 8, which would grow
[16:23:05] <Emil> Why would it be?
[16:23:08] <Emil> specing: yeah, exactly
[16:23:20] <CORDIC> Emil: Sorry, I was wrong.
[16:23:46] <bss36504> Tis a learning experience for us all.
[16:24:13] <Emil> I'm glad you got something useful out of this
[16:24:23] <Emil> I was banging my head for like two hours :D
[16:24:34] <Emil> Which is progress compared to my earlier days when I banged my head for 6 hours
[16:24:46] <bss36504> well except me. I write the best code. Just ask anyone. Ask carabia how great my code is. it's the greatest, no mistakes. and im going to use this code to fix america. ok? because the code we have now is a disaster. our code is being outsourced to jina
[16:24:59] <Emil> And I adhered to the XKCD'S code quality control also ;)
[16:25:13] <CORDIC> You might as well ``lp+= (t>>3);'', right?
[16:25:33] <Emil> Hmm?
[16:25:54] <Emil> CORDIC: the point of doing it like I write is that otherwise smaller numbers would be eradicated with the shift
[16:26:00] <bss36504> CORDIC: yeah when it was "8*lp", but that would still grow without bound.
[16:26:27] <bss36504> but then Emil changed it to 7*
[16:26:28] <Emil> CORDIC: and I need the previous value of lp (low pass) to matter more than the current read
[16:29:30] <bss36504> alright, glad got it working Emil
[16:29:36] * bss36504 , OUT!
[16:32:01] <Emil> bss36504: btw thanks for telling me about ISRs and the volatile
[16:32:16] <Emil> s
[16:32:56] <Emil> Especially that with volatiles, any access to them is not generated away but in ISRs the first access is always there
[16:33:05] <CORDIC> That ISR still makes no sense to me.
[16:33:35] <Emil> CORDIC: why so?
[16:33:38] <Emil> I can explain it
[16:38:19] <Emil> CORDIC: ?
[16:38:40] <Emil> CORDIC: I'm low pass filtering a value in the ISR and sending it out of uart
[18:19:23] <Jartza_> hmmh
[18:33:25] <Jartza> http://i.imgur.com/OBVzCHJ.png
[18:33:29] <Jartza> http://i.imgur.com/0MULvE8.png
[18:33:33] <Jartza> it works
[18:37:12] <Tom_L> what is that a screenshot of?
[18:37:20] <Tom_L> studio 7?
[18:40:45] <carabia> looks like it
[18:41:05] <Tom_L> i don't have 7 loaded
[18:41:10] <Tom_L> stopped at 6
[18:41:13] <carabia> the ONLY proper tool for atmel-stuff
[18:41:19] <Tom_L> pfft
[18:41:23] <Tom_L> i avoid it
[18:41:23] <carabia> yes
[18:41:27] <carabia> shh now commie dogs
[18:41:38] <Tom_L> un necessary bloated windows code
[18:41:50] <Tom_L> 5 wasn't bad
[18:41:56] <carabia> "i just like writing my shitty build stuff by hand and use nano!!"
[18:42:00] <Tom_L> 6 forward is a pig
[18:42:10] <carabia> MSVS is the best
[18:42:15] <Tom_L> i use programmers notepad or notepat ++
[18:42:23] <carabia> well, same shit
[18:42:36] <specing> note pat pat
[18:42:50] <Tom_L> used to use copy con
[18:42:55] <specing> GNU Emacs is life
[18:42:58] <specing> GNU Emacs is love
[18:43:00] <Tom_L> ( we will see how old he is )
[18:43:15] <carabia> when AS is a complete front and backend for code, libraries, and build + debugger front and backend all out of the box
[18:43:29] <carabia> for the WHOLE ATMEL FAMILY OF MCUS
[18:43:57] <Tom_L> if you can get it to install properly the first time
[18:44:00] <carabia> /OF COURSE/ you'd rather use your shitty notepad++ and write build shit by hand
[18:44:22] <Tom_L> studio's editor sucks too
[18:44:33] <carabia> I am really curious, how do loonix-proponents always find everything uninstallable or unrunnable for anything MS-related
[18:44:46] <carabia> compared to emacs or vim, I am sure MSVS sucks
[18:44:53] <carabia> compared to your notepad++, I am sure it's heavenly.
[18:44:59] <Tom_L> i'm not a proponent of any os in particular
[18:45:05] <carabia> though emacs sucks bollocks with its meta key bs
[18:45:12] <Tom_L> pico isn't bad
[18:45:16] <carabia> ... :D
[18:45:19] <carabia> okay then.
[18:45:22] <Tom_L> umm.. i forget the other one
[18:45:32] <carabia> nano and pico are usually the lightweight editors
[18:45:37] <carabia> those, or ed.
[18:45:40] <Tom_L> i use pico in a hurry and the other one usually
[18:45:47] <carabia> i am sure you'd love to use ed to edit your code
[18:45:57] <Tom_L> i have one called ed
[18:45:58] <carabia> ed is so much better than visual studio. Oh yes. and it's communist, too. Whoa.
[18:46:03] <Tom_L> i've used it for years
[18:46:13] <carabia> yeah, i'm sure you'll find it faster to use than visual studio
[18:46:18] * Tom_L stops feeding the troll
[18:46:40] <carabia> feels like you're the one trolling comparing some shitty notepad++ to MSVS's editing capabilities
[18:46:46] <carabia> and pico, for fucks sake. hahah
[18:47:07] <Tom_L> i wasn't comparing pico to anything
[18:47:41] <carabia> msvs is bad, pico isn't. okay.
[18:48:16] <carabia> i would rather gouge my fucking eyeballs than trying to write code on pico
[18:48:23] <carabia> try*
[18:48:57] <carabia> and with ed i'd probably just kill myself
[18:49:18] <Tom_L> if i'm in linux i generally use gedit
[18:51:33] <carabia> unnecessary bloat gnome/gtk code
[18:54:09] <carabia> GNU Emacs, on the other hand...
[18:55:00] <carabia> is one lean mean editing machine. with webkit-integration you don't ever even have to use any other program than GNU Emacs.
[19:04:46] <Jartza> Tom_L: I'm running atmel studio in parallels coherence mode on my mac :)
[19:04:52] <Jartza> so it's just another window on my mac desktop
[19:05:11] <Jartza> and only because I don't think there's support for UPDI in mac/linux much yet
[19:07:43] <Jartza> the only thing that seems to support attiny817 on my mac is gavrasm :)
[19:26:31] <Jartza> wonder when other avr prorammers start to support UPDI
[19:26:41] <Jartza> as it's half-duplex uart
[19:43:50] <rue_house> did you get it to talk?
[19:43:58] <rue_house> I remember gavrasm
[19:44:02] <rue_house> been a while
[20:08:03] <ENHering> I use Sublime Text and avrdude.
[20:08:18] <ENHering> But I know nothing
[20:12:26] <ENHering> AS runs well on Parallels?
[20:43:44] <Emil> Hmmm
[20:43:46] <Emil> Any idea
[20:44:07] <Emil> Why isn't my TIMER0_OVF_vect triggering when other interrupts are
[20:46:38] <Emil> TCCR0A=(1<<WGM01); //CTC TCCR0B=(1<<CS01)|(1<<CS00); //64 as divisor OCR0A=249 //with this should result in 10kHz
[20:46:48] <Emil> Then ISR(TIMER0_OVF_vect) is defined
[20:47:07] <Emil> And then I say TIMSK0=(1<<TOIE0); later
[20:47:27] <Emil> But still, the interrupt isn't triggering
[20:48:01] <Emil> Oh
[20:48:06] <Emil> Apparently CTC never overflows
[20:58:18] <Emil> Hmm
[20:58:19] <Emil> Strange
[20:58:44] <Emil> I though that when there was no vector defined for a given interrupt, it would perform a full reset
[20:58:47] <Emil> apparently not
[20:59:31] <Emil> AND EXCUSE ME BUT WHAT
[20:59:46] <Emil> TIMER0_COMPA_vect DOES NOT EXIST FOR ATMEGA328P :DDDDDD
[21:01:03] <Emil> This is not cool
[21:01:04] <Emil> not cool at all
[21:02:04] <Emil> wAIT
[21:02:17] <Emil> It is named in the datasheet but not in the savannah website
[21:02:28] <Emil> Is my day fucking saved
[21:04:51] <cehteh> i c .. tinys name them TIM1_...
[21:05:03] <cehteh> but megas should be TIMER....
[21:22:56] <ENHering> When you ask the extended fuse of ATmega328p to be 0x07, but the programmer complains that after setting the fuse it reads 0xFF, what does it mean?
[21:24:13] <cehteh> you or the programmer fucked up .. or just a hickup
[21:24:55] <cehteh> some programmers/avrdude/avr chips have some problems sometimes
[21:26:06] <Casper> if there is no reserved bit, something is wrong
[21:26:21] <ENHering> but 0x07 and 0xff give the same result, in the end.
[21:26:22] <Casper> some bits may be just "unchangable"
[21:26:40] <Casper> for example, while flashing ISP, you can't disable ISP
[21:30:38] <cehteh> yes (some) fuses are latched, maybe you need to powercycle to see them in effect
[21:30:59] <ENHering> Thanks
[22:20:08] <ENHering> Anybody know a simple way to convert from float to string in AVR?
[22:21:25] <CapnJ2> you mean C++ or C ?
[22:21:30] <CapnJ2> AVR is the architecture...
[22:21:36] <ENHering> avr c
[22:23:10] <ENHering> dtostrf does not seem to be working.
[22:23:39] <CapnJ2> http://www.avrfreaks.net/forum/convert-float-string-and-put-lcd
[22:25:05] <ENHering> I've seen that, CapnJ2. Thanks. I'll try implementing ftoa as in the last post of that link
[22:27:02] <CapnJ2> but what value do you get?
[22:27:08] <CapnJ2> do you get ????????? or 0.0000000 ?
[22:27:40] <ENHering> I get strange numbers... Which do not agree with the data that comes form the senros
[22:27:43] <ENHering> sensors
[22:35:37] <CapnJ2> try using static values
[22:35:55] <CapnJ2> Just to check if the problem is in your sensor side, or on the floating point library side
[22:36:18] <CapnJ2> try 0.5, 1.0, 3.14159 or any other value
[22:43:26] <ENHering> Thanks, CapnJ2
[22:43:58] <CapnJ2> did it work?
[22:44:08] <ENHering> Works with static values.
[22:44:27] <ENHering> But with the data received from sensors it does not.
[22:44:35] <CapnJ2> ok, now try this
[22:44:41] <ENHering> Data may be getting corrupted somewhere
[22:44:49] <CapnJ2> instead of reading data "directly" from the sensor, copy it to another variable
[22:44:53] <CapnJ2> like, to a float variable
[22:45:39] <CapnJ2> float latch_s1;
[22:45:47] <CapnJ2> latch_s1 = sensor_data_stuff;
[22:46:09] <ENHering> I copy it to a struct with three floats. One for each vector component.
[22:46:30] <ENHering> I'll try what you suggested
[22:46:36] <CapnJ2> no, it won't work
[22:46:54] <CapnJ2> if you are alredy copying your sensor data into memory, its the same
[22:46:56] <ENHering> It would be very good to be able to debug the code
[22:47:36] <CapnJ2> what chip are you using?
[22:48:12] <ENHering> atmega328p
[22:48:29] <ENHering> https://hackaday.io/project/11724-yauvc-yet-another-unmanned-vehicle-controller
[22:48:34] <CapnJ2> and what are you reading? (sensor -> real wolrd)
[22:48:59] <ENHering> I read sensor data via SPI from another atmega328p
[22:49:44] <ENHering> https://www.youtube.com/watch?v=UVaXAsN1HfU
[22:49:55] <ENHering> https://www.youtube.com/watch?v=VHyZjcJpICg
[22:49:57] <CapnJ2> but how are you encoding your "data" thru the SPI?
[22:50:05] <ENHering> These videos show the modules
[22:50:28] <ENHering> Data is encoded in four bytes.
[22:50:49] <ENHering> They are stored in an union and read as a float
[22:51:11] <CapnJ2> Union?
[22:51:11] <CapnJ2> or Struct?
[22:51:18] <CapnJ2> if it is a union, then there is your problem....
[22:51:31] <ENHering> union, to convert from 4 bytes to float
[22:51:44] <ENHering> it works in the arduino environment.
[22:52:00] <ENHering> why would it be a problem?
[22:52:31] <CapnJ> back
[22:52:39] <CapnJ> may I take a peek at your code?
[22:52:41] <CapnJ> if not, its ok
[22:52:44] <ENHering> union uConvertArrayToFloat {
[22:52:44] <ENHering> float f;
[22:52:44] <ENHering> unsigned char b[4];
[22:52:46] <ENHering> };
[22:52:53] <CapnJ> oic...
[22:53:03] <ENHering> You may, for sure.
[22:53:22] <ENHering> Just wait a moment, please.
[22:54:47] <ENHering> http://pastebin.com/2UbxChRD
[22:55:15] <ENHering> All the code is available here, open source:
https://xp-dev.com/hg/YAUVC
[22:56:48] <CapnJ> are you getting values "too" low or "too high" ?
[22:56:53] <CapnJ> or negative instead of positive?
[22:57:04] <ENHering> All around 2.something
[22:57:22] <ENHering> Makes no sense.
[22:57:35] <ENHering> AA
[22:57:35] <ENHering> 0.000, 2.427, -0.052
[22:57:35] <ENHering> MA
[22:57:37] <ENHering> 0.000, 2.426, -0.064
[22:57:39] <ENHering> PA
[22:57:41] <ENHering> 0.000, 2.402, -0.087
[22:57:48] <ENHering> AA is accelerometer average
[22:57:57] <ENHering> MA is magnetometer average
[22:58:04] <ENHering> PA is barometer average
[22:58:07] <CapnJ> I'll go back to basics
[22:58:15] <CapnJ> try sending constant values from the "sender" side
[22:58:23] <CapnJ> and see if you can catch it correctly
[22:58:28] <ENHering> I have an option for that.
[22:59:42] <ENHering> But it is not producing the right values too
[23:01:15] <ENHering> TE
[23:01:16] <ENHering> 0.000, 2.387, -0.083
[23:01:28] <ENHering> TE for test values, produced in the sender side.
[23:03:03] <_ami_> Hi
[23:03:32] <_ami_> my circuit at RST pin is like below
[23:03:32] <_ami_> GND ----- [Resistor/10k] ----- SWITCH -------RST pin
[23:03:55] <_ami_> I think it should work just fine since RST has internal pullups?
[23:04:32] <_ami_> what is right value for pulldown resistor? 10k is too much?
[23:04:55] <_ami_> according to
http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_applicationnote_avr042.pdf , it should be around 330 ohms
[23:05:31] <CapnJ2> well, you could check the max amps your "PIN" can take
[23:05:50] <CapnJ2> and use Ohms law
[23:07:22] <CapnJ2> R = V/I
[23:07:39] <CapnJ2> if you are using a ATMega328P, max Amps per PIN is 40mA
[23:07:50] <CapnJ2> R = 5 / 40 mA, R = 5 / 0.04, R = 125 Ohms
[23:08:08] <CapnJ2> so 125 Ohms is the "smallest value" for the resistor you could use
[23:08:29] <ENHering> CapnJ2: Thanks for your help. It is late here. I have to go to bed. I believe to have a problem with the physical SPI bus.
[23:08:57] <CapnJ2> so anything above 125 Ohms is good to go.... but try not being too close to the critical resistance
[23:09:08] <CapnJ2> 330 Ohms will work on a ATMega328P, and so will a 10K Ohms will work as well
[23:09:22] <CapnJ2> ENHering, my pleasure, will see you here tomorrow
[23:11:00] <ENHering> Hope so, CapnJ2. Good night.
[23:11:29] <CapnJ2> 10k Ohms on 5V would yield 0.5 mA, which is in a very secure zone, very low from the 40mA limit
[23:34:24] <_ami_> CapnJ2: thanks for nice explanations. Makes sense. :)
