Re: Inverting RST pin (using configuration file) not working on Raspberry Pi?
On Wed, Jun 02, 2021 at 10:13:09AM +0200, Martin Stejskal wrote: > Roger, I agree that they should "survive" more, but as you correctly > mentioned, that current will sum, so it is better to keep it low. I just mentioned it, because if you know those diodes exist and can handle a thing or two, you can design things that would be much more expensive otherwise. For example, suppose you have a mains-connected AVR in a box somewhere doing something Suppose you need to know the phase of the mains voltage... Using the protection diodes this is simple: Use a mains-voltage-rated resistor (*) to an input pin. The max leakage of an input pin is 1 uA. Aim for 10uA, so you need about 22 MOhm for the resistor. The current is well below the 10mA max for the diodes on the pin The problem with repeating that 1mA often enough is that you start thinking that /that's/ the original number. I will not confirm or deny that I've fallen into that trap. Roger. (*) Often two are used in series, should one fail, you still have the other one. -- ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** **Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.
Re: Inverting RST pin (using configuration file) not working on Raspberry Pi?
On Tue, Jun 01, 2021 at 09:56:13PM +0200, Martin Stejskal wrote:
> Thing is that every GPIO suppose to have some
> protection diode (in generic - "every" IC - there are exceptions of
> course). They typically stand like ~1 mA without problems.
That diode is quite beefy! In general ("Typical") it can take about
10mA!
That doesn't mean that it is safe to do so. Suppose you have two pins
doing that 10mA, then that 20mA will end up on the 3.3V rails. Now if
there is more than 20mA of power draw on the 3.3V, but if the 3.3V
stuff goes in power-save or something like that, you can easily
over-volt your 3.3V stuff. Really easy to mess up. So a safe margin,
say a factor of ten is reasonable.
Somehow, on the RPI, I suspect that the IO cells of the broadcom CPU
can be a bit less "beefy" than "typical". Another reason to keep a
safe margin.
Roger.
--
** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233**
f equals m times a. When your f is steady, and your m is going down
your a is going up. -- Chris Hadfield about flying up the space shuttle.
Re: [avr-chat] avrdude, stk600, updi, attiny3216
On Wed, Jun 12, 2019 at 07:58:30AM +0200, Till Sellschopp wrote: > The error messages declares a missing "pgm_enable" of the respective part > (attiny3216). > In all configurations I could find, the attiny3216 or similar uC of the > same family do not have that property. Neither do the parent parts. > Are you aware of any ressources dealing with this topic? Currently it seems > to me, that alle devices in the configuration file have the same > "pgm_enable" pattern. Just looking for "pgm_enable" in my avrdude.conf I find under "attiny12": pgm_enable = "1 0 1 0 1 1 0 0 0 1 0 1 0 0 1 1", "x x x x x x x x x x x x x x x x"; Now my avrdude.conf is too old to have your '3216 device listed. Sometimes the error messages are not completely clear. Maybe the first reference to the '3216 is where the code tries to look up the pgm_enable instruction. If the lookup fails, because avrdude is looking in a different avrdude.conf file than you, and that file doesn't have the 3216 like mine, then yes, the lookup fialed, but the whole device is missing. Double check that by running avrdude under "strace" and grep for "open" in the trace output My avrdude.conf does not have /any/ variation in the "pgm_enable" instruction. Maybe the avrdude guys decided to remove the config parameter from the config file. Then you have a new config file and an old avrdude (that still requires it?) Try adding the pgm_enable instruction listed above. Roger. -- ** r.e.wo...@bitwizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** **Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233** The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. ___ AVR-chat mailing list AVR-chat@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-chat
Re: [avr-chat] far addresses
On Tue, Aug 29, 2017 at 11:54:24AM +0200, Bob von Knobloch wrote:
> I wouldn't call it a bug as the compiler is constructed for
> processors with a 16-bit address space.
Nononono! no! The compiler (gcc) is constructed for devices with a
32-bit address space. It has been quite reasonably hacked to work for
the 16-bit address space that the AVR has
But I remember the days when my co-students were swearing at gcc
because it was not easy to get it to cooperate with a 16-bit address
space (and there are bugs you are way more likely to encounter
in a 64 k address space than in 4G. For example, what happens
when you have:
print_bytes (char *p, int len)
{
char *q;
for (q=p+len;p < q;p++)
putchar (*p);
}
Works, right? Now have p point at just below halfway your addressing
space (say 0x7ff0) and q after (say 0x8010) IIRC the above is
gcc's own idea for an optimization when you actually write
for (i=0;i
Re: [avr-chat] Verify on-target image
On Tue, Apr 11, 2017 at 07:54:34AM +0200, Rolf Pfister wrote: > Am 11.04.17 um 00:03 schrieb Sam Voss: > >I was wondering if it was possible to compare the hex file that is > >currently on the chip to hex files on the host and determine which (if > >any) were the flashed version? > > > With avrdude you could do this: > avrdude -p m8 -c avr910 -P /dev/ttyUSB0 -U flash:r:flash.hex:i > This will write the content of the microcontroller to the file flash.hex. > > But when compared the contents of flash.hex with your hex file > usally you will get a difference even the content is the same. > So it needs to convert to binary first to compare the two hex files. That's not going to help. The problem with a direct compare is that the flash file that your compiler made only contains those bytes that matter. The programmer leaves all other bytes at the default value of 0xff. When reading back from the chip you'll also see those "default 0xff" bytes in the hexfile. Just compare the hexfiles with diff, and expect to see one file ending, and the other continuing with 0xff Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. ___ AVR-chat mailing list AVR-chat@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-chat
Re: [avr-chat] ensuring that _delay_us() gets a compile-time double constant
On Tue, Dec 02, 2014 at 04:35:10PM -0900, Britton Kerin wrote: On Tue, Dec 2, 2014 at 3:36 PM, Michael Hennebry henne...@web.cs.ndsu.nodak.edu wrote: On Tue, 2 Dec 2014, Britton Kerin wrote: 1. Does _delay_us() need a double const, or is an int const guaranteed to work?The avr libc manual just says known const in one place, but the signature calls for a double. _delay_us needs a double const. It will get a double whether you give it a double or some other number. That is what prototypes are for. Prototypes are ordinary C. Yes, but in many cases the type coercian for that happens at run-time. No. When it is a constant, this happens at compile time. This is what _delay_us depens on: It does a bunch of calculations, comes to this requires XXX clocks delay and then arranges for that many clock cycles delay. There ends up being no function call in your binary for _delay_us! In file included from one_wire_slave.c:8:0: /home/bkerin/opt/avr/avr/include/util/delay.h: In function ‘ows_write_bit’: /home/bkerin/opt/avr/avr/include/util/delay.h:163:28: error: __builtin_avr_delay_cycles expects a compile time integer constant __builtin_avr_delay_cycles(__ticks_dc); My guess is that a variable or a non-constant expression was passed to _delay_us. Yes, sorry I wasn't clear: This was what happens when I pass a known non-const. I'm just wondering if this trap is dependable, and if it catches non-double consts, if that's an issue. It catches the non-constant case. If you call _delay_us (1); the compiler will make that into _delay_us (1.0); as the first step. After some macro magic it will end up __builtin_avr_delay_cycles(20); (if your clock speed is 20MHz). Note that the argument is an integer again!. Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. ___ AVR-chat mailing list AVR-chat@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-chat
Re: [avr-chat] AVR EEPROM cell: Does 0xff mean it it is erased?
On Sun, Oct 18, 2009 at 11:17:26AM +0200, Heike C. Zimmerer wrote:
do nothing if they match, do a full erase/write if they differ, and do a
write-only if the cell contains 0xff, I could go on without increasing
the time needed for powering down. Of cause, this only works if 0xff in
a cell means it doesn't need to be erased.
Have you noticed that the datasheet specifies a wide margin for the
programming times of eeprom cells? (or only a max, no min?)
Internally writing an eeprom/flash cell seems to work like:
for (i=0;iMAX;i++) {
program_cell_1_cycle (addr, value);
if (read_cell (addr) == value)
break;
}
if (i == MAX) return ERROR;
n = i;
for (i=0;in;i++) {
program_cell_1_cycle (addr, value);
}
In the old days you had to execute this algorithm for programming
certain chips.
A normal cell may require say 33 loops in the first loop, so 99
times through the second loop for a total of 132 programming cycles.
If you try to program 0x55, it may still read as 0xff for 30 cycles,
switch to 7f, 5f, 57, 55 over the next three cycles.
So if programming a location failed because of a powerdown, it might
still read as 0xff after 28 cycles. Then power goes down. Next time
you start up, you read 0xff, and conclude that it's still empty. This
algorithm would then find that after 7 cycles the correct value of
0x55 is present, and then run the second loop 21 times. In the end
your location got only 56 cylces of programming instead of the
intended 132. (in the short run, your cell WILL read as 0x55 for a
while. But it may creep back to another value between 0x55 and 0xff
over time or under different circumstances!)
Anyway, I'm not sure it still works like that. Maybe that the AVR
guarantees writing of the location once you start it. Maybe you can
provide the environmnent where you won't initiate an eeprom write
when power is going down soon.
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
___
AVR-chat mailing list
AVR-chat@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-chat
Re: [avr-chat] Dragon: mega slow at dumping Flash, normal ?
On Tue, Jun 30, 2009 at 10:10:48AM +0930, Daniel O'Connor wrote:
On Tue, 30 Jun 2009, Vincent Trouilliez wrote:
On Mon, 29 Jun 2009 23:40:31 +0930
Daniel O'Connor dar...@dons.net.au wrote:
Terminal mode can be useful for some things but I usually only use
it to change fuses or check my code has modified EEPROM as I
expect.
Same here, but I also like to have a look at the first KB's of Flash
as well. I found it helpful to trouble shoot string problems, or to
verify padding, or to check that my approximate knowledge of C's
syntax did put the right address in a table of function pointers, or
whatever... I just find it quite nice to be able to easily have a
quick look at the first KB's of Flash, in a formatted way, while
having also access to EEPROM and fuses and everyting, all from the
same place. IOW... I just looove this terminal feature of avrdude
hence my desire for it, generally, to become as good as it can get
;-)
I think you'll find objdump on your resulting binary much, much
faster :)
I have the following makefile rules too (BSD make though)..
CPPFLAGS+=-Wa,-adhlmsn=${:T:S/.c/.lst/}
LDFLAGS+=-Wl,-Map=${PROG}.map,--cref
.elf.dmp:
${OBJDUMP} -S ${.IMPSRC} ${.PREFIX}.dmp
This gives you a lot of information about how the compiler has decide to
build your code.
But Vincent will reply...
but now you're dumping the image on the computer, not the hardware AVR
chip.
Right! However, with modern programmers, after testing things one or
two times, downloading things into the AVR chip is highly reliable. So
viewing the actual chip is no longer neccesary, as long as you don't
forget the download-to-the-chip command...
Roger.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ
___
AVR-chat mailing list
AVR-chat@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-chat
[avr-chat] Avrdude: skip programming addresses.
Hi, I have written a small bootloader, which I would like to load near the top of memory to leave the lower part of memory available for normal programs. Instead of flashing my whole app, which through the slow ftdi-bitbang takes ages, I was planning on first flashing the bootloader, and then loading the real app through the bootloader. This however requires me to program address 0x600 to 0x750 with my bootloader. If I call avrdude with: ../avrdude/avrdude-5.3.1/avrdude -c rew2 -p t2313 -V -U flash:w:self_program.hex it will read the hex file, and start programming 0x000 to 0x750, taking about 5 minutes. Much longer than what I had hoped. In that case I can just as well program the app using avrdude directly. I was hoping I could tell avrdude to start at a specific address, or preferably avrdude should just see that it is useless to program addresses to the value 0xff. Does anybody have a suggestion? Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 ** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. - Adapted from lxrbot FAQ ___ AVR-chat mailing list [EMAIL PROTECTED] http://lists.nongnu.org/mailman/listinfo/avr-chat
