tirsdag den 4. september 2018 kl. 03.41.55 UTC+2 skrev k...@notreal.com:> On Mon, 3 Sep 2018 18:35:00 -0700 (PDT), Lasse Langwadt Christensen > <langwadt@fonz.dk> wrote: > > >tirsdag den 4. september 2018 kl. 03.31.47 UTC+2 skrev k...@notreal.com: > >> On Mon, 3 Sep 2018 13:25:05 -0400, Phil Hobbs > >> <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> > >> >LPC804: 15 MHz Cortex M0+, 32kB flash, 4k RAM, 12-bit 2 us ADC with 1 > >> >LSB DNL, 10-bit DAC, the usual serial stuff, 20-TSSOP: 67 cents in > >> >reels, dev board $27. > >> > >> <https://www.digikey.com/product-detail/en/stmicroelectronics/STM32F030F4P6TR/497-17333-2-ND/4755941> > >> > >> $0.55 > > > >that only has half the flash > > How much is needed? Let me guess. You're a programmer? ;-)not really, though I do occasionally program ;) it was more comparing apples to apples, the STM with the same size flash cost the same as the LPC
Nice MCU for small jobs
Started by ●September 3, 2018
Reply by ●September 3, 20182018-09-03
Reply by ●September 3, 20182018-09-03
On Mon, 3 Sep 2018 19:00:03 -0700 (PDT), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:>tirsdag den 4. september 2018 kl. 03.41.55 UTC+2 skrev k...@notreal.com: >> On Mon, 3 Sep 2018 18:35:00 -0700 (PDT), Lasse Langwadt Christensen >> <langwadt@fonz.dk> wrote: >> >> >tirsdag den 4. september 2018 kl. 03.31.47 UTC+2 skrev k...@notreal.com: >> >> On Mon, 3 Sep 2018 13:25:05 -0400, Phil Hobbs >> >> <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >> >> >> >LPC804: 15 MHz Cortex M0+, 32kB flash, 4k RAM, 12-bit 2 us ADC with 1 >> >> >LSB DNL, 10-bit DAC, the usual serial stuff, 20-TSSOP: 67 cents in >> >> >reels, dev board $27. >> >> >> >> <https://www.digikey.com/product-detail/en/stmicroelectronics/STM32F030F4P6TR/497-17333-2-ND/4755941> >> >> >> >> $0.55 >> > >> >that only has half the flash >> >> How much is needed? Let me guess. You're a programmer? ;-) > >not really, though I do occasionally program ;) > >it was more comparing apples to apples, the STM with the same size flash >cost the same as the LPCST gives the choice. The smarter you are, the more you make. Besides, how much abstraction can you stuff into 20 pins? ;-)
Reply by ●September 4, 20182018-09-04
pcdhobbs@gmail.com wrote:>>ARM is ARM, just use GCC > > Sure, unless you need any peripherals or documentation. ;)And what is the problem with peripherals in GCC? And how a compiler is related to documentation? --- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
Reply by ●September 4, 20182018-09-04
bitrex wrote:> Ok great as it seems they want one to pay some fee to enable > C++/unlimited binary size in their bespoke IDE which is silly-talk.Microchip style. Same diagnosis here. There are just too many alternatives without the silly limitations to waste one's life on something like that. Best regards, Piotr
Reply by ●September 4, 20182018-09-04
On 04/09/18 01:53, bitrex wrote:> On 09/03/2018 07:19 PM, pcdhobbs@gmail.com wrote: >> >>> Phil, >>> What is your preferred development software and debug environment? >>> John >> >> We really like the Code Red tool chain and the LPCXpresso dev boards. >> Makes it super easy to get stuff working in a hurry. >> >> We'll try out the ex-Freescale Kinetis parts soon, just to see if >> their price/performance is enougb better to worry about. >> >> The LPC M4s are cheaper than their M3s, and have more interesting >> package options >> >> Cheers >> >> Phil Hobbs >> > > One of the most useful tools imaginable for embedded development is > Compiler Explorer which lets you look at a selected compiler's ASM > output in real-time for your chosen build flags, which unfortunately > wouldn't be possible with that toolchain as it seems they use a > proprietary fork of GCC. :(Code Red does not use a proprietary fork of gcc. They used to have their own builds (based on the Code Sourcery builds, IIRC), but I believe they have switched to the standard GNU ARM Embedded packages like most other ARM gcc suppliers. They have their own proprietary library, however, as well as Eclipse plugins. NXP bought Code Red not long ago, and I think their stuff is now integrated in the standard NXP development tools (which also support the Kinetis).
Reply by ●September 4, 20182018-09-04
On 04/09/18 01:46, bitrex wrote:> On 09/03/2018 05:31 PM, Lasse Langwadt Christensen wrote: >> mandag den 3. september 2018 kl. 19.25.06 UTC+2 skrev Phil Hobbs: >>> LPC804: 15 MHz Cortex M0+, 32kB flash, 4k RAM, 12-bit 2 us ADC with 1 >>> LSB DNL, 10-bit DAC, the usual serial stuff, 20-TSSOP: 67 cents in >>> reels, dev board $27. >> >> STM has a similar cortex-m0 that does 48MHz for the same price at digikey >> >> the dev board with debugger is something like ~$10 >> >>> We're using it for a super-quiet diode laser controller where it will >>> run the temperature control and automatic power control loops. I'll >>> never use another ATmega. ;) >> >> indeed, about the only reason to use an AVR is if you absolutely must >> have 5V >> cortex is faster and cheaper with more memory >> >> > > the question I'm unsure of is whether you can use those NXP ARMs with > the toolchain of your choice or if they lock you in to their > LXCNEXpressor C-only/128k limit toolchain (for the free version) somehow. >Those days are long gone.
Reply by ●September 4, 20182018-09-04
On 04/09/18 02:36, pcdhobbs@gmail.com wrote:>> the question I'm unsure of is whether you can use those NXP ARMs >> with the toolchain of your choice or if they lock you in to their >> LXCNEXpressor C-only/128k limit toolchain (for the free version) >> somehow > > The Code Red tools are modern C++ (g++) and are free up to 256k.IIRC > the full version is another $256, gasp. >NXP owns Code Red, and their current tools - MCUXpresso - are fully free, with no limitations, and use the standard GNU ARM Embedded toolchain. You can also happily use any other version of gcc - including newer versions of GNU ARM Embedded - with the tools. NXP continues to supply legacy tools that they have picked up along the way - standard Code Red, LXCNEXpressor, Code Warrior (from Freescale) - because there are customers who want to buy new copies of the old tools for consistency. And they continue to charge, because some companies feel happier when they are paying money for the tools.> NXP supplies sample code for Keil and IAR as well. > > Cheers > > Phil Hobbs >
Reply by ●September 4, 20182018-09-04
On 04/09/18 03:57, bitrex wrote:> On 09/03/2018 09:32 PM, Lasse Langwadt Christensen wrote: >> tirsdag den 4. september 2018 kl. 02.56.51 UTC+2 skrev bitrex: >>> On 09/03/2018 08:36 PM, pcdhobbs@gmail.com wrote: >>>>> the question I'm unsure of is whether you can use those NXP ARMs with >>>>> the toolchain of your choice or if they lock you in to their >>>>> LXCNEXpressor C-only/128k limit toolchain (for the free version) >>>>> somehow >>>> >>>> The Code Red tools are modern C++ (g++) and are free up to 256k.IIRC >>>> the full version is another $256, gasp. >>>> >>>> NXP supplies sample code for Keil and IAR as well. >>>> >>>> Cheers >>>> >>>> Phil Hobbs >>>> >>> >>> I see, is that how they gitcha? The datasheet doesn't seem to actually >>> tell you all the magic steps/registers/memory locations you need to >>> write bits to to configure the peripherals as you like, it's built-in to >>> their compiler.These are in the reference manuals, not the datasheets - as has been standard for bigger microcontrollers since I started using them 25 years ago. The compiler is the compiler - it is not tuned to the specific microcontroller, nor does it have anything to do with the peripherals. Perhaps you are mixing up "compiler" with "peripheral library" or "microcontroller-specific headers". NXP - like all microcontroller manufacturers - provides peripheral libraries and headers defining the addresses, structs, bits, types, etc., for their devices. You can question the quality of the library code (I certainly do - but not just for NXP), and you can question the somewhat inconvenient way you get the files these days (with an online package generator). But the files are all available, and cost nothing. The files concerning the cpu core itself come from ARM, rather than being written by NXP.>>> So it'd be difficult to just say whip up some asm by >>> hand and drop the binary on it and have it actually do anything.No one sane uses assembly on an ARM.>> >> that is almost never in the datasheet for MCUs, you need the usermanual >> >> https://www.nxp.com/docs/en/user-guide/UM11065.pdf >> > > I can see why one might want to pay for the macros.No one sane pays for the microcontroller headers.
Reply by ●September 4, 20182018-09-04
On 09/04/2018 03:16 AM, David Brown wrote:> On 04/09/18 01:46, bitrex wrote: >> On 09/03/2018 05:31 PM, Lasse Langwadt Christensen wrote: >>> mandag den 3. september 2018 kl. 19.25.06 UTC+2 skrev Phil Hobbs: >>>> LPC804: 15 MHz Cortex M0+, 32kB flash, 4k RAM, 12-bit 2 us ADC with 1 >>>> LSB DNL, 10-bit DAC, the usual serial stuff, 20-TSSOP: 67 cents in >>>> reels, dev board $27. >>> >>> STM has a similar cortex-m0 that does 48MHz for the same price at digikey >>> >>> the dev board with debugger is something like ~$10 >>> >>>> We're using it for a super-quiet diode laser controller where it will >>>> run the temperature control and automatic power control loops. I'll >>>> never use another ATmega. ;) >>> >>> indeed, about the only reason to use an AVR is if you absolutely must >>> have 5V >>> cortex is faster and cheaper with more memory >>> >>> >> >> the question I'm unsure of is whether you can use those NXP ARMs with >> the toolchain of your choice or if they lock you in to their >> LXCNEXpressor C-only/128k limit toolchain (for the free version) somehow. >> > > Those days are long gone. >I've been experimenting with not even touching C/C++ for developing simple uP applications, e.g. <https://nim-lang.org/> which resembles a scripting language like Python, it relies on gcc being pretty efficient at optimization by first transpiling to C++ before compiling and uploading to the target device. There's some overhead generated but ideally what you get is significant reduction in development time.
Reply by ●September 4, 20182018-09-04
On 09/04/2018 01:51 AM, Piotr Wyderski wrote:> bitrex wrote: > >> Ok great as it seems they want one to pay some fee to enable >> C++/unlimited binary size in their bespoke IDE which is silly-talk. > > Microchip style. Same diagnosis here. There are just too many alternatives > without the silly limitations to waste one's life on something like that. > > Best regards, PiotrAs of several years ago at least I recall reading that the IAR compiler for ARM produced more efficient code than gcc, however at that point it was not fully C++1x-compliant it was still more like C++03. That may have changed at this point but either way a commercial license for their toolchain is a couple grand. I've not done much ARM development but so far for both AVR and ARM gcc has always worked fine for me...
