avr/avrdude
2
0
Fork 0
mirror of https://github.com/mariusgreuel/avrdude.git synced 2025-12-16 10:41:07 +00:00
Code Issues Projects Releases Wiki Activity

Use const in PROGRAMMER function arguments where appropriate

Browse Source 
In order to get meaningful const properties for the PROGRAMMER, AVRPART and
AVRMEM arguments, some code needed to be moved around, otherwise a network of
"tainted" assignments risked rendering nothing const:

 - Change void (*enable)(PROGRAMMER *pgm) to void (*enable)(PROGRAMMER *pgm,
   const AVRPART *p); this allows changes in the PROGRAMMER structure after
   the part is known. For example, use TPI, UPDI, PDI functions in that
   programmer appropriate to the part. This used to be done later in the
   process, eg, in the initialize() function, which "taints" all other
   programmer functions wrt const and sometimes requires other finessing with
   flags etc. Much clearer with the modified enable() interface.

 - Move TPI initpgm-type code from initialize() to enable() --- note that
   initpgm() does not have the info at the time when it is called whether or
   not TPI is required

 - buspirate.c: move pgm->flag to PDATA(pgm)->flag (so legitimate
   modification of the flag does not change PROGRAMMER structure)

 - Move AVRPART_INIT_SMC and AVRPART_WRITE bits from the flags field in
   AVRPART to jtagmkII.c's private data flags32 fiels as FLAGS32_INIT_SMC and
   FLAGS32_WRITE bits

 - Move the xbeeResetPin component to private data in stk500.c as this is
   needed by xbee when it saddles on the stk500 code (previously, the flags
   component of the part was re-dedicated to this)

 - Change the way the "chained" private data are used in jtag3.c whilst
   keeping the PROGRAMMER structure read-only otherwise

 - In stk500v2.c move the STK600 pgm update from stk500v2_initialize() to
   stk500v2_enable() so the former keeps the PROGRAMMER structure read-only
   (for const assertion).

 - In usbasp change the code from changing PROGRAMMER functions late to
   dispatching to TPI or regular SPI protocol functions at runtime; reason
   being the decision whether to use TPI protocol is done at run-time
   depending on the capability of the attached programmer

Also fixes Issue #1071, the treatment of default eecr value.
This commit is contained in:
Stefan Rueger
2022-08-17 16:05:28 +01:00
parent dfef8bb0a8
commit c03f4a7925
85 changed files with 1582 additions and 2217 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
src/xbee.h
View File

@@ -22,6 +22,27 @@
#define xbee_h__
extern const char xbee_desc[];
void xbee_initpgm (PROGRAMMER * pgm);
void xbee_initpgm(PROGRAMMER *pgm);
/*
* For non-direct mode (Over-The-Air) we need to issue XBee commands
* to the remote XBee in order to reset the AVR CPU and initiate the
* XBeeBoot bootloader.
*
* XBee IO port 3 is a somewhat-arbitrarily chosen pin that can be
* connected directly to the AVR reset pin.
*
* Note that port 7 was not used because it is the only pin that can
* be used as a CTS flow control output. Port 6 is the only pin that
* can be used as an RTS flow control input.
*
* Some off-the-shelf Arduino shields select a different pin. For
* example this one uses XBee IO port 7.
*
* https://wiki.dfrobot.com/Xbee_Shield_For_Arduino__no_Xbee___SKU_DFR0015_
*/
#ifndef XBEE_DEFAULT_RESET_PIN
#define XBEE_DEFAULT_RESET_PIN 3
#endif
#endif