Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
ficeto
@ficeto
I can also say that any pin should be able to be used for wakeup
//GPIO (0-15) PIN Function Bits
#define GPFSOE 0 //Sleep OE
#define GPFSS  1 //Sleep Sel
#define GPFSPD 2 //Sleep Pulldown
#define GPFSPU 3 //Sleep Pullup
#define GPFFS0 4 //Function Select bit 0
#define GPFFS1 5 //Function Select bit 1
#define GPFPD  6 //Pulldown
#define GPFPU  7 //Pullup
#define GPFFS2 8 //Function Select bit 2
//GPIO (0-15) PIN Control Bits
#define GPCWE  10 //WAKEUP_ENABLE (can be 1 only when INT_TYPE is high or low)
#define GPCI   7  //INT_TYPE (3bits) 0:disable,1:rising,2:falling,3:change,4:low,5:high
#define GPCD   2  //DRIVER 0:normal,1:open drain
#define GPCS   0  //SOURCE 0:GPIO_DATA,1:SigmaDelta
Russ Mathis
@RussMathis
But you would have to enable or setup the pin(s) before sleeping, right?
ficeto
@ficeto
yes
Russ Mathis
@RussMathis
I don't know how to do that yet! Guess some bit in a register somewhere?
ficeto
@ficeto
:D
which pin do you want to do it for?
Ivan Grokhotkov
@igrr
do you guys think that passing arguments to the bootloader through RTC mem is a good idea?
@Links2004 @ficeto
basically the options are: RTC mem or flash
ficeto
@ficeto
when is that data populated and when is it read?
Russ Mathis
@RussMathis
Would be easier than storing some value in eeprom and reading on wake?
ficeto
@ficeto
@RussMathis eeprom is on flash
Russ Mathis
@RussMathis
OK, so before sleep could save some var to RTC and on wake have it available quicker than having to read flash?
Ivan Grokhotkov
@igrr
say you have a sketch which downloads an OTA update and stores it in the flash somewhere. next it should reboot into the bootloader, passing it a command (like "flash image from 0x50000 to 0x00000")
like they do it in Android :)
almost
so the command has to go either to flash or to RTC
ficeto
@ficeto
as a matter of fact, only half a page is used for the init data
so there is plenty of space to store other stuff there, like the status of the update
Ivan Grokhotkov
@igrr
the problem with RTC is that it may contain garbage at boot...
init data? like the fourth page from the end of flash?
ficeto
@ficeto
yes
Ivan Grokhotkov
@igrr
so we need to erase it each time we write something there
ficeto
@ficeto
and when written to, only 128 bytes are written
it's a whole 4K block
use it like the eeprom, just offset
Ivan Grokhotkov
@igrr
so, the bootloader will read the first 128 bytes, store it somewhere, erase, write 128 bytes back, right?
when it needs to clear the command, that is
ficeto
@ficeto
sure
tthough no need to clear, if that command is actually status of a sort
have it a struct with info for what you are flashing
Ivan Grokhotkov
@igrr
well you need to clear if you don't want the bootloader to update again after flashing
actually not
ficeto
@ficeto
on actuall bott that could be read and known if flash went OK or failed or what
Ivan Grokhotkov
@igrr
we can overwrite this with 0xff
ficeto
@ficeto
why clear?
if the ststaus byte is update, write the image from the address bytes to 0x0
then set status updated
Ivan Grokhotkov
@igrr
when we write to flash, we can only write "1" bits
ficeto
@ficeto
yeah...
or erase whole block?
Ivan Grokhotkov
@igrr
so then we can make status_update = 0x11 and status_updated=0xff
so you can always overwrite status without erasing
smth like that
and need to erase only when we store new command there
ficeto
@ficeto
sure
that block will not live more than the rest anyway :)
so erase each time the rest are erased is fine