$70 cents on 1000 units is $700 dollars. On average little over 1 days worth of engineering time. One of the things I've learned over the years is to start looking at component costs at much higher volumes than 1000 units. However it is good to put a lot of thought into production. Again looking at component costs only can severely hurt your business if a product take too long to program & test.70 cents here and there. I don't think one will limit not caring about expenses to MCU only, in the end will end up up with 3-5 times more expensive BOM.You are making the same mistake as many others: you don't care about engineering time!
I know saving a few cents from the BOM gets you an 'atta boy' quickly because it is easy to visualise. However in many projects simple costs savings end up to become huge time sinks. If you need to spend a few weeks to try and optimise code because of a silicon bug, too litle memory or lesser performance in a cheaper microcontroller you'll end up losing your bosses' money. And it is not just development time but also the sales start later. Not to mention the time could have been spend on the next product.
Indeed socalled NRE costs can be huge. The problem is that the target for some manager is BOM reduction and not overall cost reduction. A lot of managers also take on a project just to keep their personell busy so their budget and fte's are not cut next budget round. Last don't forget ignorance, how much effort will it eventually be to change from lets say a PIC16 to an ST32F0 , most have absolutely no clue.
... you don't care about engineering time!
Indeed socalled NRE costs can be huge. The problem is that the target for some manager is BOM reduction and not overall cost reduction. A lot of managers also take on a project just to keep their personell busy so their budget and fte's are not cut next budget round. Last don't forget ignorance, how much effort will it eventually be to change from lets say a PIC16 to an ST32F0 , most have absolutely no clue.For sure - I have all sorts of functionality coded, documented, and proven solid on 8bit AVR's. My last and current projects may have benefited from more powerful chips - but it would have delayed the release by months. Opportunity costs and development costs explode and I am back to a Ramen noodle diet for 6 months. Introducing a new architecture will certainly have a time penalty. Hell, I am using a single micro to generate a 3 phase clock to sync power converters. Super easy and I have control via I2C after assembly. Cheap, easy, and the success is nearly guaranteed. I have the chips in stock and loaded into the pick_and_place because they are used in a dozen other projects for totally different tasks. I use the same chip to monitor a soft power switch and drive 2 RGB LED's, communicating over 2-wire I2C. It is easy.
For the most part - I generally prioritize speed and predictability during design. I need to do some low-priority projects with some fancier uC's to develop the skills and libraries without the time/financial pressure.
As a result nearly every project I do has a different microcontroller in it (which fits the project). I'm not stuck to a limited choice of microcontrollers.
I'm sure you can run it bare-metal as well.
I'd assume you can run a barebones binary from uboot
There are many applications where it needs to be faster and where you need more memory, for example for video IO (this chip has an ethernet interface and a camera input, so probably could be used as a web cam), or polyphonic realtime audio synthesis with effects (reverb needs lots of memory). And the Allwinner V3s is not just a core, it has some useful peripherals as well, see the datasheet, like DMA, PWM, SPI, I2C, UART, audio codec etc. So if you don't miss a peripheral for your application, it could be a cheap replacement for the higher priced STM32 series chips, but with more RAM and much faster. It can run slower as well, probably using not much more power then as a STM32 running at 180 MHz.
This is not the sort of thing that microcontrollers are typically used for. Do you really want to wait for Linux to boot and think about crashes, memory leaks, hacks, etc in your microwave oven, dishwasher, clothes washer and dryer, tv remote, alarm clock, etc? Linux SOCs and microcontrollers are two entirely different fields with some small bit of overlap in the middle. The strength of the microcontroller is in the peripherals, and the simplicity. There is effectively no boot time, there is no operating system, everything happens in real time and can be tweaked down to individual clock cycles. You can get microcontrollers in tiny packages with only a few pins, you can get ones that consume miniscule amounts of power. It is absolutely silly to suggest a Linux SOC for microcontroller applications, even if the Linux route was cheaper the end result would be inferior for the sort of applications where microcontrollers are typically used.
Engineering time also depends on who's doing the job. You'll work much faster and better if you work with something you're already familiar with. From the boss' point of view - if I employed nctnico, I would make sure to give him ARM based jobs. On the other hand, Siwastaja would have zero chance of getting ARM job - all the ARM jobs would go to nctnico!
I'm sure you can run it bare-metal as well.
I'd assume you can run a barebones binary from uboot
Right, this would be the easiest way. Boot time would be much less than a second as well, and you could integrate your program in u-boot itself, which then autostarts after u-boot did all the hard stuff like setting up the PLL etc. Don't know the version on the Allwinner, but usually u-boot even supports USB and network.
As a hobbyst, is there still a point in using them or should I invest my time in learning ARM platform?
Absolutely, don't waste your time with 8 bitters, ARM is the way to go.
http://infocenter.arm.com/help/index.jsp
Also in arduino form:
With zero arguments you're not exactly making a strong case, especially considering there's a thread's worth of arguments why 8 bit chips are relevant.
There's a reason the entire world has moved on to ARM µCs already, big time, to the tune of billions of µCs per year. And you want to steer him into a dead end road?
Eight bitters are obsolete, a thing of the past, "not recommended for new designs".
Semiconductor MCU revenue market forecast –millions of dollars
The OP: "[..] I'm trying to select a (µC) chip to learn [..]".
Had he said "I'm trying to learn electronics", you'd recommend to begin with thermionic valves? No.
There's a reason the entire world has moved on to ARM µCs already, big time, to the tune of billions of µCs per year. And you want to steer him into a dead end road?
Eight bitters are obsolete, a thing of the past, "not recommended for new designs".
8bit is a great place to learn the basics. They provide a solid baseline skill set that translates to all sorts of more complex architectures.
Eight bitters are obsolete, a thing of the past, "not recommended for new designs".8bit is a great place to learn the basics. They provide a solid baseline skill set that translates to all sorts of more complex architectures. They also provide a CRITICAL understanding of system efficiency. When a developer or programmer is using completely overkill hardware - it promotes sloppy and inefficient programming/development techniques.
but in today's situation not learning ARM means someone is behind. And anyone who is claiming ARM is more complicated than 8 bit clearly has never really looked at a simple ARM controller. These do exist and are easier to understand compared to a 8051.
IMHO this is wrong. There is absolutely no reason you can't learn to program efficiently on an ARM.
but in today's situation not learning ARM means someone is behind. And anyone who is claiming ARM is more complicated than 8 bit clearly has never really looked at a simple ARM controller. These do exist and are easier to understand compared to a 8051.You lost me here.
OR you learn the ARM core and read the thousands of pages, study registers and opcodes/assembly instructions It sure is more complicated than 8 bit cores.
If you mean the peripherals that has 0 to do with ARM but I know you know that so that is not what you meant, so what exactly did you mean to say ?
The OP: "[...] I'm trying to select a (µC) chip to learn [...]".
Had he said "I'm trying to learn electronics", you'd recommend to begin with thermionic valves? No.
There's a reason the entire world has moved on to ARM µCs already, big time, to the tune of billions of µCs per year. And you want to steer him into a dead end road?
Eight bitters are obsolete, a thing of the past, "not recommended for new designs".
Both Apple and Microsoft are working to migrate their products from Intel to ARM-based processors developed in-house.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.
There are simple ARM µCs too, and ARM assembly is easy peasy, a much better design and much easier to understand than the arbitrary ISA messes of the obsolete 8 bitters.ARM assembly isn't easy peasy. It being complicated is why industry veterans like Jack Ganssle don't bother with it. I assume we value his opinion above ours. ARM chips are a lot more complicated than 8 bit chips. There's no way around it.