Something i'm wondering is how you could be able to choose the right controller for your project. How do i know how many memory ROM or RAM is needed or if an 8 bit is enough or 32 bit.
When do you decide to go for a 32bit with Real Time Linux OS for example?
How do i know if the controller / system will be fast enough with what you need to program for it?
Experience.
Experience.
And how does Experience make sense of of the variables and requirements you have to make decisions
Do you for instance start with the minimum / maximum IO's you need?
In a professional project, do you choose based on technical requirements or costs and functional requirements? (I guess you can get the same results with a Realtime Linux OS if the price of an 32 bit controller is the same as the 8 bit) Eliminating complexity and making debugging and logging easier?
I start with a "Requirements List" - this is something that most engineers learn to do. It is basically a list of what it needs to do. It might have some specific components listed if there is something that you know that you "have to use". For example, there might be a component from an earlier project that you know is the only one available to do that task or with certain needed characteristics. It might look something like this:
1. Battery power with an operating life of 6 months from off-the-shelf "flashlight" batteries
2. uSD card for data storage - this requires SPI interface and 3.3V power supply - at least 4 IO pins
3. USB 2.x interface
4. Configuration via ASCII terminal over USB
5. Real time clock based on 32KHz watch crystal
6. Acceleration sensor LIS3DSH requires 3.3V power and I2C or SPI interface
7. Microcontroller to manage sample scheduling, data formatting and storage, plus interfaces and status
8. Three bicolor status LEDs - total of 6 IO pins
9. Start-stop switch - 1 IO
10. Electronic power switch for uSD = 1 IO
11. Max sample rate 100Hz from 3 x 16-bit data registers in sensor - data storage rate slower due to signal processing
12. Standard ISP programming interface for the chosen MCU
13. IP65 enclosure
14. No specific cost target
Note that there is no specific MCU called out. Nor, except for the sensor (which is a known requirement), any of the other components. With this, you can get a reasonable estimate of the number of IO pins.
Reviewing the list suggests that 3.3V power is appropriate. The commercial battery requirement plus 3.3V (with enough peak power to supply uSD card) suggests a micro-power switch-mode power supply (experience). Sample rate and data size suggests that an 8-bit micro will probably work (experience) though, with the mix of serial I/O, several MIPS will probably be needed. Nothing seems to suggest an RTOS though one could probably be used.
In the end, I ended up using Mega328P - FLASH was about 85% used and identifiable RAM was about 60% used (that does not include stack). Only one or two pins were left unused. I opted for a separate USB interface device (FTDI FT232R) because I had no experience with any MCU that has internal USB and I was fearful of the development time.
Energy consumption is "adequate" but could be better. I added power switching (not in the specs) so that USB supplies power when USB is plugged in. No bootloader but one would have been handy. I was prepared to scale back to M168 if the program had been small enough, but it was not. That is one advantage of choosing a device family with a range of memory sizes.
So, what I do is a sequential series of narrowing the selection options. Early choice of 3.3V power system is one of those. IO pin count was another early factor. Decision to go with 8 bit capable of several MIPS was a big one. Experience lead me to MegaXX8 family as it has enough pins, supports RTC internally, runs at 8MHz with Vcc = 3.3V and achieves several MIPS under these conditions. Note that there probably at least several other devices that would have met the requirements, but this is one I knew.
Hope this helps
Jim
In a professional project, do you choose based on technical requirements or costs and functional requirements?
You don't choose; you design and then choose.
I've posted a picture before but my design tool of choice is an A2 pad and a pencil.
Hi
one post at midnight from an insomniac.
I only know when I set up a project with a minimum of necessary components. I feel empowered.
The other thing I know. During the design time of a project, choices become infinite and you have to finish it at one point. Otherwise your project will not be built and will remain on paper forever.
Something i'm wondering is how you could be able to choose the right controller for your project. How do i know how many memory ROM or RAM is needed or if an 8 bit is enough or 32 bit.
When do you decide to go for a 32bit with Real Time Linux OS for example?
How do i know if the controller / system will be fast enough with what you need to program for it?
Experience is a good answer, I don't think anyone has ever sat down and written a tool which inputs a set of requirements and pops out with a list of candidate controllers, quite possibly such a tool is impossible. I know we used to have a tool which helped configure mainframe systems but those sold for $millions, and the tool only had to select among our own products for a few specific types of application.
Of course, you can also learn from other people's experience, look at similar products and see what controller they use. Also try asking sales reps, obviously they are highly biased, but at least the advice is free and they are somewhat motivated towards helping you find a solution that works. Often there is sample code from the manufacturer. E.g. I was asked to estimate the code size required to "add USB serial", so I compiled an USB CDC example from Atmel and the same day could tell the designers that the proposed chip was too small.
Without experience, there is "trial and error", aka prototyping. That might sound amateur but learning from experiment is the scientific method. Rather than implement the full code, identify the most time consuming part and create a benchmark for it, then trial it on some sample controllers. If you are not sure which is the time consuming part, then you will need to do some benchmarks to estimate that.
Once you have some base numbers, you can perform more paper based modelling, e.g. if you need 25 MIPS for a particular task, that would rule out a lot of 8 bit CPUs.
In most projects, as you decompose the problem you'll end up with a list of 'knowns' and 'unknowns'. Then you seek to answer the unknowns.
If the unknown is "what processor do I need for this?", then that is a complex question that needs to be broken down more. With experience, you have a baseline by which to base an educated guess.
When I started with AVRs, my first unknown was "what flash size will I require?". So I started with the largest part of the time - a mega103. I designed the hardware based on this and then wrote the code. The code ended up being around 18k. If I had chosen a mega16, then I would've been in trouble.
In terms of ram, you need to consider what arrays or tables you might need. Again, experience guides you.
In terms of performance, you need to consider how fast certain tasks need to be performed. If you're dealing with switches and relays, then you're talking in 10's of milliseconds. If you're dealing with a servo motor with a 4000cpr encoder, you might need to consider hardware assistance for the encoder and the compute time for the servo loop code.
Luckily, these days there is a swag of cheap hardware platforms from the likes of Arduino to quad core raspberry pi's and beyond. So if you have doubts, you can Google for similar projects on the interwebs or projects that might incorporate something specific that your project has. This can guide you as to what might be suitable. So purchase the board and start working.
What if it is a bad decision and you hit a wall? Well, you've just gained some experience. You should have a better idea of your requirements. But you don't want to waste time going down the wrong path - the worst waste of time is making a bad decision and sticking with it. Attempt to resolve your unknowns early, so if you need to change, then you can change swiftly. The number of times I've seen bad design decisions that have been stuck with that needed a patch to get around a problem, then another patch and so on. In any sizeable project, you'll make bad decisions - consider that you might make 100 decisions a day when writing code - 3% error isn't unreasonable.
Another technique is to simulate.
So seek to break down the unknowns into simple questions - then answer those questions.
For example - my question for today is how much storage will I need to store 100,000 events in a sqlite table? How fast can I search these on a small wireless router board? Luckily I have 110 million event record of real data to work from, so I can grab 100,000 of those and pop them into sqlite. That will answer my first question. Then I can perform some searches and get some timing information whilst running on the target hardware. My next question might be " how many events can I add per second?". You can see that very quickly I am gaining hard data by which to make an informed decision. I've also gained some baseline data. I could compare sqlite performance with a simple indexed table for example.
Soon enough, all the dominoes will start to fall and your unknowns become knowns and the solution will present itself.
I have similar challenges when doing some home construction - how much wood? how much concrete? estimation of cost? If I need some sand, how much can I fit in my trailer? Luckily we have the interwebs, so information like the density of sand can be found easily so if i known how many cubic metres of sand I need, I can estimate the weight and decide if I want to pay for a truck to deliver it or whether I can carry it in my trailer.
But, for a construction novice, it might not even be obvious where to use concrete and where to use wood. I get the feeling that this is close to the level that the OP is at.
Jim
While building your list of requirements also consider your constraints; delivery deadlines, costs, restrictions (eg, cannot purchase from certain suppliers for whatever reasons), your level of competence (will you have to learn a new compiler/language), availability of development/debugging tools (software and hardware), availability of appropriate staff and physical resources (will the production workshop have time to prototype your special widget). Do you have other competing pulls on your own availability?
Sometimes the constraints become the defining features.... beware of them.
The worst thing is that someone else chooses a controller/platform and forces us to do things on it.
And how does Experience make sense of of the variables and requirements you have to make decisions
Do you for instance start with the minimum / maximum IO's you need?
Apart from the fact that experience will simply tell you that a job monitoring a sensor and switching a pump on and off is likely doable in a 8pin 1KB 8bit micro running at 1MHz whereas detecting moving objects in 1920x1080 image with 24 bit color depth at 30 frames per second will require 100's of MB of DRAM and a processor running at 1GHz or more (in fact perhaps 4 or 8 CPU) the more scientific approach is to draw up some budgets:
1) pin budget - try to determine how many things will be wired to the micro and how many pins each will take. For example if you realise you need 3 devices on SPI then not only is that going to "eat" the SCK, MOSI, MISO pins of the SPI peripheral itself but you are going to need 3 more pins for the slave select signals. When you have considered all that will be in the design you will know how many pins (and what peripherals) you require
2) memory budget - look at the complexity of the code you write. Is it a simple loop in main then there's a chance it will fit in 1K of code space or less. If you see that you need a (full) TCP/IP stack, XLS file decoder, a full copy of OpenCV and various other things you may determine you need 3MB of code space. Same goes for RAM usage. If it's a little control loop with 5 16 bit variables you need 10 bytes of RAM. If you are going to buffer 2 minutes of 30 frame per second HD resolution video you may determine that you need 512MB of RAM and so on. When you have added up all your storage requirements you will have a sense of whether you are talking about a 1K micro with 64 bytes of RAM or a PC with 4GB of RAM backed by a secondary storage of 2TB of HDD or SSD etc
3) time/cpu budget - in this you way up how much processing effort you need. If you take my two examples I gave at the start you might determine that the sensor/pump thing could run at 1MHz or even a lot less - in fact maybe it sleeps for 98% of the time and just switches on rarely for a 1 second burst of activity at 1MHz. The image object detection thing on the other hand probably simply cannot have enough CPU power you may choose an Octo cor Cortex A15 processor running at 1.4GHz on all 8 cores and it *still* isn't as much CPU power as you would really like to get the object detection resolution you are really looking for.
Bottom line is: be realistic
You don't construct an alarm clock using a 3GHz Xeon processor rack server and you don't control a nuclear power station with a ATtiny4 running at 128kHz!
Supposedly nuclear power stations are still being run by pdp11s. The average AVR would have similar compute performance methinks! Obviously not at 128kHz. You'd need a PIC for that........
you don't control a nuclear power station with a ATtiny4 running at 128kHz!
Of course not - you'd use a Raspberry pi:
You'd need a PIC for that
How handy that awneil posted one, then... :-)
you're welcome!
