In the price listings that I have at hand, it seems that an USB-capable ("device" mode only needed) ATmega32U4 may cost roughly thrice the cost of a similarly USB-capable ST32F103C8T6 (at 1.65 USD a piece), at least in the 10 .. 100 pcs. range.
Naturally, the latter has a whole lot of other advantages, such as larger memory (both Flash and SRAM), 3 USARTs (vs. the only one on ATmega32U4; and I may indeed need a couple), the same -40 .. +85 d. C. temperature range (the device being designed is intended for outdoor use), etc.
I'm somewhat uncertain about the power consumption, and I'm not all that skilled at soldering LQFP cases (I'm going to build the prototypes by hand), but I wonder, what else I could be missing? For as it seems, the ARM 32 MCU has a clear advantage over the AVR 8 one.
Issues to consider: past familiarity with the device family; access to the toolchains; access to the device programmers/JTAG; hobby or GPL or commercial/proprietary. All things being equal, I'd go with the ARM.
0.5 mm pitch LQFP is not all that hard to solder. You'll really want a good magnifier to inspect for solder bridges, though. Look over at David L. Jones' eevblog for some enthusiastic videos. E.g., Also, search around in your junk pile for discards that have fine pitch QFPs that you can practice on.
(Actually, it's a factor slightly below 2.5, not 3.)
[...]
Alas, there's none. They say it never is too late to learn, however.
The question at hand: what'd be the minimum wiring for ST32F103C8T6? I guess that one has to connect the power, the crystal, NRST, BOOT0, BOOT1, and most likely TxD and RxD of one of the UARTs. Is there anything else I should consider (besides of the "payload" itself)?
Do I understand it correctly that a GCC cross-compiler, along with the usual GNU Binutils, etc., will be a fit? (FWIW, I'm quite familiar with the GNU toolchain per se.) Is there any free software C library to consider?
As per the datasheet, it seems to be possible to program the MCU over UART via the built-in bootloader. What software do I use to interact with the latter on the host side? So far, I've found only [1] (and yet to check if it actually works.)
[1]
formatting link
? I guess that this particular design may indeed achieve the "commercial" status, still I see nothing wrong with making the sources available to the customers. Thus, there ought to be no problem with the use of any copylefted code, whether released under GNU GPL or not.
For both the AVR and ARMs, gcc is a very solid toolchain and is supported by the manufacturers. These days you have to have a particularly good reason to choose anything other than gcc for the compiler (though there are a number of possible good reasons). So when you are starting from scratch, use gcc for either AVRs or ARM Cortex devices.
Ready-build gcc toolchains always come with a suitable library. For free toolchains, the library is also free (obviously). You can also buy commercial gcc toolchains for the Cortex M's from several sources - sometimes the library you get then is enhanced or specialised in some way. They also vary in how nice and user-friendly their IDE's are for supporting particular manufacturer's devices. (For the AVR, you get gcc along with AVR Studio for Windows, or as a stand-alone toolchain for Linux.)
formatting link
Get a JTAG debugger - bootloaders are useful for production and for upgrades, but limited for development. For the ARMs, you can get everything from top-range, massively expensive debuggers to devices that are little more than an FTDI2232D and a couple of connectors. Certainly $50 will get you a usable tool along with OpenOCD.
Remember that the license for the toolchain (GPL for gcc) has no influence on what sort of license you use on /your/ code. gcc is immensely popular for embedded development, but very little of the resulting code is released in any kind of source. The libraries normally used with gcc also have licenses allowing unrestricted use.
It's a different matter if you use example code or third-party libraries on the target - if that code is GPL'ed then you have to release your source code.
I think that's it. For some applications you don't need the crystal, but for USB you will want it.
Most of the gcc distributions come with newlib. You can in fact build gcc to run without it (and then you are missing the standard C library functions, but in my experience you can write the few you use yourself and get a much smaller executable).
There is now a distribution directly supported by ARM:
This has a modified newlib that e.g. allows printf to be tuned for size.
You could consider using SWD instead of, or as well as, the bootloader for debug access. In which case you would have a JTAG connector.
I use openocd which plays well with gdb (the debugger from the GNU toolchain). The STM32 parts are very well supported in openocd.
There's also the ST-supported bootloader (Windows) at
The Olimex USB JTAG device is probably the most widely used and supported in the low-cost category. Sparkfun is just one of many sources:
The OpenOCD source builds with minimal pain on Windows using msys/MinGW (there were a few "long longs" in a logging macro that needed to be tamed) and it talks to the Olimex JTAG.
Am Dienstag, 30. April 2013 19:37:51 UTC+2 schrieb Ivan Shmakov:
One alternative that may be interesting is Microchip's PIC32 series (based on a MIPS M4k 32bit core). The PIC32MX210F016B (16 kB Flash, 4 kB SRAM) is available in PDIP 28 and supports USB OTG. Pricing should be around US$2 for 100 pcs.
ACK, thanks. I have now soldered the MCU to a prototyping board (thus "turning" the LQFP-48 case at hand into a makeshift DIP-48 one, suitable for breadboarding, etc.)
Following [1] as an example, I've wired all the Vdd-{1,2,3} pins together, as well as Vss-{1,2,3,A}, and also built an NRST circuit as depicted there. I've also connected BOOT0 (pin 44) and BOOT1 (pin 20), via 10 k resistors, to the Power and Ground rails, respectively. (I've omitted a crystal for now.)
[1]
formatting link
Applying 3.3 V power, however, I find that nearly all the digital I/O pins are tri-stated, /including/ USART1's TxD, which, I assume, should've been configured as output by the bootloader. (Similarly, I'd assume that BOOT1 (pin 20) would've been configured for input, but it doesn't seem to be the case, either.) Any ideas on what I might have got wrong?
(Naturally, I've checked for extra or missing connections a few times, and believe I've fixed them all before applying power.)
The JTAG's JTMS/SWDIO (34) and JNTRST (40) pins seem to be pulled up, however, and JTDI (38) seem to be set up as output. (Do I understand it correctly that the JTAG pin names are relative to the adapter's side, not MCU's side, BTW?)
[...]
ACK, thanks.
I have now built Binutils 2.23.2, GCC 4.8.0, Newlib 2.0.0; as well as libopencm3 (as of af985213), which seems to be a crucial part when it comes to the access to peripherals.
I was able to compile a simplistic example (mostly following [2], yet adding a few calls from [3]), but due to the above I'm yet to see if it actually works.
[2]
formatting link
[3]
formatting link
[...]
Indeed, I've already ordered a JTAG adapter (dubbed J-Link v9; I don't know much more about it, just that it cost me some 10 USD or so), but the parcel seem to have been stuck at the country's border since 11th of April.
So, unless there's an easy way "DIY" one myself, I'd probably have to wait for some more time.
ACK, thanks!
[...]
--
FSF associate member #7257 np. Mi memoras -- Kajto
After a bit of experimentation with a dev board, it looks like TxD stays high impedance until the bootloader gets a valid sync byte (0x7F, 7-E-1, autobaud). I'd guess that this is done using the timer capture pin that's shared with USART1 RX. Once the sync byte is detected, the USART peripheral is initialized and 0x79 is sent as an ack at the set baud.
So, I wouldn't assume that you've done something wrong unless you can't get the ST serial bootloader to connect to the chip.
Looks like Rich Webb has already investigated, and this may be normal behaviour. I have only used the F2 series, and never the bootloader.
It is generally normal that I/Os default to tristate/inputs, with a few exceptions possibly (for JTAG).
I think it is relative to the CPU (see reference manual section on JTAG). So JTDI is an input.
There is the library provided by ST, but I have never used it due to extreme ugliness and verbosity. Perhaps it's fine, but I did not like the look of it :)
Up till now I have rolled my own, usually I find once the registers are setup correctly everything just sort of works by itself. So the ADC library might allow 200 different operation modes, with routines to initialise, de-initialise, query each one. But I know which mode I need, and I just write to a few registers after reset and its done. To actually use any of the perhipherals you need to refer to the manual anyway, and the register definitions are right there...
But the libopencm3 looks nice.
I suggest the ST "discovery" series of evaluation boards. They are low cost, in the $10 range I think. And they come with an integrated SWD module which is directly supported by openocd and can be used with external parts as well as the on-board device that the eval board is actually for. So you get a general purpose supported USB to SWD JTAG debugger.
And a working STM32F1 you can compare your circuit with :)
Looks sensible, thanks. Do I understand it correctly that I do not need a crystal at this point?
Alas, and indeed, I can't. I use the bootloader interaction script from [1], and it doesn't seem to be able to get the MCU to respond. And neither the bootloader seem to respond when I send \x7F (either 7E1 or 8N1) directly. (2400, 9600, 19200, 115200 baud rates tried.)
It remains a possibility that both of my adapters (a USB Serial one, based on PL-2303HX, and a MAX3232-based RS-232 TTL transceivers) are to blame -- I've seen them behaving a bit odd in other cases. (Although I was able to successfully use them to interact with an Optiboot AVR bootloader.)
I guess I'd have to wait for the JTAG adapter to arrive.
Correct. From AN2606 "The system clock is derived from the embedded internal high-speed RC, no external quartz is required for the bootloader code."
Also, it looks like it's the Systick timer and not a capture pin that is used when looking at the sync pattern: "The duration of this data frame is measured using the Systick timer. The count value of the timer is then used to calculate the corresponding baud rate factor with respect to the current system clock."
(I guess that should be 8-E-1, as there're both request and response octets >= 0x80.)
[...]
... And the thing I've actually done wrong was that I forgot to connect VDDA. (Somehow, I've missed the power supply scheme shown in the datasheet.) Now that I've fixed that, I'm able to connect to the bootloader.
As of yet, however, the interface script I use fails as follows when I try a customary "read-only test":
$ python elua-development.2368040.n2.nabble.com/attachment/2499766/0/stm32loader.py \ -l 65536 -b 115200 -r -p /dev/ttyUSB0 \ "$(mktemp -- tmp/bin.XXXXXXXX)" Bootloader version 22 Chip id `['0x4', '0x10']' Read 256 bytes at 0x8000000 ... Read 256 bytes at 0x800FF00 Traceback (most recent call last): File "elua-development.2368040.n2.nabble.com/attachment/2499766/0/stm32loader.py", line 391, in file(args[0], 'wb').write(rdata) TypeError: must be string or buffer, not list $
... But this one should be much easier for me to fix. (Even though I'm not a Python expert or something.)
Which makes me curious: how is it that when building code for the AVR 8-bit MCUs, all such values are already known by the toolchain?
Also, the code as of now executes an otherwise empty loop, toggling PB0 every 2 ^20 iterations (thus roughly 1 Hz or so.) I'm yet to find a good example on using a timer and entering a sleep mode, so that I could avoid wasting the cycles.
Easy: install avr-binutils and check out the list of files it installs. There?s a giant pile of linker scripts shipped with it. I suspect the reason arm-binutils doesn?t include same is that there are so many different vendors shipping ARM MCUs, whereas AVRs are made by only Atmel.
ACK, thanks; I've missed that Binutils has some, indeed.
To note, however, is that the Binutils' LD scripts seem to be per-family, and not per-MCU. Consider, e. g.: avr31.xr, avr51.xn, avrtiny10.xr, avrtiny10.xu, avrxmega4.x, avrxmega5.xn, avrxmega7.xbn. And there actually /is/ a comparable pile of LD scripts in the Libopencm3 distribution (e. g.: libopencm3_efm32tg.ld, libopencm3_lpc13xx.ld, libopencm3_lpc43xx.ld, libopencm3_stm32f1.ld; the last one being the one I've referenced in the trivial LD script of mine .)
Still, neither for AVR, nor for ARM, could I find the precise sizes of the respective memories (Flash, SRAM) in these scripts. (Which kind of suggests that those are specified separately.)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.