Back
[02:40:19] <sabor> avrdude version 6.2-20151117 refuses to set hfuse from 0xF7 to 0xD4 ond my m168 but I don't understand why
[02:41:38] <ferdna> sabor
[02:42:07] <Xark> sabor: I think there are some read-only (or missing) fuses that can cause that.
[02:43:30] * sabor checks the fuse bits again...
[02:44:35] <ferdna> i had this issue when programming atmega168
[02:44:48] <ferdna> 0xFF == 0xF7
[02:45:02] <ferdna> (trying to look for references)
[02:47:05] <ferdna> try to do a:
[02:47:21] <ferdna> -U hfuse:w:0x:01:m
[02:48:49] <ferdna> good night and good luck
[02:48:58] <sabor> ferdna: it complains about the byte value
[02:49:04] <sabor> is there a colon too much in your value?
[02:49:23] <sabor> good night ferdna, and thanks :)
[02:49:30] <ferdna> sabor,
http://www.avrfreaks.net/forum/avrdude-cannot-read-efuse
[02:49:32] <ferdna> last post
[02:49:47] <sabor> thanks
[02:49:56] <ferdna> also try this:
[02:49:57] <ferdna> http://www.engbedded.com/fusecalc/
[02:50:28] <sabor> fusecalc spits out the same value I calculated
[16:35:22] <LeoNerd> Random query... what does "tristate" mean to anyone... as a verb? To "tristate" a GPIO pin ... does that mean turn it into a hiZ state?
[16:35:44] <LeoNerd> Or is there a better verb to use? I want something that isn't just "read", because read also actually fetches the state, whereas this might not
[16:35:53] <Tom_itx> high impedance
[16:36:09] <Tom_itx> floating
[16:36:19] <Tom_itx> not in an on or off state
[16:36:34] <LeoNerd> Hm.. so functions named write_gpios read_gpios tristate_gpios seems reasonable
[16:36:35] <LeoNerd> ?
[16:36:51] <Tom_itx> i suppose
[16:37:12] <Tom_itx> may not go with read / write as much as high / low though
[16:37:50] <LeoNerd> Well, then you couldn't set some pins high and some pins low.. This is a function that takes a mapping, which maps pin names to desired values
[16:38:10] <LeoNerd> write_gpios( { MOSI => 0, SCK => 1 } )
[16:38:21] <Tom_itx> tri state buffers will have an enable line usually
[16:38:26] <Lambda_Aurigae> on an avr, when a pin is tri-stated, it is generally an input..
[16:38:31] <Tom_itx> for buss use
[16:39:16] <LeoNerd> Lambda_Aurigae: OK so the "tristate" in that case refers specifically to the undriven state... as opposed to the general ability of the pin to be either driving high, driving low, or undriven high-Z?
[16:39:27] <Lambda_Aurigae> correct.
[16:39:31] <LeoNerd> Hmm
[16:39:46] <LeoNerd> OK I guess that works. I mean my only other idea really was to name it 'hiZ_gpios'
[16:39:46] <Lambda_Aurigae> you have 3 states on pins on an avr...input, high out, low out
[16:40:03] <LeoNerd> Yes; three states.. so the pin itself is "tri-state", surely? ;)
[16:40:13] <Lambda_Aurigae> which is set by two different registers...one to set input/output and the other to set the output state to high or low.
[16:40:27] <LeoNerd> Yesyes I know how AVR GPIO pins work ;) I'm after general terminology
[16:40:59] <Lambda_Aurigae> there are some devices that allow high-z, input, output
[16:41:19] <Lambda_Aurigae> which is the more common tri-state
[16:41:26] <LeoNerd> How is high-Z different from "input" in this case though?
[16:41:29] <Lambda_Aurigae> and far older than microcontrollers.
[16:41:39] <Lambda_Aurigae> high-z means no connection either way.
[16:41:41] <LeoNerd> Oh.. hm.. I suppose I shouldn't technically call it "high-Z" actually, because I don't know if the hardware might have some sort of pullup/pulldown attached
[16:42:12] <Lambda_Aurigae> lots of 7400 series chips have a tri-state with high-z, in, out
[16:43:05] <Lambda_Aurigae> hmm..maybe not lots
[16:44:58] <Lambda_Aurigae> techincally, the original tri-state was in, out, high-z
[16:45:29] <Lambda_Aurigae> I've seen it used on modern microcontrollers as high-out, low-out, and input.
[16:46:39] <LeoNerd> Ooh... most randomly: PCI is interesting... it uses idle-high shared lines, but requires that all drivers output a high signal for a single clock cycle before high-Z'ing, so that the line transitions faster
[16:46:50] <LeoNerd> Otherwise the pullup isn't strong enough to get enough slewrate
[16:47:19] <Lambda_Aurigae> hehe...interfacing to PCI is a pain in the arse.
[16:47:26] <Lambda_Aurigae> was much easier with ISA.
[16:47:52] <Lambda_Aurigae> built many an ISA interface board without microcontrollers over the years.
[16:48:24] <LeoNerd> I wonder if these days you'd make an interface card using a PCI-ISA bridge onboard :)
[16:48:53] <Lambda_Aurigae> probably.
[16:49:05] <Lambda_Aurigae> or just get a pci interface chip.
[16:49:12] <Lambda_Aurigae> these days i do it with usb.
[16:49:15] <LeoNerd> I don't have any projects that need such bandwidth... I find USB quite sufficient for now
[16:49:26] <LeoNerd> Though I should play around with USBTMC sometime for my clockgen box
[16:49:49] <Lambda_Aurigae> hmmm.
[16:49:57] <Lambda_Aurigae> GPIB like comms over USB.
[16:50:00] <Lambda_Aurigae> interesting concept.
[16:50:10] <LeoNerd> Yah
[16:50:18] <Lambda_Aurigae> dunno that USB can handle the latency that real GPIB did though.
[16:50:22] <LeoNerd> Nope
[16:50:39] <LeoNerd> But most test equipment does'nt really matter.. you just do outofband control over USBTMC
[16:50:43] <Lambda_Aurigae> I remember building GPIB stuff years ago...and HPIB too.
[16:51:05] <LeoNerd> USB has the host-polling problem to it, for latency concerns