De μC programmers Kroeg

[Infant]

Dat register is 5 bytes lang.
Dus je moet het register schijven: (0x20 | 0x10)
En dan 5 keer de adress bytes naar buiten shiften.

[Pizza_Boom]

Infant schreef op zaterdag 28 maart 2015 @ 12:59:
Dat register is 5 bytes lang.
Dus je moet het register schijven: (0x20 | 0x10)
En dan 5 keer de adress bytes naar buiten shiften.

Maar ik heb in register 13 een address width van 3 bytes ingesteld... Moet ik dan niet 3x address bytes shiften?

[RobV]

@Pizza_Boom, het klinkt alsof je je eigen driver aan het schrijven bent? Kun je niet beginnen met het gebruiken van de bestaande libraries? Of zijn die niet beschikbaar op PIC? Arduino C is niet zo moeilijk te begrijpen, je zou stiekem kunnen spieken hoe anderen het gedaan hebben.

[Pizza_Boom]

RobV schreef op zaterdag 28 maart 2015 @ 18:34:
@Pizza_Boom, het klinkt alsof je je eigen driver aan het schrijven bent? Kun je niet beginnen met het gebruiken van de bestaande libraries? Of zijn die niet beschikbaar op PIC? Arduino C is niet zo moeilijk te begrijpen, je zou stiekem kunnen spieken hoe anderen het gedaan hebben.

Dat ben ik ook. Ik had wat info gevonden en heb mijn init zo goed als af. Ik zit eigenlijk alleen met dat address in mijn maag, de rest zou moeten werken (dat roep ik echter vaker. ). Verwarrende is ook dat ze uit gaan van een 5 bit registeraddress, maar om hem te schrijven, je bit 5, 6 en 7 ook moet gebruiken en wel als 001. Daardoor schrijf je dus niet register 0x10, maar 0x30.

Iets anders "lastigs" aan dat ding is dat hij of dummydata verzend als je zelf schrijft, of dummydata wil ontvangen om jou te kunnen schrijven. Efficiëntie van het SPI protocol is dus een beetje weg, maarja. Ik ben nog niet zo ver dat ik hem op de volle 100% zou willen laten draaien en daardoor in de problemen kom. Dan is het wel weer tijd voor een ander apparaatje.

Arduino heb ik eigenlijk niet genoeg kennis van om daar goed uit te kunnen spieken, datzelfde heb ik ook vaak met assembler. Ik wil nog wel eens met Arduino aan de slag, maar momenteel heeft de PIC de prioriteit. Googlen op het TX_ADDR levert me eigenlijk ook vrij weinig op. DIYembedded heeft een leuke tutorial, maar is ontzettend langdradig en ik kan bepaalde stappen van ze niet linken aan wat er moet gebeuren in de code.
Verder is dit een heel handig topic, maar ik wil het niet 1:1 kopiëren. Deze en de DIY tutorial hebben een hoop duidelijk gemaakt, de stijl is heel overzichtelijk, maar ik wil het zelf doen. En ik maak ook andere keuzes op bepaalde punten.

code:

void nrf_config()           // NRF initialisation code TX mode
    {
        CE = laag;          // chip standby, does not monitor the airdata
        __delay_ms(10);     // delay
        CSN = hoog;         // must be high when idle
        __delay_ms(100);    // delay

        CSN = laag;         // indicate data transmitting to NRF
        spiNRF_write(0x20); // write register(=001) 0 0000
        spiNRF_write(0x0A); // (0000 1010) CRC enabled, interrupts on IRQ enabled, PTX (=transceiver), power up
        CSN = hoog;         // end data transmitting
        __delay_us(1);      // delay

        CSN = laag;
        spiNRF_write(0x21); // write register(=001) 0 0001
        spiNRF_write(0x00); // turn off auto ACK
        CSN = hoog;
        __delay_us(1);
                            // register 0x22 is used only in RX mode

        CSN = laag;
        spiNRF_write(0x23); // write register(=001) 0 0003
        spiNRF_write(0x01); // address width 3 bytes
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spiNRF_write(0x24); // write register(=001) 0 0004
        spiNRF_write(0x03); // retry transmitting when failed after 250 uS, try 3 times
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spiNRF_write(0x25); // write register(=001) 0 0005
        spiNRF_write(0x05); // operating frequency set to 0000 0101
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spiNRF_write(0x26); // write register(=001) 0 0006
        spiNRF_write(0x04); // 1MB/s data rate, -6 dBm output power
        CSN = hoog;
        __delay_us(1);

                            // register 0x27 is status register
                            // register 0x28 is transmitter observer
                            // register 0x29 is received power detector
                            // triggered by power levels above -64dBm in slected channel
                            // register 0x2A - 2F = data pipe addresses
                            // register 0x30 is transmit address

        int i;
        CSN = laag;
        spiNRF_write(0x30); // write register (=001) 1 0000 = transmit address
        for (i=0; i<3; i++) // write addressbyte E7 3x for complete TX_ADDR (= E7E7E7)
            {
                spiNRF_write(0xE7);
            }
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spiNRF_write(0x31); // write register (=001) 1 0001
        spiNRF_write(0x04); // 4 byte payload in data pipe 0
        CSN = hoog;
        __delay_us(1);

    }

Deze code zou in principe grotendeels gelijk moeten zijn voor de RX chip, maar als ik al niet zeker ben van mijn TX systeem... Het builden gaat iig zonder errors, ook wel prettig.

[Voor 4% gewijzigd door Pizza_Boom op 28-03-2015 18:52]

[Sissors]

SPI is nou eenmaal full duplex, echter veruit de meeste chips hebben dat niet nodig, en dan is inderdaad één lijn gevuld met dummy data.

[Pizza_Boom]

Maar dat mag het probleem niet zijn atm. Ik zit meer met dat address register...

[Pizza_Boom]

Hmmm, bij mijn address width register:

RX/TX Address field width
'00' - Illegal
'01' - 3 bytes
'10' - 4 bytes
'11' – 5 bytes
LSByte is used if address width is below 5 byte

Dus ik moet wel 5 bytes erin trappen, maar hij gebruikt alleen de laatste 3 bytes die ik verstuur als address.

[Pizza_Boom]

Even een vervolg op deze post, dar ik heb nog steeds niet werkend krijg, wellicht dat iemand hier nog een fout ziet? Dit zijn momenteel de RX en TX code:

TX Device:

C:

/*

             ________  _______
        VDD |        \/       | VSS
        RA5 |   PIC16F1459    | RA0
        RA4 |                 | RA1 
        RA3 |                 | Vusb3v3
LED Red RC5 |                 | RC0
LED Gr  RC4 |                 | RC1
SDI CSN RC3 |                 | RC2 
SDI CE  RC6 |                 | RB4 SPI Serial Data in
SPI SDO RC7 |                 | RB5
SDI IRQ RB7 |_________________| RB6 SPI SCL (white)

*/

 #include   <xc.h>
 #include   <stdbool.h>

 #define _XTAL_FREQ 16000000
 #define byte unsigned char


 #define laag   0
 #define hoog   1

 #define CE     RC6     // Chip Enable          output
 #define IRQ    RB7     // Interrupt            input
 #define CSN    RC3     // Chip Select Not      output
 #define SDO    RC7     // Serial Data Out      output
 #define SDI    RB4     // Serial Data In       input
 #define CLK    RB6     // Clock                output



// Config Register: CONFIG1
// Oscillator Selection:                 FOSC_ECH,FOSC_ECH,FOSC_ECL,FOSC_INTOSC,FOSC_EXTRC,FOSC_HS,FOSC_XT,FOSC_LP
// Watchdog Timer Enable:                WDTE_ON,WDTE_NSLEEP,WDTE_SWDTEN,WDTE_OFF
// WDT enabled
// Power-up Timer                        PWRTE_OFF,PWRTE_ON
// MCLR Pin Function Select              MCLRE_ON,MCLRE_OFF
// Flash Program Memory Code Protection  CP_OFF,CP_ON
// Brown-out Reset Enable                BOREN_ON,BOREN_NSLEEP,BOREN_SBODEN,BOREN_OFF
// Clock Out Enable                      CLKOUTEN_OFF,CLKOUTEN_ON
//   
// Internal/External Switchover          IESO_ON,IESO_OFF
// Fail-Safe Clock Monitor Enable        FCMEN_ON,FCMEN_OFF
// Config Register:CONFIG2 
// Flash Memory Self-Write Protection    WRT_OFF,WRT_BOOT,WRT_HALF,WRT_ALL
// PLL                                   PLLEN_ENABLE,PLLEN_DISABLE
// Stack Overflow/Underflow Reset Enable STVREN_ON,STVREN_OFF
// Brown-out Reset Voltage Selection     BORV_LO,BORV_HI
// Low-Voltage Programming Enable        LVP_ON,LVP_OFF

#pragma config FOSC=INTOSC, WDTE=OFF, PWRTE=OFF, MCLRE=ON, CP=OFF, BOREN=OFF, CLKOUTEN=OFF, IESO=OFF, FCMEN=OFF, WRT=OFF, PLLEN=DISABLED, STVREN=OFF, BORV=HI, LVP=OFF,

int knop1, knop2;
bool ack;
unsigned char dataR;
unsigned char dummydata;

unsigned char spi_send(unsigned char dataS)
    {
        SSP1IF  = 0;        // clear interrupt flag
        SSP1BUF = dataS;    // send dataS(end)
        while (!SSP1IF);        // wait till SSP interrupt flag is set
        dataR   = SSP1BUF;  // read SSPBUF to dataR(ead)
        return dataR;
    }

void nrf_config()           // NRF initialisation code TX mode
    {
        CE = laag;          // chip standby, does not monitor the airdata
        __delay_ms(10);     // delay
        CSN = hoog;         // must be high when idle
        __delay_ms(100);    // delay

        CSN = laag;         // indicate data transmitting to NRF
        spi_send(0x20);     // write register(=001) 0 0000
        spi_send(0x0A);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PTX (=transceiver), power up
        CSN = hoog;         // end data transmitting
        __delay_us(1);      // delay

        CSN = laag;
        spi_send(0x21);     // write register(=001) 0 0001
        spi_send(0x00);     // turn off auto ACK
        CSN = hoog;
        __delay_us(1);
                            // register 0x22 is used only in RX mode

        CSN = laag;
        spi_send(0x23);     // write register(=001) 0 0003
        spi_send(0x01);     // address width 3 bytes
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0x24);     // write register(=001) 0 0004
        spi_send(0x03);     // retry transmitting when failed after 250 uS, try 3 times
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0x25);     // write register(=001) 0 0005
        spi_send(0x05);     // operating frequency set to 0000 0101
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0x26);     // write register(=001) 0 0006
        spi_send(0x04);     // 1MB/s data rate, -6 dBm output power
        CSN = hoog;
        __delay_us(1);

                            // register 0x27 is status register
                            // register 0x28 is transmitter observer
                            // register 0x29 is received power detector
                            // triggered by power levels above -64dBm in slected channel
                            // register 0x2A - 2F = data pipe addresses
                            // register 0x30 is transmit address

        int i;
        CSN = laag;
        spi_send(0x30);     // write register (=001) 1 0000 = transmit address
        for (i=0; i<5; i++) // write addressbyte E7 3x for complete TX_ADDR (= E7E7E7)
            {
                spi_send(0xE7);
            }
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0x31);     // write register (=001) 1 0001
        spi_send(0x04);     // 4 byte payload in data pipe 0
        CSN = hoog;
        __delay_us(1);

    }

        // send to NRF unit, 4 byte payload
        // after sending data to NRF, empty FIFO by transmitting this data
unsigned char nrf_send(unsigned char data1, unsigned char data2, unsigned char data3, unsigned char data4)
    {
        CSN = laag;
        spi_send(0xA0);         // command to write TX FIFO
        spi_send(data1);        // send data1 to TX FIFO
        spi_send(data2);        // send data2 to TX FIFO
        spi_send(data3);        // send data3 to TX FIFO
        spi_send(data4);        // send data4 to TX FIFO
        CSN = hoog;
        __delay_us(1);


        CE = hoog;                  // make CE high to initiate data transmitting
        __delay_us(100);            // keep CE high for at least 10 uS to transmit data
        CE = laag;                  // make CE low again to stop transmitting
        __delay_us(1);
        
        return 0;
    }
    

void main(void)                         // main program
{
    ANSELA  =   0x00;
    ANSELB  =   0x00;
    ANSELC  =   0x00;
    TRISA   =   0x00;
    TRISB   =   0b10010000;
    TRISC   =   0b00000000;
    OSCCON  =   0b00111100; //internal clock 16 MHz no PLL
    PORTB   =   0x00;
    PORTC   =   0x00;

    // [SPI mastermode]     
    INTCON = 0xD1;
    PIE1 = 0b00001000;
    PIE2 = 0x00;
    PIR1 = 0x00;
    PIR2 = 0x00;
    SSP1ADD  = 0x27;    // 100 kHz, SSPAD 39. instellen Fosc zo langzaam mogelijk !!!
    SSP1STAT = 0b11000000;  // input sampled at end of output time, sending at clock from active to idle
    SSP1CON1 = 0b00111010;  // SSP high clock, baudrate calculated with SSPADD
    SSP1CON3 = 0b00010000;  // SSP overwrite data when buffer is not read in slave mode, no use in mastermode
    // [/SPI mastermode]

    nrf_config();

//mastercode start
    while (1)
    {
        LATC5 = 1;
        __delay_ms(500);
        nrf_send(0x12, 0x12, 0x12, 0x12);
        LATC4 = 1;
        __delay_ms(500);
        LATC4 = LATC5 = 0;
        __delay_ms(500);
    

    }
}

//master stop

RX Device:

C:

/*

             ________  _______
        VDD |        \/       | VSS
        RA5 |   PIC16F1459    | RA0
        RA4 |                 | RA1
        RA3 |                 | Vusb3v3
LED Red RC5 |                 | RC0
LED Gr  RC4 |                 | RC1
SDI CSN RC3 |                 | RC2 
SDI CE  RC6 |                 | RB4 SPI Serial Data in
SPI SDO RC7 |                 | RB5
SDI IRQ RB7 |_________________| RB6 SPI SCL (white)

*/

 #include   <xc.h>
 #include   <stdbool.h>

 #define _XTAL_FREQ 16000000
 #define byte unsigned char


 #define laag   0
 #define hoog   1

 #define CE     RC6     // Chip Enable          output
 #define IRQ    RB7     // Interrupt            input
 #define CSN    RC3     // Chip Select Not      output
 #define SDO    RC7     // Serial Data Out      output
 #define SDI    RB4     // Serial Data In       input
 #define CLK    RB6     // Clock                output



// Config Register: CONFIG1
// Oscillator Selection:                 FOSC_ECH,FOSC_ECH,FOSC_ECL,FOSC_INTOSC,FOSC_EXTRC,FOSC_HS,FOSC_XT,FOSC_LP
// Watchdog Timer Enable:                WDTE_ON,WDTE_NSLEEP,WDTE_SWDTEN,WDTE_OFF
// WDT enabled
// Power-up Timer                        PWRTE_OFF,PWRTE_ON
// MCLR Pin Function Select              MCLRE_ON,MCLRE_OFF
// Flash Program Memory Code Protection  CP_OFF,CP_ON
// Brown-out Reset Enable                BOREN_ON,BOREN_NSLEEP,BOREN_SBODEN,BOREN_OFF
// Clock Out Enable                      CLKOUTEN_OFF,CLKOUTEN_ON
//   
// Internal/External Switchover          IESO_ON,IESO_OFF
// Fail-Safe Clock Monitor Enable        FCMEN_ON,FCMEN_OFF
// Config Register:CONFIG2 
// Flash Memory Self-Write Protection    WRT_OFF,WRT_BOOT,WRT_HALF,WRT_ALL
// PLL                                   PLLEN_ENABLE,PLLEN_DISABLE
// Stack Overflow/Underflow Reset Enable STVREN_ON,STVREN_OFF
// Brown-out Reset Voltage Selection     BORV_LO,BORV_HI
// Low-Voltage Programming Enable        LVP_ON,LVP_OFF

#pragma config FOSC=INTOSC, WDTE=OFF, PWRTE=OFF, MCLRE=ON, CP=OFF, BOREN=OFF, CLKOUTEN=OFF, IESO=OFF, FCMEN=OFF, WRT=OFF, PLLEN=DISABLED, STVREN=OFF, BORV=HI, LVP=OFF,

int knop1, knop2, j;
bool ack;
unsigned char dataR;
unsigned char dummydata;
unsigned char data1, data2, data3, data4;

unsigned char spi_send(unsigned char dataS)
    {
        SSP1IF  = 0;        // clear interrupt flag
        SSP1BUF = dataS;    // send dataS(end)
        while (!SSP1IF);        // wait till SSP interrupt flag is set
        dataR   = SSP1BUF;  // read SSPBUF to dataR(ead)
        return dataR;
    }

void nrf_config()           // NRF initialisation code RX mode
    {
        CE = laag;          // chip standby, does not monitor the airdata
        __delay_ms(10);     // delay
        CSN = hoog;         // must be high when idle
        __delay_ms(100);    // delay

        CSN = laag;         // indicate data transmitting to NRF
        spi_send(0x20);     // write register(=001) 0 0000
        spi_send(0x09);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up
        CSN = hoog;         // end data transmitting
        __delay_us(1);      // delay

        CSN = laag;
        spi_send(0x21);     // write register(=001) 0 0001
        spi_send(0x00);     // turn off auto ACK
        CSN = hoog;
        __delay_us(1);
/*                          // register 0x22 is used only in RX mode
        CSN = laag;
        spi_send(0x22);     // write register(=001) 0 0010
        spi_send(0x03);     // receive trough data pipe 0 & 1
        CSN = hoog;
        __delay_us(1); */

        CSN = laag;
        spi_send(0x23);     // write register(=001) 0 0003
        spi_send(0x01);     // address width 3 bytes
        CSN = hoog;
        __delay_us(1);

/*      CSN = laag;         // enable in TX mode
        spi_send(0x24);     // write register(=001) 0 0004
        spi_send(0x03);     // retry transmitting when failed after 250 uS, try 3 times
        CSN = hoog;
        __delay_us(1); */

        CSN = laag;
        spi_send(0x25);     // write register(=001) 0 0005
        spi_send(0x05);     // operating frequency set to 0000 0101
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0x26);     // write register(=001) 0 0006
        spi_send(0x04);     // 1MB/s data rate, -6 dBm output power
        CSN = hoog;
        __delay_us(1);

                            // register 0x27 is status register
                            // register 0x28 is transmitter observer
                            // register 0x29 is received power detector
                            // triggered by power levels above -64dBm in slected channel
                            // register 0x2A - 2F = data pipe addresses
                            // register 0x30 is transmit address

        int i;
        CSN = laag;
        spi_send(0x2A);     // write register (=001) 1 0000 = transmit address
        for (i=0; i<5; i++) // write addressbyte E7 3x for complete TX_ADDR (= E7E7E7)
            {
                spi_send(0xE7);
            }
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0x31);     // write register (=001) 1 0001
        spi_send(0x04);     // 4 byte payload in data pipe 0
        CSN = hoog;
        __delay_us(1);

        CSN = laag;         // indicate data transmitting to NRF
        spi_send(0x20);     // write register(=001) 0 0000
        spi_send(0x0B);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up
        CSN = hoog;         // end data transmitting
        __delay_us(1);      // delay

        CE = hoog;          // CE high means receiver is listening to the air data

    }

        // send to NRF unit, 4 byte payload
        // after sending data to NRF, empty FIFO by transmitting this data
unsigned char nrf_send(unsigned char data1, unsigned char data2, unsigned char data3, unsigned char data4)
    {
        CSN = laag;
        spi_send(0xA0);         // command to write TX FIFO
        spi_send(data1);        // send data1 to TX FIFO
        spi_send(data2);        // send data2 to TX FIFO
        spi_send(data3);        // send data3 to TX FIFO
        spi_send(data4);        // send data4 to TX FIFO
        CSN = hoog;
        __delay_us(1);


        CE = hoog;                  // make CE high to initiate data transmitting
        __delay_us(100);            // keep CE high for at least 10 uS to transmit data
        CE = laag;                  // make CE low again to stop transmitting
        __delay_us(1);
        
        return 0;
    }

        // read from NRF unit, 4 byte payload
        // empty RX FIFO after transmission 
void nrf_read()
    {
        CSN = laag;
        spi_send(0x61);             // command to read RX FIFO
        spi_send(0x01);             // read data, send 0x01
        data1 = dataR;              // read SSP1BUF to data1
        spi_send(0x01);             // read data, send 0x01
        data2 = dataR;              // read SSP1BUF to data2
        spi_send(0x01);             // read data, send 0x01
        data3 = dataR;              // read SSP1BUF to data3
        spi_send(0x01);             // read data, send 0x01
        data4 = dataR;              // read SSP1BUF to data4
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0xE2);             // flush RX FIFO data, data not needed anymore
        CSN = hoog;
        __delay_us(1);

        CSN = laag;
        spi_send(0x27);             // call status register
        spi_send(0x4E);             // clear interrupt, RX FIFO empty
        CSN = hoog;
        __delay_us(1);
    }

        
void main(void)                         // main program
{
    ANSELA  =   0x00;
    ANSELB  =   0x00;
    ANSELC  =   0x00;
    TRISA   =   0x00;
    TRISB   =   0b10010000;
    TRISB7  =   1;
    TRISB4  =   1;
    TRISC   =   0b00000000;
    OSCCON  =   0b00111100; //internal clock 16 MHz no PLL
    PORTB   =   0x00;
    PORTC   =   0x00;

    // [SPI mastermode]     
    INTCON = 0xD1;
    PIE1 = 0b00001000;
    PIE2 = 0x00;
    PIR1 = 0b00;
    PIR2 = 0x00;
    SSP1ADD  = 0x27;    // 100 kHz, SSPAD 39. instellen Fosc zo langzaam mogelijk !!!
    SSP1STAT = 0b11000000;  // input sampled at end of output time, sending at clock from active to idle
    SSP1CON1 = 0b00111010;  // SSP high clock, baudrate calculated with SSPADD
    SSP1CON3 = 0b00010000;  // SSP overwrite data when buffer is not read in slave mode, no use in mastermode
    // [/SPI mastermode]

    nrf_config();

//mastercode start
    while (1)
    {
        if (IRQ == 0)
            {
                LATC4 = 1;
            }
        else if (IRQ == 1)
            {
                LATC5 = 1;
            }
        __delay_ms(300);
        LATC4 = LATC5 = 0;
        __delay_ms(300);

/*      LATC5 = 1;
        __delay_ms(500);
        nrf_read();
        if (data1 == 0x12)
            {
                LATC4 = 1;
            }
        else
            {
                LATC5 = 0;
                __delay_ms(100);
                LATC5 = 1;
            }
        __delay_ms(500);
        LATC5 = LATC4 = 0;
        __delay_ms(500); */
    }
}

//master stop

Probleem is dat ik geen low krijg op mijn IRQ aan de ontvangende (RX) zijde en dus ook geen data uit kan lezen, want er is niets. Als ik de IRQ pin loskoppel gaat ie wel omlaag. Ik heb al de nrf's vervangen met elkaar en vervangen door 2 nieuwe, haalt allebei niets uit. Ik heb gisteravond ook al de code geprobeerd qua registers identiek te maken aan het voorbeeld dat ik gevonden had, maar dat haalde ook niets uit. Ik hoop dat iemand hier nog een idee heeft, want ik weet niet waar ik het nu nog moet zoeken.
Voor de mensen die geen zin hebben om alles terug te lezen: PIC16F1459 en nRF24L01+, 2x.

[Voor 0% gewijzigd door Pizza_Boom op 31-03-2015 18:22. Reden: code=c gemaakt]

[RobV]

Misschien nrf-send rond regel 155, CE toggle. Moet de chip niet enabled zijn TIJDENS de data transfer ipv erna?

Bonuspunten voor de documentatie bovenaan met de pinout.

[Voor 4% gewijzigd door RobV op 31-03-2015 13:52]

[EMP]

AH, leuk, een kroegtopic waar ik ook kan meepraten.

Ik heb gewerkt met wat Motorola, Renesas (Hitachi) en Arm (cortex M0 t/m A9) μC'tjes, met de meeste grote studio's en debuggers en vooral veel in C/C++ geprogrammeerd. Ook ASM, maar dat probeer ik tot een minimum te beperken

Reden voor zoveel verschillende controllers: een aantal jaar in de detachering werken!

Ik heb ook grotere systemen gedaan (een Intel-i7 IPC met QNX of linux), maar mijn liefde blijft toch bij de kleine chipjes.

De lappen code zal ik een ander keertje moeten lezen

[RobV]

Welkom @EMP

[Ploink]

Pizza_Boom schreef op dinsdag 31 maart 2015 @ 13:08:
Probleem is dat ik geen low krijg op mijn IRQ aan de ontvangende (RX) zijde en dus ook geen data uit kan lezen, want er is niets. Als ik de IRQ pin loskoppel gaat ie wel omlaag.

Lijkt er op dat je pin geconfigureerd is als output en de nrf hem niet omlaag kan trekken.
Pin RB7 zet je wel als input, maar er is een leuke valkuil. RB7 doet ook dienst als TX voor de serial port en als die aan staat (bitje SPEN in RCSTA), dan kun je de pin nog zo hard op input zetten, het blijft een output

Je gebruikt de uart blijkbaar niet, maar misschien zet een van je libs hem aan?

[Infant]

70% van deze kroeg pagina is nu code...

Ik heb die nRFjes altijd op 5 bytes adres gehad, ik kreeg ook niet elke pakket lengte werkend. Een te klein pakketje kan ik me herinneren werkt niet, en een te groot pakket ook niet.

Zo moeten "under the hood" ook op lijp veel rf-ellende synchroniseren, daar schijnt bij die van mij een sweet spot in te zitten.

Nou had ik van die brakke met een PCB antenne, dat als je ze 1 milimeter verschuift het berijk meteen weg is.

Op zich wil je dit, want volgens D. Adams is dat nou eenmaal de toekomst:

For years radios had been operated by means of pressing buttons and turning dials; then as the technology became more sophisticated the controls were made touch-sensitive - you merely had to brush the panels with your fingers; now all you had to do was wave your hand in the general direction of the components and hope. It saved a lot of muscular expenditure of course, but meant that you had to sit infuriatingly still if you wanted to keep listening to the same programme.

Dus ja...

[Voor 38% gewijzigd door Infant op 31-03-2015 17:46]

[RobV]

Infant schreef op dinsdag 31 maart 2015 @ 17:40:
70% van deze kroeg pagina is nu code...

Dit is dan ook het software draadje

Douglas A. wordt altijd gewaardeerd door mij.

[Ploink]

Infant schreef op dinsdag 31 maart 2015 @ 17:40:
70% van deze kroeg pagina is nu code...

Misschien een idee om voor grote lappen code pastebin oid te gebruiken en alleen een linkje in de reactie te plaatsen.

oh en "[code=c]" ipv "[code]" maakt het leesbaarder met kleurtjes

C:

unsigned char spi_send(unsigned char dataS)
    {
        SSP1IF  = 0;        // clear interrupt flag
        SSP1BUF = dataS;    // send dataS(end)
        while (!SSP1IF);        // wait till SSP interrupt flag is set
        dataR   = SSP1BUF;  // read SSPBUF to dataR(ead)
        return dataR;
    }

[Voor 40% gewijzigd door Ploink op 31-03-2015 18:06]

[Wolfboy]

Ploink schreef op dinsdag 31 maart 2015 @ 18:01:
[...]

Misschien een idee om voor grote lappen code pastebin oid te gebruiken en alleen een linkje in de reactie te plaatsen.

oh en "[code=c]" ipv "[code]" maakt het leesbaarder met kleurtjes

C:

unsigned char spi_send(unsigned char dataS)
    {
        SSP1IF  = 0;        // clear interrupt flag
        SSP1BUF = dataS;    // send dataS(end)
        while (!SSP1IF);        // wait till SSP interrupt flag is set
        dataR   = SSP1BUF;  // read SSPBUF to dataR(ead)
        return dataR;
    }

Imho zou het forum gewoon moeten auto-collapsen bij 20+ regels, zodat je het wel kan uitklappen als je dat wilt maar dat het standaard wat beperkter is kwa grootte.

Op een pastebin hosten is opzich geen slecht idee maar als het een keer down zou gaan ben je alle data kwijt en is de helft van zon' topic zinloos.

[Pizza_Boom]

En toen was er, na het heraanleggen van de las in de centrale lijn, helemaal geen internet meer... Excuseer mij bij langere reactietijd. Ik wil wel, maar kan niet. En bijna 500 regels code op je telefoon doorwerken is niet echt prettig.

RobV schreef op dinsdag 31 maart 2015 @ 13:52:
Misschien nrf-send rond regel 155, CE toggle. Moet de chip niet enabled zijn TIJDENS de data transfer ipv erna?

Volgens de data sheet pagina 72 valt de nrf in standby-II als de FIFO leeg is en CE hoog. Zodra CE laag is, wordt het standby-I.

Bonuspunten voor de documentatie bovenaan met de pinout.

Thanks. Maakt het voor jezelf ook zoveel makkelijker.

Ploink schreef op dinsdag 31 maart 2015 @ 14:59:

Lijkt er op dat je pin geconfigureerd is als output en de nrf hem niet omlaag kan trekken.
Pin RB7 zet je wel als input, maar er is een leuke valkuil. RB7 doet ook dienst als TX voor de serial port en als die aan staat (bitje SPEN in RCSTA), dan kun je de pin nog zo hard op input zetten, het blijft een output

Je gebruikt de uart blijkbaar niet, maar misschien zet een van je libs hem aan?

Ik heb ook 0 ervaring met uart en 4/5 maanden terug wist ik niets van communicatie tussen chips, inmiddels draait I2C en nu wil ik draadloos met spi. Echte libs gebruik ik niet echt, enkel 2 headers, waarvan xc8 voor de compilers is. Maar ook met pulldown erbij verandert er niets. Trek ik echter de nrf lijn eruit, dan valt ie wel naar 0 (en zonder pulldown zweeft ie soms richting 1 en weer terug).

Infant schreef op dinsdag 31 maart 2015 @ 17:40:
70% van deze kroeg pagina is nu code...

Ik heb die nRFjes altijd op 5 bytes adres gehad, ik kreeg ook niet elke pakket lengte werkend. Een te klein pakketje kan ik me herinneren werkt niet, en een te groot pakket ook niet.

Zo moeten "under the hood" ook op lijp veel rf-ellende synchroniseren, daar schijnt bij die van mij een sweet spot in te zitten.

Nou had ik van die brakke met een PCB antenne, dat als je ze 1 milimeter verschuift het berijk meteen weg is.

Op zich wil je dit, want volgens D. Adams is dat nou eenmaal de toekomst:

[...]


Dus ja...

Ik heb ook pcb antenne, maar momenteel staan ze nog geen 10 cm uit elkaar. Ik heb op 3 bytes address geprobeerd, op 5 bytes, geen verschil. Ik las dat je ze op dezelfde payload moet hebben, ze staan samen hetzelfde ingesteld en ik stuur hetzelfde.

Het lastige is nu natuurlijk ook dat er 2 onbekenden zijn. Met I2C heb ik een eeprom genomen om eerst de fouten in de master te elimineren, maar hier gaat dat niet.

Zou jij niet jouw code kunnen opsnorren en e.e.a. eens kunnen vergelijken?

Ploink schreef op dinsdag 31 maart 2015 @ 18:01:
[...]

Misschien een idee om voor grote lappen code pastebin oid te gebruiken en alleen een linkje in de reactie te plaatsen.

oh en "[code=c]" ipv "[code]" maakt het leesbaarder met kleurtjes

Dat kon ik nog net wel aanpassen op mijn telefoon. Ik had eigenlijk verwacht dat het codevak een lengtelimiet had en scrollbaar zou worden.

[Infant]

Pizza_Boom schreef op dinsdag 31 maart 2015 @ 20:51:
Ik had eigenlijk verwacht dat het codevak een lengtelimiet had en scrollbaar zou worden.

Zou mooi zijn, nu is gewoon de verwachte levensduur van mijn scrollwiel met 1 promille gereduceerd.

Zou jij niet jouw code kunnen opsnorren en e.e.a. eens kunnen vergelijken?

Ik meen me te herinneren dat ik ooit de demo code van itead studio gejat heb:

*snor snor*

Dit. http://store.iteadstudio....39qbg1j0uf3738hl7701n5ch7

De link naar dat rar file doet echter niks meer, er staat me bij dat basically alleen de defines werkte en de rest volledig verbouwd moest worden.

Het verhaal gaat over de IRQ pin toch? Ik lees die nergens uit. Ik heb ze in 5 naar 1 modus gebruikt, en poll elke keer het STATUS register helemaal dood.

*scroll scroll..... scroll*

Het eerste verschil wat ik zie in die lap code is dat je in je TX device wel POWER_UP naar de config schrijft, maar in je RX device niet...

C:

//regel 81 
spi_send(0x09);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up

Je comment suggereert al dat er nog 2 bij moet.
*edit: Een nieuwe pagina!

[Pizza_Boom]

Infant schreef op woensdag 01 april 2015 @ 00:50:
Zou mooi zijn, nu is gewoon de verwachte levensduur van mijn scrollwiel met 1 promille gereduceerd.

Sorry, het spijt me zeer.

Ik meen me te herinneren dat ik ooit de demo code van itead studio gejat heb:

*snor snor*

Dit. http://store.iteadstudio....39qbg1j0uf3738hl7701n5ch7

De link naar dat rar file doet echter niks meer, er staat me bij dat basically alleen de defines werkte en de rest volledig verbouwd moest worden.

Als die interwebz weer gefixed is, ga ik die maar eens bekijken. Thanks.

Het verhaal gaat over de IRQ pin toch? Ik lees die nergens uit. Ik heb ze in 5 naar 1 modus gebruikt, en poll elke keer het STATUS register helemaal dood.

Statusregister zit op 0x27, maar ik vis zo 1, 2, 3 de mogelijkheid om het status register te pollen. Maar eens googlen of in de datasheet opzoeken, FF snel zoeken leert al dat de eerste dataout na een CSN toggle altijd status op MISO is.

Het eerste verschil wat ik zie in die lap code is dat je in je TX device wel POWER_UP naar de config schrijft, maar in je RX device niet...

C:

//regel 81 
spi_send(0x09);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up

Je comment suggereert al dat er nog 2 bij moet.
*edit: Een nieuwe pagina!

In regel 146 komt ie nog een keer, maar dan met 0x0B, 2 hoger dus. Waarom? Had ergens gelezen dat dit bij RX op deze manier moest.

[Ploink]

Infant schreef op woensdag 01 april 2015 @ 00:50:
Het eerste verschil wat ik zie in die lap code is dat je in je TX device wel POWER_UP naar de config schrijft, maar in je RX device niet...

C:

//regel 81 
spi_send(0x09);     // (0000 1010) CRC enabled, interrupts on IRQ enabled, PRX (=transceiver), power up

Je comment suggereert al dat er nog 2 bij moet.
*edit: Een nieuwe pagina!

(0000 1010) = 10 (dec) = 0x0a (hex), dus niet 0x09, 1 er bij dus.
Om dit soort foutjes te voorkomen kun je denk ik beter direct "spi_send(0b00001010)" schrijven.

Pizza_Boom schreef op dinsdag 31 maart 2015 @ 20:51:
[...]
Ik heb ook 0 ervaring met uart en 4/5 maanden terug wist ik niets van communicatie tussen chips, inmiddels draait I2C en nu wil ik draadloos met spi. Echte libs gebruik ik niet echt, enkel 2 headers, waarvan xc8 voor de compilers is. Maar ook met pulldown erbij verandert er niets. Trek ik echter de nrf lijn eruit, dan valt ie wel naar 0 (en zonder pulldown zweeft ie soms richting 1 en weer terug).
[...]

Als ik dat goed begrijp van je omschrijving dan is het dus correct, de mcu pin is input en de nrf pin output. Je hebt dus niet twee outputs die armpje drukken tegen elkaar of twee inputs.

Ik heb ook pcb antenne, maar momenteel staan ze nog geen 10 cm uit elkaar. Ik heb op 3 bytes address geprobeerd, op 5 bytes, geen verschil. Ik las dat je ze op dezelfde payload moet hebben, ze staan samen hetzelfde ingesteld en ik stuur hetzelfde.

Misschien is 10cm zo dichtbij dat ze doof worden van de herrie (preamp is overstuurd). Zet ze verder uit elkaar of reduceer het zendvermogen.

[RobV]

Tip: Om lekker snel µ te typen op OS X, typ je option+M. De M van 'm'. Ik zat elke keer in de 'Special Characters' map te zoeken. 'U'-toets ingedrukt houden werkte ook niet. Nu ik het weet lijkt het zooooo logisch...

Edit: ook handig als je wilt opschrijven dat je capacitor 0.1µF is.

[Voor 13% gewijzigd door RobV op 01-04-2015 11:43]

[lordprimoz]

RobV schreef op woensdag 01 april 2015 @ 11:42:
Tip: Om lekker snel µ te typen op OS X, typ je option+M. De M van 'm'. Ik zat elke keer in de 'Special Characters' map te zoeken. 'U'-toets ingedrukt houden werkte ook niet. Nu ik het weet lijkt het zooooo logisch...

Edit: ook handig als je wilt opschrijven dat je capacitor 0.1µF is.

1uF werkt meestal ook prima =P

[Ploink]

Ik tiep gewoon µ en Ω voor µF en kΩ

[RobV]

Werkt in html of forums heel goed idd maar niet in tekstdocumenten. En dan staat het wel zo mooi om µ te gebruiken

[Sissors]

Ik doe zelf op fora, powerpoint, etc niet de moeite normaal gesproken. In Word 2007 en later kan je math autocorrect aanzetten ook voor buiten formules, en dat heb ik dus altijd ingeschakeld. Dan schrijf je de mu met \mu, en de Ohm met \Omega.

Die met '&' kende ik nog niet, wel handig . Even proberen: Ω

[Ploink]

"option" toets Ik heb nog nooit OSX van dichtbij gezien, als ordinaire Windows gebruiker doe ik in text documenten hetzelfde als lordprimoz:P

Maar ik heb het even opgezocht voor windows:
Ω = alt-234 (alt indrukken en 234 typen op numerieke toetsenbord)
µ = alt-230

[RobV]

Via google, voor O
S X:

16 ∂ Option-D (Delta) )
17 ∆ Option-J (Delta)
18 µ Option-M (Mu)
19 π Option-P (phi)
20 ß Option-S (beta)
21 Ω Option-Z (Omega)
22 ∏ Option-Shift-P (pi)

Nu nogvoor iOS lol. Kunnen we daarna weer lekker back ontopic

[Pizza_Boom]

Ploink schreef op woensdag 01 april 2015 @ 08:43:
(0000 1010) = 10 (dec) = 0x0a (hex), dus niet 0x09, 1 er bij dus.
Om dit soort foutjes te voorkomen kun je denk ik beter direct "spi_send(0b00001010)" schrijven.

Ik verwacht dat dit eerder een slordigheidje met kopiëren ofzo is geweest, want in regel 146 zet ik hem naar 0x0B.

Als ik dat goed begrijp van je omschrijving dan is het dus correct, de mcu pin is input en de nrf pin output. Je hebt dus niet twee outputs die armpje drukken tegen elkaar of twee inputs.

Ik kan me ook niet voorstellen dat ik 2 outputs tegen elkaar op laat drukken, maargoed. Foutje is zo gemaakt.

Misschien is 10cm zo dichtbij dat ze doof worden van de herrie (preamp is overstuurd). Zet ze verder uit elkaar of reduceer het zendvermogen.

Ik heb het zendvermogen op 0dBm of -6dBm staan. Maar inmiddels extra draadjes ertussen gezet en nu staan ze een cm of 25-30 uit elkaar

Ik ga eerst eens kijken of ik die IRQ eruit krijg en gewoon de status kan gaan pollen.

EDIT: Ik krijg als data terug bij het lezen 0x00, behalve bij de 1e read command (0x61). Daar krijg ik niet 0x00, 0xFF en 0x12 (wat ik transmit) terug. Wat wel, ik zou het niet weten.

[Voor 7% gewijzigd door Pizza_Boom op 01-04-2015 16:27]

[Pizza_Boom]

*schop* Momenteel de Logic Analyzer tool (ben opeens toch blij met die PICkit 2 en 3, 1 programmeren, ander de logic tool) eraan hangen:

Transmitter:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Begint met 0xA0 om TX FIFO te schrijven, daarna 4x 0x12. Wat ik terug zou moeten krijgen op MiSo weet ik niet, baart me nu ook geen zorgen.

Dan de receiver:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Stuur eerst de leesopdracht (0x61) en daarna 4x een dummybyte (0x01) om 4 bytes te ontvangen, gevolgd door een RX flush (0xE2), en een status register call (0x27) met opdracht de interrupt te legen (0x40). Echter, zoals te zien is, MiSo blijft een strakke lijn...

[Voor 5% gewijzigd door Pizza_Boom op 14-04-2015 16:29]

[Springuin]

https://www.sparkfun.com/...ct_Specification_v1_0.pdf pagina 49. Je klok hoort laag te zijn in rust en de data dient stabiel te zijn op een opgaande flank, dat is bij jou precies andersom.

[Pizza_Boom]

Hmmm. Ik heb inderdaad in SSPSTAT gezegd dat ik in de falling edge stuur en in de SSPCON1 dat de clock hoog is in rust... Gaan we eens even aanpassen.

[Pizza_Boom]

Nogmaals, geen reactie van de NRF...

Transmitter:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Receiver:

Ch1 = Clk
Ch2 = MoSi
Ch3 = MiSo

Code staat nog steeds hier

[Voor 3% gewijzigd door Pizza_Boom op 14-04-2015 18:01]

[Stoney3K]

Vanwaar die onderbrekingen in je kloksignaal? Op het moment dat je je CS laag gooit hoort je klok gewoon te lopen totdat je CS weer hoog maakt.

Als je dus een transactie wil doen van bijvoorbeeld 32 bits zul je die in één keer achter elkaar moeten doen.

[Pizza_Boom]

Stoney3K schreef op dinsdag 14 april 2015 @ 22:27:
Vanwaar die onderbrekingen in je kloksignaal? Op het moment dat je je CS laag gooit hoort je klok gewoon te lopen totdat je CS weer hoog maakt.

Als je dus een transactie wil doen van bijvoorbeeld 32 bits zul je die in één keer achter elkaar moeten doen.

Ik durf het niet te zeggen. Ik maak gebruik van de hardwarematige MSSP die in de PIC16F1459 zit en het stukje waar daadwerkelijk verzonden wordt is als volgt:

C:

unsigned char spi_send(unsigned char dataS)
    {
        SSP1IF  = 0;        // clear interrupt flag
        SSP1BUF = dataS;    // send dataS(end)
        while (!SSP1IF);        // wait till SSP interrupt flag is set
        dataR   = SSP1BUF;  // read SSPBUF to dataR(ead)
        return dataR;
    }

Dit wordt aangeroepen door een stukje NRF send code waarin 5x deze routine wordt aangeroepen tussen de CSN low's. Het is dus niet dat ik het zelf loop te vertragen ofzo.

C:

unsigned char nrf_send(unsigned char data1, unsigned char data2, unsigned char data3, unsigned char data4)
    {
        CSN = laag;
        spi_send(0xA0);         // command to write TX FIFO
        spi_send(data1);        // send data1 to TX FIFO
        spi_send(data2);        // send data2 to TX FIFO
        spi_send(data3);        // send data3 to TX FIFO
        spi_send(data4);        // send data4 to TX FIFO
        CSN = hoog;
        __delay_us(1);


        CE = hoog;                  // make CE high to initiate data transmitting
        __delay_us(100);            // keep CE high for at least 10 uS to transmit data
        CE = laag;                  // make CE low again to stop transmitting
        __delay_us(1);
        
        return 0;
    }

[Stoney3K]

Dat lijkt er eerder op dat er bij dat 'aanroepen' van die functie dus nog wat meer gebeurt, wat een aantal klokcycli kost en waardoor dus dat gat in je kloksignaal ontstaat. Bijvoorbeeld het omzetten van een stack pointer.

Het lezen van dat SPI register en het verplaatsen van die data naar een variabele kost bijvoorbeeld ook tijd. Je doet niets met die data, dus die kun je prima ignoren, dan hoef je ook niet op de interrupt te wachten.

Als je het wil fixen kun je het beste die spi_send ombouwen zodat je er een blok bytes (een char * dus) in kan stoppen samen met een lengte, en de hele rataplan in een for() loopje gooien. Dan weet je zeker dat er niets tussenin gebeurt.

[Pizza_Boom]

Maar het zou toch eigenlijk niet mogen uitmaken dat er een hikje in de klok zit, dat ding telt niet zelf en zo lang CSN low is, moet het toch gewoon werken? Of geldt dat weer alleen voor i2c?

De data wil ik trouwens wel gebruiken bij de uitgave van data in geval van de receiverzijde.

Heb je een voorbeeldje van hoe je dat forloopje en char gebeuren bedoelt? In het schrijven van die dingen ben ik nooit heel goed geweest.

[Stoney3K]

Sim-pel: Je doet gewoon dit in plaats van een opvolgend aantal spi_send()'s te doen.

code:

void spi_send(unsigned char * data_tx, int length)
{
    int i;
    for(i=0; i < length; i++) 
    {
            SSP1IF  = 0;        // clear interrupt flag
            SSP1BUF = data_tx[i];    // send data
            while (!SSP1IF);        // wait till SSP interrupt flag is set and register is ready to accept new data
    }
}

In dit blok gebruik je de return-waarde van spi_send() toch niet, dus ik zou eens proberen of ie zo wel de juiste gegevens wegstuurt.

Vooral de instructie 'return' (ofwel: kopieer teruggegeven waarde naar callee en spring terug vanaf de stack) kost nogal wat tijd.

Als je dan ook nog data in wil lezen, zul je ook een array mee moeten sturen waar die data in terug moet. Daar help ik je wel mee.

[Voor 4% gewijzigd door Stoney3K op 14-04-2015 22:57. Reden: indent]

[Pizza_Boom]

Hmm, dat accepteert ie niet. Deze code invoeren levert een berg errors op. Een aantal kan ik verklaren, dat komt omdat alles in de code nog gewoon met enkele SPI sends staat (to few function arguments), maar de illigal conversions of pointers to integers kan ik niet verklaren. DataS had ik al data_tx van gemaakt.

Dit was van voor je edit.
EDIT2: Ik krijg nog steeds 21 errors met to few function arguments en evenzoveel warnings met illegal conversions of integer to pointer...

[Voor 21% gewijzigd door Pizza_Boom op 14-04-2015 23:19]

[DuDePrOdUcTiOnS]

Die 'too few arguments' is omdat je waarschijnlijk niet de lengte meestuurt bij het aanroepen van de functie (length variabele). De 'illegal conversions' is omdat de data_tx variabele een pointer is (staat een *sterretje voor) en je zelf bij het aanroepen van de functie waarschijnlijk gewoon een char of int meestuurt.

[Pizza_Boom]

Momenteel stuur ik volgens mij niets mee. Ik roep gewoon spi_send aan, dat staat in een grote config void. Als ik inderdaad een spi_send(0x00) verander naar spi_send(0x00, 1) dan verdwijnt de error. Echter, (0x00, 0x01, 2) accepteert ie weer niet, terwijl ik juist begrijp uit de reacties dat met deze forloop meerdere waardes achter elkaar doorgestuurd moeten kunnen worden. Doe ik 0x00[1], 0x01[2] dan krijg ik de error dat er een pointer required is.

[RobV]

De functie verwacht een pointer naar je data en de lengte van die data. Ipv de pointer geef je nu de data mee als argument, niet het adres.

[Pizza_Boom]

Hmmm, okee. En hoe maak ik die pointer naar mijn data dan?

[DuDePrOdUcTiOnS]

*data_tx moet je zien als een array van unsigned chars. Deze kun je vullen met data en met data_tx[i] kun je door de data heen stappen.

[Pizza_Boom]

Heb je daar een codevoorbeeldje van, hoe je dat precies bedoelt? Ik heb bij de I2C slave code wel gewerkt met een soort 1D array, maar ik heb geen idee hoe ik wat hier staat, moet gaan implementeren.

[Radiant]

Stoney3K schreef op dinsdag 14 april 2015 @ 22:27:
Vanwaar die onderbrekingen in je kloksignaal? Op het moment dat je je CS laag gooit hoort je klok gewoon te lopen totdat je CS weer hoog maakt.

Als je dus een transactie wil doen van bijvoorbeeld 32 bits zul je die in één keer achter elkaar moeten doen.

Maakt niet uit. Het hele idee van die klok is juist dat je als master kan bepalen wanneer je bits verstuurt.
Sneller is altijd leuker maar die vertraging zal niet het probleem zijn.

Als je code gaat schrijven met interrupts in je master zal je helemaal zien dat je klok nooit helemaal mooi is.

[Stoney3K]

Pizza_Boom schreef op woensdag 15 april 2015 @ 16:00:
Heb je daar een codevoorbeeldje van, hoe je dat precies bedoelt? Ik heb bij de I2C slave code wel gewerkt met een soort 1D array, maar ik heb geen idee hoe ik wat hier staat, moet gaan implementeren.

Dan kun je het beste beginnen met te leren hoe arrays en pointers precies werken in C.

Die data_tx is een 'char *', dat betekent dat het geen byte (char) aan data is, maar het geheugenadres van die byte(s) aan data. En als je meer bytes wil sturen, dan zijn de geheugenadressen daarvan opeenvolgend.

Staat er bijvoorbeeld ergens een byte met gegevens '0xAA' op adres 252, dan werkt dat dus zo:

Waarde op adres 252 = data_tx[0] = 0xAA

De eerstvolgende waarde in zo'n 1-dimensionale array, data_tx[1], staat dan op adres 253, enzovoorts.

Dat maakt C heel krachtig maar (soms) ook heel smerig, omdat je met dat soort trucs gewoon buiten de grenzen van een array kan lezen schrijven waar zinnige data in zit. Dat is precies wat er bij de bekende Heartbleed-bug aan de hand was.

Wil je dus het stukje aan bytes sturen wat je in je originele programma gebruikt, dan kun je dat zo doen:

code:

char data[5];  /* Geeft aan dat er 5 bytes in deze array passen */

data[0] = 0xA0;
data[1] = data1;
data[2] = data2;
data[3] = data3;
data[4] = data4;

spi_send(data, 5);

Om 5 bytes aan data in één keer te versturen.

Radiant schreef op woensdag 15 april 2015 @ 16:27:
[...]


Maakt niet uit. Het hele idee van die klok is juist dat je als master kan bepalen wanneer je bits verstuurt.
Sneller is altijd leuker maar die vertraging zal niet het probleem zijn.

Als je code gaat schrijven met interrupts in je master zal je helemaal zien dat je klok nooit helemaal mooi is.

Het kan heel goed zijn dat sommige slave-devices kieskeurig zijn over het wel of niet hebben van een nette klok. Ik heb hier bijvoorbeeld een paar DAC's van Microchip en die houden het op een gegeven moment voor gezien als je klok te veel afwijkt tussen de bitjes.

[RobV]

Pizza_Boom schreef op woensdag 15 april 2015 @ 15:41:
Hmmm, okee. En hoe maak ik die pointer naar mijn data dan?

Ik zal het even voor je googlen. Understanding pointers

Vooruit, ik heb een goede bui:

C:

//the
unsigned char *data_to_transmit = { 0xAA, 0xBB, 0xCC, 0xDD };
//je kunt het ook zo opschrijven (verschil is voor puristen)
unsigned char data_to_transmit[] = { 0xAA, 0xBB, 0xCC, 0xDD };

//functie aanroepen met array en de lengte
spi_send(data_to_transmit, 4);

//heb je geen buffer en hoef je echt maar 1 byte versturen:
unsigned char byte_to_transmit = 0xAA;
spi_send(&byte_to_transmit, 1);
//ofwel zonder tijdelijke variabele.
spi_send(&0xAA, 1);

//aangenomen dat je de functie gebruikt die er zó uit ziet:

C:

void spi_send(unsigned char * data_tx, int length)
{
   ...
}

[Stoney3K]

RobV schreef op woensdag 15 april 2015 @ 16:35:
[...]


Ik zal het even voor je googlen. Understanding pointers

Doe het dan ook gelijk op de kortst mogelijke manier

C:

spi_send( {0xAA, data1, data2, data3, data4}, 5);

[Pizza_Boom]

Stoney3K schreef op woensdag 15 april 2015 @ 16:37:
[...]


Doe het dan ook gelijk op de kortst mogelijke manier

C:

spi_send( {0xAA, data1, data2, data3, data4}, 5);

Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.

Stoney3K schreef op woensdag 15 april 2015 @ 16:34:
[...]


Dan kun je het beste beginnen met te leren hoe arrays en pointers precies werken in C.

Die data_tx is een 'char *', dat betekent dat het geen byte (char) aan data is, maar het geheugenadres van die byte(s) aan data. En als je meer bytes wil sturen, dan zijn de geheugenadressen daarvan opeenvolgend.

Staat er bijvoorbeeld ergens een byte met gegevens '0xAA' op adres 252, dan werkt dat dus zo:

Waarde op adres 252 = data_tx\[0] = 0xAA

De eerstvolgende waarde in zo'n 1-dimensionale array, data_tx\[1], staat dan op adres 253, enzovoorts.

Dat maakt C heel krachtig maar (soms) ook heel smerig, omdat je met dat soort trucs gewoon buiten de grenzen van een array kan lezen schrijven waar zinnige data in zit. Dat is precies wat er bij de bekende Heartbleed-bug aan de hand was.

Op zo'n soort manier, maar dan precies tegengesteld, heb ik het ook al eens gebruikt bij het binnenhalen van informatie in een slave op een I2C bus. Zodat dus iedere binnenkomende byte op een apart adresje werd weggeschreven.

Wil je dus het stukje aan bytes sturen wat je in je originele programma gebruikt, dan kun je dat zo doen:

code:

char data[5];  /* Geeft aan dat er 5 bytes in deze array passen */

data[0] = 0xA0;
data[1] = data1;
data[2] = data2;
data[3] = data3;
data[4] = data4;

spi_send(data, 5);

Om 5 bytes aan data in één keer te versturen.

Die gaan we nog eens proberen. Maar bij de configs moet ik dat dus bij iedere configuratie die ik doorstuur doen, lijkt mij?

Het kan heel goed zijn dat sommige slave-devices kieskeurig zijn over het wel of niet hebben van een nette klok. Ik heb hier bijvoorbeeld een paar DAC's van Microchip en die houden het op een gegeven moment voor gezien als je klok te veel afwijkt tussen de bitjes.

Zou dat met NRF24L01's ook zo zijn?

[Voor 8% gewijzigd door Pizza_Boom op 15-04-2015 17:39]

[RobV]

Pizza_Boom schreef op woensdag 15 april 2015 @ 17:37:
[...]
Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.

Als je er '//' voor zet, zijn ook de warning weg ... Zodra je begrijpt hoe het werkt, mag je van mij de bocht afsnijden. Tot die tijd gewoon eventjes een buffertje gebruiken kijkt me handiger nu. En zoals gezegd: lees even een basic C tutorial over arrays en pointers. Het is al zo vaak uitgelegd...

[Stoney3K]

RobV schreef op woensdag 15 april 2015 @ 18:10:
[...]

Als je er '//' voor zet, zijn ook de warning weg ... Zodra je begrijpt hoe het werkt, mag je van mij de bocht afsnijden. Tot die tijd gewoon eventjes een buffertje gebruiken kijkt me handiger nu. En zoals gezegd: lees even een basic C tutorial over arrays en pointers. Het is al zo vaak uitgelegd...

"0xAA, data1, data2, data3, data4" is trouwens iets heel anders dan de array die bestaat uit 0xAA (hexadecimaal) en de inhoud van data 1 t/m 4.

Wat je er dan wel in stopt laat ik aan jou als huiswerk.

[RobV]

Stoney3K schreef op woensdag 15 april 2015 @ 18:43:
[...]


"0xAA, data1, data2, data3, data4" is trouwens iets heel anders dan de array die bestaat uit 0xAA (hexadecimaal) en de inhoud van data 1 t/m 4.

Wat je er dan wel in stopt laat ik aan jou als huiswerk.

Ik ben even de weg kwijt waarom je je eigen code quote als reactie op mijn bericht.. Laten we het niet ingewikkelder maken dan dat het is en verder gaan. We wachten af waar Pizza_Boom mee terugkomt als hij zich even ingelezen heeft in de materie.

[Voor 4% gewijzigd door RobV op 15-04-2015 18:53]

[Stoney3K]

RobV schreef op woensdag 15 april 2015 @ 18:51:
[...]

Ik ben even de weg kwijt waarom je je eigen code quote als reactie op mijn bericht.. Laten we het niet ingewikkelder maken dan dat het is en verder gaan. We wachten af waar Pizza_Boom mee terugkomt als hij zich even ingelezen heeft in de materie.

Pizza_Boom schreef op woensdag 15 april 2015 @ 17:37:
[...]
Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.

Opdracht aan Pizza_Boom dan: Leg eens uit waarom

code:

char * data_send = { 0xAA, 0xBB, 0xCC, 0xDD, 0xEE }

iets anders is dan

code:

char * data_send = "0xAA, 0xBB, 0xCC, 0xDD, 0xEE"

Hint: één van de twee is 5 bytes lang, de ander niet.

[RobV]

mooi klusje huiswerk inderdaad.

edit: je vergeet in beide gevallen een ;

[Voor 37% gewijzigd door RobV op 15-04-2015 21:39]

[Ploink]

Ik denk dat die syntax highlighting op zich al een duidelijke hint is, of verklap ik nou teveel?

[Stoney3K]

Ploink schreef op woensdag 15 april 2015 @ 20:54:
Ik denk dat die syntax highlighting op zich al een duidelijke hint is, of verklap ik nou teveel?

sst, straks heeft ie het nog te snel door...

[RobV]

Pizza_Boom schreef op woensdag 15 april 2015 @ 17:37:
[...]
Als ik het op deze manier doe, dan krijg ik errors. Maak ik van de accolades aanhalingstekens(" "), dan blijven er alleen warnings over voor dat deel.
[...]

ik vroeg me af, of je inmiddels het verschil weet tussen char, char *, char [], en het verschil tussen 'x' en "x".

[Pizza_Boom]

Eigenlijk helemaal niet meer mee bezig geweest.

[Anthor]

Ik ben atm weer bezig met wat programmeren in AtmelStudio 6 (sp2),
en ik zit me weer onwijs te ergeren aan de vertraging/lag die ik soms in de editor heb.

Hebben jullie dat ook, of is er gewoon iets mis met mijn pc?
(proc uit 2009 en 12 GB ram moet genoeg zijn toch )

[mad_max234]

Anthor schreef op dinsdag 05 mei 2015 @ 16:41:
Ik ben atm weer bezig met wat programmeren in AtmelStudio 6 (sp2),
en ik zit me weer onwijs te ergeren aan de vertraging/lag die ik soms in de editor heb.

Hebben jullie dat ook, of is er gewoon iets mis met mijn pc?
(proc uit 2009 en 12 GB ram moet genoeg zijn toch )

Ja dat heb/had ik ook, vanaf Studio 5 is dat ontstaan toen ze er MS studio bij hebben gehaald, zeer traag met opstarten, had 4GB en ahtlon M320 (2.1GHz athlon II zeg maar). Heb vorige maand nieuwe pc gekocht met broadwell i5-5200 en is stukje minder geworden. Maar zag verder nooit dat cpu, HDD of ram zwaar werd belast in de opstarttijd. Studio 4 was reten snel, de starten snel op, sneller reactie van alle onderdelen.

[joelluijmes]

Je kunt op de avr (althans de ATmega328P) een truukje gebruiken waardoor je snel een output pin kunt toggelen (zelfde als output xor). Weet iemand nog meer van dit soort kleine dingetjes voor de avr?

Voor wie er niet mee bekent is:

Writing a logic one to PINxn toggles the value of PORTxn, independent on the value of DDRxn. Note that the
SBI instruction can be used to toggle one single bit in a port.

code:

PINB = 0x20;    //ldi r24, 0x20
                //out 0x03, r24

//--------------------------------

PORTB ^= 0x20;  //in r24, 0x05
                //ld r25, 0x20
                //eor r24, 25
                //out 0x05, r24

[Ploink]

joelluijmes schreef op zondag 31 mei 2015 @ 00:20:
Weet iemand nog meer van dit soort kleine dingetjes voor de avr?

Dat is idd een handig truukje.
Voor wat betreft programmeren kwam ik dit tegen:

Creating ELF Files with other memory types
Hiermee kan je oa fuses en eeprom data in je sourcecode zetten.

6.53 Built-in Functions to Perform Arithmetic with Overflow Checking
Eindelijk een methode om snel een integer overflow te detecteren! Helaas zit dit pas in GCC 5 en die zit nog niet in atmel studio. Nog even wachten dus tot dit beschikbaar komt.

[DaWaN]

Even dit oude topic eens een schop geven.

Ik was vandaag bezig met een Cambridge Consultants XAP5 en daar zag ik enigzins onverwacht gedrag met shifts. Ik vraag mij af of dit klopt of dat het een compiler quirk was.

Ik had de volgende code waarin ik twee Uint8's bitwise in een Int32 wilde zetten:

code:

Int32 OutputLong = 0;
Uint8 InputChar1 = 0xAA;
Uint8 InputChar2 = 0xBB;
OutputLong |= ((InputChar1<<8)|(inputChar2));

Nu gaf deze code als output OutputLong 0xFFFFAABB terwijl ik 0x0000AABB had verwacht.

code:

Int32 OutputLong = 0;
Uint8 InputChar1 = 0xAA;
Uint8 InputChar2 = 0xBB;
OutputLong |= ((InputChar1<<8)|(inputChar2)) & 0x0000FFFF;

Deze code gaf wel wat ik verwacht had (namelijk 0x0000AABB), maar het ontgaat mij even waarom ik die extra bitwise AND operatie moest toevoegen. Iemand een idee?

[RobV]

Ik ben benieuwd wat eruit zou komen als je van de Int32 een UInt32 maakt?

[Hans1990]

Als ik jouw code in GCC 4.8.4 (x86 ubuntu 14.04) stop met stdint.h types krijg ik 0x0000AABB.
Architectuur afhankelijk? Compiler bug? XAP5 platform zegt me weinig, wikipedia zegt dat aangepaste GCC veel gebruikt wordt.

Die F's daar niet horen te staan. Let wel (InputChar1 << 8 ) een warning hoort te generen omdat je in principe alle 8-bits van de byte eerst afschuift, en daarna opslaat in 32-bit int. De compiler promoot stiekem dus InputChar1 al naar 32-bit. Maar ik weet niet of dat het probleem is.
Misschien idd unsigned/signed probleem, maar dat blijft vreemd voor een OR operatie.

edit:
OT: Mag wel eens wat doen aan zinopbouw als ik moe ben

[Voor 9% gewijzigd door Hans1990 op 31-05-2016 20:50]

[RobV]

Hans1990 schreef op dinsdag 31 mei 2016 @ 20:33:


Die F's daar niet horen te staan. Let wel (InputChar1 << 8 ) een warning hoort te generen omdat je in principe alle 8-bits van de byte eerst afschuift, en daarna opslaat in 32-bit int. De compiler promoot stiekem dus InputChar1 al naar 32-bit.

Ja, daar ben ik het mee eens.

[mux]

Vrijwel gegarandeerd wordt op de achtergrond die InputChar1 ergens in geheugen voorbereid (kun je dit in je disassembly/map file zien?). Wellicht een compilerbug dat die niet wordt geïnitialiseerd op 0, want flash is doorgaans inderdaad ongeprogrammeerd 0xFF.

(edit: de enige keer dat ik een vergelijkbaar probleem ben tegengekomen was met een brakke UC3-lib voor EEPROM)

[Voor 18% gewijzigd door mux op 31-05-2016 21:03]

[Sissors]

Het zit natuurlijk wel in SRAM. Granted wordt vanuit flash gekopieerd, maar dan nog steeds lijkt me dat onwaarschijnlijk. Mijn gok is dat er een foutieve unsigned -> signed conversie plaatsvindt van de uint8's, wat vervolgens naar 32-bit wordt geconverteerd.

[jeroen3]

Ik denk dat het gehele voorbeeld in de registers past.
Wat zegt de disassembler?

[DaWaN]

Hans1990 schreef op dinsdag 31 mei 2016 @ 20:33:
Als ik jouw code in GCC 4.8.4 (x86 ubuntu 14.04) stop met stdint.h types krijg ik 0x0000AABB.
Architectuur afhankelijk? Compiler bug? XAP5 platform zegt me weinig, wikipedia zegt dat aangepaste GCC veel gebruikt wordt.

Die F's daar niet horen te staan. Let wel (InputChar1 << 8 ) een warning hoort te generen omdat je in principe alle 8-bits van de byte eerst afschuift, en daarna opslaat in 32-bit int. De compiler promoot stiekem dus InputChar1 al naar 32-bit. Maar ik weet niet of dat het probleem is.
Misschien idd unsigned/signed probleem, maar dat blijft vreemd voor een OR operatie.

edit:
OT: Mag wel eens wat doen aan zinopbouw als ik moe ben

Ja mijn vermoeden is dat het ook iets met signed/unsigned te maken heeft. Ik heb ook even de code gereduceerd tot waar de 'fout' zat. Code zit in een device driver die 24 bits signed getallen uitspuugt. Om het mijzelf wat makkelijker te maken stop ik die maar in Int32's zodat ik de compiler alle berekeningen kan laten afhandelen. Grappig genoeg lost het casten van de UInt8's naar Int32's niets op en vreemd genoeg ook geen warning over de shift m.b.t. het promoten van het type.

Ik ben de laatste tijd niet zo extreem bedreven in het schrijven van C en de omgeving waarin ik werk helpt ook niet echt. Is een enorme batterij aan Python scripts waar uiteindelijk een binary uit komt rollen. Heb nu even geen zin om uit te zoeken hoe ik die build kan exporteren naar de IDE om wat beter te kunnen debuggen. Ik zal na de SW release wel even kijken of ik ook leesbare assembly eruit kan krijgen om te begrijpen wat de compiler nu precies doet, ik kom er op terug! Ben i.i.g. blij dat het geen obvious fout was en dat het uurtje dat het mij kostte om het te vinden dus niet heel dom was

Chip is overigens een GreenPeak GP691, met een vrij exotische XAP5 MCU. Is dezelfde MCU core die je in chips van CSR vind en hij heeft inderdaad een GCC gebaseerde compiler.

[Hans1990]

Als het GCC is kan je objdump op de elf of out toepassen samen met flags -D en -S. Dat disassembled alle sections en zal (indien het de source kan vinden) source code er tussen plaatsen.
Je zou dan eens kunnen redeneren wat de assembler code doet. Echter een debugger kan hier ook bij helpen, met name als je IDE kan single steppen op assembler (ipv C) niveau.

[Anthor]

Ik ben een speelgoed zwaardje aan het repareren voor het zoontje van vrienden. Er zaten wat ledjes in maar die kon ik niet redden. Nu heb ik er wat eigen electronica met een paar rgb-ledjes in gestopt en daarvoor heb ik heb een soort pseudo random getal nodig.

Op de uC (attiny44) draait snel gehackte software die ik origineel voor een ander project heb geschreven, en die nu nog maar gedeeltelijk werkt .

De uC krijgt pas stroom als er op een knopje gedrukt wordt, dan moet er één van de lichteffecten gespeeld worden die ik kan voorprogrammeren, maar dan heb ik een soort random nummer nodig (3 á 4 bits zal wel genoeg zijn), of iig iets wat wisselt als de spanning er even af is geweest. In het zwaardje zit ook nog een audio chip die iets speelt als het knopje wordt ingedrukt.
Er zit een condensatortje bij de uC, maar de batterij spanning is weg zodra de knop losgelaten wordt

De uC hangt met alle IO pinnen (ook reset als ik die uiteindelijk disable ipv gebruik voor dW ) aan ULN 2803 ingangen, dus alle ingangen worden omlaag getrokken. Dus ik kan daar niet zomaar iets uitlezen. of een adc doen

Ik kan misschien iets in de eeprom zetten, uitlezen en gewijzigd terugschrijven als de uC spanning krijgt, maar dan kan de spanning ook wegvallen tijdens een write. Wat gebeurt er met het eeprom geheugen wat dan beschreven wordt? Is de data dan gewoon weg of kan het geheugen op een of andere manier beschadigen zodat daarna altijd dezelfde byte terug komt?
Of is er een andere makkelijke manier om een random waarde ergens uit te halen?

[RobV]

Lees een niet verbonden analoge pin uit, en pak alleen de onderste 6 bits of zo, dat is redelijk random. Wellicht kun je die als seed gebruiken. Maar ik denk dat je met je attiny geef vrije pinnen meer hebt?

[Voor 23% gewijzigd door RobV op 03-06-2016 19:28]

[Anthor]

Nee, alles is bezet. Ik moet om alle leds aan te kunnen sturen ook de reset pin en dus de mogelijkheid om dat ding later makkelijk te programmeren opofferen. Het is een smd ic op een gebeund stukje stripboard waar al te veel aan gesoldeerd is.

[RobV]

Met juist gebruik van diodes kun je een output pin ook als input pin gebruiken tijdens het opstarten. Ik denk ook maar hardop ik weet het antwoord zo niet uit het hoofd

[Anthor]

Hier is een foto van het bordje (geen schoonheidsprijs):


Helaas zitten alle analoge ingangen tussen de twee linker ic's op hetzelfde pad, zo'n draadje tussen de twee delen had ik wat makkelijker kunnen vervangen.

nee, dat rode draadje hoort niet los te zitten en die grijze linksboven ook niet

[mux]

Het antwoord is: gebruik de ADC, maar dan met een interne input ipv een externe pin

Op de tinyx4(A) zit een interne temperatuursensor, die je aan de ADC kunt gooien. pagina 144.

Alternatief kun je intgnd, 1V reference of een 20x gain op een externe input die altijd laag is gebruiken.

[Hans1990]

Anthor schreef op vrijdag 03 juni 2016 @ 19:24:
Ik kan misschien iets in de eeprom zetten, uitlezen en gewijzigd terugschrijven als de uC spanning krijgt, maar dan kan de spanning ook wegvallen tijdens een write. Wat gebeurt er met het eeprom geheugen wat dan beschreven wordt? Is de data dan gewoon weg of kan het geheugen op een of andere manier beschadigen zodat daarna altijd dezelfde byte terug komt?
Of is er een andere makkelijke manier om een random waarde ergens uit te halen?

Zelfs als de knop kort wordt ingedrukt zal dat toch wel een tiende van een seconde zijn?

Je zou dan je random number kunnen berekenen met EEPROM als seed, en vervolgens de nieuwe seed naar EEPROM wegschrijven.
Volgens de datasheet kost "erase and write" (atomic operation) circa 3.4ms. Dat zou kort genoeg moeten zijn lijkt me.
Zo niet verwacht ik dat het EEPROM ge-erased is en je dus met een nieuwe reeks begint. Wil je dat afvangen is lastig, zou je dan met brown-out detect moeten gebruiken (heeft die ATTINY al wel zie ik) en voldoende capaciteit op uC voeding om exact 1 write te kunnen voltooien. Maar ik zou eerlijk gezegd niet weten waarom je dat zou willen voor een stukje speelgoed
Je hebt dan enkel een psuedo-random number generator nodig, een paar bits (of als we toch bezig zijn 8-bit) brede linear feedback shift register ofzo.

[Voor 21% gewijzigd door Hans1990 op 03-06-2016 21:01]

[Digital-DNA]

Ik weet niet of ik hier aan het juiste adres ben, maar ik wil graag eens gaan experimenteren met het aansturen van een RN4020 Bluetooth chip. Hiervoor is een ontwikkelbordje beschikbaar die ik overweeg te kopen (met PIC18F25K50 microcontroller):
http://www.microchip.com/...px?PartNO=RN-4020-PICTAIL

Nu ben ik bekend met zo'n 6 programmeertalen en flans ik dagelijks fancy apps in elkaar. Met deze tak van sport ben ik echter iets minder bekend. Misschien dat ik hier wat help kan krijgen om op gang te komen.

Mijn eerste vraag is eigenlijk heel simpel: is het bordje uit bovenstaande link genoeg om mee te ontwikkelen, of is er nog een ander bordje nodig waar deze weer in past? Uit de documentatie en de voorbeelden wordt mij dit niet helemaal duidelijk namelijk.

[DuDePrOdUcTiOnS]

Voor het random nummer genereren kun je ook de tijdsduur van het indrukken van de knop gebruiken. Gewoon ticks tellen tot de knop losgelaten wordt.

[Springuin]

Digital-dna: ik zie op de foto die pic18f niet zitten, het lijkt puur een breakout board voor die module.

Als je iets eenvoudigs wilt voor bluetooth low energy kan ik je de modules/chips van cypress aanraden: fijne ontwikkelomgeving, goede voorbeelden en goede support. Daarnaast hebben die een cortex-m0 core en, mits je ze goed programmeert, laag energieverbruik.

[Damic]

Digital-DNA schreef op vrijdag 03 juni 2016 @ 23:35:
Ik weet niet of ik hier aan het juiste adres ben, maar ik wil graag eens gaan experimenteren met het aansturen van een RN4020 Bluetooth chip. Hiervoor is een ontwikkelbordje beschikbaar die ik overweeg te kopen (met PIC18F25K50 microcontroller):
http://www.microchip.com/...px?PartNO=RN-4020-PICTAIL

Nu ben ik bekend met zo'n 6 programmeertalen en flans ik dagelijks fancy apps in elkaar. Met deze tak van sport ben ik echter iets minder bekend. Misschien dat ik hier wat help kan krijgen om op gang te komen.

Mijn eerste vraag is eigenlijk heel simpel: is het bordje uit bovenstaande link genoeg om mee te ontwikkelen, of is er nog een ander bordje nodig waar deze weer in past? Uit de documentatie en de voorbeelden wordt mij dit niet helemaal duidelijk namelijk.

Zoals Springuin al zei, het is een breakout bord ook in de RN4020 PICtail Plus Daughter Board Quick Start Guide staat dat:

The RN4020 PICtail Plus Daughter Board has PICtail Plus and PICtail connectors to interface with a PIC® microcontroller (MCU) on the development boards that
support PICtail Plus or PICtail interface with the required pin mapping.

[Digital-DNA]

Dat ding heeft twee opties geloof ik. Ik lees ook dat er een usb-kabel meegeleverd wordt en je 'm direct aan je pc kan hangen en 'ie als com-poort wordt herkend als je de USB-to-UART bridge mode gebruikt. Begrijp ik hieruit dat je 'm dan wel los kan gebruiken of hoe moet ik dit zien?

[Springuin]

Je hebt gelijk, er zit meer op dan ik dacht te zien, dat zal wel aan de achterkant zitten. Ik denk dat die pic18f in principe als usb uart bridge geprogrammeerd is zodat je direct met de module kunt praten. Dat betekent dat je genoeg hebt om van start te kunnen.

[187449]

mogguh,

iemand al is een NINA-B1 is zijn handen gehad ?

Ik zoek eigenlijk iets met een paar gpio, i2c, ble functionaliteit en min 2 uarts, rekenpower/mem is niet echt super belangrijk.
ik dacht aan een featherbordje omdat ik dan gelijk aan de slag kan.

Maar ik zie hier allerlei andere chips voorbij komen, die ontwikkelomgevingen die er dan bijbehoren, zijn die dan ook gratis, zoals arduino IDE zeg maar ?

[Voor 9% gewijzigd door 187449 op 04-06-2016 11:02]

[Radiant]

Al eens naar de Nordic nRF-serie gekeken? Zijn leuke bordjes voor beschikbaar, is een rappe Cortex M0-processor die een softstack draait voor de BLE. Verder allerlei peripherals beschikbaar.

Goeie ervaringen mee

[187449]

ah ok tnx, ja toevallig was ik de 51822 tegengekomen

[1337aldi]

Digital-DNA schreef op zaterdag 04 juni 2016 @ 09:05:
Dat ding heeft twee opties geloof ik. Ik lees ook dat er een usb-kabel meegeleverd wordt en je 'm direct aan je pc kan hangen en 'ie als com-poort wordt herkend als je de USB-to-UART bridge mode gebruikt. Begrijp ik hieruit dat je 'm dan wel los kan gebruiken of hoe moet ik dit zien?

Je kan direct met de module praten met de standaard firmware. Als je echter die PIC18 wilt herprogrammeren/debuggen heb je een PICKIT3 of ICD3 nodig. Van de pickit3 zijn ook chinese kloons beschikbaar die het prima doen.

[187449]

1337aldi schreef op zaterdag 04 juni 2016 @ 13:50:
[...]

Van de pickit3 zijn ook chinese kloons beschikbaar die het prima doen.

klopt, ik heb zelf deze chinees

[itcouldbeanyone]

Digital-DNA schreef op vrijdag 03 juni 2016 @ 23:35:
Ik weet niet of ik hier aan het juiste adres ben, maar ik wil graag eens gaan experimenteren met het aansturen van een RN4020 Bluetooth chip. Hiervoor is een ontwikkelbordje beschikbaar die ik overweeg te kopen (met PIC18F25K50 microcontroller):
http://www.microchip.com/...px?PartNO=RN-4020-PICTAIL

Nu ben ik bekend met zo'n 6 programmeertalen en flans ik dagelijks fancy apps in elkaar. Met deze tak van sport ben ik echter iets minder bekend. Misschien dat ik hier wat help kan krijgen om op gang te komen.

Mijn eerste vraag is eigenlijk heel simpel: is het bordje uit bovenstaande link genoeg om mee te ontwikkelen, of is er nog een ander bordje nodig waar deze weer in past? Uit de documentatie en de voorbeelden wordt mij dit niet helemaal duidelijk namelijk.

Ben er nu ook mee bezig. Heb de rn4020 als smd moddule in gebruik in MLDP modus.
Heb zeer goede commenucatie doormiddel van mldp browser app. Ben nu nog bezig om dit in mijn eigen app te implementeren

[Sissors]

Radiant schreef op zaterdag 04 juni 2016 @ 11:05:
Al eens naar de Nordic nRF-serie gekeken? Zijn leuke bordjes voor beschikbaar, is een rappe Cortex M0-processor die een softstack draait voor de BLE. Verder allerlei peripherals beschikbaar.

Goeie ervaringen mee

De NRF51822 is een goede optie zoals hij het beschrijft wat hij nodig heeft, maar hem rap noemen gaat me wel een beetje ver . Hij is veruit de traagste ARM MCU die ik ken met zijn M0 op 16MHz, eerstvolgende is 30MHz (die ik dus ken uit mijn hoofd).

Er is ook geloof ik een M4 versie van beschikbaar, al is die iig een stuk minder beschikbaar op allerlei dev bordjes.

Edit: Oh al weer wat dagen geleden, ach ja.

[Voor 3% gewijzigd door Sissors op 09-06-2016 22:17]

[DuDePrOdUcTiOnS]

Sissors schreef op donderdag 09 juni 2016 @ 22:17:
[...]

De NRF51822 is een goede optie zoals hij het beschrijft wat hij nodig heeft, maar hem rap noemen gaat me wel een beetje ver . Hij is veruit de traagste ARM MCU die ik ken met zijn M0 op 16MHz, eerstvolgende is 30MHz (die ik dus ken uit mijn hoofd).

Er is ook geloof ik een M4 versie van beschikbaar, al is die iig een stuk minder beschikbaar op allerlei dev bordjes.

Edit: Oh al weer wat dagen geleden, ach ja.

De nRF52832 heeft een M4 core op 64MHz.

[Digital-DNA]

itcouldbeanyone schreef op donderdag 09 juni 2016 @ 19:32:
[...]


Ben er nu ook mee bezig. Heb de rn4020 als smd moddule in gebruik in MLDP modus.
Heb zeer goede commenucatie doormiddel van mldp browser app. Ben nu nog bezig om dit in mijn eigen app te implementeren

Ik wil eigenlijk een custom GATT profiel gaan draaien en mijn app daar gebruik van laten maken. Eigenlijk een soort aangepaste hartslagmeter maar dan net anders. MLDP is voor mijn toepassing niet geschikt denk ik.

Ik zie dat je via een soort command line commando's kan sturen. Ik vraag me meer af hoe je echt een programmaatje kunt maken die je bijvoorbeeld direct laat zien als een apparaat verbinding maakt bijvoorbeeld, en via waar je het sturen van notificaties kunt regelen enzo. Ik lees iets over MLAP Code Configurator, is dat een tool die je hiervoor kunt gebruiken?

Ik heb nog niet echt ervaring met dit soort dingen.

[187449]

DuDePrOdUcTiOnS schreef op vrijdag 10 juni 2016 @ 09:25:
[...]

De nRF52832 heeft een M4 core op 64MHz.

kwam vandaag een nieuwe Arduino (primo) tegen waar die chip op zit
- http://www.pcworld.com/ar...ngs-with-primo-board.html

[itcouldbeanyone]

Digital-DNA schreef op zondag 12 juni 2016 @ 22:54:
[...]


Ik wil eigenlijk een custom GATT profiel gaan draaien en mijn app daar gebruik van laten maken. Eigenlijk een soort aangepaste hartslagmeter maar dan net anders. MLDP is voor mijn toepassing niet geschikt denk ik.

Ik zie dat je via een soort command line commando's kan sturen. Ik vraag me meer af hoe je echt een programmaatje kunt maken die je bijvoorbeeld direct laat zien als een apparaat verbinding maakt bijvoorbeeld, en via waar je het sturen van notificaties kunt regelen enzo. Ik lees iets over MLAP Code Configurator, is dat een tool die je hiervoor kunt gebruiken?

Ik heb nog niet echt ervaring met dit soort dingen.

Ik ben het ook nog allemaal aan het uitzoeken.
Heb standaard de mldp pun op hoog staan. Net als hw en sw boot pin.

Zodra de moddule aan gaat kun je dan in je command simpel via uart commandos opgeven, zo stel je de naam in. Private serivices enz.
Ik stel zelf enkel de naam in. Fabrieks naam. En serie nummer. Waarna ik het commando geef om in mldp modus te gaan.

Zodra die modus geactiveert is wordt alle data over de uart verstuurt. En dat is aan de microcontrollet kant ideaal om te programeren. Zeker waneer je toegang moet hebbe. Tot groote hoeveelheid data op je microcontroller.

Nu werkt bij mij dit via de mldp app browser app van microchip.
Nu ben ik bezig om de source code van die app te intregeren in een app die ik zelf geschreven heb in processing.org.
Dit valt me best tegen omdat ik geen kanjer ben in android en java.


Bedoel je kwa notificaties advertising?

Je command line is het uart sigaal

[Pizza_Boom]

*schopje*

Meer dan een jaar geleden dat ik hier voor het laatst gepost heb en buiten een schopje in de kroeg überhaupt lang geleden dat ik hier ben geweest. Afijn, back to basic, PICkit2 met een 16f690. Waarom? Omdat ik er nog zat heb liggen en niet echt heel ingewikkeld hoef te doen. Ik wil een servotje laten draaien, maar de PWM generator is te klein daarvoor, die kan de puls niet lang genoeg maken. De SG-90 heeft een puls van 500 tot 2400 uS nodig.

An sich lukt het programma redelijk, ik krijg de puls, de Servo vibreert niet na en wordt niet warm, dus de uitgang float niet. Echter, de puls laat zich niet mooi sturen. Normaal kan je de servo in 170-180 stappen laten draaien, ik kom tot 9 stappen van ca. 15-20 graden. Beetje te weinig dus voor een mooie werking. Ik moet dus ergens iets fout doen, maar wat?

Iemand die zin heeft om even te kijken?

C:

/*

             ________  _______
        VDD |        \/       | VSS
        RA5 |       16F690    | RA0 POT-meter
        RA4 |                 | RA1 POT-meter (ext)
Button  RA3 |                 | RA2 POT-meter (ext)
LED5e   RC5 |                 | RC0 LED0
LED4e   RC4 |                 | RC1 LED1
LED3    RC3 |                 | RC2 LED2
        RC6 |                 | RB4
        RC7 |                 | RB5
        RB7 |_________________| RB6

*/

 #include   <htc.h>

__CONFIG(FCMEN_OFF & IESO_OFF & BOREN_OFF & CP_OFF &  PWRTE_OFF & WDTE_OFF & MCLRE_OFF & FOSC_INTRCIO);

#define FOSC 8000000L

int potmeter, led;
int signaal = 125;
int stand = 10;
int i;



void delay(long i)                      // declareert de delay functie
{
    while (i--);
}

void interrupt
isr()
    {
        if(T0IF == 1)
            {
                i++;
                if(i == 21)
                    {
                        RC2 = 1;
                    //  i = 0;
                    }
                else if (i >= 28)
                    {
                        RC2 = 0;
                        i = 0;
                    }
                T0IF = 0;
            }
    }
            

/*
void PWM(void){                     // declareert de PWM functie
//      signal();
        servo();
        delay(5000);
        GO_nDONE = 1;
        while (GO_nDONE == 1);
        CCPR1L = signaal;               // bepaalt PWM hoogte aan de hand van potmeter
}
*/
void main(void)                         // hoofdprogramma
{ 

    PORTC   = 0;
    TRISC   = 0;
    PORTB   = 0;
    TRISB   = 0;
    PORTA   = 1;
    TRISA   = 1;
    ANSEL   = 0x01;         // RA0
//  ANSEL   = 0x02;         // RA1
//  ANSEL   = 0x04;         // RA2
//  EECON1  = 0b01;
    ANSELH  = 0;
    ADCON0  = 0x01;         // RA0 left justified
//  ADCON0  = 0x85;         // RA1 left justified: 0x05, RJ: 0x85
//  ADCON0  = 0x09;         // RA2 left justified

    OSCCON  = 0b01110101;   // kloksnelheid 8 mhz
    ADCON1  = 0b00110000;   // A/D clock = FRC (8 MHz)  
//  ADCON1  = 0b00000000;
    OPTION_REG  = 0b10000000;   // Prescaler 1:2
    TMR0    = 24;           // interrupt supposed to be 0,1 ms
    T0IE    = 1;            // enable timer0 interrupt flag
    GIE     = 1;            // general interrupt enabled
    PEIE    = 1;            // pherriperal interrupt enable

//  CCP1CON = 0x0C;         // 00001100
//  T2CON   = 0x06;         // 00000101
    
//  INTCON = 0b10

    while(1)
        {
        }       
}

[629110]

Leuk topic ! Ik kom het net tegen, heeft het nog zin om een STK500 te kopen via marktplaats voor 40 euro ? Ik wil hem via een RS232 naar USB adapter op mijn laptop gebruiken. Ik vind het heel jammer dat ik zo een ding al jaren geleden niet heb gekocht en elke keer zelf zitten prutten met pcb's of andere adapters.

[Rowwan]

Ik ken jou jouw controller niet goed genoeg om de code volledig te begrijpen, maar ik zie in het commentaar en interrupt van 0.1 ms. De meeste servos, en ook de sg-90, willen een periode van 20, en een variabele duty cycle tussen 1 en 2 ms.
Een duty cycle van 1.5 ms is daarbij de middenstand. 1 en 2 ms zijn de 90 graden hoeken.

Met jouw interrupt van 0.1 ms, kom ik hooguit uit 10 stappen, maar volgens mij klopt er meer niet aan je logica

[Sissors]

Ik ben niet bekend met PICs, maar Atmegas kunnen nog een clock divide by 8 op hun hoofdklok zetten. Oftewel is er een mogelijkheid hem een frequentie van 4MHz te geven? Dan kan je gewoon PWM gebruiken. (Verbaasd me een beetje overigens dat hun PWM geen servos aan kan bij standaard frequentie).

[Hans1990]

Voor servo's is hardware PWM bij uitstek ideaal.

Eigenlijk maar heel weinig servo's aangestuurd, maar dit zegt wikipedia er van:
https://en.wikipedia.org/...s_controle_servomotor.JPG

Heb je een scoop? Ik zou eens goed de waarden van je timer nameten, want volgens mij krijg je nu geen 0.1ms (10kHz) interrupt frequentie.
Daarnaast als je 170-180 stappen wilt hebben op een bereik van 500us, heb je een veels te hoge interrupt frequentie nodig op deze manier.