A few DIGI Connect ME GNU development kit 6.3 questions:
Sometimes after I stop or reload the debugger my NVRAM gets corrupted and I need to re-enter MAC, IP, etc. Any ideas why? I’ve worked around the issue by using static settings in my appconfig.h.
In GDBTK - I have to resize the source window when I start in order to see source filename pull down toolbar. Some sort of GUI glitch in the toolbar - any ideas on how to avoid it?
In GDBTK - How do you restart your program without exiting the debugger and reentering? What does the RUN button do - it seems like it should do this but it doesn’t work…
In GDBTK - How do you prevent it from reloading breakpoints from the last session? Half the time they are not valid which causes a lot of error messages to pop up.
What is the time of a threadX “tick” and in what header file is this constant defined?
Many examples call printf for debug output. Where does this I/O go and how is it controlled?
2) In GDBTK - I have to resize the source window when I start in order to see source filename pull down toolbar. Some sort of GUI glitch in the toolbar - any ideas on how to avoid it?
Yeah, it’s annoying. I haven’t figured out how to stop that either. Also equally annoying is that each window is independant on the task bar (makes ALT-TAB switching a real pain).
5) What is the time of a threadX “tick” and in what header file is this constant defined?
By default, 1/100 of a second. It is changeable by setting BSP_TICKS_PER_SECOND in bsp.h.[/i]
6) Many examples call printf for debug output. Where does this I/O go and how is it controlled?
It goes where APP_STDIO_PORT points. If BSP_INCLUDE_UDP_DEBUG_DRIVER is defined, and APP_STDIO_PORT is set to "/udpdb/0", then you can use the udpdb.exe to watch the debug messages.
One possible explanation is that the default application, pre-programmed into the flash of a Connect module is based NET+OS 6.0. You are loading an application based on 6.3, which knows ho to convert a 6.0 NVRAM params structure into a 6.3 version. Once converted the 6.3 application, unless APP_USE_NVRAM (re: appconf.h) is set to 0, writes the converted params to NVRAM. Because the 6.3 application has not been written to flash, if/when the module reboots the 6.0 application is executed and because 6.0 does not know how to convert a 6.3 params structure the application will reset the unit to defaults.
Solution: build and load a 6.3 applicaiton, perhaps nafptapp, and load the image.bin file into flash, thus eliminating the need for the application to convert the NVRAM data.
I certainly do see this as well. To date I have not found any way in which to change the size of the GDBTK window, as a default. Resizing has been the solution, thus far. I can tell you that our next release of NET+OS, version 7.0, will ship with an a Eclipse based development IDE, entitle Digi ESP. No more GDBTK, easier to use, etc. Based on previous experience with graphical UI development , this problem would seem to be a repainting issue. One would have to get the GDBTK source and debug it.
It is best to exit and rerun GDBTK, there is no other solution for this issue. Digi ESP (NET+OS 7.0) will not have this problem loading and reloading an application, via the debugger, without restarting the IDE, is possible.
I have looked into this issue, as well. I have not come across any setting which can disable this. The best one could do, at this point, would be to edit the gsbtk.ini (stored in your $HOME directory, and delete he contents of the [session] section.
Thanks both for the info. I didn’t realize I could get UDP debug info - very handy. In general the debugger works OK but I guess you get what you pay for with GNU stuff.
Cameron:
So when will we see the NETOS 7.0?
Will it introduce any incompatibilities in code written for 6.3 or any module incompatibilities like we saw from 6.0 to 6.3?
NET+OS 7.0 has been released and is currently shipping in our ConnectCore Wi-9C development kits. Any customer interested in obtaining a copy of NET+OS 7.0 should contact Digi support (see the phone/e-mail information below) or your Digi Sales representative. First, however, I encourage you to continue reading the remainder of this post.
To answer your question:
Are there going to possible challenges in porting a pre-7.0 application to 7.0, most certainly. The amount of effort will depend, entirely, upon the individual application being ported.
As an example, I have just completed porting the Digi Weather Station Demo from 6.0 to 6.3 & 7.0. Porting the application from 6.0 to 6.3 was mostly an exercise in eliminating all of those errors and warnings generated when one fails to prototype a function, declares a variable that is never uses, etc. The effort in porting from 6.3 to 7.0 took me about 6 hours. This will most certainly vary depending on the complexity of the application and whether one has made special modifications to the BSP. The time it took me to port this application is certainly not an accurate gauge of how long your effort may be; the APIs in use, amount of modification to the BSP, etc. will have be factors.
There have been a number of APIs that have been deprecated and subsequently superceded. Some APIs have simply been removed. The attached WhatsNew.txt file (shipped with 7.0) provides additional information regarding these changes.
At this present time 7.0 is primarily focused on new development opportunities, specifically in respects to the ConnectCore Wi-9C. This is, by no means, to say that current development kit customer are not welcome to upgrade. We want to control the availabilty of 7.0, however, so that there is an clear opportunity for us to make you aware of the potential challenges involved.
So we just call to get the new IDE, etc. - it works with the existing JTAG hardware and dev boards?
I think I will have to ping my rep, as I’ve just started my development and the only porting issues I see from the whatsnew.txt are some minor changes to sockets. I gather the FLASH file system, FTP server, etc. didn’t change?
How about the stability of the new TCP stack? I gather it was changed to support IPV6…