NewVPP

[fredcwbr]

Howdy all.

I'm looking more carefully into setVPP() , and there is something bugging me from the start.
As i understand this, there are two limits on the VPP that is being controled here.

To be safe, starts with the lower bound and goes to the upper bound.
The code shows that even though PES should be the source, it cannot be relied on, so safety checks are done to prevent unintentional magic smoke.

And then there is this vpp = //

., setting., * nothing against it at all ...

*** but just a thougt here , ***
just a thought

would it be more productive in a code stylish way to macro it (the code is repeated various times) ., some thing like a mapping not only from the index table to the voltage table, but the other way around., ?

// here is the tricky one, cause it depends on the 
// shield version, so using it this way encapsulates 
// whatever new shield improvements come, adding
// support to a more flexible configuration, 
// without bloating the code.
// 
#define index2Volts( int ix )
#define volts2Index( double volts )

#define safeVPP( min, max )   if ( vpp < index2Volts( 9v ) ) { \
                // instead of ... vpp = 36; //9V \
				index2Volts( 9v ) 
        ........

Wouldn't that allow an improvement on the galinfo_t, since adding VPP there would allow a bit of code to generify (don't know if that word exists, but will try it anyway )
the detection/configuration/programming using parameters for the part.

something like :

// GAL info 
typedef struct
{
    GALTYPE type;
    unsigned char id0,id1;          /* variant 1, variant 2 (eg. 16V8=0x00, 16V8A+=0x1A)*/
    short fuses;                    /* total number of fuses              */
    char pins;                      /* number of pins on chip             */
    char rows;                      /* number of fuse rows                */
    unsigned char bits;             /* number of fuses per row            */
    char uesrow;                    /* UES row number                     */
    short uesfuse;                  /* first UES fuse number              */
    char uesbytes;                  /* number of UES bytes                */
    char eraserow;                  /* row adddeess for erase             */
    char eraseallrow;               /* row address for erase all (also PES) */
    char pesrow;                    /* row address for PES read/write     */
    char pesbytes;                  /* number of PES bytes                */
    char cfgrow;                    /* row address of config bits (ACW)   */
    unsigned short cfgbase;         /* base address of the config bit numbers */
    const unsigned char *cfg;       /* pointer to config bit numbers      */
    unsigned char cfgbits;          /* number of config bits              */
    unsigned char cfgmethod;        /* strobe or set row for reading config */
    PINOUT pinout;
	VPP	float;   					/* VPP (max) of this part 			 */
} galinfo_t;

which would lead to something like :

// According do ole00 that afterburner does work properly with a -2V bias on VPP
#define SAFEVOLTAGEMARGIN  2    
#define galVPPlowend( gal )   ( gal->VPP - SAFEVOLTAGEMARGIN )
#define safeVPP_frompart( min, max, gal )   if ( vpp < index2Volts( galVPPlowend(gal) ) ) { \
                // instead of ... vpp = 36; //9V \
				index2Volts( gal->VPP ) 
				...

Does some of this make any sense?

[ole00]

hi, it is not a good idea to put vpp value into galinfo struct. The reason is that the same type of gal (lets say GAL16V8) can have different VPP based on the manufacturer (different manufacturer is different VPP). Besides, this structure is held in memory, so it is better not to extend the structure. The VPP value is calculated based on the data stored in the chip itself - so call PES data.