I've been away from this game for far too long; it's time to jump back in again. I had to force myself away just when things were getting interesting around here so that I could focus on some of my "other work".
The layout on that 85 driver I did really stinks...way too much space around the MCU, but I figured that it would be easy to flash the thing a million times. It looks like it also needed a bodge capacitor to work right. I guess I should have labeled it "alpha".
I haven't read through everything here, but a capacitor underneath the MCU sounds like a really bad idea unless you like tedious leg bending and soldering on every driver. I'm sure we can make it work without resorting to stuff like that.
If space is needed, I think it's good idea. I bend all my 85 pins anyway because they clip some much easier and the clip holds much more securely. If you haven't tried it, you should.
Another benefit of the bent legs is the MCU sits more proud and you can put resistor right up to the legs without programming clip interference.
I wonder if we really need LED - pads when the FET Drain tab available to solder to. It's nice to have a spot that is labelled and a spot that will fail first from mechanical stress, but is it really necessary when space is short?
Pyro1son,
The FET Drain Pad and LED _ Pad appear close to shorting with the pill. It's probably fine, but it looks like the FET could be slid closer to the ground ring edge.
I have dealt with the issue on a lot of drivers and have scoped it when it happens. Usually from a 3.8v-3.9v supply you'll see a 6V+ peak with 2V-3V peak-to-peak ripple (BAD). They actually run with a really dirty supply but when you get them up past 5.5V-6V it's going to have some issues. We are really pushing the MCU pretty hard switching these low-RDS but high-gate-charge FETs directly from the MCU pin, especially without any gate resistor. You can end up with either too little decoupling or if you have the cap. behind the diode you can get quite a bit of boosting. You also get a lot of ground bounce from the FET switching. There are a lot of layout tweaks that can make them run without expensive or extra parts.
You do absolutely need at least a small LED- pad if you want to use anything but an LFPAK56 FET. The SiR800DP, for example, does not really work without some extra exposed pad out the back. You can sacrifice it if you only use an LFPAK56, but I know that quite a few use the SiR800DP and it has proven to be a top performer.
Think you really need some pad space for LED-, at least with the SIR800DP FET - there's nothing on the FET there to solder to. That was my issue with Richard's board.
I’ve moved the FET away from the edge and the 2nd CAP from under the MCU as I just don’t like the Idea. I would rather just put both caps on the bottom of the board.
I'm liking it . Nice to have a pin #3 pad.This last one is still with a 13A footprint, I believe. It's still a lot to squeeze in.
I'm think'n we'll need it both ways - one design with the full 45/85 footprint, and one with the 13A/25 size. I'm thinking Richard will be working on a design as well.
Should be noted - this happened to me twice already. The 380 7135's seem to want 5 as a PWM value at a minimum (moon mode) - not sure if this has to do with the faster PWM rate of PHASE correct mode on the 25/45/85's when run at 8 Mhz.
So what I'm using now is using 3 for 350 7135's and 5 for 380 7135's as a standard practice. The 5 on a 380 may even be lower output than a 3 for a 350.
Also, I made a change in the firmware that was annoying me. For going into lock-out with the 2 clicks, then click/hold, I made the hold time shorter so you don't have to see that annoying strobe. So basically instead of strobe for about one second, you get the 4 short blinks - much more pleasing, easier to enter and confirm you are in lock-out. I checked the manual and didn't see an impact there - I didn't get too specific on hold time in the manual.
Update, more changes to the firmware:
Couple more things that kind of bugged me:
losing your place in the configuration settings. With 5 settings, hard sometimes to track if your are on setting #3 (mode ordering) or #4 (mode memory) for example. So, I now do 2 fast blinks, then blink the setting # when entering a configuration setting. When you get to 5 of course, it takes some time to do 5 blinks, but hoping it's easier to track now.
No way to completely bail out of configuration mode - you can skip to the next setting by click/hold, but still takes a while. So, I added a long hold option to bail out completely. So in configuration mode, a hold of about 1/2 sec skips to next, while a hold of 1.1 secs bails out, signaled by 5 fast blinks. I increased the config mode exit blinks from 3 to 5, since they blink faster now.
Not yet posted... Will be doing more testing... Once again, the SupFire M2-Z light is working great for re-programming/testing . Thanks Richard!
Just want to start by saying thanks to everyone putting time in on this project.
I have an idea about making some extra room for component placement on this driver. I dont know anything about running the electrical traces so if this sounds dumb please forgive.
What if the foot print for the larger micro 45/85 and the FED were put on the bottom ( the spring side) and all of the other components were put on the top. The work around for loosing the spring pad on the bottom could be mechanical.
The battery + could be a large via in the center (like in some of the above desings) that we could either just solder a rivet into or use a machined part with a larger top that a spring could be soldered to.
Like this.
I would think the top components could then be reflowed on and the bottom 2 could be hand soldered easily. Plus if only the rivet was used for the + contact the micro could be reflashed without unsoldering the driver from the pill.
Copper rivets are cheap too, a box of like 250 is ten bucks.
My 2 cents....
—
In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not. http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.
Interesting... You lose a little clearance in the battery tube, that's bout it. Not sure bout the rivet parts - best metal, etc. It gets away from the single sided driver, but at least we'd have room. I do a lot of piggyback'ed drivers still, and for those, the parts and spring would not be necessary anyway.
I have an idea about making some extra room for component placement on this driver. I dont know anything about running the electrical traces so if this sounds dumb please forgive.
What if the foot print for the larger micro 45/85 and the FED were put on the bottom ( the spring side) and all of the other components were put on the top. The work around for loosing the spring pad on the bottom could be mechanical.
The battery + could be a large via in the center (like in some of the above desings) that we could either just solder a rivet into or use a machined part with a larger top that a spring could be soldered to.
If you’re going to have components on both sides and want as much space as possible, just do this:
Those copper wires are solid and clear the MCU, at least on the drivers I’ve built with this method. It maybe a bit more work than your solution but by centering the MCU I not only have more space for components around it, I can also flash it without ripping apart the entire light.
The driver in the photo is 23mm but I’ve designed and built 17mm drivers this way, works like a charm as long as the cells are button top or have solder blobs on them. On some lights it might be a tight fit, but I haven’t had size issues with any of mine yet.
It's the same firmware renamed - little catchier and simpler . Current size is about 3600 bytes. Latest updates:
Three changes, minor updates to the manual:
make lock-out easier by shortening the hold time which eliminates activation of strobe. Itmakes it easier to confirm if lock-out is set, because if strobe does activate, you knowlock-out is not set
change the blinks for entering a setting configuration mode: it now blinks quickly twice,followed by slow blinks of 1 to 5 (1 for first setting, 5 for the 5th setting). It makesconfig mode slower but easier to track what setting you are in
add a long hold to exit configuration mode. A short hold will skip to the next setting, but if you continue to hold a little longer, it will exit altogether, indicated by 5 quick blinks
Very cool and very generous of you to share your FW Tom E. Looking forward to trying it out. I've been struggling to get in mod time for some time now. I hope to try it soon.
Might just be me but how to change modes when on?
Lets say, its in med for over 1.2 sec (its locked-in), how to go to the next mode?
Do you have to click and hold to cancel the lock-in and then click to switch modes?
Might just be me but how to change modes when on? Lets say, its in med for over 1.2 sec (its locked-in), how to go to the next mode? Do you have to click and hold to cancel the lock-in and then click to switch modes?
Think yes, you are correct. Since the 1-click turns it OFF, you can click/hold to go to previous mode, then click to go the next, click->next, etc.
It's all a matter of priority - I chose to make 1-click OFF the priority, but I believe Werner originally had it working where changing modes was priority. You can change this behavior, if you like, and have it work without the mode lock-in feature - change the following from 1 to 0, at line #296 in Narsil.c (I think this should work - might not have tried it though...):
I have dealt with the issue on a lot of drivers and have scoped it when it happens. Usually from a 3.8v-3.9v supply you’ll see a 6V+ peak with 2V-3V peak-to-peak ripple (BAD). They actually run with a really dirty supply but when you get them up past 5.5V-6V it’s going to have some issues. We are really pushing the MCU pretty hard switching these low-RDS but high-gate-charge FETs directly from the MCU pin, especially without any gate resistor. You can end up with either too little decoupling or if you have the cap. behind the diode you can get quite a bit of boosting. You also get a lot of ground bounce from the FET switching. There are a lot of layout tweaks that can make them run without expensive or extra parts.
You do absolutely need at least a small LED- pad if you want to use anything but an LFPAK56 FET. The SiR800DP, for example, does not really work without some extra exposed pad out the back. You can sacrifice it if you only use an LFPAK56, but I know that quite a few use the SiR800DP and it has proven to be a top performer.
+1
There has been a lot of work on this thread experimenting with bypass capacitors, but I did not see anything done with FET selection. Perhaps a FET with better dynamic switching parameters would alleviate most of these issues.
If anyone can find it, please post. Mitko was seeing 5-8% bumps on amps, and he mentioned they were even pretty cheap. Dunno about any side effects though.
For those who can shed some light on it, please check out the data sheet. I'm thinking there may be an equivalent sold under another name/part # somewhere.
The big deal for us is the amount of gate charge at a given gate voltage. Usually, the lower RDS on FETs have a higher gate charge. We are switching relatively slow (<20 KHz) but we are are also asking a lot more from the MCU than it was designed to do. We get away with it most of the time in the name of compactness and simplicity, but it would be best if there was a gate driver, even a makeshift one, that drove the FET gate. I have experimented a bit with this, and while it does work great I don't think that it is necessary to add the extra cost, however small, and complexity to these drivers.
Since we aren't really pushing the thermal dissipation limits on these FETs in the partial duty cycle modes, I think that adding a gate resistor back into the mix may be the easiest solution. This will ease the load on the MCU and we don't really care if the FET spends a few more microseconds in the linear region with the loads we are switching with them.
The way I see it is that we want highest amps at low cost and stability. It is not surprising that all three cannot be met without design changes. I’d say that only two out of three goals are possible.
high amps and low cost but low stability (current design)
moderate amps and low cost and stability can be achieved by inserting current limit resistor or FET with higher RDSon or gate resistor
high amps and stability can be achieved by redesigning the board for better power distribution and filtering (power plane and bypass caps)
An analogy I’d like to make is building your own PC. Pairing a budget motherboard with a maximally overclocked CPU will result in an unstable system that reboots under load. Upgrading the motherboard can give you higher speed and stability but cost more money.
Ahhh - I really don't know what a gate driver is, but there is a real problem here -- both on a SupFire M6 (triple) and a single 219C light running a Tiny85 at 8 Mhz, the MCU was having all sorts of problems. The small cap seemed to have solved it for me. For the M6, I was using a 22 mm wight FET+1 driver, so plenty of room extra pad for the cap. For the 219C EDC light, wiring the cap over the MCU isn't a good solution, but it worked.
So you think the gate resistor would work? I can't recall now, but though I had a gate resistor on one that was failing -- I could be wrong. I've been pulling off the 10K-22K gate resistors I had on there, because I was using them previously thinking they would/could solve the flicker problem when going from hi to moon, but they made the flicker less bright, but it still occurred. The firmware change is what really fixed that problem, so, I thought they are no longer necessary.
Richard - I've used two of your 85 FET+1 drivers btw (MTN-17DDm 85 v0.01), both in 18650 EDC tube lights, but the LED- pad is a problem for sure.
Hhmm, I should try it. So I assume you still set the fuse(s) for 8 Mhz? The PWM's would be 1/2 the speed they are now at 8 Mhz? Think the clock is shared?
Yep, leave the fuses set to 8Mhz. It divides whatever the clock is set to in the fuses. Except the “Divide clock by 8 internally; [CKDIV8=0]” fuse. That fuse actually already uses the CLKPR.
The CLKPR should affect everything. It changes the clock entirely.
Quote:
This can be used with all clock source options, and it will affect the clock frequency of the CPU and all synchronous peripherals. clk I/O, clk ADC, clk CPU, and clk FLASH are divided by a factor as shown in Table 6-15 on page 33
Didn't try the clock yet, but ran into yet another 85 FET+1 driver that had the same flaky problems, but with a single XM-L2. This time, it seemed to only behave bad with a LG MJ1 cell (3500 10A). Other cells, like a 30Q worked fine. The cap between the 85 grnd and Vc pin did the trick once again. This was in a swm C20C using RMM's 85 FET+1 driver.
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
I tried 8 MHz, 6.4 MHz, 4 MHz, and 128 kHz. They all had the same power spike issue. However, at least slowed down to 128 kHz I discovered that it seems to reset on the trailing edge of the strobe pulse instead of a leading edge. So it seems to reboot when the FET power is turned off.
I also tried each brownout setting but it didn’t seem to make any difference.
Oh, and after flashing at 128 kHz, it doesn’t seem to want to be flashed any more. Anyone have any idea how to recover that?
If space is needed, I think it's good idea. I bend all my 85 pins anyway because they clip some much easier and the clip holds much more securely. If you haven't tried it, you should.
Another benefit of the bent legs is the MCU sits more proud and you can put resistor right up to the legs without programming clip interference.
I wonder if we really need LED - pads when the FET Drain tab available to solder to. It's nice to have a spot that is labelled and a spot that will fail first from mechanical stress, but is it really necessary when space is short?
Pyro1son,
The FET Drain Pad and LED _ Pad appear close to shorting with the pill. It's probably fine, but it looks like the FET could be slid closer to the ground ring edge.
I have dealt with the issue on a lot of drivers and have scoped it when it happens. Usually from a 3.8v-3.9v supply you'll see a 6V+ peak with 2V-3V peak-to-peak ripple (BAD). They actually run with a really dirty supply but when you get them up past 5.5V-6V it's going to have some issues. We are really pushing the MCU pretty hard switching these low-RDS but high-gate-charge FETs directly from the MCU pin, especially without any gate resistor. You can end up with either too little decoupling or if you have the cap. behind the diode you can get quite a bit of boosting. You also get a lot of ground bounce from the FET switching. There are a lot of layout tweaks that can make them run without expensive or extra parts.
You do absolutely need at least a small LED- pad if you want to use anything but an LFPAK56 FET. The SiR800DP, for example, does not really work without some extra exposed pad out the back. You can sacrifice it if you only use an LFPAK56, but I know that quite a few use the SiR800DP and it has proven to be a top performer.
Mountain Electronics : batteries, Noctigon, and much more! What's new?
Think you really need some pad space for LED-, at least with the SIR800DP FET - there's nothing on the FET there to solder to. That was my issue with Richard's board.
I’ve moved the FET away from the edge and the 2nd CAP from under the MCU as I just don’t like the Idea. I would rather just put both caps on the bottom of the board.
Pastebin &nbs
I'm liking it
. Nice to have a pin #3 pad.This last one is still with a 13A footprint, I believe. It's still a lot to squeeze in.
I'm think'n we'll need it both ways - one design with the full 45/85 footprint, and one with the 13A/25 size. I'm thinking Richard will be working on a design as well.
It’s definitely a squeeze with the 85 footprint
Pastebin &nbs
Nice looking board.
Thanks for the info on the SiR800DP guys. I haven't been keeping up on FET's.
Should be noted - this happened to me twice already. The 380 7135's seem to want 5 as a PWM value at a minimum (moon mode) - not sure if this has to do with the faster PWM rate of PHASE correct mode on the 25/45/85's when run at 8 Mhz.
So what I'm using now is using 3 for 350 7135's and 5 for 380 7135's as a standard practice. The 5 on a 380 may even be lower output than a 3 for a 350.
Also, I made a change in the firmware that was annoying me. For going into lock-out with the 2 clicks, then click/hold, I made the hold time shorter so you don't have to see that annoying strobe. So basically instead of strobe for about one second, you get the 4 short blinks - much more pleasing, easier to enter and confirm you are in lock-out. I checked the manual and didn't see an impact there - I didn't get too specific on hold time in the manual.
Update, more changes to the firmware:
Couple more things that kind of bugged me:
Not yet posted... Will be doing more testing... Once again, the SupFire M2-Z light is working great for re-programming/testing
. Thanks Richard!
Hi all,
Just want to start by saying thanks to everyone putting time in on this project.
I have an idea about making some extra room for component placement on this driver. I dont know anything about running the electrical traces so if this sounds dumb please forgive.
What if the foot print for the larger micro 45/85 and the FED were put on the bottom ( the spring side) and all of the other components were put on the top. The work around for loosing the spring pad on the bottom could be mechanical.
The battery + could be a large via in the center (like in some of the above desings) that we could either just solder a rivet into or use a machined part with a larger top that a spring could be soldered to.
Like this.
I would think the top components could then be reflowed on and the bottom 2 could be hand soldered easily. Plus if only the rivet was used for the + contact the micro could be reflashed without unsoldering the driver from the pill.
Copper rivets are cheap too, a box of like 250 is ten bucks.
My 2 cents....
In Him (Jesus Christ) was life; and the life was the light of men. And the light shineth in darkness; and the darkness comprehended it not.
http://asflashlights.com/ Everyday Carry Flashlights, plus Upgrades for Maglite.
Interesting... You lose a little clearance in the battery tube, that's bout it. Not sure bout the rivet parts - best metal, etc. It gets away from the single sided driver, but at least we'd have room. I do a lot of piggyback'ed drivers still, and for those, the parts and spring would not be necessary anyway.
If you’re going to have components on both sides and want as much space as possible, just do this:
Those copper wires are solid and clear the MCU, at least on the drivers I’ve built with this method. It maybe a bit more work than your solution but by centering the MCU I not only have more space for components around it, I can also flash it without ripping apart the entire light.
The driver in the photo is 23mm but I’ve designed and built 17mm drivers this way, works like a charm as long as the cells are button top or have solder blobs on them. On some lights it might be a tight fit, but I haven’t had size issues with any of mine yet.
https://www.flickr.com/photos/akrylamid/
Narsil is here - click on the sword to get the manual:
Get Narsil firmware here, folder link that includes PDF of the manual: drive.google.com - ATtiny254585Support
Taking up the handle-shard of Narsil after his father's defeat, Isildur cut the One Ring from Sauron's hand, defeating him.
Very nice, Tom
I haven't used the latest version yet, but will be putting it on the next '85 build I do.
Thanks again for making this available to everyone.
It's the same firmware renamed - little catchier and simpler
. Current size is about 3600 bytes. Latest updates:
Three changes, minor updates to the manual:
make lock-out easier by shortening the hold time which eliminates activation of strobe. It makes it easier to confirm if lock-out is set, because if strobe does activate, you know lock-out is not set
change the blinks for entering a setting configuration mode: it now blinks quickly twice, followed by slow blinks of 1 to 5 (1 for first setting, 5 for the 5th setting). It makes config mode slower but easier to track what setting you are in
add a long hold to exit configuration mode. A short hold will skip to the next setting, but if you continue to hold a little longer, it will exit altogether, indicated by 5 quick blinks
I don't know if any of you watch NCIS, but if you do I think you'll get the reference:
I nominate Tom E. as BLF's Elf Lord.
Mountain Electronics : batteries, Noctigon, and much more! What's new?
Very cool and very generous of you to share your FW Tom E. Looking forward to trying it out. I've been struggling to get in mod time for some time now. I hope to try it soon.
Thanks
. For Richard: go kiss an orc... 
"The time of the Elves... is over"
Might just be me but how to change modes when on?
Lets say, its in med for over 1.2 sec (its locked-in), how to go to the next mode?
Do you have to click and hold to cancel the lock-in and then click to switch modes?
Think yes, you are correct. Since the 1-click turns it OFF, you can click/hold to go to previous mode, then click to go the next, click->next, etc.
It's all a matter of priority - I chose to make 1-click OFF the priority, but I believe Werner originally had it working where changing modes was priority. You can change this behavior, if you like, and have it work without the mode lock-in feature - change the following from 1 to 0, at line #296 in Narsil.c (I think this should work - might not have tried it though...):
volatile byte byLockOutEnable = 1; // button lock-out feature is enabled+1
There has been a lot of work on this thread experimenting with bypass capacitors, but I did not see anything done with FET selection. Perhaps a FET with better dynamic switching parameters would alleviate most of these issues.
one year rookie
It looks like Mitko has gotten outstanding results on a FET he found. To me, the packaging looks like a SIR800DP, but I can't find it anywhere around.
Post #615 here: http://budgetlightforum.com/node/35507, data sheet: https://store.comet.bg/download-file.php?id=7648
Talked about here as well: http://budgetlightforum.com/node/42183
If anyone can find it, please post. Mitko was seeing 5-8% bumps on amps, and he mentioned they were even pretty cheap. Dunno about any side effects though.
For those who can shed some light on it, please check out the data sheet. I'm thinking there may be an equivalent sold under another name/part # somewhere.
The big deal for us is the amount of gate charge at a given gate voltage. Usually, the lower RDS on FETs have a higher gate charge. We are switching relatively slow (<20 KHz) but we are are also asking a lot more from the MCU than it was designed to do. We get away with it most of the time in the name of compactness and simplicity, but it would be best if there was a gate driver, even a makeshift one, that drove the FET gate. I have experimented a bit with this, and while it does work great I don't think that it is necessary to add the extra cost, however small, and complexity to these drivers.
Since we aren't really pushing the thermal dissipation limits on these FETs in the partial duty cycle modes, I think that adding a gate resistor back into the mix may be the easiest solution. This will ease the load on the MCU and we don't really care if the FET spends a few more microseconds in the linear region with the loads we are switching with them.
Mountain Electronics : batteries, Noctigon, and much more! What's new?
The way I see it is that we want highest amps at low cost and stability. It is not surprising that all three cannot be met without design changes. I’d say that only two out of three goals are possible.
An analogy I’d like to make is building your own PC. Pairing a budget motherboard with a maximally overclocked CPU will result in an unstable system that reboots under load. Upgrading the motherboard can give you higher speed and stability but cost more money.
one year rookie
Ahhh - I really don't know what a gate driver is, but there is a real problem here -- both on a SupFire M6 (triple) and a single 219C light running a Tiny85 at 8 Mhz, the MCU was having all sorts of problems. The small cap seemed to have solved it for me. For the M6, I was using a 22 mm wight FET+1 driver, so plenty of room extra pad for the cap. For the 219C EDC light, wiring the cap over the MCU isn't a good solution, but it worked.
So you think the gate resistor would work? I can't recall now, but though I had a gate resistor on one that was failing -- I could be wrong. I've been pulling off the 10K-22K gate resistors I had on there, because I was using them previously thinking they would/could solve the flicker problem when going from hi to moon, but they made the flicker less bright, but it still occurred. The firmware change is what really fixed that problem, so, I thought they are no longer necessary.
Richard - I've used two of your 85 FET+1 drivers btw (MTN-17DDm 85 v0.01), both in 18650 EDC tube lights, but the LED- pad is a problem for sure.
CLKPR divides the clock.
6.5.2 of the datasheet, page 32-33.
This should do 4mhz if I'm not mistaken.
// special procedure required to change clock prescaler
cli(); // Interrupts must be disabled
CLKPR=(1<<CLKPCE); // Enable clock change for next 4 cycles
CLKPR=1; // Clock/2, 4mhz
sei(); // Re-enable interrupts
I have not tested this. My lights aren't having any problems and my tiny85 is in use.
Reducing the clock also reduces power consumption.
xkcd.com/1603 Li-ion battery safety 101.
Hhmm, I should try it. So I assume you still set the fuse(s) for 8 Mhz? The PWM's would be 1/2 the speed they are now at 8 Mhz? Think the clock is shared?
Yep, leave the fuses set to 8Mhz. It divides whatever the clock is set to in the fuses. Except the “Divide clock by 8 internally; [CKDIV8=0]” fuse. That fuse actually already uses the CLKPR.
The CLKPR should affect everything. It changes the clock entirely.
xkcd.com/1603 Li-ion battery safety 101.
Didn't try the clock yet, but ran into yet another 85 FET+1 driver that had the same flaky problems, but with a single XM-L2. This time, it seemed to only behave bad with a LG MJ1 cell (3500 10A). Other cells, like a 30Q worked fine. The cap between the 85 grnd and Vc pin did the trick once again. This was in a swm C20C using RMM's 85 FET+1 driver.
I tried 8 MHz, 6.4 MHz, 4 MHz, and 128 kHz. They all had the same power spike issue. However, at least slowed down to 128 kHz I discovered that it seems to reset on the trailing edge of the strobe pulse instead of a leading edge. So it seems to reboot when the FET power is turned off.
I also tried each brownout setting but it didn’t seem to make any difference.
Oh, and after flashing at 128 kHz, it doesn’t seem to want to be flashed any more. Anyone have any idea how to recover that?
You have to slow down the ISP clock rate (to < 1/4 the CPU clock rate?)
I use a STK-500 for programming… don’t know the magic word for avrdude to change the clock rate.
Pages