[libopencm3-devel] logo idea

ke one? I'd love to get forward with having a logo! Cheers, Karl P [1] https://github.com/brabo -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Busine

Re: [libopencm3-devel] Ok, random git question

nucleo boards since I've got 3 different ones now, (L0, > F0, > and F4) and it seems like ST is handing them out at their talks so useful to > people showing up and discovering loc3. I can work it out normally

Re: [libopencm3-devel] I don't suppose anyone has played with the Nucleo F0 board?

(some warnings I've spoken to PaulF about, but flashed ok) I've not tried anything on the f0 board yet. Cheers, Karl P On 11/18/2014 09:15 PM, Chuck McManis wrote: > So while I wait for Sparkfun to approve my ability to post on the OpenOCD > forums, a bit more work here on the

Re: [libopencm3-devel] I don't suppose anyone has played with the Nucleo F0 board?

ble_HSI' > in procedure 'mww' called at file Yeah, this is something I've reported, I'm going to see if I can fix it myself, save Paul the work of fixing it :) It's because the l0 disco

Re: [libopencm3-devel] I don't suppose anyone has played with the Nucleo F0 board?

Have a look at https://github.com/libopencm3/libopencm3/pull/362 and the example referenced there, I got a basic miniblink up and running tonight, and finished off all the RCC register defiitions at least. Cheers, Karl P On 11/17/2014 05:03 PM, Chuck McManis wrote: > On Mon, Nov 17, 2014

Re: [libopencm3-devel] F0 support

IIRC, the f0 has the "other" i2c peripheral, as on the f3. This needs someone to test them out and link them in, yes. Try and avoid copying the code though :) There's still place for higher level i2c functions, but that's probably a different topic. Cheers, Karl P On

Re: [libopencm3-devel] SPI problem on STM32F0 series.

See also https://github.com/libopencm3/libopencm3/issues/318 This is a known issue, f3 has the same spi peripheral, and it regularly catches people, not just with libopencm3! On 08/16/2014 03:28 AM, Марко Краљевић wrote: > Today I started first work with STM3F0 series (F030, in 20 pin tssop. S

Re: [libopencm3-devel] Problems with new RCC?

Agreed. I've pushed the fix. Cheers, Karl P On 04/08/2014 06:24 AM, Марко Краљевић wrote: > Hi, I just 'ported' one of my programs to use the newer > rcc_periph_clock_enable() instead of rcc_peripheral_enable_clock(). This is > on a > F103VD. > > It seem

Re: [libopencm3-devel] ST nucleo

bout the static linking quirks of LGPL ;) (Note, this is just me, don't read too much into this as any sort of "official" direction statement or anything) mbed is going to be supporting freescale, LPC and ST boards, and they've got corporate backing. It's also a lot more ap

Re: [libopencm3-devel] system reset?

I'm using scb_reset_system() just fine on the L151 parts, fwiw. Cheers, Karl P On 01/26/2014 01:05 AM, Chuck McManis wrote: > So I was playing around with an example I was writing and wanted to initiate a > software reset, basically duplicated what pushing the reset button does. >

Re: [libopencm3-devel] create common tiva(stellaris) and lpc directories.

ve sooner or later. Likewise with LPC. Also, we're using the totally dead and buried names lm4f, which makes it harder for people to find if they are only using current TI docs. It might the right thing to do anyway. Cheers, Karl P

Re: [libopencm3-devel] STM32F3: Fix USART1_BASE

Thanks, merged On 11/17/2013 10:33 AM, b...@elektron.ikp.physik.tu-darmstadt.de wrote: > Hello, > > USART1 on the STM32F3 is places at offset 0x3800 like in F1 and not on > offset 0x1000 as on F2/F4. > > Bye > -- Sponsor

Re: [libopencm3-devel] stm32f4 library: passing address to register directly to functions?

. It hides the bus the peripheral is connected to though, which I'm not entirely sure is better or worse, but it means you only use a single parameter for the periph. It looks generally good though. Cheers, Karl P

Re: [libopencm3-devel] stm32f4 library: passing address to register directly to functions?

, but it makes the code so much easier for my simple brane to deal with. I can read lowercase, separated (_) words that describe what's happening, and I don't have to scan for a P vs a H, and a 1 vs a 2 as single characters inside a larger word. Cheers, Karl P --

Re: [libopencm3-devel] stm32f4 library: passing address to register directly to functions?

On 10/09/2013 07:05 PM, Chuck McManis wrote: > On Wed, Oct 9, 2013 at 10:06 AM, Linge Dai > wrote: > > which allows modifying any arbitrary register. The programmers need to > explicitly enforce restrictions on what to pass to the function. Is the > API > meant

Re: [libopencm3-devel] scb.h

ouch. I think SCB_SHPR(shpr_id) should be kept as is, but the comments are not helpful, and yes, the current definitions of SCB_SHPR1..3 are really the same as SCB_SHPR(1) and SCB_SHPR(3) which is not really what you'd expect. Further, I don't think the definitions of SCB_SHPR1_PRI_ are he