Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
cheap USB-capable MCUs: ARM 32 or AVR 8?
330 views
Skip to first unread message
Ivan Shmakov
Apr 30, 2013, 1:37:51 PM4/30/13
to
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.
--
FSF associate member #7257
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.
--
FSF associate member #7257
Rich Webb
Apr 30, 2013, 9:20:34 PM4/30/13
to
On Tue, 30 Apr 2013 17:37:51 +0000, Ivan Shmakov <onei...@gmail.com>
wrote:
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.,
<http://www.eevblog.com/2011/07/18/eevblog-186-soldering-tutorial-part-3-surface-mount/>
Also, search around in your junk pile for discards that have fine
pitch QFPs that you can practice on.
wrote:
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.,
<http://www.eevblog.com/2011/07/18/eevblog-186-soldering-tutorial-part-3-surface-mount/>
Also, search around in your junk pile for discards that have fine
pitch QFPs that you can practice on.
Ivan Shmakov
May 1, 2013, 6:33:41 AM5/1/13
to
>>>>> Rich Webb <web...@example.net> writes:
[...]
>> 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;
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)?
> access to the toolchains;
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?
> access to the device programmers/JTAG;
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] http://elua-development.2368040.n2.nabble.com/STM32-Bootloader-Flashing-in-Python-td2499766.html
> hobby or GPL or commercial/proprietary.
? 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.
> 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.,
> <http://www.eevblog.com/2011/07/18/eevblog-186-soldering-tutorial-part-3-surface-mount/>
> Also, search around in your junk pile for discards that have fine
> pitch QFPs that you can practice on.
ACK, thanks!
>>>>> On Tue, 30 Apr 2013 17:37:51 +0000, Ivan Shmakov wrote:
>> 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.
(Actually, it's a factor slightly below 2.5, not 3.)
>> 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.
[...]
>> 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;
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)?
> access to the toolchains;
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?
> access to the device programmers/JTAG;
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] http://elua-development.2368040.n2.nabble.com/STM32-Bootloader-Flashing-in-Python-td2499766.html
> hobby or GPL or commercial/proprietary.
"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.
> 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.,
> <http://www.eevblog.com/2011/07/18/eevblog-186-soldering-tutorial-part-3-surface-mount/>
> Also, search around in your junk pile for discards that have fine
> pitch QFPs that you can practice on.
David Brown
May 1, 2013, 10:15:48 AM5/1/13
to
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.)
>
> > access to the device programmers/JTAG;
>
> 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] http://elua-development.2368040.n2.nabble.com/STM32-Bootloader-Flashing-in-Python-td2499766.html
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.
>
> > hobby or GPL or commercial/proprietary.
>
> ? 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.
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.
John Devereux
May 1, 2013, 10:25:53 AM5/1/13
to
Ivan Shmakov <onei...@gmail.com> writes:
>>>>>> Rich Webb <web...@example.net> writes:
>>>>>> On Tue, 30 Apr 2013 17:37:51 +0000, Ivan Shmakov wrote:
>
> >> 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.
>
> (Actually, it's a factor slightly below 2.5, not 3.)
>
> [...]
>
> >> 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;
>
> 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)?
I think that's it. For some applications you don't need the crystal, but
>>>>>> Rich Webb <web...@example.net> writes:
>>>>>> On Tue, 30 Apr 2013 17:37:51 +0000, Ivan Shmakov wrote:
>
> >> 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.
>
> (Actually, it's a factor slightly below 2.5, not 3.)
>
> [...]
>
> >> 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;
>
> 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)?
for USB you will want it.
>
> > access to the toolchains;
>
> 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?
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:
<https://launchpad.net/gcc-arm-embedded>
This has a modified newlib that e.g. allows printf to be tuned for size.
>
> > access to the device programmers/JTAG;
>
> 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.)
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.
> [1] http://elua-development.2368040.n2.nabble.com/STM32-Bootloader-Flashing-in-Python-td2499766.html
>
> > hobby or GPL or commercial/proprietary.
>
> ? 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.
>
> > 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.,
> > <http://www.eevblog.com/2011/07/18/eevblog-186-soldering-tutorial-part-3-surface-mount/>
> > Also, search around in your junk pile for discards that have fine
> > pitch QFPs that you can practice on.
>
> ACK, thanks!
--
Rich Webb
May 1, 2013, 11:54:04 AM5/1/13
to
<http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF257525>
>
>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.
supported in the low-cost category. Sparkfun is just one of many
sources: <https://www.sparkfun.com/products/7834>
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.
cuby....@googlemail.com
May 1, 2013, 5:12:59 PM5/1/13
to
Am Dienstag, 30. April 2013 19:37:51 UTC+2 schrieb Ivan Shmakov:
> 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.
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.
> 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.
-- Michael
Ivan Shmakov
May 4, 2013, 1:30:50 PM5/4/13
to
>>>>> John Devereux <jo...@devereux.me.uk> writes:
>>>>> Ivan Shmakov <onei...@gmail.com> writes:
[...]
>> 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)?
> I think that's it. For some applications you don't need the crystal,
> but for USB you will want it.
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] http://yourportablelab.com/downloads/schematics/STM32F103RBT6mini.pdf
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?)
[...]
>> 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?
> 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:
> <https://launchpad.net/gcc-arm-embedded>
> This has a modified newlib that e. g. allows printf to be tuned for
> size.
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] http://www.triplespark.net/elec/pdev/arm/stm32.html
[3] http://libopencm3.github.io/docs/latest/stm32f1/html/group__gpio__file.htm
[...]
>> 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.)
> 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.
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.
> I use openocd which plays well with gdb (the debugger from the GNU
> toolchain). The STM32 parts are very well supported in openocd.
ACK, thanks!
[...]
--
FSF associate member #7257 np. Mi memoras -- Kajto
>>>>> Ivan Shmakov <onei...@gmail.com> writes:
[...]
>> 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)?
> I think that's it. For some applications you don't need the crystal,
> but for USB you will want it.
(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] http://yourportablelab.com/downloads/schematics/STM32F103RBT6mini.pdf
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?)
[...]
>> 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?
> 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:
> <https://launchpad.net/gcc-arm-embedded>
> size.
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] http://www.triplespark.net/elec/pdev/arm/stm32.html
[3] http://libopencm3.github.io/docs/latest/stm32f1/html/group__gpio__file.htm
[...]
>> 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.)
> 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 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.
> I use openocd which plays well with gdb (the debugger from the GNU
> toolchain). The STM32 parts are very well supported in openocd.
[...]
--
FSF associate member #7257 np. Mi memoras -- Kajto
Rich Webb
May 4, 2013, 5:34:08 PM5/4/13
to
On Sat, 04 May 2013 17:30:50 +0000, Ivan Shmakov <onei...@gmail.com>
wrote:
> 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?
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.
wrote:
> 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?
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.
John Devereux
May 5, 2013, 3:43:27 AM5/5/13
to
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).
> (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?)
JTAG). So JTDI is an input.
> [...]
>
> >> 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?
>
> > 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:
>
> > <https://launchpad.net/gcc-arm-embedded>
>
> > This has a modified newlib that e. g. allows printf to be tuned for
> > size.
>
> 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.
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 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] http://www.triplespark.net/elec/pdev/arm/stm32.html
> [3] http://libopencm3.github.io/docs/latest/stm32f1/html/group__gpio__file.htm
>
> [...]
>
> >> 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.)
>
> > 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.
>
> 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.
I suggest the ST "discovery" series of evaluation boards. They are low
> 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] http://www.triplespark.net/elec/pdev/arm/stm32.html
> [3] http://libopencm3.github.io/docs/latest/stm32f1/html/group__gpio__file.htm
>
> [...]
>
> >> 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.)
>
> > 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.
>
> 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.
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.
<http://www.digikey.co.uk/scripts/dksearch/dksus.dll?vendor=0&keywords=stm32f1+discovery>
And a working STM32F1 you can compare your circuit with :)
> > I use openocd which plays well with gdb (the debugger from the GNU
> > toolchain). The STM32 parts are very well supported in openocd.
>
> ACK, thanks!
>
> [...]
--
Ivan Shmakov
May 5, 2013, 1:59:27 PM5/5/13
to
>>>>> Rich Webb <web...@example.net> writes:
>>>>> Ivan Shmakov <onei...@gmail.com> wrote:
>> 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.
[...]
>>>>> Ivan Shmakov <onei...@gmail.com> wrote:
>> 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.
> 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.
do not need a crystal at this point?
> 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.
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.
[1] http://elua-development.2368040.n2.nabble.com/STM32-Bootloader-Flashing-in-Python-td2499766.html
Rich Webb
May 5, 2013, 2:24:31 PM5/5/13
to
On Sun, 05 May 2013 17:59:27 +0000, Ivan Shmakov <onei...@gmail.com>
wrote:
>>>>>> Rich Webb <web...@example.net> writes:
>>>>>> Ivan Shmakov <onei...@gmail.com> wrote:
>
> >> 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.
>
>[...]
>
> > 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.
>
> Looks sensible, thanks. Do I understand it correctly that I
> do not need a crystal at this point?
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."
wrote:
>>>>>> Rich Webb <web...@example.net> writes:
>>>>>> Ivan Shmakov <onei...@gmail.com> wrote:
>
> >> 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.
>
>[...]
>
> > 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.
>
> Looks sensible, thanks. Do I understand it correctly that I
> do not need a crystal at this point?
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."
Ivan Shmakov
May 12, 2013, 4:43:58 PM5/12/13
to
>>>>> Rich Webb <web...@example.net> writes:
response octets >= 0x80.)
[...]
> 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.
... 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 <module>
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.)
>>>>> On Sat, 04 May 2013 17:30:50 +0000, Ivan Shmakov wrote:
>> 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?
> 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 guess that should be 8-E-1, as there're both request and
>> 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?
> 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).
response octets >= 0x80.)
[...]
> 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.
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 <module>
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.)
Rich Webb
May 12, 2013, 6:26:06 PM5/12/13
to
On Sun, 12 May 2013 20:43:58 +0000, Ivan Shmakov <onei...@gmail.com>
wrote:
>>>>>> Rich Webb <web...@example.net> writes:
>>>>>> On Sat, 04 May 2013 17:30:50 +0000, Ivan Shmakov wrote:
>
> >> 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?
>
> > 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 guess that should be 8-E-1, as there're both request and
> response octets >= 0x80.)
Yep, my bad. Should be 8-E-1 as you noted.
> > 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.
>
> ... 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":
>
[snippety snip]
wrote:
>>>>>> Rich Webb <web...@example.net> writes:
>>>>>> On Sat, 04 May 2013 17:30:50 +0000, Ivan Shmakov wrote:
>
> >> 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?
>
> > 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 guess that should be 8-E-1, as there're both request and
> response octets >= 0x80.)
> > 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.
>
> ... 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":
>
> ... But this one should be much easier for me to fix. (Even
> though I'm not a Python expert or something.)
Nevertheless, progress!
> though I'm not a Python expert or something.)
Ivan Shmakov
May 14, 2013, 3:00:21 PM5/14/13
to
>>>>> Rich Webb <web...@example.net> writes:
>>>>> On Sun, 12 May 2013 20:43:58 +0000, Ivan Shmakov wrote:
[Cross-posting to news:comp.sys.arm, just in case.]
[...]
>> ... 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":
I've now posted both the example code [1] I've tried and a patch
[2] I've used to fix the issue above.
[1] news:87ip2ll...@violet.siamics.net
[2] news:874ne7m...@violet.siamics.net
http://ftp.funet.fi/index/archive/alt.sources/2779.gz
In order to build the example, I've had to use an LD script,
like:
MEMORY {
rom (rx) : ORIGIN = 0x08000000, LENGTH = 64K
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}
INCLUDE libopencm3_stm32f1.ld
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.
TIA.
>>>>> On Sun, 12 May 2013 20:43:58 +0000, Ivan Shmakov wrote:
[Cross-posting to news:comp.sys.arm, just in case.]
[...]
>> ... 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":
>> ... But this one should be much easier for me to fix. (Even though
>> I'm not a Python expert or something.)
> Nevertheless, progress!
Indeed.
>> I'm not a Python expert or something.)
> Nevertheless, progress!
I've now posted both the example code [1] I've tried and a patch
[2] I've used to fix the issue above.
[1] news:87ip2ll...@violet.siamics.net
[2] news:874ne7m...@violet.siamics.net
http://ftp.funet.fi/index/archive/alt.sources/2779.gz
In order to build the example, I've had to use an LD script,
like:
MEMORY {
rom (rx) : ORIGIN = 0x08000000, LENGTH = 64K
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}
INCLUDE libopencm3_stm32f1.ld
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.
TIA.
Christopher Head
May 17, 2013, 3:16:49 AM5/17/13
to
On Tue, 14 May 2013 19:00:21 +0000
Ivan Shmakov <onei...@gmail.com> wrote:
> 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?
Easy: install avr-binutils and check out the list of files it installs.
Ivan Shmakov <onei...@gmail.com> wrote:
> 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?
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.
Chris
Tauno Voipio
May 17, 2013, 4:22:45 AM5/17/13
to
in most ARMs, the address space layout is set by the board
design around the chip.
The number of different AVR chips is quite limited, but there
are countless different ARM board designs.
--
Tauno Voipio
Ivan Shmakov
May 17, 2013, 12:03:41 PM5/17/13
to
>>>>> Christopher Head <ch...@is.invalid> writes:
> 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.
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.)
>>>>> On Tue, 14 May 2013 19:00:21 +0000 Ivan Shmakov wrote:
>> MEMORY {
>> rom (rx) : ORIGIN = 0x08000000, LENGTH = 64K
>> ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
>> }
>> MEMORY {
>> rom (rx) : ORIGIN = 0x08000000, LENGTH = 64K
>> ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
>> }
>> 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?
> Easy: install avr-binutils and check out the list of files it
> installs.
ACK, thanks; I've missed that Binutils has some, indeed.
>> AVR 8-bit MCUs, all such values are already known by the toolchain?
> 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.
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.)
Bill Giovino
Jun 11, 2013, 3:49:29 PM6/11/13
to
How about a PIC with USB?
http://microcontroller.com/news/Microchip_PIC16F145X_PIC18F97J94.asp
Very cheap, a full family of products. An open-source USB framework is available for download.
http://microcontroller.com/news/Microchip_PIC16F145X_PIC18F97J94.asp
Very cheap, a full family of products. An open-source USB framework is available for download.
j.m.gr...@gmail.com
Jun 11, 2013, 4:09:22 PM6/11/13
to
On Wednesday, May 1, 2013 5:37:51 AM UTC+12, Ivan Shmakov wrote:
> 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.
>
> 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.
>
> For as it seems, the ARM 32 MCU has a clear advantage over the
> AVR 8 one.
Beware the loss-leader. It seems that price did not last long at all ?
> AVR 8 one.
Best I can find STM32F103C8T6 now for
100 : $3.1232, most show 100: $4.22
So you then compare that with ATXMEGA16A4U 100: $1.62
-jg
toto
Jun 12, 2013, 2:43:31 AM6/12/13
to
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KL2&nodeId=01624698C9E3EC#
0 new messages