#avr | Logs for 2014-03-02

Back
[00:32:55] * Casper squashes rue_shop2
[00:56:46] <rue_shop2> root@freebee5:/files/temp# ohm -r 900 -i .002
[00:56:46] <rue_shop2> Wattage is: 0.003600
[00:56:46] <rue_shop2> Current is: 0.002000
[00:56:46] <rue_shop2> Voltage is: 1.800000
[00:56:46] <rue_shop2> Resistance is : 900.000000
[00:56:48] <rue_shop2> hmmmm
[00:56:58] <rue_shop2> I think I know the answer
[00:58:39] <rue_shop2> now I need an op-amp current source
[01:09:49] <rue_shop2> damn op-amps cant work within 1.5V of v+
[01:09:50] <rue_shop2> ARG
[01:09:55] * rue_shop2 rethinks again
[01:13:04] <rue_shop2> hmmm
[01:13:19] <rue_shop2> 0.7*3 = 2.1
[01:14:31] <rue_shop2> 1n4001 @ 10mA
[01:14:33] <rue_shop2> ...
[01:32:52] <Casper> make a joule theif that boost the voltage!
[01:38:07] <rue_shop2> what I need is a ground referenced current source
[01:53:49] <Casper> what I need is good sleep
[07:36:20] <naquad> geez, i've finally did it. pulse length is 640-2000 and there was an absolutely stupid bug in source i've sent: it was stopping at \r and \n left for the next time so it was getting <number> than 0
[11:00:57] <zmo> hi!
[11:02:40] <zmo> I got a weird problem I'm struggling to debug, and it'll be hard to make it into a short compilable example: I'm controlling a stepper using an ISR() routine. I set the direction pin up before starting the ISR, and then I generate pulses in the ISR to control the stepper.
[11:03:36] <zmo> The problem is that when I set the direction pin up *before* starting the ISR, the value does not get changed, but it gets changed after like ~1000 steps in the ISR routine
[11:04:04] <zmo> and there's no other code using the direction pin elsewhere
[11:04:12] <zmo> not even in the ISR routine
[11:04:40] <zmo> so what could make the pin value changed with such a weird "delay"? any ideas I could investigate on?
[11:26:01] <zmo> !@#$!@#$!@$!@$ damn I forgot to set the pins as output /o\
[11:26:13] * zmo auto-facepalm
[11:35:59] <jacekowski> zmo: ???
[11:36:13] <jacekowski> zmo: how did the pin change into output then
[11:36:21] <jacekowski> zmo: or was it just random noise changing it
[11:36:40] <jacekowski> or just the pullup resistor
[11:41:58] <naquad> if i'm setting timer1 to fast pwm mode, then its top is ICR1, bottom is 0, but when does it toggle OCAx? at bottom or at OCR1A?
[11:42:05] <naquad> fast pwm mode 14 btw
[11:51:10] <zmo> jacekowski - well, I don't get why it was "almost" working
[11:51:12] <zmo> but still
[11:51:20] <zmo> I'm betting on the random noise
[11:51:23] <zmo> but it got me crazy
[13:53:37] <Roter> i have a question. I sometime cross 12v and ground wires from my atx modded power supply
[13:53:42] <Roter> is it realy bad?
[13:53:49] <Roter> or just dont do it regulary?
[13:54:02] <specing> you could blow a fuse
[13:54:33] <Roter> but what would be the chance?
[13:54:57] <Roter> if i crossed the wires 100 times for 1s , how many fuses would i blow?
[13:54:58] <Roter> :D
[13:55:03] <Roter> aproximetly
[13:58:06] * specing unearths a 500 yo tree
[13:58:15] * specing smacks Roter into the ground with it
[13:59:00] <Roter> i guess that is a stupid question...
[14:11:35] <megal0maniac_afk> specing: I've been waiting for the tree to re-surface
[14:11:54] <megal0maniac_afk> Roter: I hope it blows up. Then you'd be more careful
[14:15:44] <Roter> i dont mean i would do it on purpose, i know its bad, but i just wanted to know how bad it is
[14:15:57] <Roter> a little bit harsh dont you think?
[14:17:47] <megal0maniac_afk> Roter: Not at all. It is always possible to avoid. Blowing the power supply should provide enough motivation for you to exercise the degree of caution necessary :)
[14:18:46] <Roter> alright then, i guess no explosions for me today.
[14:56:54] <bss36504> I'm banging my head off my desk here trying to get this SD card to work. I'm using this: http://www.roland-riegel.de/sd-reader/index.html SD Library, and I can initialize the card, but the partition doesn't open properly. The library attempts to tread the SD card like a superfloppy since it is not reading the partition table at all. I think it is failing somewhere where it has to do an SD block read but I cant tell for sure yet. A
[14:56:54] <bss36504> able to assist?
[15:24:54] <Lambda-Aurigae> bss36504, ummm...would have to duplicate your setup to try it.
[15:25:13] <Lambda-Aurigae> what is your partition formatted to?
[15:26:21] <bss36504> Lambda-Aurigae: Well yes, I suppose you would. The card init's properly, so there is at the very least a solid connection between the MCU and the card. The card is 256MB and is formatted to FAT16, 1 partition.
[15:27:00] <Lambda-Aurigae> and what avr are you using?
[15:27:07] <bss36504> 32U4
[15:27:27] <Lambda-Aurigae> should have enough ram then.
[15:27:33] <bss36504> I thought so haha
[15:35:12] <Lambda-Aurigae> without duplicating your hardware and software setup, no way to know,,,for me at least. I've never used that lib.
[15:36:47] <bss36504> Seems pretty solid. I might look at Petit FS + some custom drivers, I just didnt really want to do that. I'm sort of time constrained, and I've been screwing with this SD stuff for too long.
[15:40:45] <Lambda-Aurigae> I've had mixed success with SD cards...some just work, some just don't.
[15:40:56] <Lambda-Aurigae> and anything over 1GB is,,,,just doesn't.
[15:41:27] <bss36504> Why wouldnt one over 1GB work? if the lib supports SDHC then you should be good.
[15:41:53] <Lambda-Aurigae> well,,,guessing the lib I was using doesn't support SDHC.
[15:42:05] <Lambda-Aurigae> as it's something I threw together myself from the SD docs.
[15:46:46] <bss36504> Ah yeah, thats not light reading for sure. Kind of like reading the USB spec, but way less useful in the long run
[15:57:20] <Lambda-Aurigae> I did that too years ago.
[15:57:36] <Lambda-Aurigae> back before v-usb existed..
[15:57:51] <Lambda-Aurigae> there was a guy who wrote something similar to v-usb on his own completely in assembly.
[15:58:08] <bss36504> dear lord. that must have been quite a job
[15:58:20] <Lambda-Aurigae> same guy wrote a bitbanged ethernet software.
[15:58:33] <bss36504> Does he just have nothing else to do?
[15:59:15] <bss36504> I like to think that I'm technically capable of these sorts of things, as in, I possess the necessary reading comprehension and coding skills, but I definitely don't have the patience.
[15:59:41] <Lambda-Aurigae> http://www.cesko.host.sk/IgorPlugUDP/IgorPlug-UDP%20%28AVR%29_eng.htm
[16:00:16] <Lambda-Aurigae> I used to have the patience but these days my attention span is closer to that of a squirrel on meth than that of a real programmer.
[16:01:22] <bss36504> haha I know the feeling
[16:02:45] <Lambda-Aurigae> http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20%28AVR%29_eng.htm
[16:03:02] <Lambda-Aurigae> this guy even explains what he did and why in his code...it's an interesting read.
[16:04:31] <Lambda-Aurigae> and, considering he did it with an at90s2313-10 overclocked to 12MHz, it is rather awesome.
[16:05:08] <bss36504> Alright thats pretty badass. I'll be sure to take a look.
[16:06:16] <Lambda-Aurigae> v-usb is assembly at the core too but they gave us a nice C wrapper for it.
[16:06:44] <Lambda-Aurigae> neither would I use for a commercial product, being as they are both hacks and not real reliable.
[16:06:53] <Lambda-Aurigae> but you can learn lots from them.
[16:07:15] <bss36504> Oh for sure. Besides LUFA is pretty damn sweet, especially since there are some decent USB chip options now
[16:07:22] <Lambda-Aurigae> I love the igorplug udp too....sends udp packets over ethernet...can't receive but for a remote sensor or something it is fun.
[18:34:30] <naquad> in pwm mode 14 when is overflow set? when TCNT1 reaches ICR1 or just 65535?
[22:06:26] <naquad> i've got ds1302, tried to link it with this library: https://gist.github.com/cosard/4135891 - and i get 85 for minute, second and 25 hour. any ideas what's wrong? thats a third library i'm trying
[22:22:47] <tzanger> naquad: are you getting the same results with each library?
[22:22:54] <naquad> yes
[22:23:58] <tzanger> naquad: that suggests that they're all working fine and they aren't designed for your specific part
[22:24:04] <naquad> :(
[22:24:17] <tzanger> naquad: it's not the end of the world, it's called debugging
[22:24:25] <tzanger> here I'll try to help
[22:24:26] <naquad> i'm a total noob, i can bet that part is ok, wiring is not
[22:24:30] <tzanger> let me grab the datasheet
[22:25:40] <tzanger> ok it looks like perhaps the register map is different
[22:29:58] <tzanger> what is the library you're using now?
[22:30:18] <tzanger> wait
[22:30:35] <tzanger> ds1302_update_time()
[22:30:41] <tzanger> how are you getting the seconds into SEC?
[22:30:56] <tzanger> I don't see a SEC variable anyway
[22:31:13] <tzanger> are you not getting a compiler warning on line 23?
[22:31:33] <naquad> i'm getting dozens of warnings with -Wall
[22:31:37] <tzanger> wow this code is so broken
[22:31:43] <tzanger> why don't you fix your code
[22:31:57] <tzanger> you can't declare a pointer to rtc and then not point it at anything
[22:31:59] <naquad> because its not mine
[22:32:06] <tzanger> oh wait
[22:32:10] <tzanger> you are pointint it
[22:32:12] <tzanger> line 15
[22:32:21] <tzanger> what is SEC though
[22:32:51] <tzanger> you have 'sec' but not 'SEC'
[22:33:12] <tzanger> and if it's sec you want, line 23 should read &sec
[22:33:29] <tzanger> it looks like the library works entirely in the structure
[22:34:21] <tzanger> you will have to get into the library
[22:34:23] <tzanger> whose is it
[22:35:41] <naquad> i don't know
[22:35:44] <naquad> i've just googled it
[22:35:49] <tzanger> so how on earth are you building this
[22:36:04] <ephexis> hi, i really need some help with a question if anyone has a few minutes to spare please
[22:36:06] <tzanger> you've got to have a function called ds1302_update_time() defined somewhere
[22:36:18] <tzanger> ephexis: I can try to help
[22:36:25] <naquad> rtc.c
[22:36:28] <naquad> file is below
[22:36:36] <naquad> there are 3 files in this gist
[22:36:41] <tzanger> oh I see
[22:36:48] <tzanger> sorry I'm used to pastebin, didn't think to scroll down
[22:36:52] <ephexis> tzanger, A line of assembly code is RJMP AGAIN. The corresponding machine instruction is saved in Program memory as the word 0xF9CF at address 0x000A. What address does the program jump to?
[22:37:25] <tzanger> ok here we go naquad
[22:37:27] <tzanger> so
[22:40:14] <tzanger> ds1302_update_time() calls ds1302_comms() and that calls ds1302_read_byte()
[22:40:35] <tzanger> and ds1302_read_byte() takes a register address
[22:40:54] <tzanger> seconds is sec_r and that's defined in rtc.h as 0x81 on line 40
[22:42:54] <tzanger> so looking at the ds1302 datasheet, table 3 on page 9 shows that regiser 0x81 is indeed seconds, but they're stored in BCD, not binary
[22:43:01] <tzanger> so are you intepreting it as BCD?
[22:43:52] <tzanger> ephexis: what does the AVR ISA tell you? I don't have it in front of me
[22:43:52] <naquad> yes
[22:43:55] <naquad> library has this
[22:44:20] <naquad> see ds1302_comms if branch with rw == READ
[22:44:38] <tzanger> hm, interesting
[22:44:48] <tzanger> have you explicitly set the time before using these routines?
[22:45:00] <tzanger> i.e. are there garbage values stored and it's giving you something screwy to work with?
[22:45:17] <tzanger> ephexis: which chip is this for?
[22:46:01] <ephexis> tzanger, sorry, ISA? no particular chip is specified, but we've been working with the atmega8535
[22:46:40] <naquad> nope, i didn't
[22:46:43] <naquad> but will do now
[22:46:51] <ephexis> im not normally one to ask for help with homework but ive spent hours trying to figure this out
[23:48:38] <tzanger> ephexis: I've got to go to bed but if you meet me here in about 9h or so I can help