Back
[00:07:07] * inflex runs off to the post to deliver another package
[00:07:35] <Casper> damn timezone
[00:07:40] <Casper> it make it weird...
[00:07:47] <Casper> you go to the post office at 1am :D
[00:24:08] <Ninja0> someone live?
[00:36:53] <Casper> not me
[00:39:36] <CapnKernel> Nope I'm head too.
[00:39:40] <CapnKernel> Oops, dead too.
[00:39:45] <CapnKernel> Severed head maybe.
[00:39:50] <inflex> O_o
[00:39:56] <inflex> well that was fun
[00:40:10] <inflex> my account was still blocked at the post office and my car didn't start when I wanted to come home
[00:40:19] * inflex fears the ignition block is failing rapidly now
[00:42:21] <Casper> inflex: have you checked for faulty spark plug?
[00:42:41] <inflex> no, the car wouldn't even turn over
[00:42:46] <inflex> it's happened before
[00:43:00] <inflex> the ignition block is failing on other areas too - the contacts in it are wearing out
[00:43:28] <inflex> looks like I might have to bring the "start" and "accessories" leads out to buttons/toggles
[00:43:35] <Casper> by ignition block, you mean the switch?
[00:43:44] <inflex> yes
[00:44:06] <inflex> it's unfortunately one of those keycoded types, so it's $450 to get a replacement
[00:44:24] <Casper> old car?
[00:44:35] <inflex> '96
[00:45:08] <Casper> what kind of protection? passlock 1/2? or passlock3/rf?
[00:45:35] <inflex> not sure to be honest, it's for a Ford Falcon 6cyl 4.0
[00:49:21] <inflex> mmm... I feel the urge to mess with the CSS on my NQRC website
[00:49:37] <inflex> something to make it seem a little more modern again (the style is only about 18 months old already)
[00:51:55] <Casper> 450$ seems alot for that...
[00:52:04] <Casper> sadly I can'T check the mitchel right now...
[00:53:24] <Casper> ah
[00:53:27] <Casper> it's rfid
[00:54:37] <Casper> but inflex
[00:54:45] <Casper> why do you say it's the ignition and not the starter?
[00:56:01] <inflex> because after bashing the ignition the "right way", it started
[00:56:19] <inflex> I could be wrong, yes, it could be a dud brush on the starter motor, that is possible
[00:57:22] <Casper> afaik, it's rare that the switch fail, but very common that the starter or the relay fail (and yes, there is probably a relay too)
[00:58:08] <inflex> for sure, that's possible. I know also that the accessories switch position is failing - I have to wiggle the key to get it to come on
[00:58:38] <inflex> I'll check the starter relay - at least it's a moderately cheap option to replace
[00:59:01] <inflex> gharr... no sales in 24hrs... pissing me off
[00:59:31] <inflex> I've got that dozen designs out there, waiting for them to arrive (coming via HK-post, so probably 2wks to go - they have been dispatched though, I even had one PCB go from submission -> delivery in 3 days )
[01:02:29] <Casper> inflex: from what I gathered from google, your car use PATS (passive anti-theft system) which is RFID
[01:02:39] <inflex> sounds about right
[01:03:11] <Casper> if you install switch, don't forget to put the key near the ignition or something, or relocate the pickup coil and put the key close...
[01:03:58] <inflex> well, I was thinking of still using the key... but just using a switch to fire the relay
[01:04:03] <inflex> (or rather, a pushbutton)
[01:04:46] <inflex> or does the RFID reading only occur during the part where you've turned the key to "Start" ?
[01:05:19] <Casper> that I do not know
[01:05:23] <inflex> np
[01:05:28] <Casper> I think when you turn to start
[01:05:33] <Casper> but
[01:05:43] <Casper> you might want to find an used one or something
[01:05:45] <Casper> because
[01:06:02] <Casper> on some car, if the accessory contact fail, you can damage the transmission
[01:10:10] <Casper> on my car I got issues with the security system
[01:10:17] <Casper> fortunatelly I have the Passlock-II
[01:10:36] <Casper> this one is a nice one
[01:10:51] <Casper> the pins in the switch have magnets on it
[01:10:56] <Casper> and an hall sensor on top
[01:10:58] <inflex> ugh
[01:10:59] <inflex> okay
[01:11:03] <inflex> that makes it better
[01:11:10] <inflex> I think I just need to get rid of this car
[01:11:12] <Casper> based on the height of the key, that make an unique resistance
[01:11:15] <inflex> just don't have the $$$ for it and can't get a loan
[01:11:53] <Casper> what I did is: cut the back and yellow wire, put 1k resistor, make a relearn procedure and voila
[01:12:05] <inflex> hahah damned nice
[01:12:10] <Casper> the relearn is damn easy... put key to run, wait atleast 10 mins, turn to off, start the car
[01:12:11] <inflex> bbiab - making a coffee
[01:12:27] <abcminiuser> Oh damn
[01:13:01] <Casper> abcminiuser: ? too easy to bypass?
[01:13:18] <abcminiuser> Anyone notice a rather glaring issue with this diagram?
https://bluetooth-explorerbot.googlecode.com/svn/trunk/Thesis/Figures/FirmwareBlockDiagram.png
[01:14:06] <Casper> all outgoing?
[01:14:12] <abcminiuser> Besides that
[01:14:43] <Casper> external sram in hardware driver?
[01:15:19] <abcminiuser> Engineering aside
[01:15:27] <Casper> no idea then
[01:16:14] <Casper> what did you saw?
[01:16:20] <abcminiuser> It looks like a goddam swastika
[01:16:22] <abcminiuser> Whoops :P
[01:16:34] <Casper> a what?
[01:17:15] <abcminiuser> http://www.erichufschmid.net/Magyar1/swastika.gif
[01:18:34] <Casper> didn't noticed, and not really imo
[01:19:41] <abcminiuser> Ah good
[01:19:48] <abcminiuser> I was worried I'd have to re-jigger it
[01:19:51] <abcminiuser> And I'm lazy
[01:20:15] <Casper> but if you're that worried to offence someone, then just make it in the other way...
[01:30:06] <CapnKernel> /me hates Illinois Nazis
[01:31:24] <inflex> meh
[01:31:31] <inflex> people have thought my PLD logo was a swastika
[01:32:42] <inflex> http://pldaniels.com/pld-mainpage-image.png <=- this one
[01:33:14] <ziph> Looks like a Cyclone to me. :)
[01:35:06] <CapnKernel> inflex: cute
[01:38:56] <inflex> apparently that's a bad logo to have though, the Feng shui is bad
[01:39:52] <inflex> you know, we really need to plant more trees... suck up this excess CO2 that we're putting out
[01:40:03] <inflex> (since we can't add more capacity to the ocean)
[01:40:42] <inflex> or someone needs to find a method of secquesting CO2 into an inert solid form, producing less than it takes of course ;)
[01:40:43] <ziph> Or develop organisms to do it on a large scale.
[01:41:02] <ziph> But the prevailing wisdom seems to be that living in mud huts is the real solution.
[01:41:08] <inflex> well, unfortunately not many organisms do it :( algae I suppose is your choice
[01:41:17] <inflex> I'd say having less ppl on the earth
[01:41:17] <ziph> Engineer them.
[01:41:26] <inflex> but that's still a 50 yr plan
[01:41:42] <inflex> but then, European/Western birthrates -are- down
[01:41:51] <ziph> The mud hut thing is because the people bleating loudest also hate consumption and commercialisation.
[01:42:26] <inflex> but use the internet ;)
[01:42:46] <ziph> The internet is a huge energy waster. :)
[01:42:51] <inflex> I remember even as a kid, my first "inventions" were things to clean up the atmosphere - how bizzare
[01:42:58] <inflex> ziph: I agree, it is rather
[01:43:15] <inflex> ziph: certainly in its current form - but at least with the internet we can change the power consumption down every few years
[01:43:18] <ziph> Particularly since 99% of the stuff going over it is pornography.
[01:43:27] <inflex> curious to see how ARM servers help in that wa
[01:43:57] <inflex> I'd like to see even better CPU speed scaling options
[01:44:08] <inflex> eg, clocking all the way down to 400MHz or so if needed
[01:44:27] <inflex> this CPU only goes 1.25GHz or 2.5GHz :(
[01:44:36] <inflex> my Atom's did 0.8 / 1.1 / 1.6
[01:47:15] <inflex> Anyhow, on AVR matters, trying to decide if I should get a batch of boards done for my most popular product using the T10 chip ratehr than the T13... the proto's I did were good - but it's still meaning a bit of a change
[01:47:41] <inflex> also means I'm now going to start blowing the RST line to save me using the pullup
[01:48:29] <inflex> yes, it's true, I am that skimpy that I'll ditch the RST pullup
[01:48:38] <inflex> it's not the money, it's that it's another part I don't have to place
[01:49:07] <inflex> I'd even drop the pull-down's on the MOSFETs driving the buzzers, if I wasn't so paranoid about the AVR not being able to keep them tied down enough
[04:37:12] <karlp> abcminiuser: the glaring issue with that diagram is that your webserver isn't providing proper mime types!
[04:37:29] <karlp> (and no, I didn't see even a hint of swastika action)
[04:37:31] <abcminiuser> karlp, it's Google's :P
[04:37:37] <abcminiuser> Awesome, that's settled then
[04:37:44] <abcminiuser> I'm just paranoid I guess
[04:37:46] <karlp> but, some people will look for a swastika anywhere, no matter what you do
[04:38:01] <karlp> but I don't think you have anything to worry about
[04:38:25] <karlp> what uni are you at if I may ask?
[04:38:35] <karlp> or, more correctly, about to finish at?
[04:39:08] <karlp> just curious :) in a procrastinating at work kinda way :)
[04:44:19] <soul-d> that swatika the thingy thats on every japanese map denoting temples ?
[04:46:27] <Steffanx> That too probably
[05:17:41] <TwisteR> Should I disable (UCSRnB &= (uint8_t) ~_BV(RXENn)) the receiver while transmitting data over RS-485? Or switching the flow control pin (connected to both /RE and DE pins of max485) is sufficient?
[05:20:12] <ziph> Switching RE should be sufficient.
[05:23:05] <TwisteR> and I found this topic:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=78055&start=0
[05:23:29] <TwisteR> "And, when high clock and slow baud rates are used, insert small delay between finish of receiving data and turning transmitter on. Hint: receiving of byte is completed around half of stop bit, transmitting after it's end. Without this delay two transmitters may be active in different states: one high (start bit), second low (stop bit) for rest of stop bit of last send byte."
[05:25:02] <TwisteR> I think this is the reason my rs485 network does not working correctly: my F_CPU is 11 MHz (high enough?) and baudrate is 38400 (low enough?)
[05:29:01] <karlp> TwisteR: I wait 1ms after bringing driver enable high, and 4ms after bringing it low again.
[05:29:23] <karlp> I haven't experiemented much with how much smaller they can be, but not having any delay at all was giving me some issues
[05:29:28] <karlp> I'd occasionally get some garbage
[05:30:06] <karlp> sorry, let me rephrase, I leave driver enable high for 4ms after sending, to make sure the uart has drained out.
[05:30:34] <karlp> I should be able to replace that with some checks on status bits, but it works well enough for my needs.
[05:31:23] <TwisteR> I'm just trying to figure out why the fgets() continuously returns NULL (EOF flag is set) after I've sent some bytes over rs485
[05:32:32] <TwisteR> without sending those bytes fgets() works just fine, so I think that the problem occures somewhere in my transmit routine
[05:33:13] <inflex> oooh DAMN.... lovely SOT-23 MOSFETs.... only 16mR resistance!
[05:33:19] * inflex buys a reel
[05:34:01] <karlp> TwisteR: do you have pull ups (at least internal) on the rx line?
[05:34:20] <karlp> you can get false start bits on transitions otherwise.
[05:34:25] <TwisteR> oh
[05:34:28] <karlp> which probably show up as a null?
[05:34:35] <TwisteR> thanks, I will check that out too
[05:34:48] <karlp> some 485 transceivers need them more than others
[05:36:47] <inflex> It's sad when you get excited over a MOSFET :(
[05:37:45] <ziph> inflex: Which MOSFET?
[05:39:49] <inflex> http://au.element14.com/nxp/pmv16un/mosfet-n-ch-20v-5-8a-sot23/dp/1894627
[05:40:05] <inflex> To date, I've been using their PMV31XN which was 31mR
[05:40:27] <ziph> Phew, wouldn't mind a bit of bump and grind with that baby.
[05:40:31] <inflex> hahah
[05:40:56] <inflex> dropping to 15mR really eliminates a lot of the potentially marginal situations I was running in to with some of my new designs
[05:41:33] <inflex> especially my switchmode BAC unit which used the N-ch MOSFET on the low-side for the whole soft on/off process, which would have to take up to 2~4A pulses
[05:41:51] <inflex> the 31mR would have been able to cope just, but this one makes it a lot easier now
[05:42:03] <ziph> What's the thermal resistance of it?
[05:42:45] <ziph> Vth is a bit high, are you using it in a 3.3V design?
[05:42:59] <ziph> Oh, wait, it's 700mV. :)
[05:43:19] <inflex> junction to ambient is ~250'C/W
[05:43:34] <inflex> I like to keep them at no more than 50'C above ambient if possible
[05:43:41] <ziph> So it could actually survive full current on a cool day. :)
[05:44:05] <inflex> yeah, now this will be 64'C above ambient at 4A
[05:44:28] <inflex> so it'll still fry your finger :p
[05:44:33] <ziph> What gate voltage are you using?
[05:44:39] <inflex> 4.8~5V
[05:45:14] <inflex> I see their max is 8V, not surprising it's so low
[05:45:43] <ziph> Whew, managed to hide the element14 page for it before my wife saw it.
[05:46:07] <ziph> Yeah, at 3.3V you probably wouldn't get that Ron.
[05:48:17] <ziph> Much nicer than the 7002's I usually use, although I tend to need the 60V Vds.
[05:50:40] <inflex> 7002 or 2007?
[05:51:06] * inflex bought a reel of 2000 of some really woefully bad Rdson 2007 or similar MOSFETs, but they're great in another way - they allow me to avoid using a resistor
[05:51:24] <ziph> 2N7002
[05:51:57] <ziph> Not good for power. :)
[05:52:26] <ziph> What, to run LEDs without a resistor? :)
[05:55:28] <inflex> nah, for a buzzer at low voltage
[05:56:25] <inflex> a 20R one would save me on the LEDs
[05:56:30] <inflex> (PWM'd)
[05:56:39] <inflex> at least they're easy to turn on/off due to such low gate charge
[05:57:23] <ziph> Speaking of which I still need to find a suitable op amp for my USB controlled load...
[05:57:42] <ziph> One that can be made stable when driving a massive gate charge. :)
[05:58:14] <grummund> ooh... USB controlled load, what's that?
[05:59:02] <ziph> It's a big power N-FET that has the current controlled over USB. The bandwidth is about 10kHz.
[05:59:35] <ziph> I designed it to test transients on SMPS's.
[06:00:24] <grummund> interesting, i had thoughts of doing something similar
[06:00:36] <ziph> Stability analysis is interesting because the small signal gain changes depending on the DC gate voltage. :)
[06:15:22] <ziph> Nice, I can change the PWM match values in Crossworks and the LED changes without me even stopping execution. :)
[06:27:51] <grummund> agh. coding inside the debugger is the road to ruin :P
[07:15:37] <TwisteR> karlp: cool, my receiver/fgets() is now working properly after data transmit, thanks for your advices about delays and rx pull-up!
[07:21:23] <karlp> glad to hear it :)
[07:23:45] <TwisteR> now I can not receive anything at the other end :-) fgets() there is just permanently waits for incoming data despite the fact that my device transmitted the responce on request
[07:25:04] <karlp> by adding the delays, you may have ended up both sides on tx-enable at the same time?
[07:25:25] <karlp> be sure the other side has tx-e/_rx-e low?
[07:25:26] <TwisteR> both devices use the same rs485 routines and uart lowlevel functions. But slave can receive and proceed master's commands, and master can not receive anything from slave
[07:25:59] <karlp> if the slave is responding while the master is still in it's delay, you will never see it...
[07:26:07] <Essobi> Can't you read the rx with the tx and verify what you sent is was showed up on the tx?
[07:26:15] <Essobi> err
[07:26:21] <Essobi> tx with the rx
[07:26:53] <Essobi> It'd atleast tell you if there was a colision.
[07:27:36] <karlp> TwisteR: delays on tx are functional, but probably not optimal. jacekowski is probably the master on this,
[07:27:51] <karlp> idelly you'd turn off the tx-e as soon as the last bit has been transmitted
[07:29:10] <TwisteR> here is my rs485.c, it's pretty primitive and works the way you are talking about:
https://tfsoft.org.ua/websvn/filedetails.php?repname=sokrat_control&path=%2Ftrunk%2Ffirmware%2Frs485.c
[07:30:08] <TwisteR> header with macro defines:
https://tfsoft.org.ua/websvn/filedetails.php?repname=sokrat_control&path=%2Ftrunk%2Ffirmware%2Frs485.h
[07:31:30] <TwisteR> so all my devices are in receive mode most of the time and transmits only on master request, as required by rs-485 standard
[07:32:55] <TwisteR> here is interface.c (see process_cmd() function, case 'D'):
https://tfsoft.org.ua/websvn/filedetails.php?repname=sokrat_control&path=%2Ftrunk%2Ffirmware%2Finterface.c
[07:34:07] <karlp> I don't have the outermost delays, before asserting txe, and after deasserting,
[07:34:08] <TwisteR> I'm trying to send "PING!" as soon as I've got the "D" char. I can see that this case is working correctly
[07:35:54] <karlp> and what are you getting?
[07:36:03] <karlp> the D gets received, but the otherside never gets the ping?
[07:36:36] <TwisteR> because I see "start" and "stop" messages (connected to other UART) on "D" command, but I don't see any "PING!" message over rs485 bus at the other end — fgets() is simply waits there
[07:37:13] <TwisteR> yes
[07:39:07] <TwisteR> I need some current sensors on the bus to be able to monitor it in both directions using DSO, right?
[07:39:21] <grummund> is it 2-wire rs485 ?
[07:39:25] <TwisteR> yes
[07:40:31] <karlp> what's DSO?
[07:40:44] <grummund> in that case the transmit routine needs to be using both TXE and TXC interrupts
[07:40:57] <TwisteR> digital storage o-scope
[07:41:12] <grummund> which differs from basic uart comms using only TXE
[07:41:22] <karlp> TwisteR: ^^^ what grummond said is the "right" way, the delays only work if the far side doesn't reply too fast
[07:42:23] <TwisteR> so I need "assymetrical" delays and different rs485.c on master and slave?
[07:42:57] <grummund> don't use fixed delays
[07:43:53] <TwisteR> I'm not using interrupts at all, perhaps that is my problem...
[07:44:15] <grummund> but you can still use the flags
[07:45:29] <TwisteR> No, I would better rewrite my code to use interrupts, while it is primitive enough and I can do that with a little pain :-)
[07:45:54] <grummund> wait for tx register empty flag; enable tx on the rs485 transceiver; write to UDR; wait for tx complete flag.
[07:46:15] <grummund> ; oh, and then disable tx on the rs485 transceiver.
[07:47:25] <TwisteR> ok, thanks
[11:27:42] <Steffann> h4x0r` !
[13:30:21] <theSameGuy> Jagged, the signal of the oscilloscope as just fixed 1 khz - 3,3v and I think I need ~32 khz :/
[13:30:38] <theSameGuy> but i got a other controller now and try it this way
[13:30:47] <theSameGuy> another*
[13:32:11] <JanneP__> okey.. 1kHz should also work
[13:32:17] <theSameGuy> yes?
[13:32:44] <theSameGuy> oh I haven't tryed it hard since I saw iths only 1 Khz
[13:32:51] <JanneP__> the different xtal settings are AFAIK for different drive settings
[13:33:21] <JanneP__> anyways, if it fails, you can then use your new chip to generate the needed clock
[13:33:53] <theSameGuy> Yes I am at home now, but I have the other chip with me, its a arduino with me
[13:34:17] <theSameGuy> i just connect the output pin to xtal1, right?
[13:34:30] <theSameGuy> and the 3,3v is enough`?
[13:35:13] <JanneP__> should be
[13:36:48] <theSameGuy> okay, so I do a loop, where I wait 15 µs until toggle to get 32 khz
[13:37:19] <theSameGuy> its runnig on 20 mhz itself
[13:43:29] <theSameGuy> doesnt work, maybe I mess something other - to set the wrong fuses was the first and only thing i have done, so i dont know -.-
[13:44:57] <theSameGuy> or its the programmer, it seems that i cant set the speed with -B in avrdude
[13:46:25] <RikusW> theSameGuy: try while(1) { PORTB++; }; inside main()
[13:46:31] <RikusW> use PB0 for clock
[13:46:41] <RikusW> and set DDRB = 1
[13:46:47] <RikusW> or FF
[13:48:54] <theSameGuy> RikusW, the on i got from my friend is a arduino, I just used the led toogle example
[13:48:58] <RikusW> theSameGuy: the avr clock needs to be at least 4 or 5 times higher than ISP clock
[13:49:20] <RikusW> so higher is better
[13:49:30] <RikusW> what did you set the fuses to ?
[13:49:34] <RikusW> and on what avr ?
[13:49:34] <theSameGuy> ok, so i do 20 mzh and juts toggle it?
[13:49:38] <Steffanx> low freq. crystal RikusW
[13:49:44] <theSameGuy> E4 on the atmega644
[13:49:53] <theSameGuy> Steffanx, right ;)
[13:49:56] <RikusW> E4 lfuse ?
[13:50:01] <theSameGuy> yes
[13:50:58] <RikusW> and hfuse ?
[13:51:11] <RikusW> did you change hfuse or efuse ?
[13:51:48] <theSameGuy> no only the lfuse
[13:52:10] <theSameGuy> I did this in my make file avrdude -p $(MMCU) -c $(PROGRAMMER) -U lfuse:w:0xe4:m
[13:56:55] <RikusW> theSameGuy: do you have a 1 or 4MHz crystal around ?
[13:58:14] <theSameGuy> RikusW, i can use the reference signal of a oscilloscope its 3,3V - 1khz
[13:58:31] <theSameGuy> but nothing with 1-4 mhz
[13:58:37] <theSameGuy> only the controller with 20 mhz
[13:58:38] <RikusW> thats a bit low, ISP clock will have to be 200Hz
[13:59:16] <RikusW> put this in the arduino code while(1) { PORTB++; };
[13:59:20] <RikusW> it should compile
[13:59:30] <RikusW> use PB0 to XT1 on m644
[13:59:39] <theSameGuy> okay i try
[13:59:51] <theSameGuy> but my usbasp is saying avrdude: warning: cannot set sck period. please check for usbasp firmware update.
[14:00:02] <theSameGuy> duno if it sets it itself?
[14:00:39] <RikusW> your low frequency crystal setting seems to be 32768Hz watch crystal
[14:01:08] <theSameGuy> yes this is what Steffanx told me too
[14:01:30] <RikusW> what programmer do you use ?
[14:01:40] <theSameGuy> avrdude
[14:01:45] <theSameGuy> with a usbasp
[14:02:01] <theSameGuy> from china :/ for a few $
[14:04:21] <RikusW> Is there perhaps a "slow sck" jumper on PC2 of usbasp ?
[14:04:35] <theSameGuy> Rickta59, no, i allready checked
[14:06:27] <RikusW> try the above code on the arduino
[14:06:35] <theSameGuy> like this
http://www.ebay.de/itm/USBASP-USB-ISP-AVR-Programmer-USB-ATMEGA8-ATMEGA128-New-for-Protostack-Board-kit-/260889112050?pt=LH_DefaultDomain_0&hash=item3cbe33edf2
[14:07:19] <RikusW> DDRB = 1; while(1) { PORTB++; };
[14:08:13] <theSameGuy> one moment
[14:15:17] <theSameGuy> doesnt work in this aduino ide, but i fixed it so it fits, but doenst work
[14:15:38] <theSameGuy> I dont know, i think there is no way around getting a new one =/
[14:16:09] <RikusW> try getting a 32 kHz crystal ?
[14:16:23] <theSameGuy> or this
[14:16:33] <RikusW> and set usbasb to use a low sck like 1kHz
[14:16:37] <theSameGuy> but will this work out with the programmer too?
[14:16:49] <RikusW> 8kHz at most or it will fail
[14:16:57] <theSameGuy> I see
[14:17:23] <theSameGuy> avrdude is saying me it cant set the speed with -B
[14:17:24] <RikusW> pulling down PC2 on usbasp is supposed to set its sck to 8kHz
[14:17:41] <RikusW> maybe your usbasp fw is old...
[14:18:09] <theSameGuy> i just bought it but this could be it anyway
[14:18:11] <RikusW> try -B 125
[14:18:36] <RikusW> -B 125 = 125 us = 8kHz
[14:19:12] <theSameGuy> avrdude: set SCK frequency to 8000 Hz
[14:19:13] <theSameGuy> avrdude: warning: cannot set sck period. please check for usbasp firmware update.
[14:19:21] <theSameGuy> maybe thats the problem, the programmer
[14:19:49] <theSameGuy> when i try this: avrdude -B 125 -p atmega644 -c usbasp -U lfuse:w:0xe2:m
[14:20:36] <RikusW> why did you change lfuse in the first place ?
[14:20:43] <RikusW> wanted to use a crystal ?
[14:21:00] <theSameGuy> no, i wanted to remove the division by 8
[14:21:02] <RikusW> for 16MHz use lfuse = 0xFF
[14:21:35] <RikusW> you can do that in firmware
[14:21:36] <theSameGuy> but I looked it up for a atmega32 instead of a atmega644
[14:21:41] <RikusW> setting PLLCSR
[14:21:59] <theSameGuy> oh i havent know that :/
[14:22:57] <RikusW> err clkpr
[14:23:11] <RikusW> CLKPR = (1<<CLKPCE); CLKPR = 0;
[14:23:16] <theSameGuy> The describption of my programmer says: Software controlled SCK option to support targets with low clock speed (< 1.5MHz)
[14:23:40] <theSameGuy> RikusW, ty i will try this on the next one ;)
[14:24:06] <RikusW> theSameGuy: when you get the next one you can try and fix this one
[14:24:29] <theSameGuy> RikusW, this would be an option =)
[14:25:16] <RikusW> you don't know someone with a dragon or stk500 / 600 ?
[14:25:27] <RikusW> they can do HVPP to fix this
[14:25:46] <theSameGuy> no :(
[14:30:19] <theSameGuy> I will ask one, maybe he has a programmer with HVPP support. but i dont think so
[14:32:59] <theSameGuy> big thanks four your help RikusW, and Steffanx for yours too
[14:33:32] <Steffanx> Big you're welcome
[14:52:21] <RikusW> theSameGuy: how about manual HVPP ? :-P
[14:52:32] <RikusW> programming lfuse isn't that difficult
[14:52:41] <RikusW> or use the other m644 to help you
[14:52:41] <theSameGuy> how does it work?
[14:52:53] <RikusW> you have the m644 datasheet ?
[14:52:57] <theSameGuy> yes
[14:53:00] <theSameGuy> as a pdf
[14:54:03] <RikusW> read the memory programming chapter --> parallel programming
[14:55:04] <Casper> fuse recovery is easy when you have another working avr... just make an insane led flasher, as in no delay
[14:55:06] <RikusW> (control, data) (4C, 40) XT1 (2C, E2) (66, E2) (6E, E2)
[14:55:13] <Casper> and feed that to the clock in
[14:55:23] <Casper> and you have an high chance of being able to recover
[14:55:27] <RikusW> yeah, that would be the first option
[14:55:50] <RikusW> (control, data) (4C, 40) pulse XT1 (2C, E2) pulse XT1 (66, E2) (6E, E2)
[14:56:11] <Casper> all external clock will accept a direct clock
[14:56:20] <RikusW> that should work after successfully entering HVPP mode...
[14:56:50] <RikusW> supplying external clock would be safer too if it works
[14:57:15] <RikusW> Casper: will low freq 32kHz accept 4MHz or higher on XT1 ?
[14:57:26] <RikusW> it should but I'm not sure
[14:57:33] <Casper> afaik yes
[14:57:55] <Casper> all of the mode change the output mode
[14:58:02] <Casper> not the input
[14:58:25] <RikusW> theSameGuy: If you do try HVPP please use a 1500 Ohm resistor from 12V to reset for the safety of you m644 :-P
[14:59:18] <RikusW> but try clocking XT1 first using the new m644
[14:59:30] <theSameGuy> RikusW, ok, at first i qill wait for the replay of my friend who i ask for a HVPP programmer. an i will keep on trying with the other controller
[14:59:40] <theSameGuy> will*
[14:59:57] <RikusW> theSameGuy: you have a scope ?
[15:00:06] <RikusW> or frequency meter ?
[15:00:15] <theSameGuy> yes
[15:00:41] <RikusW> measure PB0 out from earlier to see if it does supply a clock ?
[15:01:18] <RikusW> should be about 5 to 10MHz
[15:01:45] <theSameGuy> i haven't one myself, but i can use it tomorrow and then i will do it
[15:03:27] <RikusW> for the default usbasp 375k sck 2MHz should be high enough
[15:03:37] <RikusW> higher won't hurt
[15:04:19] <Casper> one way to know if it oscillate...
[15:04:21] <Casper> take a led
[15:04:38] <RikusW> and see if its dim
[15:04:38] <Casper> and check if it turn on from pin to ground and pin to vcc
[15:04:50] <RikusW> ah
[15:04:51] <RikusW> nice
[15:04:57] <JanneP__> i though toggling a pin on arduino generates something like 90 lines of assemler code
[15:04:58] <Casper> if you can make it turn on on both, it mean the pin provide both
[15:05:31] <RikusW> JanneP__: arduino can directly access ports
[15:05:36] <RikusW> but its not documented
[15:05:48] <RikusW> arduino use avr-gcc
[15:07:54] <JanneP__> aha, so writing directly to port will generate fast code, as expected and opposite to digital write?
[15:08:18] <RikusW> yes
[15:08:36] <RikusW> wiring is inefficient to say the least...
[15:09:23] <RikusW> a little binary arithmetic won't hurt anyone ;)
[15:09:31] <RikusW> so use the ports directly
[15:10:02] <JanneP__> newbies will die thinking of ~& and | =)
[15:10:19] <RikusW> its easy...
[15:10:38] <RikusW> its C not even avr
[15:11:10] <JanneP__> difficulty is relative... for someone with no experience it can be too mcuh
[15:33:04] <h4x0r`> its bitwise C
[15:33:17] <h4x0r`> new reps freak out so hard
[15:36:33] <RikusW> why ?
[15:36:41] <RikusW> its quite simple once you understand it...
[15:37:51] <h4x0r`> i guess its just daunting at first
[15:38:23] <h4x0r`> i picked it up without a hitch though, thanks to the people here, and other channels, and gewgle.
[15:38:34] <h4x0r`> annnnnnd the datasheet.
[15:39:08] <RikusW> like the binary multiplication table, only 4 entries ;)
[15:39:16] <RikusW> what could be simpler
[17:01:44] <Guest31865> Hi all
[23:57:08] <ishmal> hey, quick Q: what's the gcc macro for avr?
[23:57:35] <Casper> avr-gcc?
[23:58:12] <ishmal> yeah, there is some gcc option that dumps all of the builtins
[23:58:53] <ishmal> im writing some c code, testing it on linux, want to get the #ifdefs right
