Hardware init function profit a great deal from being inlined if the
given parameters are constant -- which is the common use-case, we could
probably call this for all timers and still have less overhead. The
hwtimer_pwm_ini (which calls hwtimer_ini) gets completely computed at
compile-time resulting only in the register settings of hwtimer_ini.
This is now possible because we get rid of static storage for the
max_ticks and instead compute this in hwtimer_pwm_max_ticks from the
timer register settings.
Some platforms are missing timer channels, this is now left to the
(missing) preprocessor definitions on those platforms, no
platform-specific defines needed anymore.
Also fix usage of timer counter register 3 (hardcoded) in
cpu/avr/dev/clock.c -- this code isn't used on many platforms as it
requires a very special quartz clock frequency but this now also uses
the platform timer specification.
We can now directly compile arduino sketches (.pde) files.
Arduino compatible analogWrite works now.
But there is still a long way to go, serial I/O and timer stuff (delay,
millis etc) currently don't work (not tested but I don't expect this to
work).
It can be used in an arduino sketch or in a normal contiki program.
We get a PWM frequency of 490.2 Hz (a period of 2.040 ms), that's
Arduino compatible. If you need different frequencies see native timer
usage in examples/osd/pwm-example
In a contiki program you have to call arduino_pwm_timer_init to
initialize the timer before pwm works. The arduino sketch wrapper
already does this.
For running a sketch, see examples/osd/arduino-sketch
The following problems were present in the existing DCO calibration algorithm:
Problem #1. In function msp430_quick_synch_dco(), the "for(i=0; i < 1000; i++) { .. }" loop is optimized away by the compiler, as i is not volatile. Making i volatile would improve the results, but would not be sufficient: see the next point.
Problem #2. According to MSP430F2617 Device Erratasheet, bug BCL12 precludes a naive implementations of "fast" calibration altogether. The bug is present on all MCU revisions up to date.
The description of the bug:
"After switching RSELx bits (located in register BCSCTL1) from a value of >13 to a value of <12 OR from a value of <12 to a value of >13, the resulting clock delivered by the DCO can stop before the new clock frequency is applied. This dead time is approximately 20 us. In some instances, the DCO may completely stop, requiring a power cycle.
Furthermore, if all of the RSELx bits in the BSCTL1 register are set, modifying the DCOCTL register to change the DCOx or the MODx bits could also result in DCO dead time or DCO hang up."
In Contiki code for msp430f2xxx @ 8MHz, the RSEL search currently typically goes from 15 down to 11, thus violating the rules.
Step-by-step RSEL change is proposed as the best possible workaround:
"[..] more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."
Problem #3. The old Contiki code started from the highest possible calibration values: RSEL=15, DCOx=7. According to MSP430F2617
datasheet, this means that the DCO frequency is set to 26 MHz. For one, Vcc under 3V is not supported for this frequency, so this means that battery-powered nodes have a big problem. The minimal operating voltages are:
- 1.8V for RSEL <= 13
- 2.2V for RSEL = 14
- 3.0V for RSEL = 15
So the correct way is to always start calibration from RSEL <= 13, unless explicityly pre-calibred values are present.
Problem #4. Timer B should be turned off after the calibration, following the "Principles for Low-Power Applications" in MSP430 user's Guide.
The patch fixes these issues by performing step-by-step calibration and turning off Timer B afterwards. As opposed to MSP430F1xxx calibration, this algorithm does not change the ACLK divider beforehand; attempts to make calibration more precise would lead to looping in some cases, as the calibration step granularity at larger frequencies is quite big.
Additionally, the patch improves DCOSYNCH_CONF_ENABLED behavior, allowing the resynchronization to correct for more than one step.
The CC2538 currently has two addressing options: a hardcoded address set
at compile time or the address stored in primary address section of the
info page. This commit adds the option to choose the secondary location
of the ieee address from the info page, or any memory address.
To use, define `IEEE_ADDR_CONF_USE_SECONDARY_LOCATION` in `project-conf.h`
or similar.
For example:
#define IEEE_ADDR_CONF_USE_SECONDARY_LOCATION 1
Some CFLAGS and LDFLAGS previously only enabled with SMALL=1 have
now been enabled for all builds, regardless of the value of SMALL.
Therefore, from now on, SMALL only chooses between -Os and -O2
As discussed in #503, -Os was broken with one of the toolchains
recommended in the platform's README and for that reason we were
using -O2 by default.
This commit sets the default to -Os and updates the README to no
longer recommend the toolchain in question
lpm.c needs to #include lpm.h in order to get the definition of
lpm_periph_permit_pm1_func_t, which made the replacement macros conflict with
the function definitions for the LPM_CONF_ENABLE == 0 case. This change fixes
this issue by #if-ing out the code in lpm.c in that case. Also, the replacement
macro for lpm_register_peripheral() was missing in that case, which is fixed
here.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
If a project needs to use some libraries at link stage, then the corresponding
linker options (e.g. '-lm') have to be passed after any .o file depending on
these libraries. Hence, LDFLAGS cannot be used to add such options when invoking
$(LD) in Makefile.cc2538, or it should be moved to the correct location.
Instead, this change adds TARGET_LIBFILES to the correct location, like most
other Contiki targets.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
