On Sat, 1 Feb 2014, skeezix wrote:
# "Up to 192+4 Kbytes of SRAM including 64- Kbyte of CCM (core coupled
# memory) data RAMUp to 192+4 Kbytes of SRAM including 64- Kbyte of CCM
# (core coupled memory) data RAM"
#
# Which is to say, SRAM 112K, SRAM 16K, and CCM 64K. There is n
On Sat, 1 Feb 2014, Jeff Mitchell wrote:
# I need to look up details .. But iirc the f405 haz 192k se as f429
# disco; isn't it 112K main sram, maybe 16Kb sram2 and 64Kb ccm? Maybe ccm
# is counted separate .. If there is another 64KB on a different bus to
# main sram1 I might be in luck. My fr
On Fri, 31 Jan 2014, Jeff Mitchell wrote:
# Excellent and many thanks! This will be enormously useful!
.. and it was; I was able to get an order of magnitude increase in
processing with this trick.
The DMA problem is still quite a nuisance though; there is other
work to be done
On Fri, 31 Jan 2014, Chuck McManis wrote:
# You start running into contention for the AHB bus. This is exactly where
# I'm stuck between an FPGA and a hard place :-) Basically as you start
# running code, the fetches from RAM can interfere with the DMA. There are
# a few things you can do, One
I wonder if anyone has some ideas here, or can clear up some of my
observations.
Project here is a VGA display driven from STM32F4, currently on
the F429 disco board to make life a little easier. Its running great,
image is crisp and sharp, no blurr or jiggle going on (thanks t
On Wed, 15 Jan 2014, Donald E Haselwood wrote:
# the bus to stall until the previous operation (the write to clear the
# flag) has completed.
#
# For example,
# void SPI2_IRQHandler(void)
# {
# volatile unsigned int dummy;
# ... some code...
# SPI2_CR2 &= ~SPI_CR2_RXNEIE;// Tur
On Wed, 15 Jan 2014, Frank Duignan wrote:
# There are a number of options available to Tim2 - A good read of the
reference guide is required. Alternatively, if you just want a periodic
interrupt why not use systick - it is
# much simpler (doesn't even require ack'ing the irq)
For the pr
On Wed, 15 Jan 2014, Frank Duignan wrote:
# More likely the interrupt is tail-chaining (re-entering immediately) and this
is happening so quickly that the port has no time to react. What mode is the
timer set to? I.e
# Interrupt on what, does it auto clear etc.
gh; any way to stop
On Wed, 15 Jan 2014, Frank Duignan wrote:
# More likely the interrupt is tail-chaining (re-entering immediately) and this
is happening so quickly that the port has no time to react. What mode is the
timer set to? I.e
# Interrupt on what, does it auto clear etc.
The entirety of the timer set u
On Wed, 15 Jan 2014, skeezix wrote:
# Continuing the hunt ..
Newest finding..
If I twiddle the isr function around a bit, and make it _last
longer_, everything is peachy. Of note:
void tim2_isr ( void ) {
TIM_SR(TIM2) &= ~TIM_SR_UIF; /* Clear interrrupt
Continuing the hunt ..
Chuck has been pounding out ideas on the google plus group (Cortex
M3..), and I've got gdb working nicely now anyway.. and it would seem:
i) The ISR is in fact being called
ii) Togglign the GPIO inside of it is not working
On Tue, 14 Jan 2014, Ken Sarkies wrote:
# The 205RE is 512K and you could well run into trouble with specifying a
# smaller memory. I have found that to be the case when I've played with
# 103's of different sizes.
I did fix this up, to no avail.
# Is your program crashing when using
On Mon, 13 Jan 2014, Chuck McManis wrote:
# Includes of the form #include
# are the correct form, the variant (F2) in this case is added by the
Quite, thanks.
# I would suggest you do initialization in the following order:
# 1) Clock
# 2) GPIOs
# 3) Alternate Function peripherals (usua
e right ones, but
it seems right. At least, it works..
.. where works means I can blink a LED using a polling timer, but
not an isr one ;)
Is it possible I'm not including appropriate ISR tables into the
binary, or other subtlties?
jeff
On Mon, 13 Jan 2014,
Here is the code in question:
http://pastebin.com/xTxn5829
To summarize -- just polling the timer works fine; but my attempt
at enabling the ISR isn't working, so I'm probably missing a register
setting somewhere :)
If you fine people come up with anything, let me know
Does anyone have a libopencm3 based example, against the STM32 F2,
that illustrates ISR's invoking based on timers?
I did try using a couple of the examples (see timer.c) in the F1
directory to no avail; I've got a few attempts at it, and it looks like
(guessing, didn't hook up
On Sun, 12 Jan 2014, Chuck McManis wrote:
# > I will revisit after coffee :)
#
# Heh, always a good idea :-). HSE is high speed external, HSI is high
# speed Internal.
Discovered the CMSIS Periph pdf on the ST site, which clued me in
on this point ;)
I had (for fun) pop
On Sun, 12 Jan 2014, skeezix wrote:
# rcc_clock_setup_hse_3v3 ( &hse_8mhz_3v3[CLOCK_3V3_120MHZ]);
#
# Question: are there any pre-req's for this function to work? I
# know the lib works at least at some level, since blinking the LED via GPIO
# function call is happy.
Complete STM32 noobie here, I'm afraid.
I noticed in the rcc.[hc] code theres a handy dandy function that
looks ready to go to set 120MHz (which is the chip max - STM32F205RE if
memory serves, just slapped onto a breadboard; its working, I can blink
LEDs.)
rcc_clock_se
19 matches
Mail list logo
