#avr | Logs for 2012-05-15

Back
[01:40:39] <seba-> if you connect a 5V avr to 12 VDC do you fry it?
[01:42:33] <inflex> yes
[01:42:42] * inflex has done so in the past... goes *pop*
[01:42:52] <inflex> usually after about 5~10 seconds
[01:42:57] <seba-> :/
[01:43:18] <inflex> Sometimes you get a zombie chip, where some parts still work but others are dead
[01:43:19] * seba- cries
[01:43:22] <seba-> yeah
[01:43:27] <seba-> i can ISP program it
[01:43:31] <seba-> some pins work
[01:43:33] <seba-> most of them don't
[01:45:00] <inflex> yep, sounds about right
[01:45:29] <seba-> :(
[03:52:04] <profil> Hello! I'm trying to set the 3 timers in my 328P (arduino uno) to be equivalent, but I doesn't get the right result when dimming 2 RGB LEDs. This is what I came out with from the datasheet http://codepad.org/6Ts5bA4r, what's wrong?
[03:53:30] <Casper> you forgot something
[03:53:40] <Casper> 2 out of the 3 timers are 16 bits
[03:56:55] <profil> yes, timer1 and timer2? But I only want 8-bit pwm
[03:58:01] <profil> I thought I set up 8 bit fast pwm with the WGM bits?
[03:58:09] <profil> Casper: ^
[04:10:35] <profil> ahh, now I found my error.. I set the WGM bits wrong
[04:10:55] <profil> they are on both TCCRnA and TCCRnB..
[05:27:28] <antto> what are these fuse bits exactly?
[06:22:39] <marloshouse> antto: what are fuse bits in general?
[06:22:52] <antto> what do they mean exactly
[06:23:15] <marloshouse> you mean, what do they do? or what is the meaning of a particular bit?
[06:23:19] <marloshouse> not sure what you're asking
[06:23:27] <antto> what do they do
[06:23:48] <marloshouse> they pre-wire the cpu to work in a particular way
[06:23:53] <marloshouse> electrically
[06:24:18] <marloshouse> like, they prewire the cpu to drive the oscillator in a particular way
[06:25:10] <antto> i'm trying to port some code from python (which i don't understand) into C++ .. the code itself is for flashing .hex via serial port (FTDI chip) onto atmega162
[06:25:33] <antto> and there are functions like: getFuseH() getFuseL()
[06:25:48] <Grievre> antto: learn python
[06:25:51] <Grievre> it's seriously easy
[06:25:54] <Grievre> and a useful language to know
[06:25:56] <marloshouse> like, if you laid out a circuit board, with several oscillator options, and had them all wired, before you could 'use' your circuit, you'd have to choose from one of your circuits, so you'd blow the fuses on the circuits you don't need and the one you want would remain. that's where the term 'fuse circuit' comes from.
[06:27:35] <marloshouse> antto: yes, there are two sets of fuses (or sixteen of them) a H fuse, 8-bits, and an L fuse (another 8 bits). each fuse bit corresponds to a particular CPU function that you want enabled or disabled.
[06:27:53] <marloshouse> you have to look at the atmega162 datasheet to see what the fuse bits are assigned to
[06:28:04] <marloshouse> and you need to have them set properly else the cpu won't run
[06:28:31] <antto> how are they involved in flashing .hex via serial port?
[06:28:42] <marloshouse> but if you're flashing an existing and running cpu chip, sometimes the easiest thing to do is simply read the fuse bits and make sure they stay set properly
[06:29:07] <antto> hm
[06:29:13] <marloshouse> i don't have the 162 datasheet in front of me, but...
[06:29:26] <antto> what do you mean? "stay set properly"
[06:29:32] <antto> can they, uhm.. "move" ?
[06:30:09] <marloshouse> well, you can set some fuse bits that might disallow an in-use COM port used for flashing the device
[06:30:20] <marloshouse> flashing occurs over a set of wires
[06:30:35] <marloshouse> and you have to have the fuses set properly otherwise those functions become unavailable
[06:30:59] <antto> uh, i don't understand.. O_o
[06:31:09] <marloshouse> (trying to explain, bear with me)
[06:31:24] <marloshouse> let me ask first, what is your electronics background
[06:31:48] <antto> just to be sure, i'm talking about flashing .hex from a computer, since i do not have what you call a "programmer"
[06:32:00] <antto> some device which you put the chip on..
[06:32:15] <marloshouse> yes, how do you connect to this device you're intending to flash to
[06:32:16] <antto> the device runs in "bootload" mode
[06:33:04] <antto> USB cable, but the device has this FTDI chip, which emulates a serial port
[06:33:17] <marloshouse> right
[06:33:24] <antto> my electronics background is near zero ;]
[06:34:21] <marloshouse> the fuses 'program' the CPU (atmega162) to be able toproperly communicate with the FTDI chip... if the fuses are changed, that interface between the cpu and the ftdi could end up not working (depending on how the board is built).
[06:34:35] <marloshouse> so, no, the fuses don't 'move'
[06:34:50] <marloshouse> but they can change if you change them
[06:35:11] <antto> in other words, i should NEVER touch the fuses, otherwise i'll screw up the chip
[06:35:12] <marloshouse> since you're simply uploading a hex file, to an existing running device, you probably don't need to worry about the fuses
[06:35:19] <marloshouse> pretty much, correct
[06:35:38] <marloshouse> the fuses, for instance, control how the oscillator runs on the cpu
[06:35:42] <antto> it's possible that this python code has functions which aren't actually used (grr)
[06:36:14] <marloshouse> change them, and the oscillator doesn't run... no more chip (as far as your fdti is concerned and so forth)
[06:36:27] <antto> as far as i can see, the hex flash function looks like this:
[06:37:46] <antto> app calls a function setLED() O_o
[06:38:09] <antto> then sends 'a' and want's to read 'Y'
[06:38:37] <marloshouse> sends to what and reads from what?
[06:38:58] <antto> to the serial port on which the device is connected
[06:39:02] <marloshouse> k
[06:39:26] <antto> then sends 'P' <- this is for "programming mode" .. wants to read 0x0D
[06:39:44] <antto> then sets address to some "startaddress"
[06:39:48] <antto> then there's a loop
[06:39:57] <marloshouse> k, seems simple enough
[06:40:04] <antto> which i guess is the actual hex data transmition
[06:40:26] <antto> so, so far i didn't see the readFuse() functions being used
[06:40:53] <antto> there are a few variables which are predefined in the python code
[06:41:07] <marloshouse> which is probably correct, fuses require special functions to set, since they are so critical
[06:41:34] <marloshouse> generally a decent programmer will make if difficult to inadvertently set the fuses
[06:41:36] <antto> flash_size = 16384; eeprom_size = 512; flashpage_size = 128; eeprompage_size = 4;
[06:41:49] <marloshouse> k
[06:42:16] <antto> i know what the flash_size is, that's the space for the actual program (the hex)
[06:42:32] <antto> eeprom is the internal eeprom in the chip, 512kb
[06:42:46] <antto> the other 2 variables are not clear to me
[06:43:32] <marloshouse> me neither, i could guess, but i'd have to see the whole program.
[06:43:39] <marloshouse> at this point i wouldn't sweat the fuses
[06:43:53] <marloshouse> they're important, but not for what you're trying to do it sounds like
[06:44:05] <marloshouse> you're just reflashing an existing board
[06:44:37] <antto> yes, if i brake the bootloader - i'm screwed, i'll have to either buy another chip (with pre-flashed bootloader) or that "programmer" device
[06:44:37] <marloshouse> when i'm building something from scratch i have to worry about the fuses (at least once) :)
[06:45:09] <marloshouse> you are correct... but a good bootloader should be unbreakable... (i say should)
[06:45:34] <antto> how can i tell if it is?
[06:48:48] <antto> also something that bugs me
[06:49:04] <antto> that setAddress() function..
[06:49:53] <antto> is it possible i setAddress() somewhere where the bootloader is, and accidentally part of the hex is written there, which would most likely scramble it?
[06:57:24] <karlp> whee, new gcc supports int24_t, that will come in handy :)
[07:14:44] <DarkSector> Wow, so JTAGEN fuse is by default enabled on the ATmega32
[07:14:53] <DarkSector> does that even make sense?
[07:15:06] <DarkSector> because I programmed the chip and found out that the fuse was enable.d
[07:15:38] <DarkSector> Hmm, interesting.
[07:25:14] <Tom_itx> always pays to check
[07:25:59] <DarkSector> Lol I don't even have a JTAG programmer/debugger and I am playing with TAP
[07:26:04] <DarkSector> accidental fail
[07:26:26] <Tom_itx> keep it up and you'll own one
[07:26:39] <lifeeth> :)
[07:26:42] <DarkSector> :)
[07:26:47] <DarkSector> also I now have a new problem
[07:26:51] <DarkSector> on a different chip
[07:26:59] <DarkSector> ATmega32 different piece
[07:27:32] <DarkSector> I programmed PORTC = 0x00 with sink configuration but my PORTC is outputting a high on all pins
[07:27:45] <DarkSector> is there any fuse responsible for such kind of error?
[07:29:52] <Tom_itx> did you set the direction register?
[07:30:06] <lifeeth> deafults to input right?
[07:30:12] <lifeeth> JTAG?
[07:30:14] <Tom_itx> one can never be sure
[07:30:15] <DarkSector> DDRC = 0xFF;
[07:30:24] <DarkSector> I made sure of that though.
[07:30:31] <DarkSector> D port seems to be working
[07:30:35] <lifeeth> Bah the slow mobile internets
[07:30:35] <Tom_itx> isn't jtag on portc?
[07:30:37] <Tom_itx> i forget
[07:30:38] <DarkSector> Yep
[07:30:47] <lifeeth> Disable jtag
[07:30:49] <lifeeth> :)
[07:30:50] <DarkSector> But apart from TAP all other pins should work
[07:31:00] <Tom_itx> oh gawd, you screwed the pooch again!!
[07:31:00] <lifeeth> DarkSector : try disabling jtag
[07:31:00] <DarkSector> it's already disabled JTAGEN is not set
[07:31:07] <lifeeth> hmm
[07:31:22] <Tom_itx> try a different port
[07:31:28] <Tom_itx> as a test
[07:31:30] <DarkSector> yeah D works
[07:31:32] <lifeeth> DarkSector : Have you tried turning it off and on again? :D
[07:31:34] <DarkSector> I tried it just now
[07:31:40] <DarkSector> yeah, that I haven't done :)
[07:31:42] <DarkSector> hang on
[07:32:38] <DarkSector> Nope
[07:32:41] <DarkSector> C port is busted
[07:32:49] <Tom_itx> u sure?
[07:32:57] <DarkSector> Yeah because all other ports work
[07:33:06] <DarkSector> and C just outputs a high
[07:33:06] <Tom_itx> u sure jtag is disabled?
[07:33:12] <DarkSector> Definitely
[07:33:18] <Tom_itx> how do you know?
[07:33:34] <DarkSector> Even if JTAG is disabled, all other pins should work
[07:33:43] <Tom_itx> portc is full of jtag and TOSCx
[07:33:50] <DarkSector> uh, yes
[07:33:56] <Tom_itx> and that fills the port
[07:34:08] <Tom_itx> i know i looked :)
[07:34:16] <DarkSector> No no, that's right
[07:34:20] <Tom_itx> i don't know what to tell you
[07:34:26] <DarkSector> but JTAGEN is disabled
[07:34:30] <DarkSector> I rechecked.
[07:34:45] <Tom_itx> buy a jtag programmer and test the port for jtag :)
[07:34:49] <Tom_itx> it may not be borked
[07:35:03] <DarkSector> oh can't do that, out of monies for now'
[07:35:14] <DarkSector> what if I program the D port and then check the C port
[07:35:17] <Tom_itx> it was somewhat of a joke but it would be a test
[07:35:27] <DarkSector> yes, I take jokes seriously :D
[07:35:36] <DarkSector> ah electronics humor
[07:35:41] <DarkSector> u so silly
[07:36:57] <Tom_itx> TWI is on port c too
[07:37:15] <DarkSector> yes
[07:37:50] <DarkSector> Wow, this is new, when I measure the level on SDA the port D seems to stop
[07:38:26] <DarkSector> No false alarm it doesn't stop
[07:38:35] <DarkSector> also, PORTC is still outputting high
[07:38:42] <DarkSector> all of it
[07:39:08] <Tom_itx> what is this wired to? a breadboard or something else
[07:39:15] <DarkSector> yep
[07:39:17] <DarkSector> breadboard
[07:39:24] <Tom_itx> make sure you aren't pulling it high somehow
[07:39:36] <DarkSector> I replaced the chip, the other one works
[07:39:38] <Tom_itx> beyond that i have no other bits to offer
[07:39:46] <DarkSector> so I know that the breadboard isn't the problem
[07:39:50] <Tom_itx> or bytes for that matter
[07:39:54] <DarkSector> bytes?
[07:40:16] * Tom_itx bytes DarkSector
[07:40:24] <DarkSector> heh
[07:40:45] <Tom_itx> it is odd but i dunno what else to try
[07:40:53] <DarkSector> CS and E engineers are hungry people
[07:40:56] <DarkSector> bits and bytes
[07:41:04] <DarkSector> no wonder most of us are fat
[07:42:14] <RikusW> and they talk a lot too, words and double words :-P
[07:42:41] <DarkSector> lol
[07:43:04] <Tom_itx> word structures are often used too
[07:44:33] <DarkSector> Wow, another interesting thing I noticed
[07:44:41] <DarkSector> 100 ms on a different chip shows different delay
[07:45:00] <DarkSector> the one with the bad C PORT shows 100ms delay as maybe 10 or 20 ms
[07:45:02] <Tom_itx> do you have a 3rd chip?
[07:45:06] <RikusW> using RC osc ?
[07:45:12] <DarkSector> External Crystal
[07:45:16] <DarkSector> 16Mhz
[07:45:16] <Tom_itx> you may wanna check your breadboard
[07:45:26] <DarkSector> aww man I hate rewiring
[07:45:36] <Tom_itx> ok
[07:45:44] <Tom_itx> leave it and never know
[07:45:51] <DarkSector> okay rewiring is fun suddenly.
[07:46:11] <Tom_itx> well, you know what you've got going on, we don't
[07:46:53] <DarkSector> Is there any capacitor on AREF?
[07:46:59] <DarkSector> ever required I mean?
[07:47:10] <Tom_itx> i forget but i think there should be
[07:47:17] <lifeeth> Its the ADC reference
[07:47:17] <DarkSector> 0.1uF?
[07:47:18] <lifeeth> so..
[07:47:25] <DarkSector> yeah that shouldn't matter
[07:47:27] <DarkSector> in this case
[07:47:34] <DarkSector> because right now I have it hooked to 5V
[07:47:42] <Tom_itx> aref should be tied to something err at least avcc
[07:47:56] <Tom_itx> is avcc on 5v too?
[07:48:04] <DarkSector> yeah AVCC has 10uH to VCC
[07:48:06] <DarkSector> yeah 5V
[07:48:19] <DarkSector> and a 0.1uF capacitor to GND
[07:48:36] <Tom_itx> that sounds like their standard procedure for that
[07:48:47] <DarkSector> yep, I confirmed it from the datasheet
[07:49:41] * Tom_itx gives DarkSector a star and moves him to the front of the class
[07:50:36] <DarkSector> http://ragefac.es/370
[07:51:49] * Tom_itx heads off to the coal mine
[07:53:23] <RikusW> I used 39uH and 100nF
[07:53:24] <DarkSector> okay all ports work on the good chip including port A. They show the same delay on all ports. This is going to be my control
[07:53:30] <DarkSector> RikusW: for AVCC?
[07:53:35] <RikusW> yes
[07:53:41] <RikusW> I got the 39uH cheaply
[07:53:46] <DarkSector> I see
[07:53:58] <DarkSector> I have about a 100 of 10uH with me
[07:54:00] <DarkSector> only used 1
[07:54:02] <RikusW> a little more than 10uH wont hurt, only be a better filter
[07:54:24] <RikusW> smd or th ?
[07:54:25] <Tom_itx> may change what gets filtered
[07:55:12] <DarkSector> th
[07:55:18] <RikusW> me too
[07:55:21] <DarkSector> I get my stuff from wholesale mart
[07:55:26] <DarkSector> only get reels of 100
[07:55:28] <DarkSector> or more
[07:55:30] <DarkSector> no less
[07:55:32] <RikusW> I had a hard time finding smd inductors
[07:56:14] <DarkSector> Okay I finally have some notion of what's wrong on the bad chip
[07:56:26] <DarkSector> it shows delay of less than what it's been programmed
[07:56:37] <DarkSector> like 10 ms is probably 1ms for it
[07:56:44] <DarkSector> and PORTC is all high
[07:57:19] <DarkSector> 2.5V on PORTC all pions
[07:57:22] <DarkSector> *pins
[07:58:16] <lifeeth> DarkSector : Delay less than what it is been programmed for?
[07:58:21] <DarkSector> yes
[07:58:29] <DarkSector> If I progam the delay for 100ms
[07:58:36] <DarkSector> I get about say 10 ms
[07:58:41] <DarkSector> on the LED
[07:59:28] <DarkSector> so now I am going to compare its fuses with the control
[08:00:14] <RikusW> DarkSector: check CKDIV8
[08:00:18] <karlp> are you sure you have the right fuses set?
[08:00:26] <DarkSector> yes about to check
[08:00:28] <karlp> between clock mixups and jtag, that sniffs like fuses
[08:01:13] <RikusW> DarkSector: what avr is that ?
[08:01:25] <DarkSector> oh god
[08:01:27] <DarkSector> my hand burnt
[08:01:29] <DarkSector> the chip is burning
[08:01:53] <DarkSector> RIP AVR ATmega32
[08:02:16] <Grievre> don't let the magic smoke out!
[08:02:29] <DarkSector> I literally burnt my finger
[08:02:49] <DarkSector> hey lifeeth looks like I got another trademark.
[08:02:56] <DarkSector> on my finger.
[08:02:57] <lifeeth> :D
[08:03:00] <lifeeth> ROFL
[08:03:03] <lifeeth> Magic blue smoke
[08:03:05] <lifeeth> or violet
[08:03:19] <RikusW> DarkSector: I have a free jtagice mki clone for a m32
[08:03:30] <RikusW> you'll have to load it onto another avr
[08:03:31] <DarkSector> RikusW: wow, how?
[08:03:45] <DarkSector> RikusW: shall I tell you my address? I'll pay for the shipping :)
[08:03:55] <RikusW> http://sites.google.com/site/megau2s/home/jtag
[08:04:08] <RikusW> DarkSector: you can build it yourself
[08:04:19] <DarkSector> ooh interesting.
[08:04:21] <DarkSector> thanks RikusW
[08:04:22] <RikusW> you'll only need something like a m8 or m328
[08:04:24] <DarkSector> I'll give it a look
[08:04:30] <DarkSector> yeah I have both
[08:04:38] <DarkSector> I am done using Arduinos.
[08:04:43] <DarkSector> must rip apart chips.
[08:04:43] <RikusW> you'll need AVRStudio 4 to use it
[08:04:50] <DarkSector> oh crap
[08:04:52] <RikusW> or avarice in Linux
[08:04:54] <DarkSector> I have 5 installed.
[08:05:00] <DarkSector> yeah linux will work.
[08:05:06] <RikusW> 5 don't support jtagice mki
[08:05:16] <RikusW> and you need AS4 to compile it
[08:05:21] <RikusW> or AS5
[08:05:28] <DarkSector> plau
[08:05:30] <DarkSector> err
[08:05:32] <DarkSector> okay
[08:05:45] <RikusW> its all asm
[08:05:51] <DarkSector> I CANT BELIEVE THIS.
[08:05:57] <DarkSector> The chip works after cooling down
[08:06:03] <RikusW> DarkSector: I have disassembled the original mki fw
[08:06:17] <DarkSector> RikusW: sweet
[08:06:19] <RikusW> and made my own version
[08:06:32] <karlp> cooling down?
[08:06:39] <karlp> umm, how hot was it, and why?
[08:06:45] <RikusW> rather don't ask how long it took ;) (months...)
[08:06:45] <DarkSector> VCC + GND
[08:06:48] <DarkSector> that's why
[08:07:00] <DarkSector> RikusW: you sir are a genius.
[08:07:05] <RikusW> you reversed vcc and gnd ?...
[08:07:18] <DarkSector> Well actually when I removed the chip
[08:07:28] <specing> It doesen't look like you are implementing anything atm
[08:07:32] <DarkSector> I put VCC on GND while replacing it
[08:07:37] <specing> wrong window
[08:07:41] <DarkSector> thanks specing
[08:07:44] <DarkSector> that was very helpful
[08:08:19] * specing is hiding behind his ww shield
[08:09:23] <RikusW> DarkSector: so you have another m32 left alive ?
[08:09:34] <DarkSector> Yes apparently I do :)
[08:10:08] <lifeeth> DarkSector : move to 328p
[08:10:08] <DarkSector> Ooh the fuses are different
[08:10:08] <DarkSector> win
[08:10:13] <DarkSector> lifeeth: butwai?
[08:10:14] <RikusW> good
[08:10:18] <lifeeth> easier to source
[08:10:28] <RikusW> how about m324a its cheaper than m328p
[08:10:43] <DarkSector> ah
[08:10:52] <DarkSector> RikusW: availability might be an issue
[08:11:33] <RikusW> I got mine from rs-online.com
[08:11:49] <DarkSector> Okay first fuse: BOOTSZ is different: BADCHIP has it as 256W_3F00 and good chip has it as 2084W_3800
[08:12:07] <DarkSector> must see what BOOTSZ does
[08:12:12] <RikusW> what is the hex values ?
[08:12:39] <rvsjoen> is it possible to modify the system time by writing to the TCNT1 in an atmega1284P ?
[08:12:41] <RikusW> that only changes the bootsector size, it won't affect the ports
[08:12:52] <rvsjoen> I can't seem to get it working :/
[08:12:57] <RikusW> rvsjoen: why not, its is writable
[08:13:13] <RikusW> do you have an os on the chip too ?
[08:13:31] <DarkSector> bad: 0xDF 0x1F good: 0xD9 0x1E
[08:13:35] <rvsjoen> it's running a customized AVR2025 IEE802.15.4 stack
[08:14:01] <DarkSector> aha! BODLEVEL is supposed to be 2v7 it's 4.0
[08:14:16] <RikusW> rvsjoen: its probably keeping the time variable somewhere in ram
[08:14:29] <DarkSector> brb lunch.
[08:15:01] <rvsjoen> basically, the library already provides a function for gettime() (namely pal_get_current_time()) so I tried to inverse it and implement pal_set_current_time() like this http://dpaste.com/748463/
[08:15:55] <lifeeth> DarkSector : I thought you were in IST
[08:15:59] <rvsjoen> according to the documentation, TCNT1 should contain the 16 least significant bits, while sys_time should contain the 16 most significant bits
[08:17:27] <rvsjoen> sys_time is also declared volatile
[08:17:47] <RikusW> rvsjoen: you do know that TCNT1H must be written before TCNT1L ? or do you use TCNT1 = x; ?
[08:18:39] <rvsjoen> thats news to me, i'll look into that, thanks
[08:18:49] <DarkSector> lifeeth: IIT?
[08:18:59] <lifeeth> DarkSector : Indian Standard Time
[08:19:05] <DarkSector> lifeeth: oh yeah, I am
[08:19:18] <DarkSector> lifeeth: I haven't had lunch though, been sleeping.
[08:21:47] <DarkSector> ladies gentlemen and horses I have fixed the bad chip.
[08:22:06] <DarkSector> and I thank you all for your tremendous support.
[08:22:18] <DarkSector> I now have 2 ATmega32s
[08:23:10] <RikusW> antto: you'll basically want to leave the fuses alone, anyways a bootloader cannot change them
[08:23:31] <RikusW> DarkSector: so it was the fuses ? :)
[08:23:38] <DarkSector> Yes it was the fuses.
[08:23:55] <RikusW> just remember to turn on JTAGEN before trying the mki clone
[08:23:55] <DarkSector> and I've unknowingly been using internal osc
[08:24:02] <DarkSector> when I have an external crystal attached.
[08:24:07] <antto> RikusW: do you know what this "pagesize" means?
[08:24:09] <DarkSector> yes definitely I'll do that
[08:24:27] <RikusW> antto: the page size of the flash
[08:24:37] <antto> and what is it exactly?
[08:24:38] <RikusW> antto: you need to write the avr page by page
[08:25:03] <RikusW> its usually about 64 or 128 bytes depending on avr
[08:25:12] <antto> i know the chip has 16KB for hex
[08:25:38] <antto> and in the python code, a variable "pagesize = 128" is defined
[08:25:38] <RikusW> DarkSector: what kind of programmer do you currently have ?
[08:26:15] <DarkSector> AVR ISP MKII
[08:28:06] <RikusW> DarkSector: nice, the original or a clone ?
[08:28:20] <DarkSector> Original, bought it from ATMEL
[08:28:34] <RikusW> I got a dragon instead
[08:29:03] <DarkSector> I know
[08:29:07] <DarkSector> I was supposed to get one
[08:29:11] <RikusW> but since building my own stk500 clone + jtag mki clone I don't really use it for avr, its now reserved for avr32
[08:29:16] <DarkSector> but then lifeeth's ordering got delayed :)
[08:29:31] <DarkSector> I really really need a tutorial on AVR fuses.
[08:30:17] <RikusW> DarkSector: on my site there is my RavrProg utility, basically the programming dialog of AS4/5
[08:30:31] <RikusW> but a bit better, it compiles in linux using Qt4
[08:30:41] <DarkSector> is this the site? https://sites.google.com/site/megau2s/home
[08:30:46] <RikusW> http://sites.google.com/site/megau2s/home/supporting-software
[08:31:05] <RikusW> you'll have to use qmake first
[08:31:34] <DarkSector> you are around on #avr right RikusW I mean usually?
[08:31:42] <RikusW> the AS4 fuse programming dialog was better than AS5...
[08:31:46] <RikusW> usually yes
[08:32:01] <RikusW> I'm gmt+2
[08:32:03] <DarkSector> okay cool, when I start using it, I'll ping you and ask you if I have questions
[08:32:05] <DarkSector> oh
[08:32:14] <DarkSector> I am GMT+5:30
[08:32:21] <DarkSector> so not that much difference I think
[08:33:05] <RikusW> I compiled my app in Windows, but the win Qt sdk is like 4GB and it was painfull to get working....
[08:33:22] <RikusW> and there is still some issues in winXP...
[08:33:25] <DarkSector> I see
[08:33:35] <RikusW> but it works fine in Linux
[08:33:52] <RikusW> even with the AVR ISP MKII and dragon
[08:35:16] <RikusW> DarkSector: http://www.image-share.com/ipng-875-235.html
[08:37:12] <RikusW> DarkSector: one more thing, turning on a fuse means setting it to 0....
[08:40:07] <RikusW> antto: there is 128 pages of 128 bytes each on the m162 (128*128=16384)
[08:40:31] <antto> oh, so these are like sort of sectors?
[08:43:21] <RikusW> yes
[08:43:35] <RikusW> the bootloader erase the flash page by page
[08:43:46] <RikusW> just before rewriting them
[08:44:47] <RikusW> after loading the page you'll need to send 'm' to write the page
[08:45:34] <antto> ahum
[08:47:31] <RikusW> antto: if you connect a terminal app to you bootloader and type 'a' it should echo 'Y'
[08:54:39] <RikusW> you'll probably do 'e' 'A' <start of page 0 == 00 00> loop for all pages { loop 64 times { 'c' ll 'C' hh } 'A' <start of page> 'm' 'A' <next page> }
[08:54:53] <RikusW> and 'A' seems to use word adressing, not byte addressing....
[08:55:17] <RikusW> so 'A' (byteaddr >> 1)
[08:56:05] <antto> yeah, i almost wrote the code (looking at the C sources you linked to yesterday, and the original python code)
[08:56:14] <antto> trying to figure out which is right ;]
[08:56:28] <antto> i hope i don't f*ck up the bootloader
[08:56:38] <RikusW> improbable
[08:56:55] <RikusW> read the lockbits and check them
[08:57:04] <RikusW> it should be set to protect the bootloader
[08:57:25] <antto> do i wanna do that?
[08:57:54] <RikusW> just send 'r' to the bootloader and check the hex value of the returned byte
[08:59:27] <RikusW> seems your bootloader doesn't support changing the lockbits with 'l' so you cannot change it
[08:59:53] <antto> what kind of terminal app i need?
[09:00:08] <RikusW> hterm maybe, oor your own app ?
[09:00:57] <RikusW> if lockbit 4 is 0 you are safe
[09:01:02] <RikusW> 0xEF
[09:01:42] <RikusW> see BLB11 in the m162 datasheet
[09:16:24] <antto> i think it doesn't respond at all
[09:17:09] <RikusW> sending a should echo Y
[09:18:00] <RikusW> use minicom in linux
[09:18:07] <RikusW> or hyperterminal in win
[09:18:19] <RikusW> and do set the baud to 19200 8n1
[09:18:27] <antto> i think now it responded
[09:18:32] <antto> 0xFF
[09:19:23] <RikusW> FF is not good...
[09:19:35] <RikusW> means you could overwrite the bootloader
[09:19:51] <RikusW> don't you know someone with a programmer ?
[09:19:54] <antto> x_X
[09:19:58] <RikusW> set BLB11 to 0
[09:19:58] <antto> nope
[09:20:07] <antto> what's BLB11?
[09:20:14] <RikusW> boot lock bit 11
[09:20:19] <RikusW> check the m162 ds
[09:21:39] <RikusW> just keep away from the last 512 bytes or 1kb of flash, thats where the bootloader are
[09:22:05] <RikusW> have to go
[09:54:25] <antto> i hate pdfs
[10:05:34] <OndraSter> why do ARMs often sink or drive only upto 5 - 10mA tops?
[10:05:41] <OndraSter> that makes them fairly useless often
[10:05:53] <OndraSter> or you need to use external buffers and what not
[10:06:04] <OndraSter> screw that, xmegas can do 20mA everywhere, somewhere even more I think
[10:07:01] <OndraSter> 25mA
[10:07:12] <OndraSter> 200mA per gnd/vcc pin
[10:07:31] <OndraSter> which means... if you have got 4 sets of vcc and gnd pins, you can do 200mA on EACH side of the chip?
[10:08:33] <OndraSter> ah I see
[10:08:43] <OndraSter> two giant notes
[12:25:56] <_abc_> Hello. What static source analyzer would work well with mingw and gcc?
[12:30:14] <_abc_> Does valgrind work with avr-gcc?
[12:30:18] * _abc_ tries
[12:40:01] <karlp> valgrind uses the underlying operating system to work, so.... no.
[12:40:20] <karlp> it replaces syscalls with ones that monitor, wihtout syscalls, you don't get valgrind.
[12:41:01] * RikusW hooked some winapi's, it works nicely for hacking stuff
[12:41:22] <karlp> that's rather different to avr-gcc...
[12:42:21] <Kev> winapi ?
[12:42:22] <antto> RikusW: i think i got the code for flashing the hex working, BUT it's very slow O_o
[12:43:27] <RikusW> how slow for say 1kb ?
[12:43:43] <RikusW> you should write code to read the flash too
[12:43:54] <RikusW> so that you can verify what you have written
[12:44:03] <antto> the original python app flashes the hex for not more than say 20 or 30 seconds
[12:44:18] <antto> mine takes just 2 seconds to increment 1 percent O_o
[12:44:32] <RikusW> at 19200 you get like 2kb/s....
[12:44:53] <RikusW> well there is overhead so say 1kb/s
[12:45:12] <antto> hm..
[12:45:36] <antto> the hex is around 15kb
[12:46:04] <antto> ehm i meant the actual data, not the size of the .hex file itself
[12:46:07] <RikusW> it should probably take like 20s
[12:46:12] <RikusW> 10s then
[12:46:31] <antto> yeah that's about how much it takes for the python app to flash it
[12:46:51] <antto> in the python code, i saw something about "fast mode"
[12:46:56] <antto> lemme see it
[12:47:04] <RikusW> did you dump the python app's commands ?
[12:47:18] <antto> what do you mean?
[12:47:36] <RikusW> there is auto increment, so you don't have to set the address for each word...
[12:48:07] <antto> yeah
[12:48:09] <antto> i have this
[12:48:38] <antto> gotta put some debug cout <<
[12:50:07] <antto> well, yeah, there's autoincrement going on
[12:50:38] <antto> in the py code, there's this 'Z' command being sent
[12:52:18] <antto> i guess it writes one page at a time (aka 128bytes) ??
[12:52:34] <antto> without the 'c' 'C' all the time
[12:52:35] <antto> hm
[12:53:07] <RikusW> yes it seems so
[12:53:16] <RikusW> you must send low then high bytes
[12:53:28] <RikusW> I just had a peek at the xoxbox code
[12:53:40] <RikusW> so 'Z' 128 bytes
[12:53:48] <RikusW> and that writes the page for you too
[12:53:49] <antto> at it's bootloader?
[12:54:01] <RikusW> so no 'm' anymore when using Z
[12:54:10] <antto> hm
[12:54:13] <RikusW> yes I downloaded its bootloader code
[12:54:27] <RikusW> Z would be double the speed
[12:54:36] <antto> what happens for when there remains data which is less than the page size?
[12:54:58] <RikusW> and 'z' reads a page
[12:55:17] <RikusW> you need to fill it with FF FF
[12:55:36] <antto> hm.. cool
[12:55:53] <antto> i'll try that
[12:56:07] <antto> btw, i tryied what you said about the lockbits
[12:56:13] <antto> command 'l' doesn't work
[12:56:23] <antto> it immediately returns '?'
[12:56:41] <antto> brb
[12:57:44] <RikusW> yes l isn't implemented
[12:57:55] <RikusW> 'r' should return the current lockbits
[12:59:45] <_abc_> I tried to run splint on avr-gcc code which works, it does not like some gcc constructs. Like #define macro( var, ... ) <- the dots
[13:00:06] <_abc_> Is there an interest in hacking a patch for splint to swallow that kind of problem, and also binary constants and other gcc-isms?
[13:00:24] <_abc_> I am interested in contributing (I am not a flex/bison expert)
[13:02:20] <karlp> if splint doesn't support ... in #defines, I'd say splint is a very out of date package.
[13:02:38] <karlp> or you need to turn on some gcc options?
[13:04:09] <_abc_> karlp: splint is so out of date that there is a wikipedia request to remove its page
[13:04:15] <_abc_> karlp: BUT there is nothing else?
[13:04:24] <_abc_> I am not aware of any gcc options on splint
[13:04:39] <karlp> it's actually a splint faq.Can I use variadic macros in Splint?
[13:04:40] <karlp> Sorry, Splint does not yet support variadic macros. We hope to fix this in a future release.
[13:05:02] <karlp> sorry, I'm not doing any static analysis on my embedded code. (I should be I know)
[13:05:17] <karlp> I use check to run unit tests on small parts of it, but nothing more.
[13:05:43] <_abc_> check?
[13:05:58] <_abc_> I am not pedantic on mebedded like that but it is sane to do that
[13:06:09] <karlp> it's only sane if it's possible :)
[13:06:18] <_abc_> My firmware frequently exceeds 5000loc for small avrs and I can't afford to fix 20-100 units later
[13:06:51] <_abc_> Seriously, how hard would it be to marry the gcc .flex file with the splint one and cause splint to understand what it needs to
[13:06:51] <karlp> you can have a look at compiling with clang, it has some static analysis apparently,
[13:07:00] <_abc_> Yes I heard about that
[13:07:08] <_abc_> I think I have clang installed
[13:07:16] <karlp> or, just put up with splint's issues on variadic macros, and hope that you get something useful.
[13:07:23] <karlp> don't try and get complete coverage
[13:07:28] <_abc_> Would the macros not all be expanded if I run the preprocessor on the sources first?
[13:07:52] <_abc_> karlp: splint simply bails when it sees a variadic macro and there are plenty of those in avr-gcc libc
[13:07:53] <karlp> if you're lucky.
[13:08:01] <_abc_> karlp: lucky?
[13:08:18] <_abc_> I expect to need to wrestle with preprocessor output later to trace back the thing to the original file
[13:08:22] <karlp> you probably can get it to save all the preprocessed outputs, and then have splint run on them,
[13:08:35] <karlp> yeah, comparing back to the source will start getting tedious
[13:08:53] <_abc_> I would have to write some script inside the makefile of the project which preprocesses and then saves that in some temp place, and runs splint on the mess
[13:09:08] <karlp> sounds like a lot of value add :)
[13:09:11] <_abc_> It is not that hard, I just don't have the stamina for that.
[13:09:24] <_abc_> Not right now, at least.
[13:10:07] <_abc_> karlp: well strictly speaking all I have to do is copy the %c.%o stanza in the makefile and make it do %c.%C or such
[13:11:03] <_abc_> (and select -pedantic for gpp since I'm at it)
[13:14:52] <_abc_> what is the define for the CPU used internally by avr-gcc again please?
[13:15:05] <_abc_> I mean a sample macro like CPU_ATMEGA8 or such?
[13:15:19] <karlp> go and look in your avr-libc dir at io.h and have a look at them all.
[13:15:32] <karlp> or the avr-libc docs, it has a page somewhere that lists them all.
[13:16:40] <_abc_> __AVR_ATmega8__
[13:16:56] <_abc_> it's easyer to keep the .s file and read it :)
[13:59:49] <_abc_> update: I managed to run splint on my avr-gcc code but it throws tons of warnings on avr-gcc includes which are not splint proofed
[14:00:29] <_abc_> The maintainers should really look into splint proofing the includes, using the provided simple means (like #ifndef S_SPLINT ... dodgy code here ... #endif)
[14:00:43] <Steffanx> splint ..
[14:00:56] <Steffanx> ah nvm :P
[14:01:19] <_abc_> I mean all I had to do was put the __fuses and __lockbits sections into #ifndef S_SPLINT to make my source pass
[14:01:36] <_abc_> that being said, the splint manual is from 2003....
[14:01:50] <_abc_> hey the current C standard is from *last* century >:)
[14:01:57] <_abc_> so in that respect, splint is fresh and new...
[14:02:00] <_abc_> cough
[14:02:06] <_abc_> (C99)
[14:02:25] <_abc_> So anyway the options for running splint on avr-gcc code are:
[14:02:30] <_abc_> (brb)
[14:07:24] <_abc_> Okay I ALMOST managed to run splint on it, it does not like binary constants
[14:08:31] <vectory_> wth is splint, a new language?
[14:09:48] <Steffanx> wikipedia knows it all
[14:09:49] <Steffanx> http://en.wikipedia.org/wiki/Splint_(programming_tool)
[14:22:49] <karlp> abc, no, really, split developers should work on supporting reallllly common code constructs :)
[14:34:16] <_abc_> karlp: okay, please read this (txt) http://ompldr.org/vZHJlbg mini howto
[14:34:37] <_abc_> karlp: there are no developers left, the code is almost orphaned
[14:34:55] <_abc_> karlp: and it DOES run on modern gcc if the prepreocessor is involved (splint calls it)
[14:35:18] <_abc_> There are other tricks involved, however. If you run the code I posted in the mini howto above, you will see for yourself.
[14:35:30] <_abc_> Only thing is, 0b001 constants are not supported for now
[14:35:36] <_abc_> So they have to be guarded
[14:35:55] <_abc_> If it is easy to add them to the .lex used by splint I will patch it if I have the time and publish the patch
[14:36:08] <_abc_> enjoy, or not
[14:36:11] <antto> oops, what do you do when your percent meter goes to 100% then starts to go over 100% but fast?
[14:36:13] <antto> mmuhahaha
[14:36:35] <antto> did i just erase the bootloader
[14:36:35] <abcminiuser_> Greetings, mortal
[14:36:38] <abcminiuser_> *mortals
[14:36:43] <_abc_> (running splint on hellow.c which includes avr.h and stdio.h throws >90 warnings on headers - someone has not been tidy - cough)
[14:36:49] <_abc_> abcminiuser_: greetz
[14:36:55] <_abc_> abcminiuser_: just joined?
[14:37:01] <_abc_> abcminiuser_: please look here: http://ompldr.org/vZHJlbg
[14:37:06] <abcminiuser_> _abc_, just ran out of things to read :P
[14:37:06] <karlp> abcminiuser_: if you put that on something with a better url, I'm sure it will actually be useful to people
[14:37:10] <_abc_> abcminiuser_: just posted this, very relevant to avr-gcc :)
[14:37:20] <_abc_> karlp: tab completion fail
[14:37:25] <_abc_> karlp: yes, that would be good
[14:37:31] <_abc_> I should put it up somewhere.
[14:37:35] <abcminiuser_> _abc_, disregard splint, acquire cppcheck
[14:37:48] <_abc_> abcminiuser_: I don't use c++
[14:37:51] <_abc_> abcminiuser_: on avrs
[14:37:59] <_abc_> abcminiuser_: splint seems to run nicely
[14:37:59] <Steffanx> It'll do C too ...
[14:38:03] <abcminiuser_> _abc_, neither, but it works with C code too
[14:38:15] <abcminiuser_> It's also waaay more up to date than splint is, and super easy to use
[14:38:22] * _abc_ cppcheks
[14:38:30] <karlp> _abc_: really, splint doesn't run nicely, you're asking for all of the avr-libc to get #ifdefs all over it just for splint
[14:39:11] <_abc_> karlp: no, I am not, I am asking for avr-libc *includes* to be fixed in the oopses they seem to contain wrt splint output
[14:39:44] <karlp> yes, the avr-libc source needs to get ifdefs for an out of date tool
[14:39:48] <karlp> it's not going to happen.
[14:39:59] <_abc_> karlp: I did not say that, please re-read what I said
[14:40:09] <_abc_> splint finds C coding inconsistencies in avr-libc headers
[14:40:18] <_abc_> not because it can't parse them , but because they are there
[14:41:28] <karlp> no, the sections you want to hide,
[14:41:41] <karlp> if splint can't understand section attributes, _splint_ needs to change.
[14:41:51] <_abc_> Only sections which need to be hidden are __fuses and __lockbits sections in user (my) source
[14:42:14] <_abc_> karlp: that's easy to say. Are you volunteering or are you *demanding*
[14:42:49] <karlp> I'm not demanding splint change, far from it, I don't use it
[14:43:04] <karlp> I just don't like your chances of getting avr-libc to change _at all_ to support splint.
[14:43:14] <karlp> but, I do still think your notes on _using_ splint are very useful
[14:43:20] <karlp> I'd lvoe to see them given a more permanent home
[14:43:33] <_abc_> they don't need to support splint dude they need to be more compliant with their own standards... C that is...
[14:43:49] <_abc_> karlp: ompldr is quite permanent usually
[14:44:03] <_abc_> karlp: wikipedia could be too if the tards would not delete stuff there all the time
[14:44:11] <_abc_> karlp: also I have a number of anonymous webpages
[14:44:25] <_abc_> karlp: I would like to see that stanza integrated in makefiles heh
[14:44:49] <_abc_> And I need to write that part and it's 22:30 here after a long day, so, maybe some other time
[14:49:03] <karlp> would you object if I put it up verbatim, attributed to you on my page?
[14:49:11] <karlp> I'd hate to see it lost to the irc logs forever...
[14:50:04] <OndraSter> hmm there is no nullptr or even null in Atmel Studio in default? :P
[14:59:12] <_abc_> karlp: go ahead
[14:59:31] <_abc_> OndraSter: are you looking for NULL defined in stdlib.h perhaps?
[14:59:50] <OndraSter> most likely :)
[15:00:08] <_abc_> OndraSter: there are other places which define it without including stdlib
[15:00:21] <_abc_> maybe ask abcminiuser he is better at this than I am
[15:00:35] <OndraSter> well I don't mind few extra (kilo)bytes of program or memory..
[15:00:40] <OndraSter> 256kB flash is fairly big place :)
[15:13:44] <_abc_> I am looking at splint 3.2.1 src/cscanner.l and its Digit type is not too hard to hack, there are things like cscannerHelp_processHex() which parse a hex into an int, so all I need to do is write cscannerHelp_processBin() ... :)
[15:46:49] <DarkSector> Okay what the hell is happening. A simple LED program and the AVR refuses to follow it. I made a video out of it so that I can show you what's happening and the code is in the description http://www.youtube.com/watch?v=Y2S9zBVWZZ4&feature=youtu.be
[15:47:31] <DarkSector> I have the Programmer attached if that is a matter of concern.
[15:49:14] <specing> P(me going on youtube) = 0
[15:49:28] <DarkSector> what
[15:49:31] <DarkSector> oh
[15:49:40] <DarkSector> specing: butwai sir?
[15:50:34] <specing> #bash (for example) has a limit for CODE SNIPPETS about 15 lines and you come here with a video?
[15:50:52] <specing> They would butcher you in #bash for this :P
[15:51:38] <specing> Well but you know... this is not #bash :)
[15:52:53] <DarkSector> yeah that's why I am here
[15:53:07] <DarkSector> Also why would anyone come with a vid on #bash?
[15:53:11] <DarkSector> that's code
[15:53:19] <DarkSector> this is hardware output that cannot be explained
[15:53:44] <DarkSector> How am I to explain this? Blink wait Blink Blink Blink wait for it Blink ...
[15:55:34] <izua> you should have put the code with syntax highlighting in the first second of the video :D
[15:55:53] <OndraSter> DarkSector, don't you have watchdog reset fuse?
[15:55:57] <OndraSter> err
[15:56:01] <OndraSter> watchdog always on fuse
[15:56:40] <karlp> _abc_: http://false.ekta.is/2012/05/static-analysis-for-avr-code-with-splint/
[15:58:35] <Casper> DarkSector: the programmer can be the issue
[15:59:10] <Casper> but
[15:59:17] <Casper> do you have a decoupling cap?
[15:59:41] <Casper> have you set the watchdog? (should be off ideally)
[16:00:00] * OndraSter has never used decoupling caps when dealing with anything and it always worked (on breadboard that is, on real boards it is all decoupled)
[16:00:16] <DarkSector> decoupling caps
[16:00:17] <DarkSector> no
[16:00:27] <DarkSector> watchdog fuse
[16:00:32] <DarkSector> no I don't think so
[16:01:43] <DarkSector> 0xD9 0xCE
[16:02:23] <DarkSector> Does the ATmega32 even have WDTEN?
[16:02:29] <DarkSector> WDTON I mean
[16:02:38] <Kevin`> DarkSector: what's the reset line connected to?
[16:02:47] <DarkSector> 4k7 to 5V
[16:03:06] <karlp> OndraSter: you're lucky, lots of times you have odd or less than stellar behaviour on breadboards it's because of the lack of decoupling
[16:03:11] <Casper> try 1k to 5v
[16:03:55] <Xata> Hello
[16:04:06] <DarkSector> ok]
[16:04:27] <OndraSter> DarkSector, I see you have Bootloader reset vector fuse programmed?
[16:04:39] <OndraSter> http://www.engbedded.com/fusecalc
[16:04:43] <OndraSter> D9 CE
[16:05:04] <OndraSter> or is it CE D9?
[16:05:09] <Xata> i do not know where to ask, so i ask here - is there any less specific channel? not about avr only, but about all the electronics
[16:05:19] <OndraSter> ok it is CE D9 :)
[16:05:29] <OndraSter> Xata, ##electronics
[16:05:34] <OndraSter> but be warned! :D
[16:05:48] <Steffanx> Yeah, the old IRC people are there :P
[16:05:49] <OndraSter> DarkSector, you have set external crystal
[16:05:56] <OndraSter> do you have one there? :P
[16:05:59] <OndraSter> with proper loading caps,
[16:06:00] <OndraSter> ?
[16:06:09] <Steffanx> old and grumpy
[16:06:16] <Xata> OndraSter: wel, this is better than sex with too much manuals for too few information
[16:06:29] <DarkSector> yes
[16:06:30] <OndraSter> sex with manuals?
[16:06:36] <DarkSector> OndraSter: 16MHz
[16:06:38] <OndraSter> ok
[16:06:47] <DarkSector> I've set the F_CPU to 16000000UL
[16:06:52] <DarkSector> oh god, it's the fuses
[16:06:58] <DarkSector> it works alright with internal osc
[16:07:01] <Xata> OndraSter: yes. and i must admit - this is the best sex i ever had
[16:07:05] <OndraSter> :D
[16:07:10] <OndraSter> DarkSector, what capacitors do you use?
[16:07:15] <Xata> last thing i have to try - with gurls
[16:07:19] <DarkSector> err for what?
[16:07:23] <OndraSter> for the crystal
[16:07:27] <DarkSector> XTAL? 22pF
[16:07:29] <Xata> DarkSector: i really don't know
[16:07:30] <OndraSter> ok
[16:07:41] <DarkSector> Xata: what
[16:07:45] <OndraSter> -.-
[16:07:49] <OndraSter> lol Xata
[16:07:50] <DarkSector> nvm
[16:08:09] <DarkSector> doesn't your client highlight your name?
[16:08:12] <Xata> OndraSter: how is your wubwubwub machine?
[16:08:20] <DarkSector> lots of difference b/w Xata and XTAL
[16:08:43] <OndraSter> :) thinking about how to do each amplification stage so I can switch different outputs to one global output BNC, Xata
[16:08:46] <Xata> DarkSector: a joke.
[16:09:36] <OndraSter> first they will be all apmlified (if they would not be equal to) 3.3Vpp, then ran through opamp to be 2.5Vpp (because I will be using 2.5V reference for DAC), then differential amplifier to set the amplitude and then amplified to maximum of 10Vpp
[16:09:39] <Xata> OndraSter: um, maybe try a switch?
[16:09:45] <OndraSter> analog switch, yes
[16:09:59] <Xata> OndraSter: yep. why not?
[16:10:07] <OndraSter> I will be using one :)
[16:10:09] <OndraSter> 4:1
[16:10:20] <OndraSter> and maybe another 2:1 added to it, because I might add arbitrary waveforms
[16:10:24] <OndraSter> afterall, xmegas have DAC :P
[16:10:35] <OndraSter> 2 channels
[16:10:44] <OndraSter> one for the amplitude settings, second for the arbitrary waveform
[16:10:48] <DarkSector> unjoke
[16:10:56] <OndraSter> 8:1 costs more than 4:1 + 2:1
[16:11:11] <OndraSter> and has worse parametres
[16:11:25] <Xata> OndraSter: but i still don't get how do you going to make current coolnes with sine+sqr+saw
[16:11:38] <Xata> *are you going
[16:11:39] <OndraSter> how am I going to do what?
[16:11:55] <OndraSter> btw: http://smartmania.cz/images/galerie/KomunitniAkceMicrosoft/img13.jpg
[16:12:24] <OndraSter> yesterday we were grabbing a beer with Microsoft :P
[16:12:41] <OndraSter> only one N9 and one Android guy (not on this photo luckily!)
[16:12:48] <OndraSter> the rest of us all had WP7 phones :P
[16:12:50] <Xata> OndraSter: wel that cool dubstep sounds are not only filters, but cool waveforms also, and as far as i remember you have analog devices sine, sqr and saw generators
[16:13:00] <OndraSter> yes
[16:13:05] <OndraSter> that's all you have got
[16:13:14] <OndraSter> it is not supposed to be dubstep sound generator
[16:13:25] <OndraSter> it is supposed to be waveform generator for hobbyists
[16:14:46] <_abc_> http://peter5.50webs.com/free/ karlp I put it up, and I patched splint for binary constants too
[16:14:52] <_abc_> And I am not abcminiuser :)
[16:14:56] <_abc_> Done, and done.
[16:15:06] <OndraSter> but I suppose that with some heavy math involved one could make simple synth tool for dubstep with the arbitrary waveform option :P
[16:15:11] <OndraSter> 500ksps should do it
[16:15:37] <Xata> that's why i use table lookup and atmega as generator - you can make any waveform you like. kinda waveform sampler. but that sallen-key filter suck - it has too low quality
[16:16:15] <Xata> and adding stages - i don't get it, how to make it move with the main filter
[16:16:58] <Xata> even thinkking about dropping op-amp design and just copy for example a moog
[16:17:13] <OndraSter> no idea - only sine output is filtered through LC filter that cuts it off at about 30 - 35MHz, the rest is unfiltered
[16:17:18] <OndraSter> (hard to filter square or arbitrary!)
[16:19:48] <Xata> DarkSector: also for me 15pf on xtal are ok
[16:20:29] <DarkSector> hmm yeah
[16:20:33] <DarkSector> but it's the fuses
[16:20:36] <DarkSector> I know for sure now
[16:24:20] <antto> grr
[16:24:50] <antto> when "self programming" hex files, does the data from the hex go in the same order as it is in the file?
[16:25:22] <Xata> OndraSter: had a look on you pic. it is cool, but win7 still sucks. no mp3 ringtones? no flash in browser? no god damn backward compatibility? come on...
[16:25:45] <DarkSector> Xata +1 on that
[16:25:58] <OndraSter> mp3 ringtones are there
[16:26:02] <Xata> HURAAAH
[16:26:07] <Xata> :D
[16:26:07] <OndraSter> no flash in browser - only android with stock browser has it
[16:26:12] <OndraSter> and it sucks there
[16:26:18] <OndraSter> backward compatibility with what?
[16:26:25] <Xata> with wm6.5?
[16:26:33] <OndraSter> that is not predecessor
[16:26:55] <Xata> than why it is called 7-th?
[16:27:04] <OndraSter> because they kept the name
[16:27:18] <OndraSter> they have completely redone the shell and upgraded kernel
[16:27:25] <OndraSter> the shell is absolutely different
[16:27:51] <OndraSter> WM was unfixable
[16:28:04] <OndraSter> I've got things I shouldn't be having and believe me, it is a mess
[16:28:25] <OndraSter> any fix = breaking compatibility
[16:30:11] <Xata> OndraSter: hm, maybe. but don't let amiga persecution complex guide you
[16:31:22] <OndraSter> :P
[16:31:29] <OndraSter> I am too young to remember Amiga really
[16:34:58] <Xata> OndraSter: as i already told i am 23, but back in 1997 i had a speecy and amiga was just a dream
[16:35:09] <OndraSter> :)
[16:35:19] <OndraSter> I am 19.5 in 35 minutes
[16:35:36] <Xata> and having speecy in 97 was ok for this country
[16:36:19] <Xata> even more - havin _anything_ was ok that time
[16:36:52] <OndraSter> hmm in 97... thinking what we had
[16:36:58] <OndraSter> 486 maybe?
[16:37:16] <OndraSter> the first PC I did something on myself was either 486 or Pentium 1
[16:37:29] <OndraSter> and it was playing Transport Tycoon DeLuxe from Win95 :)
[16:37:36] <OndraSter> and then playing Polda 1 (czech adventure game)
[16:39:52] <Xata> OndraSter: oh, ttd. i had it in 2000, and still playing (openTTD ofc). the second rts. first was age of empire.
[16:40:24] <antto> what happens if the hex flash for some reason failed, and the firmware is corrupted? will it escape back to the "bootload" mode?
[16:40:30] <OndraSter> :)
[16:40:33] <antto> or will it simply "freeze" into UB
[16:40:45] <OndraSter> how do you enter the bootloader normally?
[16:41:00] <antto> a rotary encoder must point to a location
[16:41:14] <antto> otherwise the firmware is loaded
[16:41:34] <OndraSter> oh
[16:41:36] <OndraSter> sure it will work
[16:42:06] <Xata> i got PC in 99, and that was a time - i was the bright young one behind all that looser with their dendy, snes and speecy
[16:43:57] <antto> then hm..
[16:44:32] <antto> when reflashing hex, does the rest of the memory have to be cleared to 0xFF (of course, excluding the bootloader area)
[16:45:46] <specing> memory is auto-erased before programming
[16:46:11] <antto> then what am i doing wrong?!
[16:46:49] <antto> when using the 'Z' command (to send one page at a time) do i have to set the address each time before that (aka 'A' command)
[16:47:29] <antto> and do i have to use the 'm' command?
[16:47:32] <Xata> specing: nat always. using gromov's programmer and its programm needs a blanking by hands
[16:48:08] <Xata> otherwize - fails with mess in memory
[16:48:36] <OndraSter> the page has to be erased, it might be done automatically, depends on the bootloader!
[16:50:01] <Xata> OndraSter: leaved the ##electronics. no reaction even regarding my despite attempt to have some attention
[16:50:15] <OndraSter> heh
[16:50:18] <OndraSter> never been there myself
[16:51:12] <antto> if the chip has 128 "pages" but i only send 90 (that's how big my hex is) - should the remaining pages be also cleared to 0xFF ?
[16:52:06] <OndraSter> that's your choice
[16:52:08] <Xata> i suppose no. but you better clear it. just ftgj
[16:52:25] <OndraSter> it is better actually
[16:52:34] <OndraSter> if your program goes crazy and jumps to unused part
[16:52:43] <OndraSter> 0xFF is NOP... or is NOP 0x00?
[16:52:49] <OndraSter> anyway, it will end up in bootloader
[16:52:53] <OndraSter> and not doing anything crazy
[16:55:50] <Casper> nop afaik is 0xFF
[16:56:13] <Casper> which is the erased state of the flash
[16:57:02] <OndraSter> there you go, that is the reason why to clear even unused pages
[16:57:21] <antto> does the 'e' command erase the bootloader too?
[16:57:24] <OndraSter> and something is killing my wifi perfomance, even remote desktop is unusable, gotta reboot router
[16:57:34] <OndraSter> I bet you it doesn't
[16:57:39] <OndraSter> e is chip erase?
[16:57:47] <Casper> chip erase, it do all
[16:57:51] <antto> yeah-ish..
[16:57:51] <OndraSter> if the boot lock bits are set correctly it won't erase BL
[16:58:00] <Casper> OndraSter: actually
[16:58:04] <OndraSter> can it?
[16:58:05] <antto> as far as i know they aren't set
[16:58:07] <Casper> if any of the lock bit is set
[16:58:10] <Casper> you can't read
[16:58:17] <Casper> nor write to the flash section
[16:58:22] <antto> 'r' returns 0xFF
[16:58:26] <Casper> but you can erase all
[16:58:30] <Casper> which is what the -e do
[16:58:31] <OndraSter> hmmm
[16:58:59] <OndraSter> I've written my own small bootloader before so appearantly my chip erase does someting else than his
[16:59:07] <OndraSter> are you using STK500 bl?
[16:59:13] <antto> no
[16:59:20] <Xata> antto: maybe it is time to spend 3$ for another chip?
[16:59:26] <antto> it's a modified bootloader
[16:59:47] <OndraSter> my chip erase went page by page to numberOfPages-PagesInBL
[17:00:21] <Casper> that was the bootloader
[17:00:26] <Casper> not the programmer
[17:00:48] <antto> so the safest (and slowest) way is to manually send _all_ 128 pages, even if the last few of them are empty
[17:01:33] <antto> so i gotta change my code slightly..
[17:01:44] * antto * ctrl+a, del
[17:02:16] <Xata> shift+del, for sure
[17:02:41] <Essobi> Herp derp.
[17:02:56] <Essobi> Anyone recommend a mixed signal scope sub $300?
[17:04:08] <Xata> sub $300? i suppose - the one you make
[17:04:28] <antto> i tryied to make my own.. out of nothing ;P~
[17:04:38] <antto> and it almost worked
[17:05:44] <Xata> well, here you can find one with one input source from soviet 1968
[17:06:10] <antto> http://www.youtube.com/watch?v=tL-Gb4q0uXw
[17:06:37] <Xata> Essobi: but if you are not in ex-ussr than start to suffer
[17:07:30] <Xata> antto: something like puredata?
[17:08:05] <antto> Xata: synthedit, but the scope is c++ software rendering
[17:08:53] <Xata> antto: and what is the source of waveform?
[17:09:01] <Xata> Hardware/Simulated?
[17:09:07] <antto> hardware
[17:09:21] <antto> thru the soundcard analog inputs
[17:09:44] <Xata> antto: that could be done much easier in pd without all that c++ headache
[17:10:22] <Xata> on the other side - makeing a plugin for synthedit == being cool
[17:10:22] <antto> but, not sure if you noticed.. did the signal appear to be ac-coupled on the scope?
[17:11:06] <Xata> antto: i donno, ror
[17:11:31] <antto> but my soundcard is ac-coupled
[17:11:46] <antto> i bet you can't do that in puredata without getting your hands dirty with c++
[17:12:03] <antto> or whatever language it supports
[17:12:08] <Essobi> I've seen a few projects that're low end 5v logic signal analyzers with 328ps... and a few dirty sound card scope looking ones..
[17:12:42] <Essobi> But the sub $300 market is weird.. you'll see some that're $60-70 bucks, then up to $300, and the feature set doesn't look that diverse.
[17:12:43] <Xata> antto: exactly what you done? maybe not. but scope is a standart object in pd, and even max/msp
[17:13:07] <antto> i have a filter, which is part of this scope
[17:13:23] <antto> it's sort of an "inverse high-pass" filter
[17:13:45] <Xata> inverse?
[17:13:58] <Xata> on what axis?
[17:13:58] <antto> under perfect conditions - it neutralises the effect of your normal 1-pole RC HP filter
[17:14:17] <antto> in other words
[17:14:57] <antto> if you process a signal with a HP filter at some frequency, then you can feed the output of this into the "inverse HP" filter, set to the same frequency
[17:15:04] <antto> and you get the original signal
[17:15:24] <antto> so that's the special thing about this scope there
[17:15:24] <Xata> antto: than why not output->lp, then lp output + orig. output and voila
[17:15:47] <antto> what?!
[17:15:52] <Xata> 5 moves in pd
[17:16:13] <antto> you can't do this with a LP
[17:16:51] <antto> if you feed a step signal to a HP filter - it outputs a spice which decreases exponentially towards zero
[17:17:07] <antto> and just how will a LP filter make a step signal out of this spike?
[17:17:24] <Xata> antto: you limit the frq range where was the parasite hp, and than add it several times to the original signal.
[17:18:02] <antto> several times?
[17:18:20] <Xata> you can do it once, if it will be enough
[17:18:46] <antto> note: you do not have access to the "original signal" since in practice it originates from a hardware device
[17:19:01] <antto> all you have is the output of the HP filter
[17:19:58] <Xata> than write a buffer, operate on it, play it
[17:20:49] <Xata> tune it, fix it, trash it, change it, mail - upgrade it
[17:21:37] <Xata> antto: i call the output of hp "the original sound"
[17:21:44] <Xata> this is how we roll here, yeaaaah
[17:21:44] <antto> it's not
[17:22:41] <Xata> antto: but the idea is to restore the original signal?
[17:22:46] <antto> yes
[17:22:52] <antto> before it was HP filtered
[17:23:03] <antto> as if the HP filter wasn't there at all
[17:23:06] <Xata> and all we have is post-hp wave?
[17:23:11] <antto> yes
[17:23:20] <antto> that's what i'm talking about all the time ;]
[17:24:18] <Xata> but adding several lp's to original sound is the only exit. you can not restore it if there is none
[17:24:56] <Xata> *there is none low frqs in input
[17:24:58] <antto> you don't have the original sound, and LP is useless in that case
[17:25:11] <Xata> damn.. i'll draw it
[17:25:39] <antto> the solution is a filter which works in the opposite way to a HP filter
[17:25:46] <antto> running at the same frequency
[17:26:14] <antto> which for my soundcard is usually 1Hz
[17:32:46] <Xata> antto: http://img715.imageshack.us/img715/9583/32581371.jpg
[17:33:26] <OndraSter> Xata, not sure if it is me
[17:33:30] <OndraSter> but I don't understand the picture :D
[17:34:01] <antto> what are you gonna feed this LP with?
[17:34:08] <Xata> who knows
[17:34:19] <Xata> antto: with post-hp signal
[17:34:35] <antto> i'm talking about perfect reconstruction (that's under perfect conditions)
[17:34:44] <OndraSter> why not just buy full scope + logic analyzer?
[17:34:44] <Xata> got to go
[17:34:48] <OndraSter> bb
[17:34:50] <Xata> buy
[17:34:55] <Xata> *bye :D
[17:34:55] <OndraSter> okay, make
[17:34:57] <OndraSter> :D
[17:34:57] <antto> OndraSter: i wish i could ;]
[17:35:10] <OndraSter> I got old analog scope for free (40MHz) from my teacher
[17:35:20] <OndraSter> and you can get logic analyzers, copies of the saleae, for like $20
[17:35:24] <OndraSter> or make your own with AVR
[17:35:25] <antto> i bought something else, very expensive, so.. no more toys any time soon for me
[17:36:25] <OndraSter> actually we had some old logic analyzers at school for LPT port in our school thrown away... but I couldn't take anything, because it has to be documented and special companies have to recycle it
[17:36:26] <OndraSter> DAMNIT
[17:36:32] <OndraSter> I still could've used a lot of gear :(
[17:36:57] <OndraSter> they had some DMMs with broken display (desktop ones)... if anything I could've used the chassis from it
[18:19:38] <OndraSter> ARRRGH, why isn't USB.org selling /4 PID blocks per $1? They'd make $4096 per one VID block! Instead $2000 as they do now for one full /16 block :(
[18:36:26] <Dagger2> because there is no shortage of blocks and they figure most people who would buy IDs need much less than 2000 of them
[18:37:12] <Dagger2> and they've decided to optimize for biggest money intake at the detriment of end-users that have to deal with the inevitable devices using unlicensed IDs
[18:37:47] <Dagger2> ... is what I guess is the answer to that question, based on a general cynical attitude to life
[19:00:35] <antto> i don't understand.. why doesn't this app work thru a serial port "pipe" but works otherwise
[19:00:43] <antto> i can't log it
[19:00:48] <antto> grr
[19:02:36] <jfysh> Hi! I'm wondering if anyone can help me with some really unexpected behaviour with avr-gcc?
[19:04:09] <jfysh> Very briefly, if I compile with -mmcu=atmega324a then upload to an ATmega324A-PU MCU, I get very weird behaviour (constantly resetting, not appearing to run all parts of the code, etc). If I compile with -mmcu=atmega324pa and upload, it works just fine.
[19:05:01] <jfysh> I guess what I'm trying to wrap my head around is 1. why does atmega324a NOT work, for an ATmega324A MCU and 2. if this is often the case, is there any reference mapping between chip model and what -mmcu argument needs to be passed?
[19:07:42] <antto> *shrug*
[19:09:17] <jfysh> Yeah.. that's where I got to :) I guess I just have to try and avoid targetting to many different types of chip. Now I've found the magic incantation, the ATmega324A seems to be working a treat...
[19:55:05] <rue_mohr> antto,
[19:55:15] <rue_mohr> how do you work it 'otherwise'
[19:55:29] <rue_mohr> are you sure that when you try to pipe it, the baud rate is right?
[19:55:30] <antto> what, what?
[19:55:36] <antto> oh
[19:55:52] <antto> i use a virtual com port app
[19:56:06] <antto> it creates 2 virtual ports (COM7 and COM8)
[19:56:11] <rue_mohr> ok does it put the com port settings back when you close it?
[19:56:22] <antto> uhm
[19:56:41] <rue_mohr> windows or linux or mac?
[19:56:53] <antto> the python app, when it opens the com port - it sets the baud rate i guess
[19:56:57] <antto> windows
[19:56:58] <rue_mohr> sounds like windows
[19:57:17] <antto> it must set it, because it works to one point
[19:57:30] <rue_mohr> what baud rate?
[19:57:44] <antto> i mean, it successifully sends a bunch of commands like 's' 'S' 'A' 'a' 'x' ..
[19:57:47] <antto> 19200
[20:00:09] <antto> the app fails with a weird error which i've never seen otherwise
[20:01:21] <antto> "global name 'serial' is not defined"
[20:01:50] <antto> this happens after it transmits 1 full page, and the device responds with 0x0D as normal
[20:10:12] <grummund> antto: how are you doing that?
[20:10:27] <antto> doing what?
[20:10:35] <grummund> the pipe
[20:10:59] <antto> using one app which creates two (linked) virtual COM ports
[20:11:14] <antto> then i wrote a small app which acts as a data logger
[20:12:08] <antto> device -> COM3 <- myapp -> (COM7<->COM8) <- the_python_app
[20:12:18] <antto> COM7 and 8 are the "virtual" ports
[20:12:25] <Sordna> are you running linux?
[20:12:31] <antto> no, windows
[20:13:05] <Sordna> is the communication bi-directional or just from the comm port into the python app?
[20:13:57] <Sordna> oops, nevermind second question,,,don't think it will work for windows.
[20:14:01] <antto> obviously it works, since the app is able to query the device for stuff like the 7-char identifyier, autoincrement, setleds..
[20:14:06] <Sordna> rather, don't think my idea would work..
[20:14:31] <antto> the app is able to send the first page of the hex
[20:14:41] <antto> but then it stops with the error
[20:14:54] <antto> if i connect the app directly to COM3 (the device) - it works
[20:15:11] <antto> but why doesn't it work thru the pipe
[20:15:28] <antto> i mean, i'd expect it to either work, or completely not work at all
[20:15:38] <antto> instead, it "works to some point" O_o
[20:15:47] <Sordna> buffer over/underflow?
[20:15:55] <antto> hm
[20:15:59] <grummund> sounds like line buffering issue
[20:16:57] <antto> in my app, i'm reading one byte at a time, and sending it to the other side immediately
[20:17:23] <antto> and i have a small rest(1) (one millisecond sleep)
[20:18:07] <grummund> myapp links the two virtual serial ports?
[20:18:13] <antto> no
[20:18:38] <antto> the two virtual serial ports (7 and 8) are linked by the virtual com port app
[20:18:43] <antto> that's yet another app
[20:18:54] <grummund> myapp is for data logging?
[20:18:57] <antto> yes
[20:19:10] <antto> it links com7 to com3 (device)
[20:19:15] <antto> and logs to file
[20:20:19] <grummund> check the method used to open com port in myapp
[20:20:34] <antto> it's good
[20:20:55] <antto> 19200, binary, 8 data bits, no parity, 1 stop bit
[20:21:22] <grummund> no i mean stty modes
[20:21:34] <antto> uhm, what's that?
[20:21:40] <rue_mohr> ok the avr cant keep up with the 19200
[20:22:01] <rue_mohr> what does the avr do with the data?
[20:22:19] <antto> ah wait
[20:22:27] <antto> i think i flashed it
[20:22:37] <grummund> antto: it's a while since i played with serial stuff in linux, but it's more than just baud & parity setup i think
[20:22:45] <antto> i increased myapp's buffer from 1 byte to 8 bytes
[20:22:50] <grummund> antto: "this happens after it transmits 1 full page, and the device responds with 0x0D as normal"
[20:22:50] <rue_mohr> he's using windows
[20:22:59] <grummund> oh
[20:23:30] <rue_mohr> if he pushes 19200 at an avr with no handshaking its gonna trip up unless its just shoveling the bytes to leds
[20:23:53] <antto> i don't understand
[20:24:01] <rue_mohr> it cant shovel fast enough
[20:24:13] <rue_mohr> change your project to operate at 2400 and it'll be ok
[20:24:16] <rue_mohr> prolly
[20:24:34] <antto> that means to change also the firmware and bootloader?
[20:24:42] <rue_mohr> yes
[20:24:44] <antto> i can't touch the bootloader
[20:24:51] <rue_mohr> what does the avr do with the data
[20:25:09] <antto> ehm, stores it on the flash?
[20:25:11] <rue_mohr> you can prolly leave the bootloader how it is and just use a lower baud in your program
[20:25:25] <rue_mohr> well you cant write 2kB/sec to flash
[20:25:26] <antto> the program doesn't have a problem
[20:25:38] <rue_mohr> do you know what handshaking is?
[20:25:44] <antto> not sure
[20:26:20] <rue_mohr> during the transfer of data, the two computers confirm that the other is ready for more data before itjust keep sending
[20:26:50] <antto> well, the python app sends one page and waits for 0x0D
[20:26:53] <grummund> wait ... this is confusing...
[20:26:56] <antto> so that's 128bytes at a time
[20:27:20] <grummund> if it works direct without the "data logger", how can the avr baud rate be at fault?
[20:27:24] <antto> whenever the device is ready - it sends the 0x0D and the app continues with the next page
[20:27:32] <rue_mohr> http://en.wikipedia.org/wiki/Flow_control
[20:27:43] <antto> grummund: yeah, that's the strange part
[20:27:45] <antto> ;]
[20:27:49] <rue_mohr> does it store the page in ram?
[20:28:09] <rue_mohr> are you making a bootloader?
[20:28:09] <antto> man, this is about flashing .hex via serial port
[20:28:17] <grummund> antto: the 0x0D seems suspect to me, can you modify the protocal to use something else (for test) ?
[20:28:37] <antto> grummund: no, i can't change the bootloader
[20:28:37] <rue_mohr> or are you making an eeprom programmer?
[20:29:07] <rue_mohr> is the bootloader the thing with the problem or is it the application?
[20:29:36] <rue_mohr> yay chase tail...
[20:29:46] <antto> rue_mohr: this is a device, which has an atmega162, with some modified bootloader, also has this FTDI chip, and there's a python app, which can flash firmware onto the device via serial port (aka usb)
[20:30:21] <rue_mohr> so your making a programmer from a board with a bootloader
[20:30:42] <rue_mohr> that or your making a bootloader for a board with a bootloader
[20:30:45] <antto> i'm trying to make a C++ app as a replacement for the python app
[20:30:56] <rue_mohr> aka, chain loader, cause hell, is one bootloader ever enough?
[20:31:14] <grummund> WORKS: atmega -- COM3 -- the_python_app
[20:31:16] <grummund> FAILS: atmega -- COM3 -- data_logger_app -- (COM7<->COM8) -- the_python_app
[20:31:20] <grummund> rue_mohr: ^^
[20:31:24] <rue_mohr> antto, when your python program sends data, it prolly goes like
[20:31:25] <antto> ^^
[20:31:34] <rue_mohr> . .. .. . ... .. .. .. . . . .... . . .
[20:31:58] <rue_mohr> when you use c++ or pipe it to the port the data goes like
[20:32:01] <rue_mohr> ...............................
[20:32:17] <rue_mohr> because there are no breaks for the chip to catch up, it misses data and screws up
[20:32:59] <antto> actually, the python app flashes the given .hex file faster than my c++ app O_o
[20:33:15] <rue_mohr> oh hmmm
[20:33:29] <rue_mohr> so you cant talk to the data logger properly
[20:33:55] <rue_mohr> I have about 10 mins and I have to go for work
[20:34:27] <grummund> antto: how do you make the virtual ports?
[20:34:37] <antto> another app makes them
[20:34:45] <grummund> yeah, how?
[20:34:46] <antto> "com0com"
[20:34:53] <antto> well, installs a driver
[20:35:08] <antto> windows detects 2 new devices (serial ports)
[20:35:09] <grummund> can it link virtual & real com port?
[20:35:10] <rue_mohr> is com3 a usb port or a builtin?
[20:35:19] <antto> grummund: no
[20:35:45] <antto> rue_mohr: COM3 is another virtual port, from the FTDI USB<->Serial driver
[20:35:50] <antto> it becomes a mess, i know ;]
[20:36:07] <rue_mohr> your better off with it being a usb port thana real one
[20:36:15] <rue_mohr> hmmmm
[20:36:39] <rue_mohr> why dont you just make a eavesdropping cable?
[20:36:49] <antto> uhm, the device connects with a USB cable, but both the device and the PC think it's a serial port
[20:37:01] <rue_mohr> yea
[20:37:29] <grummund> you'd need to eavesdrop on the TTL side of FTDI.
[20:37:34] <rue_mohr> na
[20:37:42] <rue_mohr> you can do it at the rs232 level
[20:37:46] <rue_mohr> its not terminated
[20:37:54] <antto> changing the bootloader or cable isn't a solution, since this device is already owned by a few thousand people the way it was built initially
[20:38:13] <antto> all i can do is replace the crappy python app with a "better" c++ app
[20:38:17] <rue_mohr> nono, you want to reverse engineer the protocol yes?
[20:38:55] <antto> well, in order to make my app - i DO have to know the protocol
[20:39:04] <antto> that's the whole point of logging the data
[20:39:39] <grummund> antto: the point is you could do it with hardware logging instead of your 'software' data logger
[20:39:49] <antto> hardware logging?!
[20:39:57] <antto> i don't think i have such toolz
[20:40:03] <antto> hammer?
[20:40:06] <antto> axe?
[20:40:37] <antto> i'm trying something with my logger, might work
[20:40:47] <antto> increasing the buffer size to more than 1 byte
[20:42:31] <antto> hm
[20:42:33] <grummund> you need 3 hardware RS-232 ports (or USB FTDI)
[20:43:06] <antto> it seems now it worked
[20:43:17] <grummund> atmega -+--- COM3 -- the_python_app
[20:43:22] <antto> the python flashed the whole hex, and my app logged it
[20:43:23] <grummund> +---- COM4 -- log tx
[20:43:25] <grummund> +---- COM5 -- log rx
[21:27:27] <ThersiT> I can't figure out why this is only giving me gibberish on my terminal. http://pastebin.com/nR5n1xS9 and a header http://pastebin.com/Kz4DLHcR
[21:29:01] <ThersiT> There is an array in there called msg. If I make sendString send msg it comes up fine on my terminal.
[21:37:24] <Casper> ThersiT: if you get junk, I'ld bet that you use the internal RC oscillator
[21:41:07] <ThersiT> I'm on a ceramic resonator 16MHz. But it print's right if I make it use that msg array.
[21:45:11] <ThersiT> It's gotta be how I'm passing the data to the function. It's a piece of an example from a book that dosen't work. I'm just trying to get it working so I can continue following along with the book.
[22:39:18] <antto> what "LED" does the setLED command set??
[22:46:35] <Tom_itx> maybe you pass it a parameter
[22:47:20] <antto> yeah it has a 2nd byte
[22:47:30] <antto> what is it's purpose?
[22:47:59] <Tom_itx> how should i know? i didn't write it
[22:48:04] <antto> ;]
[22:48:09] <antto> me neither
[22:48:20] <Tom_itx> then write one of your own
[22:48:26] <antto> can't
[22:49:54] <Tom_itx> where did it come from?
[22:50:17] <antto> someone else wrote it
[22:50:22] <Tom_itx> who?
[22:50:31] <antto> some guy
[22:50:38] <antto> i'm not even sure
[22:50:52] <antto> i guess there's no room for comments in asm code ;]
[22:51:00] <Tom_itx> sure there is
[22:51:15] <Tom_itx> asm should be liberally commented
[22:53:30] <ferdna> i need a air solenoid 2" anything cheap?
[23:27:44] <ThersiT> Would anyone take a look at my question from earlier? I've read everything I can find trying to figure this out and I'm just not getting it. I'd really appreciate any help at all.
[23:39:28] <ferdna> ThersiT, re-post?
[23:39:47] <ThersiT> I can't figure out why this is only giving me gibberish on my terminal. http://pastebin.com/nR5n1xS9 and a header http://pastebin.com/Kz4DLHcR
[23:39:56] <ThersiT> There is an array in there called msg. If I make sendString send msg it comes up fine on my terminal.
[23:40:27] <ThersiT> It's gotta be how I'm passing the data to the function. It's a piece of an example from a book that dosen't work. I'm just trying to get it working so I can continue following along with the book.
[23:45:59] <Casper> ThersiT: what uart speed?
[23:47:03] <ThersiT> My terminal is set for 9600.
[23:52:07] <ThersiT> The uart setup works. I can make it print readable characters. I think the problem is in line 9 sendString("CD"); I don't think that string is making it to the function correctly.