Either I don't know how to properly use instantiate your AdcTripleFeature, or inheritance access specifiers are wrong.

class AdcTriple -> class AdcDual -> struct AdcMulti -> class AdcFeatureBase

since no access specifier is put, AdcMulti inherits publicly, but AdcDual, AdcTriple inherit privately. Therefore AdcTriple has no access to AdcFeatureBase _adc field.

Here:

The demo code has adc.startRegularConversion(); for each time around the loop— to take advantage of continuous mode, the first conversion should be started outside the loop, I think?

This is a suggested enhancement— I've started doing it externally, but I'm wondering if you might be interested in having it in the main distribution.

The concept is to supply some headers providing key stm32plus base classes needed to compile firmware logical blocks for off-board unit testing (eg, using gtest). I've been experimenting with template-based dependency injection, and that's just plain necessary in some scenarios, but it'd be very convenient to have a mocks/config/gpio.h header which supplies a mock stm32plus::GpioPinRef which can be used for testing.

This could be an external thing, but something like a basic GPIO mock would likely be broadly useful.

Happy to contribute this, but I can't provide any examples or testing beyond the F4 series.

Should be a matter of calling through to the TIM_EncoderInterfaceConfig function, and then configuring the GPIO alternate function, probably with a RemapX scheme similar to the Usart.

Any particular opinions about the design of this?

Wish all the code would be available on github for social contribution. I believe I would pull some requests.

1. DAC_DmaCmd is called too early (in constructor). If one trusts Standard peripheral library's documentation, it states DMA shall be configured first. I had an issue with DAC stability - every once it would not transmit. Moving DAC_DmaCmd call after configuring and enabling DMA in beginRead() solved this issue.
   2.DMA_FIFOMode seems to be set to DMA_FIFOMode_Enable regardless of what was specified in feature template.

$scons mode=debug mcu=f1mdvl hse=8000000
scons: Reading SConscript files ...
stm32plus build version is 030500
File "/home/wang/Desktop/gb/stm32plus/lib/build/debug-f1mdvl-8000000/cmake/SConscript", line 45
with open(str(source_file), "r") as s, open(str(target_file), "w") as t:
^
SyntaxError: invalid syntax

python2.6.6
scons 2.2.0
gcc version 4.8.4 20140526 (release) [ARM/embedded-4_8-branch revision 211358] (GNU Tools for ARM Embedded Processors)

what's wrong?

Support the F0 series

Release 3.2.0 will support ST's implementation of the Cortex M0 core in the form of the STM32F0 series.

This may be not an issue, but a kind of report.

As of GCC4.8, the behavior of -Wall has changed and includes the new warning flag -Wunused-local-typedefs. It stops building due to the -Werror flag in SConstruct file.
To resolve this matter, -Wno-unused-local-typedefs flag should be passed to CXXFLAGS.

I got following by default:

~/dev/stm32/stm32plus$ scons mode=debug mcu=f4 hse=12000000
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
arm-none-eabi-g++ -o examples/ads7843/build/debug-f4-12000000/ads7843.o -c -Wextra -Werror -pedantic-errors -fno-rtti -std=gnu++0x -fno-threadsafe-statics -pipe -Wall -Werror -ffunction-sections -fdata-sections -fno-exceptions -mthumb -gdwarf-2 -pipe -DHSE_VALUE=12000000 -mcpu=cortex-m4 -DSTM32PLUS_F4 -O0 -g3 -Ilib/include -Ilib/include/stl -Ilib -Iexamples/ads7843 examples/ads7843/ads7843.cpp
In file included from lib/include/event/slot.h:32:0,
                 from lib/include/config/event.h:24,
                 from lib/include/config/rtc.h:19,
                 from lib/include/config/timer.h:24,
                 from lib/include/config/timing.h:18,
                 from lib/include/config/display/tft.h:23,
                 from examples/ads7843/ads7843.cpp:8:
lib/include/event/fd/FastDelegate.h: In function 'OutputClass fastdelegate::detail::horrible_cast(InputClass)':
lib/include/event/fd/FastDelegate.h:178:14: error: typedef 'ERROR_CantUseHorrible_cast' locally defined but not used [-Werror=unused-local-typedefs]
  typedef int ERROR_CantUseHorrible_cast[sizeof(InputClass)==sizeof(u) 
              ^
lib/include/event/fd/FastDelegate.h: In static member function 'static fastdelegate::detail::GenericClass* fastdelegate::detail::SimplifyMemFunc<N>::Convert(X*, XFuncType, GenericMemFuncType&)':
lib/include/event/fd/FastDelegate.h:295:16: error: typedef 'ERROR_Unsupported_member_function_pointer_on_this_compiler' locally defined but not used [-Werror=unused-local-typedefs]
   typedef char ERROR_Unsupported_member_function_pointer_on_this_compiler[N-100];
                ^
lib/include/event/fd/FastDelegate.h: In member function 'void fastdelegate::detail::ClosurePtr<GenericMemFunc, StaticFuncPtr, UnvoidStaticFuncPtr>::bindstaticfunc(DerivedClass*, ParentInvokerSig, StaticFuncPtr)':
lib/include/event/fd/FastDelegate.h:781:15: error: typedef 'ERROR_CantUseEvilMethod' locally defined but not used [-Werror=unused-local-typedefs]
   typedef int ERROR_CantUseEvilMethod[sizeof(GenericClass *)==sizeof(function_to_bind) ? 1 : -1];
               ^
lib/include/event/fd/FastDelegate.h: In member function 'UnvoidStaticFuncPtr fastdelegate::detail::ClosurePtr<GenericMemFunc, StaticFuncPtr, UnvoidStaticFuncPtr>::GetStaticFunction() const':
lib/include/event/fd/FastDelegate.h:796:15: error: typedef 'ERROR_CantUseEvilMethod' locally defined but not used [-Werror=unused-local-typedefs]
   typedef int ERROR_CantUseEvilMethod[sizeof(UnvoidStaticFuncPtr)==sizeof(this) ? 1 : -1];
               ^
cc1plus: all warnings being treated as errors
scons: *** [examples/ads7843/build/debug-f4-12000000/ads7843.o] Error 1
scons: building terminated because of errors.

$ arm-none-eabi-g++ -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-g++
COLLECT_LTO_WRAPPER=/opt/cross/arm-none-eabi-x-tools/bin/../libexec/gcc/arm-none-eabi/4.8.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.8.1/configure --target=arm-none-eabi --prefix=/home/tokoro/dev/build-script/install --disable-shared --disable-nls --disable-threads --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp -v --enable-languages=c,c++ --enable-interwork --disable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2 --with-newlib --with-headers=../newlib-2.0.0/newlib/libc/include --with-mpc=/home/tokoro/dev/build-script/addontools --with-mpfr=/home/tokoro/dev/build-script/addontools --with-gmp=/home/tokoro/dev/build-script/addontools
Thread model: single
gcc version 4.8.1 (GCC) 

The current implementation emulates the SDIO multi-block read/write commands by issuing multiple single-block read/write commands as required. This enhancement will use the actual native multi-block commands that perform better for large consecutive reads and writes.

There are a few sections of the library using perl scripts to autogenerate IO mappings and such, eg: https://github.com/andysworkshop/stm32plus/tree/master/lib/include/gpio/autogen

However, there's a lot more code being manually managed which could be candidates for this, even something as simple as Adc1.h, Adc2.h, and Adc3.h, which are identical but for very small differences.

Some steps to consider which might lower the barrier and make it possible to use source generation more broadly:

• Hosted, generated docs, based on and including a copy of the generated sources, so that the git repo itself is no longer the primary reference for the installed source.
• Use of an established templating scheme, for example, empy: http://www.alcyone.com/software/empy/
• Integration with SCons, so that the templated files render as part of the build, rather than a separate manual step. The SConscript files in those directories could contain whatever simple logic feeds the template system (with any significant data remaining separate, in csv or yaml as appropriate).
• Establishment of a few conventions about the autogen directories, especially with an eye toward a) minimizing the friction associated with templating up a few simple files, and b) allowing a single shared template to generate files for multiple chip series.

I'm poking away at hosted docs for stm32plus—that's of immediate benefit to others on my team. Can't commit to any particular timeline for the rest, but wanted to throw it across your radar for discussion.

The f1_mdvl branch is where support for the medium density value line devices is being developed. The examples will target the "STM32 Value Line Discovery" board (128/8Kb) at 24MHz.

The VL discovery board offers a very cheap entry into the world of 32-bit ARM MCUs and the LQFP packages are not difficult to work with when you need to build your own PCBs.

Version 1.1.2 of the GNU ARM Eclipse Plugin has now been released supporting Eclipse Kepler. Release 3.0.2 will migrate to this combination of Eclipse/GNU ARM plugin.

This migration was driven by the author of the GNU ARM plugin marking version 0.5 as "end of life" and not supporting versions of Eclipse prior to Kepler with the new plugin.

To be clear, it will not be possible to use Eclipse Indigo with the .project/.cproject files that will accompany release 3.0.2 of stm32plus. You must migrate to Kepler.

I've come across a panel that requires additional initialisation compared to the original Sony. Need to support it in stm32plus as a "TypeB" option.

Upcoming support for the high resolution R61523 controller makes it desirable to support some larger fonts.

Font data on the F1 and F4 is intentionally compiled into SRAM so that the bitband region can be used to gain fast access to the individual font bits. The F0 does not support bitbanding and has limited SRAM therefore the font data should be compiled into flash.

For the TIM8_CH1N capability:

https://github.com/andysworkshop/stm32plus/blob/master/lib/include/timer/features/f4/Timer8GpioFeature.h#L60

Only A7 is offered, but this function is also on A5. It's not clear to me how the remap array should be structured to permit this.

Hello,

there seems to be a problem with static constexpr in different positions where macros are used in the expression.

Example: Timer1GpioFeature.h
static constexpr const uint16_t pins[4]={ GPIO_Pin_14,GPIO_Pin_0,0,GPIO_Pin_10 };
does not compile with the following error message:
C:\ChibiStudio\workspace\stemwin\Libraries\stm32plus-3.2.0\include/timer/features/f1/Timer1GpioFeature.h: In static member function 'static void stm32plus::TIM1_CH2N::initialise()':
C:\ChibiStudio\workspace\stemwin\Libraries\stm32plus-3.2.0\include/timer/features/f1/Timer1GpioFeature.h:216:86: internal compiler error: unexpected expression '(uint16_t)(16384)' of kind cast_expr
static constexpr const uint16_t pins[4]={ GPIO_Pin_14,GPIO_Pin_0,0,GPIO_Pin_10 };

Replacing GPIO_Pin_14 with the constant 0x4000 instead of the macro content ((uint16_t)0x4000) which causes the compiler to fail.

Thanks for your great work.

Daniel

Font class does not support fonts with non-contiguous characters properly. This will be fixed in 3.0.2.

In file: include/dma/features/{f0,f1,f4}/DacDmaWriterFeature.h
from line 61 onwards: you forgot to put braces in function calls.

if(TDacAlignmentFeature::getAlignment==DAC_Align_12b_R)... and so on.

A board to be featured on my blog will have the s25fl208k flash IC on it. I will add support to stm32plus for that IC.

I'm about ready to make some progress on this, so I'm just filing a ticket for discussion purposes.

At least at first, it'll be a partly manual workflow where a locally-run script runs a SCons install build and packages the output, with an optional extra step to push the resulting debs to an apt repo on bintray.

This will have to be done once per release—we can both be owners of the bintray repo, so I can take care of doing it too, or I can remove myself from the bintray repo and you can handle it.

Suggested packages would be:

stm32-030300-small-f4-8000000-dev <- lib, include
stm32-030300-small-f4-8000000-example <- bin
stm32-030300-small-f4-8000000 <- metapackage installing the other two

Versioning would just be 1.0 for everything. Using the version field would be neat, but it comes at the cost that you could only every install one version from packaging. I'm not sure that's worth it.

If/when #24 goes in, that'll add another tiny package of the form stm32-030300-cmake, which installs a script which is common to all configs, and would be a dependency of the dev package(s).

The final piece of all this would be supplying a reasonable getting-started story for users of the packages— eg, "Add the apt repo, install the package, clone this small example, build, download to your discovery kit, and tada!" What other pieces would be necessary to make that a reality? Probably some kind of stlink/openocd/dfu-util loader installation, plus the compiler installation.

Hello,

Is it possible to build Coocox coIDE project with stm32plus library for STM32F103RB board?

Architecture STM32F103RB

• Chip: ARM Cortex-M3 core
• LCD controller: ILI9325
• Touchscreen controller: ADS7843
• Flash memory: 128 Kbytes

Thanks a lot,

Christian.

Release 3.2.1 of stm32plus will support the ADC peripheral in all the MCUs supported by the library. Support will include

• All clocking options
• DMA
• Interrupts
• Regular and injected (where supported by the MCU) channels
• All triggering options
• Multi ADC configurations (where supported by the MCU)

Two issues in one here.

1. My handling of the way that the standard peripheral library on the F0 supported 16-bit wide transfers is flawed and does not work properly.
2. The 4-byte receive FIFO on the F0 caused problems with RNXE not being set when bytes arrived unless the FIFO notify threshold was configured correctly.

The calculation for the _initDivider yields a number too big to fit in the 8 bits allowed in the clock divider register. SdCardSdioFeature::detectDividers()

The impact is that an unintended frequency is being used to communicate with the card during the initialisation phase. The maximum allowed by the standard is 400kHz and it's quite possible this error means that we exceed that limit. Not sure if any cards actually care enough to not initialise due to this bug though.

include/stl/ostream_helpers:253
stm32plus::StringUtil namespace missing. Could not compile following code:
std::ostringstream ostr;
ostr << 2.0;

@ include/adc/features/f4/AdcChannelGpioInitialiser.h

I can supply this if you'd consider merging it. The impact from the user's side would be:

a) stm32plus is built/installed using scons (no change)
b) the user's project can use scons or CMake, as is their preference. CMake can generate native project/build files for Make, Eclipse, Code::Blocks, etc.

I'm experiencing issues with the N-channel outputs on the 407's advanced timers.

Example setup:

struct TimerPins
{
  typedef gpio::PE9 TIM1_CH1_Pin;
  typedef gpio::PE8 TIM1_CH1N_Pin;
  typedef gpio::PE11 TIM1_CH2_Pin;
  typedef gpio::PE10 TIM1_CH2N_Pin;
};

Timer1<
      Timer1InternalClockFeature,
      TimerChannel1Feature,
      TimerChannel2Feature,
      Timer1CustomGpioFeature<
        TIM1_CH1_OUT<TimerPins>,
        TIM1_CH1N<TimerPins>,
        TIM1_CH2_OUT<TimerPins>,
        TIM1_CH2N<TimerPins>>
> tim1;

And the following initialization:

tim1.setTimeBaseByFrequency(20000000, 1999);
tim1.TimerChannel1Feature::initCompareForPwmOutput();
tim1.TimerChannel2Feature::initCompareForPwmOutput();
tim1.enablePeripheral();
tim1.TimerChannel1Feature::setDutyCycle(20);
tim1.TimerChannel2Feature::setDutyCycle(20);

For Timer1 (as written), I see 20% pulses on PE9 and PE11 exactly as expected, but on PE8 and PE10, I see very low, compressed pulses, as if the line is connected to something other than the timer peripheral and being asserted low by that.

For Timer8, with a similar initialization, the CH1N and CH2N pins show no activity at all.

Is this a library bug? I'm not certain that the GPIO_AF setup is occurring correctly or completely in either case. In the process of looking into it, but I thought I'd let you know of the anomaly.

I'm playing with the library so I want to know if it is possible to only build one example.

Thank you

Hi,

While trying to compile your example code (http://andybrown.me.uk/wk/2013/02/10/stm32plus-2-0-0/) for a STM32F0R8 i get this error on eclipse...

In file included from /home/joao/Downloads/stm32plus-3.2.0/lib/include/config/timer.h:184:0,
from /home/joao/Downloads/stm32plus-3.2.0/lib/include/config/timing.h:18,
from ../src/main.cpp:9:
/home/joao/Downloads/stm32plus-3.2.0/lib/include/timer/features/f0/Timer1GpioFeature.h: In static member function 'static void stm32plus::TIM1_ETR::initialise()':
/home/joao/Downloads/stm32plus-3.2.0/lib/include/timer/features/f0/Timer1GpioFeature.h:30:77: internal compiler error: unexpected expression '(uint16_t)(4096)' of kind cast_expr
static constexpr const uint16_t pins[4]={ GPIO_Pin_12,GPIO_Pin_12,0,0 };
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [src/main.o] Error 1

I tried with the 3.2.0 and the 3.3.0 version, with the same result.
I'm running Ubuntu 14.04 64 bits , eclipse Kepler, gnu-tools for arm "gcc-arm-none-eabi-4_8-2014q2-20140609"

The exported project is where - https://dl.dropboxusercontent.com/u/6280450/test_blink.zip

Thanks!

Hi,
I tried the ads7843 example, change the LcdPanel to ILI9481, change the inilcd and was able to test the touch. The only problem I found som far is that the LED box produce the following error when touched:

Starting program: /home/ze/Development/stm32plus/examples/ads7843/build/fast-f1hd-8000000/ads7843.elf 
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08007fa0 in WWDG_IRQHandler ()
(gdb) bt
#0  0x08007fa0 in WWDG_IRQHandler ()
#1  <signal handler called>
#2  setDutyCycle (dutyCycle=53 '5', this=0x5e149bef)
    at lib/include/timer/features/TimerChannel2Feature.h:127
#3  ADS7843Test::doDemo (this=this@entry=0x2000ff44) at examples/ads7843/ads7843.cpp:483
#4  0x08007f16 in run (this=0x2000ff44) at examples/ads7843/ads7843.cpp:104
#5  main () at examples/ads7843/ads7843.cpp:580
(gdb)

Hi, I have a suggestion for the implementation of timeout.

Your code seem to have implemented it by using MillisecondTimer, but this fact is not well-documented.

I think that MillisecondTimer and the timeout functionality should be separated.
It is not trivial that timeout is automatically enabled when using MillisecondTimer so they should be switched like this:

(When using timeout)

I2C1_Default<I2CTimeoutFeature,...> i2c; // Add timeout feature which initialises MillisecondTimer automatically
// MillisecondTimer::initialise(); // Now this isn't necessary because of the timeout feature

(When using MillisecondTimer with no timeout)

I2C1_Default<SomeOtherFeature,...> i2c; // Doesn't use MillisecondTimer for timeout
MillisecondTimer::initialise(); // Necessary to use MillisecondTimer

Thank you for your fascinating library and I hopefully make it more efficient and useful.

Potentially could be implemented as an MCU variant, eg, separate mcu=f4 and mcu=f4-hf.

I tried briefly to hack this in myself by modifying the flags in the toplevel SConstruct, but it wasn't able to build afterward.

The next major peripheral to be supported will be USB (high speed) on the F4. I plan to incrementally release support for peripheral and host modes and the popular device classes. Updates will be posted to this issue when I start work on support for this complex peripheral.

Hi,
Using the following hardware:
-TFT http://www.ebay.com/itm/3-2-TFT-LCD-Module-Display-with-Touch-PCB-adapter-262K-Color-Screen-480-X-320-/251306651231?pt=LH_DefaultDomain_0&hash=item3a830b2e5f
-Dev Board http://www.wvshare.com/product/Port103V.htm

I got the colors inverted. Only after add _accessMode.writeCommand(ili9481::ExitInvertModeCmd::Opcode); it get the right colors.

Is there a way to get tft controller information?

Thank you

The Renesas R61523 is a 640x360 TFT controller. I intend to provide full support for this device.

LCD controllers require different timings for read and write operations. This enhancement will allow those timings to be specified separately.

Short version is that the Terry Guo PPA does things slightly differently from the new upstream Debian package which is now in Trusty. There's an Ubuntu bug about it here:

https://bugs.launchpad.net/gcc-arm-embedded/+bug/1309060

There's a workaround mentioned to force apt to download the PPA version of gcc-arm-none-eabi rather than the Ubuntu one. However, I've found it frustrating, as an apt-get upgrade can cause it to be switched back. Seems like there are three possible outcomes:

• The upstream package is modified to add these files.
• One or more upstream packages are added, containing the library sources.
• stm32plus bundles the additional headers and sources upon which it depends.

Either of the first two resolutions is dependent upon the change not only occurring, but also being made available to Trusty. I'm unsure how realistic this is to expect.

A race condition in the availableToRead and availableToWrite() methods means that this class cannot currently be used to write from an IRQ while simultaneously reading from the main thread. This enhancement will fix that.

If FontConv is used to save a font with some characters missing in the middle then the Font class may not find all characters in the font successfully.

32bit timers are available in some products as mentioned in AN4013.

Currently, all the counter register values are bounded in 16bit (by config functions in TimerChannelXFeature.h).
Since this can affect #29, it would be nice to decide to support 32bit timers or not.

Any opinions?

in the file stm32plus\lib\include\display\graphic\tft\lgdp453x\LGDP453xPortraitSpecialisation.h,
on the line 144 in the function :

template<class TAccessMode>
inline void LGDP453xOrientation<PORTRAIT,TAccessMode>::moveY(int16_t ystart,int16_t yend) const {
      _accessMode.writeCommand(lgdp453x::VerticalRAMPositionStartCmd::Opcode,ystart);
      _accessMode.writeCommand(lgdp453x::VerticalRAMPositionEndCmd::Opcode,yend);
      _accessMode.writeCommand(lgdp453x::VerticalRAMPositionEndCmd::Opcode,yend);
}

last line should be:

       _accessMode.writeCommand(lgdp453x::VerticalAddressCmd::Opcode,ystart);

As a very preliminary starting point, I've placed a current copy of the generated docs online here:

http://mikepurvis.github.io/stm32plus

Some obvious next steps with this:

• Either use a better/prettier Doxygen template, or wrap the generated doxygen in something attractive like Sphinx.
• Supplement the API docs with usage docs (much of this content exists, but is in the comment blocks on top of the relevant example sources).
• The mega list of all classes is so overwhelming as to be basically useless. We could consider using Doxygen's grouping feature to list things by "module".
• The docs should automatically generate— either by having travis publish them to S3, or to github Pages, or using a doc-building service like ReadTheDocs.

Anyhow, can't promise how quickly I'll be able to get to any of this, but it's another ticket for discussion, or for others to pick up the torch on if they want.

although you parametrise your feature class with PeripheralDataSize, MemoryDataSize, you seem to always set DMA_PeripheralDataSize_HalfWord, DMA_MemoryDataSize_HalfWord in constructor.

Need to add support for charsets that have >255 char codes. Implementation should not negatively impact the majority of bitmap fonts that have <=255 characters by adding wasted space.

Hello,

currently I'm working on projects, where I mix stm32plus with existing libs. In one case stemwin, which is partly closed source.
Some of the libs configure interrupts on their own and bring their own interrupt handler as C function.
Currently it's necessary to rewrite the interrupt handler in stm32 to call the C interrupt handler.
Also the call of the InterruptEventSender has to be removed, since it causes an hard fault when there is no instance from the corresponding object.
Doing this rewrite is not a nice solution. Also the other way round, changing the code of the C lib to use stm32plus objects is not clean.
Typical situation: C lib uses one timer and the new C++ code uses another.

I like to request 2 changes:

1. "InteruptEventSender" only to be called if there is an instance of the corresponding offset.
2. allow to register "C" callbacks to the different events.

Thanks a lot,

Daniel

The library will already build successfully using the GNU Tools for ARM embedded Processors toolchain. This release will make that official.

The reason for the addition of support is that hard floating point support is not available in the free CodeSourcery Lite toolchain.

Support for the Micrel KSZ8091RNA ethernet PHY will be added to the TCP/IP stack. The KSZ8091RNA is very similar in operation to the KSZ8051MLL with the obvious major difference that it's RMII instead of MII.

Testing on the F107 is possible with the following physical and link layer configuration:

typedef PhysicalLayer<KSZ8091RNA> MyPhysicalLayer;
typedef DatalinkLayer<MyPhysicalLayer,RemapRmiiInterface,Mac> MyDatalinkLayer;

I've built a development board around the KSZ8091RNA that will feature in an article on my website in the coming months.