-
The problem with uC driving digital SMPS is that they need an ultrafast mechanism (faster than interrupts) to respond to spikes, shortcircuits etc.
You do need a hardware statemachine for that OR handle the error situations in additional hardware (extra cost).
Well, if the thing is a battery charger (the battery being permanently connected), and the supply is a well-behaved 24V SMPS itself, and assuming you put in proper protection for hot-plugging and so on - where will those spikes come from? I know that unexpected things can always happen in the real-world, but there is always a balance between keeping a circuit safe and paranoia.
I did a lot of simulations and so on, the biggest issues that suggested were ringing on startup, and variations in load and current. Particularly the charger needs *some* load to startup properly, but you don't want that to be the battery. So I decided on isolation FETs and a switchable resistive load that can be in circuit for long enough to get the charger up to the correct voltage. Maybe there are better ways of doing this, but this is the best I could come up with at the moment. Open to better ideas of course.
I think h/w protection for over-voltage makes sense, for the rest, the uC should be able to deal with it.
-
Hi guys!
This year in two courses of my University Degree we started using microcontrollers and the professor chose the PIC24FV16KM202: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM240013-2.
I think that they are quite easy to program with MPLAB X and it has loads of peripherals that are very user friendly. Of couse it also has its flaws. I've not mess with I2C or SPI yet.
Do you think that it is worth to switch to an ARM Cortex-M (STM, NXP, TI)? For what I've seen thet seem more confusing to program, but maybe that comes with my habit to the PIC24F.
I mostly do motor control and sensor interface with them. -
If your working on a project and your running out of reasources before feature creep sets in, its probably time to learn atleast a new more powerful flavour of what your used to, and grow from there.
e.g. try implementing a colour touchscreen on a atmel 328p, and you really cannot do anything for quite some time while it draws the screen, compare that to an arm which can DMA the screen from a memory in a much more reasonable time, with minimal input from the micro. -
You can try learn 7 architectures at the same time. For example 8051 + AVR8 + PIC8 + PIC16 + PIC32 + ARM Cortex-M + ARM7TDMI. Very quickly you are going to find patterns, getting very good at writing architecture-independent portable C code, appreciate stdint.h and start accumulate your own middleware.
With the architectures you have listed that is impossible. The 8051 and PIC8 don't work efficient with pointers so you need to adopt an entirely different (poorly maintainable) coding style to get some performance.
Yup. The 8051 and PIC8 are fine if all you're doing is replacing something that you *could* do with a bunch of gates, latches, shift registers etc -- hardware.
They are not at all good if you want to write *software*, especially using modern practices. Or even C.
The humble old ARM7TDMI is a fine target for C and C++ with full 32 bit variables and big address space. The AVR8 is pretty good too, if you don't need too much RAM and you're mostly using 8 or 16 bit variables. -
Hi guys!
This year in two courses of my University Degree we started using microcontrollers and the professor chose the PIC24FV16KM202: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM240013-2.
I think that they are quite easy to program with MPLAB X and it has loads of peripherals that are very user friendly. Of couse it also has its flaws. I've not mess with I2C or SPI yet.
It's when the device starts communicating with external peripherals that things get interesting. Asynchronous events (in the case of slave SPI) take a little more work to program. Typically it's a matter of grabbing the data during an interrupt and putting it in a queue. Newer ARM devices will have a DMA channel with queue capabilities.QuoteDo you think that it is worth to switch to an ARM Cortex-M (STM, NXP, TI)? For what I've seen thet seem more confusing to program, but maybe that comes with my habit to the PIC24F.
I mostly do motor control and sensor interface with them.
The ARM Cortex M4s, for example, are FAST! The STM32F407VG will run at 168 MHz, has 1MB of flash and 256 kB of RAM plus a WIDE range of peripherals. Yet it's a cheap device at $12 qty 1 and $8 at qty 1000. No, it's not a jellybean part like some of the PICs and AVRs but it is one heck of a uC.
I'm slowly coming up to speed with the STM32F4-Discovery board using ST's infrastructure (CubeMX). In some ways this increases the learning curve, in others ways, it gets results early. I'm still thinking about it. My 32k limit with the limited IAR toolchain is getting eaten up fast with all the code generated by CubeMX. I also have the Eclipse based toolchain when I run out of code space.
I like the mbed LPC1768 variant with the mbed online toolchain and libraries. The libraries provide just enough hand-holding without becoming obtrusive. I like the idea that I can just call up a library for Ethernet, write a bit of code for the top level and have a network connected uC with an hour's work. Maybe less now that I know how to do it.
If you decide to play with the STM32, buy the book:
https://leanpub.com/mastering-stm32
The author gets you started from the very bottom, installing the free Eclipse based toolchain. Just follow along and everything should work out well.
-
Thanks a lot!
This could be a nice project for next summer.
I was looking at the small Nucleo boards like the L432KC (low power) or the F303K8.. As they are cheap and look very capable!
That book seems to be very nice. -
Quote
There's no doubt that ARM and Cortex M/A is the present, and the near future ... but I think it's worth keeping an eye on RISC-V as it's getting quite a bit of support from big names as it moves out of academia into industry.
- free and open license-free instruction set, similar in spirit to an improved MIPS. Inherently supports 32, 64, or 128 bit implementations. All standard instructions are 32 bits long, with optional standard Thumb2-like extension with 16 bit instructions duplicating the most common 32 bit instructions (gives ~30% code size reduction). Instruction set is designed for customization with plenty of room for vendors to add 16 bit, 32 bit, or longer instructions.
- supported by gcc, binutils, glibc, newlib, linux kernel, qemu
- Berkeley university has released three free and open core designs, roughly at Cortex M0+ (Z-scale), Cortex A5/A53 (Rocket), and Cortex A15/A72 (BOOM) complexity/performance levels. In fact they are all implemented as core generators, rather than fixed cores, with many aspects configurable (and they all share much of the same definition code).
- anyone can use Berkeley's cores or core generators, customized or not, or design their own from-scratch cores. This is in contrast to ARM, where Apple, Samsung, Qualcomm and a handfull of others have paid big big bucks to ARM to be allowed to design their own cores, but everyone else has to use off-the-shelf cores that ARM designed.
- roughly 40 companies are known to be working on CPUs and SoCs using RISC-V.
- SiFive, a startup founded by Berkeley people who designed RISC-V, have a 32-bit no MMU no FP microcontroller SoC that runs anywhere between 16 and 320 MHz in production. At the moment you can only buy it on their "HiFive1" Arduino-compatable development board. Later this year they expect to have a linux-capable quad core 1.6 GHz SoC and dev board. Their main business plan is to design and fab custom SoCs. They say they can add your peripherals, special function units, custom instructions, and get you the first wafer of sample chips for typically under US$100k.
There's no doubt that ARM does a very good job, their standard cores are good and the license fees are not huge. Thee are, as you say, thousands of MCUs available using them. It's a different matter if you want to customize the CPU core or build your own. And their 64 bit offering is incompatible with 32 bit and has much bigger code size (no Thumb equivalent).
But worth keeping an eye on RISC-V.
Thanks for sharing the info
-
Quote
Do you think that it is worth to switch to an ARM Cortex-M (STM, NXP, TI)?
One doesn't "switch" - one ADDS a new chip to their knowledge base. That's always a good thing, IMO, assuming you have the time to do so.
A problem with ARM chips is that each vendor has their own peripherals, and a LOT of microcontroller programming is dealing with the peripherals, rather than with the CPU itself (especially so as you get into the more modern architectures.) So if you spend a bunch of time figuring out the Atmel SAM3X (CM3) USART peripheral, that will be next to useless when you have to program a TI Tiva USART, or even an Atmel SAMD SERCOM. Timers, USB, Ethernet, A2D are even more diverse...
You should definitely look at some 32bit microcontroller, anyway. The way they throw address space at problems is sort-of mind bogglingly different from microcontrollers with a more limited address spaces, and is "interesting." "bit banding: 16Mb of the address space is reserved for accessing 2Mb of memory/peripherals in an atomically bitwise fashion." "Fast peripheral bus: The XXX peripheral is available on the AHB bus at address 0xHHHHHHHH, and also on the FPB at address 0xABCD000, which is faster."
-
PSOC.
For me what stands out is -
1) Routability
2) Fast 12 bit SAR A/D and slow 20 bit DelSig
3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFB
can be used as a GP fast processor block, similar to RISC block
4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGA
like capability
5) Onboard Vref
6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....
7) LCD, COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB
9) Custom components capability, create with schematic capture or Verilog
10) DMA to offload processes like filters, COM, Display
11) ARM M0 (PSOC 4) or M3 (PSOC 5LP) or 8051 core(PSOC 3)
12) Extensive clock generation capabilities
13) All components supported by extensive prewritten APIs
15) PSOC 6 dual ARM core imminent.
https://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true
http://www.cypress.com/documentation/code-examples/psoc-345-code-examples
Great video library
Attached component list. A component is an on chip HW resource.
Free GUI design tool with schematic capture, "Creator". Components have rich API library attached
to each component. Compilers free as well.
PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as well
https://www.elektormagazine.com/labs/robot-build-with-cypress-psoc
http://www.cypress.com/products/32-bit-arm-cortex-m-psoc
Regards, Dana.
-
Quote from: technix
The 8051 and PIC8 don't work efficient with pointers
Pointers are an abomination that should not exist in a high level language.The 8051 and PIC8 are fine if all you're doing is replacing something that you *could* do with a bunch of gates, latches, shift registers etc -- hardware.
Yep. That is what micro controllers were invented to do.QuoteThey are not at all good if you want to write *software*, especially using modern practices. Or even C.
Yet probably over 90% of the 'software' written for them is in C, and people seem to be happy enough with the results despite it being 'not at all good'. Where they fall down is in limited memory (particularly RAM) and slow CPU speed, which limits their ability to run 'software' (ie. bloated 'modern' code that consists of layers of crap that tries to make it 'architecture-independent').
-
That still doesn't mean they aren't used under the hood. You can program without pointers in C++ but they will be used under the hood extensively.Quote from: technixThe 8051 and PIC8 don't work efficient with pointers
Pointers are an abomination that should not exist in a high level language. -
I thought I'd refresh my memory about the OP:
But recently I got interested in an ARM STM32 for design I am working on, and decided it was worth picking up a cheap dev board and dipping a toe in. The spur was really some advanced features they have for PWM control (which I learnt of here) and the fact that someone I know and respect uses them a lot on his products.
It's not clear if the project can even be accomplished on an 8-bit microcontroller since the OP's looking at the STM32 line.
It probably *could* but getting a bit towards the stress point. I made a proto buck regulator with a combination of stripboard and and old PIC dev USB board which has an 8 bit PIC on it. Worked fine, there is a PWM output with deadband control that I could use to create a synchronous rectifier. I didn't get as far as monitoring op voltage/current and doing the feedback side, but i think it should have been OK. The issue thoigh was resolution - the PWM o/p was a bit lacking in bits.
...
Can the STM32 do PWM with sufficient flexibility for deadtime | shoot-through handling?
I am interested in a similar project. But I look at the STM32 PWM register setup examples and they appear quite complicated - albeit I've only played with basic blinky examples with a discovery board. If I wanted to also have inverted outputs - for high and low side mosfets, then I think that would require two timers and need synchronization. That becomes more complicated when there's a fedback loop controlling the PWM for both timers.
I keep think thinking that would be much simpler with an fpga, with the PWM generation defined in software (Verilog).
It would be interesting to know - if anyone has better insight or a different experience. -
There are also "special purpose" MCUs like some of the C2000 or DSPIC series that are specifically intended for motor control, digital switching power control, and safety certified applications that presumably have some architectural and firmware / library / toolchain features intended to ease concern about such uses that could cause system hardware failure / other problem due to a firmware bug or lack of control.
These architectures are much simpler to analyze w.r.t WCET, which is required for schedulability analysis. Safety critical systems require the paper work to proof a system is reliable by design, specifying that all deadlines are always met (for example Liu&Layland bound or response time analysis).
If you compare e.g. dsPIC to a cortex m0+, then you'll find that the cortex m0+ is overloaded with features that complicates formal analysis, like multi-stage pipelines, FLASH accelerators, DMA, nested interrupts, etc.
I've no doubt a quick cortex m4 has the capability to do motor control, but if it is hard to certify for safety/critical operation due to architecture it's probably skipped. Basically similar story as the FPGA's. -
Basically similar story as the FPGA's.
Is that true when the vendor toolchain will provide a timing analysis and max-clock speed that the fpga can be run with correct signal propagation? -
You can perform post-simulation after routing, which should behave very close to the real device. For example create a testbench that verifies the structural design against the post-simulation design. Both should behave identically, at e.g. the rising edge of clock.
Timing analysis in the world of FPGA's is about setup/hold times. This is pretty much an automated process, requiring human intervention when set constraints cannot be met.
Timing analysis like I mentioned on MCU's is about multitasking, where you want a schedulability analysis of all tasks that are hard real-time, but perhaps also do overload analysis etc.
There are still opportunities to make lots of mistakes in FPGA's, like create a latch, or incorrectly translate designs between behavioural and structural models. But alot of these errors can be caught in functional simulation without even requiring synthesis.