Monday, September 27, 2004
How to Build an Application
Digi's implicit assumption is that you will go through the example programs under netos60_gnu/src/examples, find one that approximates your needs, and cut&paste the appropriate code into your own app. If you have any questions, you can always read the source, post to support forums or ask tech support. There is help - quite a big help file - but it is a typical reference document. That is to say, if you already know the answer, you can learn the details, but if you don't even know the question yet, you are SOL.
In addition to my core logic, my application needed telnet code (from example project natelserl), ftp code (from example project naftpapp) and raw socket access (from example project nafsockapp).
There is no facility in the standard libraries to reload code. You must include some method of updating code in your application. I use ftp, but tftp and http are both possibilities. If you ever load code with a dysfunctional update method into a ConnectMe, you have just made that ConnectMe into an OTP device.
War Story: After putting all the elements together, the ftp service didn't work. At this point, I really wasn't clear on the memory map so it was tough to know how things were failing. But they were failing. After (only) one sleepless night, I found that the ftp service needs nearly exclusive CPU access. After putting in handshake logic to idle the other threads when FTP was active, the application started working like a champ.
Hint: The FTP service has a nasty quirk. Unless your code ends on a segment boundary, there will always be some bytes left in buffer when the ftp client says "download complete." the ftp library will not write those dangling bytes to Flash until the ftp client disconnects ("bye"). So if you do what comes naturally and cycle power when the PC says "download complete" you will have a ConnectMe with a corrupt Flash image. When updating code via FTP, ALWAYS type "bye" and wait at least 30 seconds before removing power.
Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.
In addition to my core logic, my application needed telnet code (from example project natelserl), ftp code (from example project naftpapp) and raw socket access (from example project nafsockapp).
There is no facility in the standard libraries to reload code. You must include some method of updating code in your application. I use ftp, but tftp and http are both possibilities. If you ever load code with a dysfunctional update method into a ConnectMe, you have just made that ConnectMe into an OTP device.
War Story: After putting all the elements together, the ftp service didn't work. At this point, I really wasn't clear on the memory map so it was tough to know how things were failing. But they were failing. After (only) one sleepless night, I found that the ftp service needs nearly exclusive CPU access. After putting in handshake logic to idle the other threads when FTP was active, the application started working like a champ.
Hint: The FTP service has a nasty quirk. Unless your code ends on a segment boundary, there will always be some bytes left in buffer when the ftp client says "download complete." the ftp library will not write those dangling bytes to Flash until the ftp client disconnects ("bye"). So if you do what comes naturally and cycle power when the PC says "download complete" you will have a ConnectMe with a corrupt Flash image. When updating code via FTP, ALWAYS type "bye" and wait at least 30 seconds before removing power.
Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.
# posted by Larry Martin @ 6:43 PM 
