My imaginary project needs 3 fully featured USARTs, 2 fully featured SPIs and possibly Ethernet if I can convince myself that lwIP can handle multiple concurrent connections. You would think that is a simple answer: Yes, No... Something like that... I still can't find it written down anywhere.
/**
* MEMP_NUM_TCP_PCB: the number of simultaneously active TCP connections.
* (requires the LWIP_TCP option)
*/
#ifndef MEMP_NUM_TCP_PCB
#define MEMP_NUM_TCP_PCB 5
#endif
/**
* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections.
* (requires the LWIP_TCP option)
*/
#ifndef MEMP_NUM_TCP_PCB_LISTEN
#define MEMP_NUM_TCP_PCB_LISTEN 8
#endif
But I have never used it (yet...).
Why? I don't care for single-stepping and even though I am migrating toward the STM32F4 boards with ST-Link, I seem to get my stuff to work with just simple printf() statements.
Quoteintegrated IDE around eclipse/gccNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
That is precisly what I am recommending you do not do.
I have used
Code worrier - slow and cumbersome,
Atollic - slow and cumbersome,
VxWorks Workbench
Hate all of them with a passion
www.ihateeclipse.com
With ALL Eclipse embedded integrations, you cannot tell when debugging if the micro has locked up on or if Eclipse has just decided to go off and do some studpid useless background task!
Do you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.
I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.
I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.
QuoteDo you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.
I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.
I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.No, your stated goal is to improve your coding skill. For learning to program, it does not really matter how much the boards cost, just that they are easy to use/develop on. Picking mbed compatible boards pretty much covers that. The more expensive boards are aimed at commercial companies that want to tailor the boards into early prototypes.
If on the other hand you have a specific project in mind, then you should work out the project requirments are and get a board that has as much as that project needs. In other word, what kind of peripherals will the project need? Work out which board has those peripherals and get that one.
Yes, sorry about all the debate on which tool is best. It is down to personal preference. There are a number of tools which should work without much setup effort. As a professional embedded software engineer, I do not have time to mess around with freeware tools that may do the job, I am interrested in tools that will work straight away and NOT waste my time. I have pretty bad experiences with commercial tools based around the open source Eclipse toolset hence I prefer not to use ANY tool that is Eclipse based, however that is not to say that all of them are bad or will not work. I can tell you NOT to bother with the free version of Atollic, has the same code size limitations as IAR but with all the issues that put me off Eclipse. The code size limit should not be a problem if you are just doing tutorial projects, it will only be a problem if you are working on a medium to large project (you can get FreeRtos and some functiinality in the 32K!). I suggest you have a quick look at the web sites for the tools that you are interrested in, if you have used tools before in the past this may help you pick the tool which best fits with the one you used before. Otherwise, try one and see how you get on.
Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.
In the early years of OpenOCD, getting a setup to work was akin to magic. This was back, say, 10 years ago. Give or take...
I haven't tried since and probably never will again. But, yes, it's my fault... There were simply too many parameters and far too many combinations...
...
If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.
Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.
In the early years of OpenOCD, getting a setup to work was akin to magic. This was back, say, 10 years ago. Give or take...
I haven't tried since and probably never will again. But, yes, it's my fault... There were simply too many parameters and far too many combinations...
...
If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.
All you need to do (assuming you have OpenOCD and gdb installed):
1) Create a file called openocd.cfg to save you typing parameters (this is using the ST32F042 Nucleo board with built-in STLink):
---- cut ---
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f0x.cfg]
---- cut ---
The interfaces and targets you can find either in the documentation or just look in the folder where OpenOCD was installed - there are interface and target subdirectories containing files for both the interfaces (dongles) and targets. If you want JTAG transport, just put jtag instead of hla_swd. OpenOCD ships with these files for many common devboards, including the Nucleos and Discoveries, so just look there and adapt one if you don't find a matching one.
...
nctnico, we all know you are superhuman and debuggers are for pussies, but most do prefer to have a debugger available. I also knew one programmer like that that never needed debugger and debugged everything with printfs and a pencil on paper printouts of the code. It took him days to discover what another developer solved in 10 minutes by calling a debugger.
Thanks for the tutorial! Seriously! I have cut the text to a file where I can study it later.
Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.
Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.I prefer to actually put a breakpoint in the handler and investigate the issue while the system is still alive with memory and registers intact than have to do it postmortem from a trace, if possible. Stacktraces have their place, but are far from the fastest way of debugging such issue.
Nonsense. I've used Eclipse extensively to develop for and debug on ARM Cortexes and I've never once had Eclipse "lock up". Do you have some specific evidence, or are you relaying anecdotal tales? Perhaps the Eclipse-based tool you've used wasn't configured correctly.
IMO most of the hate directed at Eclipse is due to vendors taking the base Eclipse and integrating every piece of plug-in garbage they can find in some lame attempt to make it more useful. All of those dodgy plug-ins just serve to make Eclipse slow and unstable. I use the bare cones Eclipse with only the CDT add-ons and it's both fast and stable.
Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.
Thank you for the reply.
The Disco is compatible with mbed: https://developer.mbed.org/platforms/ST-Discovery-L476VG/
I will have a look at IAR but I know that the free version has 32kB limit (16kB for M0+) and lets say I am not the best programmer in terms of code optimization, but I think this will force me to be.
Do you recommend other platforms at this price (20 euros) ?
I wanted a platform that is compatible with mbed.com because I want to start with that and the progress to IAR or GCC.
The STM board is a much powerful Cortex M4 instead of a M0+, but at this point I do not think it matters because I do not have a project in mind which requires features that M4 has and M0+ hasn't. I just want to start working with ARM 32 bit micros and "master" the interrupts and timers and communication protocols (SPI, I2C and UART especially).
I was thinking of purchasing one of those 2 boards: STM32L476G-DISCO or NXP FRDM-KL46Z. What do think or recommand ?
One of these cheap breadboard-friendly Chinese boards?
I wanted a platform that is compatible with mbed.com because I want to start with that and the progress to IAR or GCC.
The STM board is a much powerful Cortex M4 instead of a M0+, but at this point I do not think it matters because I do not have a project in mind which requires features that M4 has and M0+ hasn't. I just want to start working with ARM 32 bit micros and "master" the interrupts and timers and communication protocols (SPI, I2C and UART especially).I was thinking of purchasing one of those 2 boards: STM32L476G-DISCO or NXP FRDM-KL46Z. What do think or recommend ?One of these cheap breadboard-friendly Chinese boards?
But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.
But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.
That's certainly one solution, however one I see more useful in the field on a deployed system than during development.
Another way of doing it is to use the record feature in gdb and reverse debugging. Have a look at this video:
http://undo.io/resources/presentations/cppcon-2015-greg-law-give-me-15-minutes-ill-change/
He is solving a similar problem - a semi-random crash. He puts a breakpoint in the exit handler, watchpoint on the memory location that is being changed and tells gdb to record the behaviour of the code. And then when the bug happens, he can just walk it back right to the code that has triggered it.
I haven't tried this with the hard fault handler on ARM, but don't see why it shouldn't work.
I can't watch the video from where I'm now but I assume he's using the backtrace functionality of GDB. Because the amount of data pushed onto the stack for each function is known it is not difficult for a debugger to trace the execution back and determine the function's parameters. I use this often when I need to trace the origion of a problem but always for code running on a PC. However I don't see why this shouldn't work with an embedded target (as long as the stack didn't get corrupted).