In article <87obepoq98.fsf@devereux.me.uk>, john@devereux.me.uk says...> > Mike Perkins <spam@spam.com> writes: > > > Can anyone point me in the direction of a suitable user's group? > > > > I'm currently battling with a STM32F205 and come across a couple of snags!! > > You could ask here - I've been using this part a bit.I've also used the F205 in a few designs. I've now switched to the F405 to get a bit more speed and the FPU. The F205 seems to be in bit of a low spot in the acceptance curve. The F1XX parts get all the low-end slots and the F4XX parts are getting the top end slots. There doesn't seem to be a lot of demand in the middle. That said, the F2XX parts have more than enough RAM, Flash and processing power for boards I've put them into. It's also pretty easy to contol power requirments by stopping the CPU clock until the next interrupt. I found the biggest advantage of the F2XX series to be the hardware 4-bit SD card interface. After 5+ years of mucking about with SPI interfaces to SD cards, it was nice to finally get some real performance out of my storage system. Mark Borgerson
STM32F2 series users group
Started by ●March 11, 2013
Reply by ●March 12, 20132013-03-12
Reply by ●March 12, 20132013-03-12
Mark Borgerson <mborgerson@comcast.net> writes:> In article <87obepoq98.fsf@devereux.me.uk>, john@devereux.me.uk says... >> >> Mike Perkins <spam@spam.com> writes: >> >> > Can anyone point me in the direction of a suitable user's group? >> > >> > I'm currently battling with a STM32F205 and come across a couple of snags!! >> >> You could ask here - I've been using this part a bit. > > I've also used the F205 in a few designs. I've now switched to the > F405 to get a bit more speed and the FPU. The F205 seems to be > in bit of a low spot in the acceptance curve. The F1XX parts get > all the low-end slots and the F4XX parts are getting the top end > slots. There doesn't seem to be a lot of demand in the middle.Yes could be - but I found quite a premium for the M4 based parts. The F4 is pin compatible so I can try to get things working on the F2, if I run out of horsepower I can "upgrade" I suppose. NXP LPC32xx is looking pretty good then though.> That said, the F2XX parts have more than enough RAM, Flash and > processing power for boards I've put them into. It's also pretty > easy to contol power requirments by stopping the CPU clock until > the next interrupt. > > I found the biggest advantage of the F2XX series to be the hardware > 4-bit SD card interface. After 5+ years of mucking about with > SPI interfaces to SD cards, it was nice to finally get some real > performance out of my storage system. > > Mark Borgerson >-- John Devereux
Reply by ●March 13, 20132013-03-13
On 12/03/2013 16:28, John Devereux wrote:> Mark Borgerson <mborgerson@comcast.net> writes: > >> In article <87obepoq98.fsf@devereux.me.uk>, john@devereux.me.uk says... >>> >>> Mike Perkins <spam@spam.com> writes: >>> >>>> Can anyone point me in the direction of a suitable user's group? >>>> >>>> I'm currently battling with a STM32F205 and come across a couple of snags!! >>> >>> You could ask here - I've been using this part a bit. >> >> I've also used the F205 in a few designs. I've now switched to the >> F405 to get a bit more speed and the FPU. The F205 seems to be >> in bit of a low spot in the acceptance curve. The F1XX parts get >> all the low-end slots and the F4XX parts are getting the top end >> slots. There doesn't seem to be a lot of demand in the middle. > > Yes could be - but I found quite a premium for the M4 based parts. The > F4 is pin compatible so I can try to get things working on the F2, if I > run out of horsepower I can "upgrade" I suppose. NXP LPC32xx is looking > pretty good then though. > >> That said, the F2XX parts have more than enough RAM, Flash and >> processing power for boards I've put them into. It's also pretty >> easy to contol power requirments by stopping the CPU clock until >> the next interrupt. >> >> I found the biggest advantage of the F2XX series to be the hardware >> 4-bit SD card interface. After 5+ years of mucking about with >> SPI interfaces to SD cards, it was nice to finally get some real >> performance out of my storage system. >> >> Mark Borgerson >> >I felt the F2 part offered sufficient memory for the price. It also has a an RTC which has sub uA drain on Vbat, so a serious contender for using a small lithium cell for maintaining time. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
Reply by ●March 13, 20132013-03-13
On 11/03/2013 18:08, John Devereux wrote:> Mike Perkins <spam@spam.com> writes: > >> On 11/03/2013 16:28, John Devereux wrote: >>> Mike Perkins <spam@spam.com> writes: >>> >>>> Can anyone point me in the direction of a suitable user's group? >>>> >>>> I'm currently battling with a STM32F205 and come across a couple of snags!! >>> >>> You could ask here - I've been using this part a bit. >>> >> >> I'm finding the ST documents a little lacking and using an old library >> hasn't helped. >> >> I've got a UART running, or at least sending characters but the >> interrupt for USART_SR->TC isn't working. There is very little >> information of the NVI in the Reference Manual (RM0033) about the NVIC >> though at least I've now sussed out I need to read more of the >> Cortex-M3 documents. > > Like Stephen said the NVIC is part of the CM3 core; you are supposed to > read the ARM documentation for that. Although there are examples in the > ST peripheral library. > >> Many thanks for the offer, I might yet pick your brains. > > Stephen posted a better answer than I would have (so good he posted it > thrice :) ). > > I have not used the TC irq specifically yet, but not had any issues with > interrupts generally. > > Have you got any interrupts working at all yet? > > Can you see the TC flag active in the SR? > > If so should be matter of setting the USART_CR1 TXEIE bit (bit 7) for > the UART. > > Then you need to handle the TX interrupt and check the status register > there to see what triggered it. > > If I get time I may change my debug uart to be interrupt driven, get it > working properly. >Many thank for the ideas. Interrupts are working well. I now have a problem with FreeRTOS: I fill a queue with 6 characters Enable TCIE In the interrupt routing I see 6 characters - great Send 6 characters and when the queue is empty disable TCIE I fill a queue with 6 characters Enable TCIE In the interrupt routing I now see 7 characters - not so great!! I'm left wondering if xQueueReceiveFromISR function corrupts pointers if the queue is empty? -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
Reply by ●March 13, 20132013-03-13
On 13/03/2013 23:57, Mike Perkins wrote:> On 11/03/2013 18:08, John Devereux wrote: >> Mike Perkins <spam@spam.com> writes: >> >>> On 11/03/2013 16:28, John Devereux wrote: >>>> Mike Perkins <spam@spam.com> writes: >>>> >>>>> Can anyone point me in the direction of a suitable user's group? >>>>> >>>>> I'm currently battling with a STM32F205 and come across a couple of >>>>> snags!! >>>> >>>> You could ask here - I've been using this part a bit. >>>> >>> >>> I'm finding the ST documents a little lacking and using an old library >>> hasn't helped. >>> >>> I've got a UART running, or at least sending characters but the >>> interrupt for USART_SR->TC isn't working. There is very little >>> information of the NVI in the Reference Manual (RM0033) about the NVIC >>> though at least I've now sussed out I need to read more of the >>> Cortex-M3 documents. >> >> Like Stephen said the NVIC is part of the CM3 core; you are supposed to >> read the ARM documentation for that. Although there are examples in the >> ST peripheral library. >> >>> Many thanks for the offer, I might yet pick your brains. >> >> Stephen posted a better answer than I would have (so good he posted it >> thrice :) ). >> >> I have not used the TC irq specifically yet, but not had any issues with >> interrupts generally. >> >> Have you got any interrupts working at all yet? >> >> Can you see the TC flag active in the SR? >> >> If so should be matter of setting the USART_CR1 TXEIE bit (bit 7) for >> the UART. >> >> Then you need to handle the TX interrupt and check the status register >> there to see what triggered it. >> >> If I get time I may change my debug uart to be interrupt driven, get it >> working properly. >> > > Many thank for the ideas. Interrupts are working well. > > I now have a problem with FreeRTOS: > > I fill a queue with 6 characters > Enable TCIE > In the interrupt routing I see 6 characters - great > Send 6 characters and when the queue is empty disable TCIE > I fill a queue with 6 characters > Enable TCIE > In the interrupt routing I now see 7 characters - not so great!! > > I'm left wondering if xQueueReceiveFromISR function corrupts pointers if > the queue is empty? >Queues are working fine. It was a character I added to the queue from another task. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
Reply by ●March 14, 20132013-03-14
On Wed, 13 Mar 2013 23:57:11 +0000, Mike Perkins <spam@spam.com> wrote:>I fill a queue with 6 characters >Enable TCIE >In the interrupt routing I see 6 characters - great >Send 6 characters and when the queue is empty disable TCIE >I fill a queue with 6 characters >Enable TCIEAssuming that you F2 device's USART is very similar to the F4 USART, I note that you are using the TC bit rather than TXE. TC means that the transmitter registers are completely done, and you can turn the line around, e.g. for half duplex busses. TXE means that the USART can take another character. In both cases disabling and enabling interrupts can lead to multiple interrupts that do not mean that you should send a character. You must check the queues inside the interrupt handlers. I would send you our ISRs, but I know nothing of FreeRTOS, write only minimal quantities of C, and program mostly in an unfashionable but productive language. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●March 14, 20132013-03-14
On 14/03/2013 11:40, Stephen Pelc wrote:> On Wed, 13 Mar 2013 23:57:11 +0000, Mike Perkins <spam@spam.com> > wrote: > >> I fill a queue with 6 characters Enable TCIE In the interrupt >> routing I see 6 characters - great Send 6 characters and when the >> queue is empty disable TCIE I fill a queue with 6 characters Enable >> TCIE > > Assuming that you F2 device's USART is very similar to the F4 USART, > I note that you are using the TC bit rather than TXE. TC means that > the transmitter registers are completely done, and you can turn the > line around, e.g. for half duplex busses. TXE means that the USART > can take another character.Well spotted. My post wasn't an accurate representation of the ISR. I first check for the TC flag, clear the flag and disable the interrupt. I don't really need to use this flag but thought I'd use it for completeness if I should want to extend to RS485 and disable the transmitter. I then check the TXE flag and send another character if there's one in the queue. If there is I place data in the DR register and enable the TCIE and TXEIE interrupt bit.> In both cases disabling and enabling interrupts can lead to multiple > interrupts that do not mean that you should send a character. You > must check the queues inside the interrupt handlers. > > I would send you our ISRs, but I know nothing of FreeRTOS, write only > minimal quantities of C, and program mostly in an unfashionable but > productive language. > > Stephen >FreeRTOS actually works quite well! I like the way you can setup tasks and has inbuilt queues. Also the way your own ISRs can place data onto a queue which a task can deal with later. I'm sure my C won't be much better! -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
