|
|
|
\documentclass[11pt]{article}
|
|
%Gummi|065|=)
|
|
\usepackage{graphicx}
|
|
\usepackage{caption}
|
|
\usepackage{xcolor}
|
|
\usepackage[vcentering,dvips]{geometry}
|
|
\geometry{papersize={6in,9in},total={4.5in,6.8in}}
|
|
%\title{\textbf{Door Alarm}}
|
|
\author{Steak Electronics}
|
|
\date{}
|
|
\begin{document}
|
|
|
|
%\maketitle
|
|
|
|
%\tableofcontents
|
|
\textcolor{green!60!blue!70}{
|
|
\section{Attiny Solar Energy Harvest Tests}}
|
|
|
|
I have the following:
|
|
\begin{itemize}
|
|
\item Solar panels
|
|
\item Attiny 10
|
|
\end{itemize}
|
|
To this list, I will add a supercap, and an energy harvesting IC. The goal being to load the super cap during the day, and to run 24/7. I will need an exceptionally low power micro. The super cap will need to be about 3.3V or 5V.
|
|
\textcolor{green!60!blue!70}{
|
|
\subsection{Micro Considerations}}
|
|
The Arduino Atmega328P is not an option. I'm looking to have a current draw of only 1mA max, (ideally 500uA) when active. Moteino is also not an option for this. Those are made for batteries. I want to be battery free. A super cap, however can be used to store energy. I'll get to that shortly.
|
|
|
|
For micros, I have some Attiny10 on hand, and these have a reasonably low power pull in active mode. Let's build those up first. What will the micro do? No idea. I haven't a clue.
|
|
|
|
\textcolor{green!60!blue!70}{
|
|
\subsubsection{Micro Notes}}
|
|
Must run at 1.8V / 1MHz per front page of data sheet, for 200uA draw in active mode.
|
|
\\
|
|
\\
|
|
|
|
|
|
\textcolor{green!60!blue!70}{
|
|
\subsection{Energy Storage}}
|
|
I don't want a battery. Let's go with a super cap. The solar panels will only be active some of the time, so I will want to harvest energy with some kind of IC into the cap when the sun is out.\footnote{Reference: www.analog.com/media/en/technical-documentation/technical-articles/solarenergyharvesting.pdf is a start. I'll need to do more research.}
|
|
|
|
\textcolor{green!60!blue!70}{ \subsection{Make parts, not scrap}} I will
|
|
want to make sure that all parts I build are perf board parts, not
|
|
breadboard scrap (to be torn down and rebuilt again). This is an Attiny,
|
|
so no need to test much, yet.
|
|
|
|
\textcolor{green!60!blue!70}{ \subsubsection{Testing Arduino Loader}}
|
|
Tested this with the blink_LED.c in code folder. The code is as simple as possible.
|
|
It is the following:
|
|
\begin{verbatim}
|
|
//#include <xc.h>
|
|
#include <avr/io.h>
|
|
#include <util/delay.h>
|
|
|
|
int main(void)
|
|
{
|
|
// PB2 output
|
|
DDRB = 1<<2;
|
|
|
|
while(1)
|
|
{
|
|
// Toggle PB2
|
|
PINB = 1<<2;
|
|
_delay_ms(500);
|
|
}
|
|
}
|
|
\end{verbatim}
|
|
When programmed in Mplab, with XC8 compiler, and Attiny10 support, I get the following
|
|
hex output:
|
|
\begin{verbatim}
|
|
:100000000AC020C01FC01EC01DC01CC01BC01AC01B
|
|
:1000100019C018C017C011271FBFCFE5D0E0DEBF41
|
|
:0A002000CDBF03D000C0F894FFCF5D
|
|
:10002A0044E041B940B95FE966E871E05150604087
|
|
:0A003A007040E1F700C00000F5CFB0
|
|
:02004400DDCF0E
|
|
:00000001FF
|
|
\end{verbatim}
|
|
The content of this hex isn't the focus of this passage. Instead, I want you to review the
|
|
results of a D for Dump Memory, by the Arduino Loader.
|
|
\begin{verbatim}
|
|
|
|
Current memory state:
|
|
|
|
registers, SRAM
|
|
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
|
|
0000: 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|
|
0030: 00 00 00 00 00 00 03 00 00 79 00 03 00 00 00 00
|
|
0040: B7 AD AE FA 58 70 63 6B FB 5A B4 1B FF FF 35 3F
|
|
0050: 67 D7 33 43 DF 5F FB 72 C9 7D FE E9 9D C5 00 12
|
|
NVM lock
|
|
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
|
|
3F00: FF FF
|
|
configuration
|
|
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
|
|
3F40: FF FF
|
|
calibration
|
|
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
|
|
3F80: 79 FF
|
|
device ID
|
|
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
|
|
3FC0: 1E 90 03 FF
|
|
program
|
|
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
|
|
4000: 0A C0 20 C0 1F C0 1E C0 1D C0 1C C0 1B C0 1A C0
|
|
4010: 19 C0 18 C0 17 C0 11 27 1F BF CF E5 D0 E0 DE BF
|
|
4020: CD BF 03 D0 00 C0 F8 94 FF CF 44 E0 41 B9 40 B9
|
|
4030: 5F E9 66 E8 71 E0 51 50 60 40 70 40 E1 F7 00 C0
|
|
4040: 00 00 F5 CF DD CF FF FF FF FF FF FF FF FF FF FF
|
|
4050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
|
|
4060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
|
|
(...some memory omitted here for brevity...)
|
|
43E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
|
|
43F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
|
|
\end{verbatim}
|
|
|
|
Notice that the AC020C01F is set. That is from the hex. But the 01000...
|
|
before it seems to be missing. Some deciphering of how the Arduino programs
|
|
the Attiny is in order here.
|
|
|
|
Regardless, when programming, the Arduino reports 70 bytes written, and
|
|
likewise in the Mplab project memorymap.xml file, it also notes 70 bytes
|
|
for the sketch. This lines up.\footnote{Although for an unknown reason, every command registers twice on the Arduino serial monitor, but this appears to be harmless.}
|
|
|
|
The blinking LED works. Let's move on.
|
|
|
|
|
|
\end{document}
|
|
|