Back
[13:19:22] <ThersiT> Time to buy a new programmer, my dasa is just too slow. Does anyone know the difference between the ISP500 and the ISP-MK2 from Olimex?
[13:19:41] <ThersiT> Is one newer then the other?
[13:21:28] <RikusW> mk2 is probably newer
[13:23:24] <ThersiT> That's kinda what I figured. I'm in the US and none of Olimex distributors have that one.
[13:23:42] <RikusW> Tom_itx also sell a mk2 clone
[13:24:05] <ThersiT> hmm, I'll check that out.
[13:24:30] <RikusW> I also have a STK500 clone capable of HVPP/SP
[13:25:09] <RikusW> and it can do jtag too
[13:26:08] <ThersiT> Honestly, I'm really not sure when to use a HV. Is that only when you get yourself into trouble?
[13:26:51] <RikusW> For fixing fuses mostly, its a pain to setup, you have to connect 20 wires...
[13:27:13] <RikusW> It is quite fast, faster than ISP
[13:27:34] <RikusW> (depending on ISP clock...)
[13:27:40] <ThersiT> I was about to ask if there's a jtag emulator out there that could prog thru icsp.
[13:27:57] <RikusW> I have a free one
[13:28:11] <RikusW> it can run on a mega8, its a jtagice mki clone
[13:28:39] <ThersiT> not usb tho?
[13:28:57] <RikusW> usb too if you have a mega32u2
[13:29:01] <RikusW> http://sites.google.com/site/megau2s/home -> jtag
[13:29:34] <RikusW> but the mki only supports a few older avr's
[13:30:03] <RikusW> I've added programming support for newer avr's but that isn't uploaded yet
[13:30:36] <RikusW> The dragon can do all that for $49
[13:30:42] <ThersiT> hmm i do like building stuff my self.
[13:31:13] <RikusW> You'll need AVRStudio 4 to use it on windows
[13:31:44] <RikusW> or avarice on linux, it does need AS4/5 to compile though
[13:31:49] <ThersiT> yea my only beef with dragon is it's lack of a case and size. wouldn't fit well in my bag.
[13:32:40] <RikusW> the dragon is quite small ?!
[13:33:17] <ThersiT> is it? i've only seen pics on the net.
[13:33:37] <RikusW> and you could keep it in its original box with only the ribbon cable coming out
[13:34:11] <RikusW> its like 2x4 inches
[13:35:18] <ThersiT> that might be the best way to go.
[13:35:51] <RikusW> It supports ISP/HVPP/JTAG
[13:36:28] <ThersiT> I use eclipse (avrdude) on linux. Think I'll into any problems there?
[13:36:33] <RikusW> since building my own programmer I don't use it for ISP anymore ;)
[13:36:53] <RikusW> It does work with the newer versions of avrdude
[13:37:09] <RikusW> On my site there is a Qt frontend for it too
[13:37:21] <RikusW> I'm working on an avrdude alternative
[13:37:28] <ThersiT> think I've got the newest.
[13:37:38] <RikusW> it compiles relatively easily on linux
[13:37:48] <ThersiT> that would be cool
[13:38:18] <RikusW> check on the support software tab on my site -> RavrProg
[13:38:39] <RikusW> its alpha at the moment ;)
[13:38:54] <ThersiT> I really want to get jtag going too.
[13:39:09] <RikusW> jtag is just one more wire than ISP
[13:39:15] <RikusW> its fairly easy to use
[13:39:44] <RikusW> You'll have to get AS5 to update the dragon's firmware though, that cannot be done on Linux.... :(
[13:40:37] <ThersiT> I don't mind more wires. I want to get away from using uart msgs for debugging. ;)
[13:41:30] <RikusW> That mki clone of mine can debug m16 162 32 64 128 as is.
[13:41:31] <ThersiT> That's cool I can slap together a windows install for upgrading.
[13:42:01] <RikusW> I think it should work for the newer stuff too, but AS4 and avarice don't support it
[13:42:25] <ThersiT> All I've got is 328 and 644.
[13:42:45] <RikusW> 328 use debugWire 644 use jtag
[13:42:59] <ThersiT> Using 644 for my current project
[13:43:08] <RikusW> I've decoded most of the debugWire commands too ;)
[13:43:31] <RikusW> http://www.ruemohr.org/docs/debugwire.html
[13:46:25] <ThersiT> wow your site is the place to go if you want to know about programmers. :)
[13:48:26] <RikusW> check out
http://tom-itx.dyndns.org:81/~webpage/ too
[13:48:44] <RikusW> there is a nice article on AVR programming interfaces
[13:50:40] <RikusW> ThersiT: on my site there is also links to most avr datasheets
[13:50:57] <ThersiT> I have to take off but thanks for all this info. I'll be reading over it tonight. :)
[13:52:55] <RikusW> :)
[14:14:16] <RikusW> crabby computer for anyone ?
http://www.technologyreview.com/blog/arxiv/27730/
[15:30:38] <tosmo> under what circumstances would execution be stopped? in my case, why would a while (true) {} loop in main stop? it happens when i handle serial input, but i cannot narrow it down currently
[15:31:03] <Casper> interrupts
[15:31:15] <Casper> watchdog timer
[15:31:28] <Casper> and bug
[15:39:28] <tosmo> last time i had one of those bugs main() got executet over and over again, now it stops. what kind of bug would make it stop? buffer overflow? could damaged pin be problematic? (i caused some ESD's at the ICSP header)
[15:40:30] <Thetawaves> over write the stack space used to store the return address of a function call
[15:41:06] <Thetawaves> its an error that happens inside your interrupt service routine
[15:44:27] <Casper> tosmo: why is your car dieing when idling?
[15:44:51] <Casper> without seeing the code and your schem it's impossible to tell
[15:45:21] <Thetawaves> yeah, i've only got good guesses
[15:45:39] <Thetawaves> but it sounds like something he's doing is trashing the stack
[15:45:50] <Thetawaves> why else would functions not return they way they are supposed to?
[15:53:22] <Casper> Thetawaves: there is also a supply instability that could occur
[15:53:33] <Thetawaves> ohhhh yeah
[15:53:34] <Casper> like not using a decoupling cap
[16:34:14] <specing> DAFUQ is GCC think its doing??!
[16:34:34] <specing> ptr += u8 * sizeof():
[16:34:39] <specing> mul ...
[16:34:47] <specing> movw r18, r0!!!
[16:35:01] <specing> add r30, r18
[16:35:03] <specing> WTF?!
[16:35:46] <OndraSter> as in wasting r18?
[16:35:48] <OndraSter> or what
[16:36:02] <specing> yes
[16:36:26] <Casper> or not
[16:36:29] <OndraSter> actually
[16:36:30] <OndraSter> movw
[16:36:38] <OndraSter> it moves r18:19 to r0:1
[16:36:51] <OndraSter> although it could do add r30, r0...
[16:37:00] <OndraSter> (err, it moves 0:1 to 18:19)
[16:37:01] <Casper> but
[16:37:13] <Casper> can the add instruction cross the 0-15 16-31 register boundary?
[16:37:19] <OndraSter> I think so
[16:38:25] <OndraSter> I wish we had more 16bit instructions :(
[16:45:41] <OndraSter> it would be for us (or is it just me anymore?) waaaay better :P
[16:45:43] <OndraSter> and easier
[16:45:55] <OndraSter> for time "preciseů tasks it IS required to write in asm...
[16:46:00] <OndraSter> my project would not work in C...
[16:49:53] <specing> OndraSter: movw r0, r18
[16:49:59] <specing> I misstyped it
[16:50:08] <specing> or
[16:50:10] <specing> lol
[16:50:24] <specing> I did not misstype it
[16:51:16] <OndraSter> mul outputs to r0:1 :)
[16:51:55] <specing> *pdata += ADCL;
[16:51:55] <specing> ba: e0 91 60 00 lds r30, 0x0060
[16:51:55] <specing> be: f0 91 61 00 lds r31, 0x0061
[16:51:55] <specing> c2: 94 b1 in r25, 0x04 ; 4
[16:51:55] <specing> c4: 80 81 ld r24, Z
[16:51:57] <specing> c6: 89 0f add r24, r25
[16:52:00] <specing> c8: 80 83 st Z, r24
[16:52:02] <specing> adc (*(pdata + 1), ADCH);
[16:52:05] <specing> ca: 95 b1 in r25, 0x05 ; 5
[16:52:07] <specing> cc: e0 91 60 00 lds r30, 0x0060
[16:52:10] <specing> d0: f0 91 61 00 lds r31, 0x0061
[16:52:12] <specing> look at this mess...
[16:52:18] <specing> adc is simply an inline function for asm adc
[16:53:02] <OndraSter> eh
[16:53:11] <specing> d4: 81 81 ldd r24, Z+1 ; 0x01
[16:53:12] <specing> d6: 89 1f adc r24, r25
[16:54:30] <OndraSter> like I said, for heavy CPU load I do everything in asm, for the regular stuff (driving display, with few buttons and rotary encoder and driving two or three peripherals on SPI) goes to C farm
[16:55:22] <specing> I see where all this is going
[16:55:45] <OndraSter> when you "have to" open up the asm listing and check the result, you should go for ASM :)
[16:55:55] <OndraSter> I would end it with that :P
[16:55:57] <specing> I see myself as a compiler dev in ten years time
[16:56:02] <OndraSter> hehe
[16:56:25] <specing> And then Im going to grow a beard and be like donald knuth
[16:56:55] <OndraSter> hehe
[16:57:09] <OndraSter> I have a dream (actually more dreams!) too :P
[16:57:19] <OndraSter> something like "hardware engineer @ Microsoft" lol
[16:57:51] * j4cbo has written a compiler. it's fun.
[16:58:24] <OndraSter> asm compiler - not that hard IMHO
[16:58:30] <OndraSter> C compiler? way less fun :P
[16:58:38] <OndraSter> mostly when you need to implement optimizing tasks etc
[16:59:03] <j4cbo> if the input is asm, it's an assembler, not a compiler :P
[16:59:11] <OndraSter> well, sure
[16:59:13] <Landon> you're not really compiling much for asm->machine code :P
[16:59:17] <OndraSter> sure
[16:59:22] <OndraSter> you have to just "translate"
[16:59:23] <OndraSter> 1:1
[16:59:47] <j4cbo> depends... some assemblers do moderately fancy stuff these days, like handling constant pools
[17:00:08] <OndraSter> :)
[17:00:45] <OndraSter> I thought about some "easy" way for n00bs to AVR... anyone familiar with NXT? NZXT? or w/e is it called... that Lego thingy
[17:00:51] <OndraSter> it has also "point & click app"
[17:00:56] <Landon> yeah, NXT
[17:01:07] <OndraSter> what about something similar, but for AVR :)
[17:02:01] <Landon> :P
[17:02:06] <Landon> well, in an interview recently I was asked
[17:02:18] <Landon> "Do you use arduino?" "No? Thank god!"
[17:02:33] <Landon> s/arduino/OndraSter's Point & Assembler/
[17:02:35] <Landon> hehehe
[17:02:45] <OndraSter> :D
[17:02:51] <OndraSter> I use arduino when I need quickly develop something
[17:02:56] <OndraSter> like when I was dumping EEPROM
[17:03:10] <OndraSter> I just used 595s and 165 for data and address shifting
[17:03:19] <OndraSter> because it was half megabyte EEPROM
[17:03:34] <OndraSter> => 19 addressing bits and 8 data bits
[17:04:05] <OndraSter> just simple "sketch" that in cycle sends the address, clocks the output registers, latches the data from the EEPROM and reads the data back on SPI again
[17:06:09] <OndraSter> plus it dumpts the data to the serial port
[17:06:19] <OndraSter> dumps*
[17:07:33] <Landon> seems like that should be about the point yuo have your own library portfolio :P
[17:11:02] <OndraSter> hmmhm my PC won't sleep... it always turns on itself again after about 10 secs or so...
[17:11:08] <OndraSter> and in the log I can see "power button"
[17:11:09] <OndraSter> :o)
[17:12:03] <Casper> dirty one?
[17:12:25] <OndraSter> hmm it must be some driver
[17:16:57] <OndraSter> :/
[17:16:59] <OndraSter> still nothing
[17:17:07] <OndraSter> gn anyway
[18:15:23] <w|zzy> I agree with Ondraster.. If i want to very quickly prototype something, particularly something i have done before, i will use the arduino.
[18:23:03] <Tom_itx> i think their boards are good
[20:28:04] <clOI> hello everybody. I need an additional software uart and even though there are enough libraries which implement this already (and I will probably use one of those) I was wondering how and why those software uarts are implemented
[20:28:37] <Casper> why: lack of enought hardware one
[20:28:43] <clOI> apparently the signal is usually sampled
[20:28:52] <clOI> yes, i have 3 serial connections
[20:28:53] <Casper> how: by bitbanging a gpio
[20:29:39] <nevyn> and having a timer interrupt that reads the pin faster than serial data rates
[20:29:44] <clOI> .. sampled for every bit. Wouldn't it also possible to trigger an IRQ on every bit-change and calculate based on a time difference how many bits have been sent?
[20:29:58] <Casper> too long
[20:30:01] <Casper> better use a timer
[20:30:16] <clOI> with too long, you mean, that this calculation takes too long?
[20:30:31] <nevyn> it's too flakey
[20:30:35] <Casper> start the timer on start bit
[20:30:43] <Casper> then sample the 10 bits
[20:30:57] <Casper> then check if the 10th bit is a 0
[20:30:59] <nevyn> finding out how many serial periods between the last statechange is harder than you think
[20:31:02] <Casper> if so the byte should be valid
[20:31:10] <Casper> also
[20:31:26] <Casper> there is no time base in avr
[20:31:34] <nevyn> cause you now need to read a timer compare it to a stored timer value blah blah eww.
[20:31:47] <clOI> but I would need a timer for every serial connection then (maybe could use one with some trickery)
[20:32:37] <Casper> if it's the same speed, then you can use the same
[20:32:39] <Casper> but
[20:32:50] <clOI> if i use the timer only to increment TCNT and read this value, I could substract it in the pin-change IRQ
[20:32:55] <Casper> I advice you to upgrade to one with enought serial ports
[20:33:28] <clOI> Casper: I don't really need them. Would just be fun to have them. (I.e. the whole project is for fun)
[20:33:34] <nevyn> clOI: in the best of cases softuarts are kinda.. flakey
[20:33:50] <nevyn> it's not as bad as doing usb in software (that way lies madness)
[20:33:54] <nevyn> but it's close
[20:34:29] <clOI> nevyn: IMO the whole UART idea is broken and I only discovered SPI last week and find it amazing
[20:34:38] <nevyn> spi is awesome
[20:34:57] * Casper stills need to find a bus that can accept star network
[21:07:44] <inflex> Casper: ethernet! :)
[21:08:22] <Casper> inflex: that is not a multi-drop bus
[21:09:34] <inflex> oh okay, sorry
[21:13:02] <Casper> it seems like CAN is the more suited one
[21:19:58] <nevyn> ethernet with 802.11AVB
[21:20:23] <Casper> that is not multi drop bus
[21:20:32] <nevyn> so define a multidrop bus.
[21:21:38] <Casper> a single wire with many devices on the same wire
[21:21:43] <j4cbo> how is ethernet *not* multidrop?
[21:21:55] <j4cbo> Casper:
http://en.wikipedia.org/wiki/10BASE5
[21:22:04] <nevyn> 10base2
[21:22:21] <nevyn> Casper: DS 1wire
[21:22:28] <nevyn> Casper: what does it need to do?
[21:23:09] <Casper> nevyn: 1 wire bus do not handle star network
[21:25:05] <nevyn> star physical or star logical?
[21:25:17] <Casper> physical
[21:25:48] <nevyn> does CAN?
[21:26:06] <Casper> no and yes
[21:26:13] <Casper> car manufacturer does it
[21:26:16] <nevyn> so ethernet with a HUB is totally multidrop
[21:26:17] <Casper> but technically don't
[21:26:22] <Casper> no
[21:26:26] <Casper> it's not multidrop
[21:26:28] <nevyn> and star
[21:26:36] <nevyn> it's a single media
[21:26:37] <Casper> it's star, but single drop
[21:26:50] <nevyn> you want to do multidrop on each leg of the star?
[21:30:30] <Casper> first, I do not want an hub
[21:30:48] <Casper> then it's star, and each "leg" can have another star
[21:31:03] <nevyn> mmm..
[21:35:26] <ThersiT> I've got something weird going on just trying to PWM a RGB LED. It's a common anode LED so I tried to use inverting mode but I can't seem to get it to light. I have a test LED that if I put it in backwards it's ok...
[21:36:35] <ThersiT> But then I tried to just turn all the channels on w/o PWM and the red channel seems to be backwards.
[21:36:55] <ThersiT> Here's that little test I did..
http://pastebin.com/XAmxFb2h
[21:36:55] <nevyn> so the annode.
[21:37:00] <nevyn> is the longest pin.
[21:37:16] <nevyn> I think?
[21:37:32] <ThersiT> Well it's actually a LCD backlight.
[21:37:45] <nevyn> make a little test circuit
[21:37:46] <nevyn> and poke
[21:39:05] <ThersiT> I have been. I have to set the pin to 0 to get it to light so I'm pretty sure it's common anode.
[21:39:10] <Casper> lcd backlight need more current than what an avr can provide directly
[21:40:13] <ThersiT> It's that only two of the channels (green and blue) lit when I turned them all on that concerns me.
[21:40:31] <ThersiT> well that might do it.
[21:41:35] <ThersiT> heh heh, So when I plugged two lcds into the same pins, that might have been a bad move?
[21:42:41] <ThersiT> Could I have damaged this pin? because it's really acting funny.
[21:48:35] <Casper> it could
[21:48:49] <Casper> those backlight take lots of power, so it's basically a short to the avr
[21:56:19] <ThersiT> Thank you!! I just tried with a regular RGB LED and it works fine.
[21:56:40] <ThersiT> And the pin seems to be ok.
[22:29:08] <Tom_itx> ha
[22:30:19] <Tom_itx> had the wrong device selected. at90can128 and atmega128 are rather similar until you try to program one
[22:30:47] <Tom_itx> it didn't error reading the signature or the fuses
[23:47:27] <inflex> mog: did you ever get that 8x2 COG going?