AVR Freaks

Replacing all the obvious Arduino stuff is the first thing to do; the easiest ones are delay() and pinMode().

Then, I would replace the SoftwareSerial class by a dummy class and make Sigfox an instance of this dummy class. Create dummy member functions until there are no compile errors.

Finally, flesh out the dummy functions until the program works with the hardware USART.

I think it might fit on a tiny402, on a 202 I have serious doubts.

Check this file:

http://ww1.microchip.com/downloa...

The 202 is a tiny 0 series, broadly speaking they only require three pins for programming and debugging. That is:

- Vdd

- GND

- UPDI

from the side of snap, we have the following:

Now for the UPDI pin, if you check the previous link you will see that you can use the Pin 4 (PGD) as the UPDI pin. remember that the SNAP does not provide power to your target, hence, you have to power your board externally.

PS: check the assembly marking of your SNAP, if its assembly#02-10381-R1 then you might have to do some changes that is to remove the pull-up resistor R48 from the board manually.

Regards,

Moe

EDIT: From the side of tiny 202, you will also need to Connct the Vdd, GND & UPDI(PA0). you dont need any other external components or pull-up resistors.

NO, you dont. We are not speaking here about the decoupling capacitors (100nF to Vcc to GND ) which obviously is there in almost any AVR MCU. we are speaking about the line itself that is directly connected to the Vcc from SNAP.

SO, Jim, please read and then you can comment!

You have a while loop AFTER the led toggle and delay. I'm not sure why you have to figure out your own delay values, why not just use <util/delay.h> so you can use _delay_ms(). You also have a broken breakpoint that will do no good, and its hard telling where you are 'stuck' but I would guess you are simply 'stuck' in the while loop with nothing to do. You can add asm("nop"); in places where you want to break, as it is about the only reliable way to put a breakpoint where you want it.

This was done for a tiny416 and takes about 1100 bytes, so a 202 may work ok unless you start adding things like sprintf, etc.-

//ATTiny 416 Xplained Nano
#include <stdint.h>

#include "Port.hpp"
#include "Usart.hpp"
#include "Rtc.hpp"
#include "Slpctrl.hpp"
#include "Adc.hpp"

#define F_CPU 3333333   //reset value for 20M
#include <util/delay.h> //using simple delay
#include <stdlib.h>     //itoa

//led on nano board
PB5_OUTL_t ledpin;
PA0_OUTL_t wakepin;
PA1_ANA_t adcpin;

//usart0 alternate pins, no buffer
Usart< Usart0_Alt, 0 > uart0;
Rtc rtc;
Pit pit;
Adc0 adc;

void shutdown(){
    rtc.clksel( rtc.INT1K );        // clk src = int 1khz
    pit.period( pit. CYC32K );      // /32768 = 32.768sec
    //just need an isr to clear pit flag
    Cpuint::set_func( Cpuint::RTC_PIT,
            [](){ pit.flagclr(); }
    );
    uart0.putstr("AT$P=2\r");       //modem powerdown, takes ~7ms to send
    while( not u.tx_complete() );   //wait until tx done
    pit.irq( true );
    Cpuint::on( true );
    uint8_t count = 110;            // 1H = 3600 / 32.768 = 109.86
    //powerdown for an hour 32sec at a time
    for( ; count--; Slpctrl::sleep( Slpctrl::POWERDOWN ) );
    //an hour has passed
    pit.irq( false );
    Cpuint::on( false );
}

int main() {

    //tx only, don't care what module has to say
    //if no response, nothing we can do about it anyway
    uart0.setupUART( 9600, u.TX_NORMAL );

    for(;;){
        //wakeup modem
        wakepin.on();
        _delay_ms(100);
        wakepin.off();

        ledpin.on();

        //read voltage
        uint16_t v = 0;
        for( uint8_t i = 32; i--; v += adc.adc_val( adcpin ) );
        v /= 32;
        v = v * 1552ul / 1024; // 3.3*4.703*100=1552
        //char buf[8];
        //itoa((uint8_t)v, buf, 16);  //Low byte
        //itoa(v>>8, &buf[2], 16);    //High byte
        //or with simple leading 0 support
        char buf[8] = {'0','0','0','0'}; 
        uint8_t L = v, H = v>>8; 
        itoa(L, buf+(L<16), 16); //Low byte 
        itoa(H, buf+2+(H<16), 16); //High byte

        //send
        uart0.putstr("AT$SF=");
        uart0.putstr(buf);
        uart0.putch('\r');
        //wait until all done before sleep
        //(my putch always clears txc flag before sending)
        while( not uart0.tx_complete() );

        //done
        ledpin.off();
        shutdown();
    }
}

This is my own c++ drivers, but similar c code will be about the same or smaller. Its probably not what you are doing, but I think its close enough to say that a 202 will probably work ok.

edit- I would roll my own itoa or similar as you will need leading 0 support, and bringing in sprintf will most likely not fit in a 202.

> __delay_ms() is not recognized by XC8 AVR compiler

That's because its _delay_ms() and _delay_us() - only 1 leading underscore. Check out uitil/delay.h 

>You could write the whole algorithm described above in AVR assembly language and have it fit in a few hundred bytes.

Whether you use 1k/1.5k/0.5k of a 2k part, it makes no difference. If I was bumping up against the 2K, I would simply find a couple spare pennies laying around to get a tiny402 with 4K (1ea qty is another 2 cents). If 4K is not enough, I would go from 8 pin to 14 pin where you can currently get up to 16K (where you will need to find a couple spare dimes).

PORTA_toggle_pin_level(2)

If they are thinking this is a bitmask, then 2 would be 1<<1 (PA1), instead of 1<<2 (PA2).

Go look at the Atmel Start source code they provided, I imagine they have a bitmask version and a pin version to toggle a pin (or pins). I think I took a look recently, and I think you seem to be using the the right one (_pin_level), but who knows. When I looked, I don't think their function comments were correct (copy/paste errors find their way into everything).

There are other options available, but I add this to the execute after build option-

${MP_CC_DIR}/avr-objdump -dhSC ${ImageDir}/${PROJECTNAME}.${IMAGE_TYPE}.elf > list.txt; 

(I use xcx8, but have a toolchain option pointed at the binary folder so I can use c++, so the above path's are not correct for 'normal' xc8)

I always keep this file open, just to gain an understanding of what the compiler is up to. As a side effect you eventually get to understand assembly for the mcu in use.

Your time is better served learning to drive the compiler to get it to go in the direction you want using a stock/reliable engine, rather than tinker under the hood of the mcu searching for a few extra horsepower. The driver gets to the destination quicker and more reliably than the tinkerer. In my opinion. I happen to think the better direction is c++ which has some nice advantages with no real downside.