Janos

I've started writing a small GUI for the LM4Flash tool with Xcode. I've no experience with Objective-C and the Cocoa Framework, so it is a lot of try and error work for me - but in the end it doesn't seem to be that difficult to write such a simple program. If I'm successful I'll share it with you

@@Janos the upload command is hardcoded into the Energia IDE and unfortunately can not be changed. The next release of Energia will be based on the new 1.6.x IDE that will have all these commands configured inside text files. At that point it will be very easy to change the upload command.
 
Robert

I'm using lm4flash and OpenOCD as an alternative for embedXcode.
 
lm4flash is provided by Energia and OpenOCD is installed with Homebrew
$ brew install openocd

Yes, that's basically what's happening.
 
 
To be clear, dynamic allocation doesn't require an OS. The "new" and "malloc" functionality is provided by the Runtime Support Library, which also contains the initialisation code that runs before main(). That library is included with the C/C++ compiler and gets built in to your project automatically. On embedded platforms sometimes the heap size is set to zero by default, however, and that needs to be increased to allow dynamic allocation. I guess that's already done if you're using energia.
 
The problem is more to do with what happens to the heap structure used to manage the dynamic allocations.
 
If your program is continually allocating and freeing memory while it runs you run the risk of forgetting to free some memory. When that happens you end up with less free memory available until the next reset. It's possible for all the free space in the heap to leak away, and eventually no allocations are possible.
 
Also, allocating and freeing memory during runtime can cause the free space on the heap to become fragmented to the extent that a big allocation fails. If you allocate a couple of different memory blocks like so:
A *a = new A(); // size = 4 B *b = new B(); // size = 2 Then a heap of size 8 might look like this ("|" marks the start and end of the heap):
 
|aaaabb__|
 
Now try this:
delete a; C *c = new C(); // size = 6 The heap would end up like this after the delete:
 
|____bb__|
 
Now there's six spaces free, but they're not in a contiguous block so new C() will fail. Different patterns of allocation and deletion can produce different results. In this case the program would work if b got allocated before a. Unconstrained patterns of allocation and deletion make it hard to work out whether a particular allocation will succeed. You need to inspect the internal state of the heap or know the full history of allocation/release to find out whether the free space is all in one block or not.
 
Finally, the allocator might take longer to return when the memory gets fragmented. That's no good for real-time applications.
 
For these reasons it's common to avoid allocating and deleting memory during runtime in embedded software. That can be done by never using new/malloc, but other options are available.
 
As spirilis pointed out, it's fine to allocate memory dynamically at startup if you know it's needed for the whole lifetime of the program. If there's no deallocation the heap can't get fragmented and there's no risk of memory leaks if all the allocation is done at startup.
 
The other pattern that avoids fragmentation is where later allocations are always deleted before earlier ones. That's similar to the way local variables get stored on the stack. A stack keeps all the used memory at one end and the free memory at the other, so it can't get fragmented. You just have to be sure there's enough stack space for the maximum possible amount used.

And here one that goes into the details, including the virtual part:
http://www.cplusplus.com/doc/tutorial/polymorphism/

I think this is possible. What you do is create a pointer of type base class and instantiate a subclass then assign the base class ptr to it, but make sure all base class methods are declared "virtual".
 
On a phone with 2 toddlers in tow right now so I can't test an example but be sure your base class ptr accesses methods and variables using "->" instead of "."
 
In C++ terms a virtual table lookup occurs every time you access the subclass instance.

Hi,
 
I just wrote my first own library to access the Quadrature Encoder Interface of the TM4C129 with my Connected Launchpad and thought that it could be useful for others too.
 
It can be downloaded here. Since I'm a beginner in C++, some feedback would be nice!

Hi,
 
I just wrote my first own library to access the Quadrature Encoder Interface of the TM4C129 with my Connected Launchpad and thought that it could be useful for others too.
 
It can be downloaded here. Since I'm a beginner in C++, some feedback would be nice!

Hi,
 
I just wrote my first own library to access the Quadrature Encoder Interface of the TM4C129 with my Connected Launchpad and thought that it could be useful for others too.
 
It can be downloaded here. Since I'm a beginner in C++, some feedback would be nice!

Okay. Got the answer by myself. All I had to do was include <Energia.h>.
 

 
And I noticed, that driverlib and inc are already inside Energia, so I deleted them from my library folder. Finally it looks like this:
#include "TivaC-Encoder.h" #include <Energia.h> #include <driverlib/sysctl.h> #include <driverlib/qei.h> If this library does a good job, I'll post it here.

Hi,
I have created my library inspired to fatihinanc's code.
 
Now it's only working on 2X16 display LCD and it have some methods like Arduino's Liquid Crystal to be more likeable. I hope you'll like it.
At the following link you can find the project... and here some info.