Search found 333 matches
- Fri Jul 15, 2011 8:54 am
- Forum: NetBurner Software
- Topic: Exception handling
- Replies: 9
- Views: 6945
Re: Exception handling
Thanks Tod, I have had a look again and I didn't find any reference to malloc or free in the code. It uses the C++ new and delete instead. I back tracked all the code to the day before and this compiles (thank goodness for source control). I then entered the -fexceptions in the miscelaneous box and ...
- Thu Jul 14, 2011 10:07 pm
- Forum: NetBurner Software
- Topic: Exception handling
- Replies: 9
- Views: 6945
Re: Exception handling
Looking through this code I don't like the way it handles data ranges. There is a lot of assert() calls in there. For me, this is not good programming style. Actually, these type of calls should only be used during initial debugging to catch programming errors and then removed. Looks like a bit of w...
- Thu Jul 14, 2011 9:10 pm
- Forum: NetBurner Software
- Topic: Exception handling
- Replies: 9
- Views: 6945
Re: Exception handling
Hi Tod, All the errors appear to be in the header files but I suspect it is the calls to them that are the issue. This library uses a lot of dynamic memory accesses. In reference to removing them, that thought had crossed my mind. As the software was originally developed to run on Linux the exceptio...
- Thu Jul 14, 2011 4:38 am
- Forum: NetBurner Software
- Topic: Exception handling
- Replies: 9
- Views: 6945
Re: Exception handling
OK. With that help I got the library to compile with absolutely no errors which is pretty damned amazing. The only issue is that now when I enable exceptions in my main project to allow this one to build, I get this error... actually a number of them in malloc. C:\nburn\gcc-m68k\m68k-elf\include/mal...
- Wed Jul 13, 2011 11:30 am
- Forum: NetBurner Software
- Topic: Exception handling
- Replies: 9
- Views: 6945
Exception handling
I have downloaded some code to do DNP3 protocol and it is written in C and C++. It is going to require a little porting work as it was originally developed for a Unix system!! I am trying to build the code just to see what sort of errors I am getting and exception handling is one I can't seem to get...
- Wed Jul 13, 2011 11:02 am
- Forum: NetBurner Software
- Topic: Is eTPU function calls thread safe?
- Replies: 8
- Views: 4469
Re: Is eTPU function calls thread safe?
So far so good. Everything is running fine all day.
Cheers for all the pointers.
Dave...
Cheers for all the pointers.
Dave...
- Tue Jul 12, 2011 10:22 pm
- Forum: NetBurner Software
- Topic: Is eTPU function calls thread safe?
- Replies: 8
- Views: 4469
Re: Is eTPU function calls thread safe?
OK. I think I found it. In the return from the crc16 check in the Modbus library, the function would return the CRC value it failed on instead of CRC_FAILURE flag. This was OK some of the time as the value would end up being negative and this indicated an error but if the CRC was positive, it would ...
- Tue Jul 12, 2011 8:37 pm
- Forum: NetBurner Software
- Topic: Is eTPU function calls thread safe?
- Replies: 8
- Views: 4469
Re: Is eTPU function calls thread safe?
Thanks for the pointers Tod. Sadly my testing last night was interrupted overnight by Windows deciding it should reboot because of an update. This feature is now disabled. I want to control when to reboot. I am re-running it today and see what happens. I have added additional code but I have a feeli...
- Tue Jul 12, 2011 7:28 am
- Forum: NetBurner Software
- Topic: Debugger stops OSSched() at: asm ("UCOSWAITS_HERE:")
- Replies: 3
- Views: 3346
Re: Debugger stops OSSched() at: asm ("UCOSWAITS_HERE:")
Hi David, Have you resolved this? I see this if there is any crash in one of the tasks I have running. It makes tracking it down a little harder. What I do is look at the debug window where the list of tasks if located (normally top left) and check each one in turn to see where it has paused. Genera...
- Tue Jul 12, 2011 7:20 am
- Forum: NetBurner Software
- Topic: Is eTPU function calls thread safe?
- Replies: 8
- Views: 4469
Re: Is eTPU function calls thread safe?
Even with the priority set to middle, it works just fine until I hit this error and it crashes. Master is at 9600 and slave is at 19200. I am doing about 10 Modbus register requests on a round robin with the task idling for 4 ticks between. I am not seeing any Modbus failures unless I have the graph...