Trouble with SX-Key IDE (.SYM file cannot be created)
William Pietro
Posts: 5
We have a mystery bug. When we try to add a simple subroutine to existing assembly code we get an error "SASM is unable to create .SYM file". It doesn't matter what the subroutine is (even a single RET statement). Any suggestions?
Comments
Does the unmodified code assemble without problems? I ask because I wonder if there is a file that SASM is trying to create that has been locked by Windows for some reason. Every once in a while I have had a file that I deleted but that Windows is convinced is still there. This hasn't happened with the SX-Key before, but anything is possible.
You could also try renaming the file and assembling to see if that changes anything. Also, try unchecking the "SASM files to 'SASM Output' directory" checkbox in the configuration dialog for the assembler.
Thanks, PeterM
Thank you for your reply. We tried unchecking the SASM files to... box. The unmodified code does assemble without problems. Here's another piece of the puzzle. If we include the subroutine directly in the main code file, no prolem. It occurs only when we try to add it as an "INCLUDE" file. We worked around this by consolidating several include files into one. This now works. My conclusion - there must be some limit (perhaps unintentional) to the number of INCLUDEs one can have in the source code (no more than 9).
Ah, the plot thickens...
You didn't mention that the new code was added in an include file in your original post. Indeed, there is a limit to the number of include files you can have. This was an arbitrary decision by the original programmers of SASM, but one which is currently ingrained pretty deep into the code.
Check out page 55 of the SX-Key 2.0 manual. There you'll see the following information (and more) about include files with SASM:
Please note that the path specification must be specified within quotes, and that the total length of the
path specification may not exceed 63 characters.
It is possible to have more than one INCLUDE directive in a program and it is also possible that
INCLUDE directives are used in include files, i.e. nesting of include files is allowed at a maximum level
of 10.
Honestly, I'm glad to hear that you're using the include file capability, even if you did bump into a limitation of it. Are you also using the "Top" file feature? It makes working with include files a lot easier.
Thanks, PeterM
PS - Just to clarify, 10 files is the total limit for all include files, and actually (I'd have to double check the code) it may be the total number of files in the entire project. I mention this in case you were thinking you might be able to work around this limitation by nesting your includes. It's possible to read the manual and think that each level of include nesting can have 10 files. You can't.
Thank you again for all the clarification. We did read the SX-Key manual and missed that tidbit. Our first inclination was not to think this was a normal limit, since such a simple problem could have been caught in the software upon reading the 11th include, resulting in a more 'direct' error message. Also, we have a Visual Studio .NET compiler on each machine and it was detecting the uncaught exception, further complicating our confusion. Thank you very much for your help.
Bill
Yeah, I have VC++ on my machine, and it always seems to come up offering to let me debug some program that's crashed. Of course, if the program is a commercial one that I don't have source for, it's kind of pointless....
I'll look into the error message issue.
BTW, you never mentioned if you're using the "Top" feature or not.
Thanks, PeterM
Well, that was actually a trick question. I don't think that the Top feature has been officially documented by Parallax anywhere, so I thought I'd take a moment to try and help out. Here's the documentation I wrote for the beta testers:
“Top” Files:
The addition of the SASM assembler in version 2.0 of the IDE allowed “include” files for the first time. However, using them in projects has not been as easy as it could be. The problem stems from the fact that when the user tells the IDE to assemble, whatever file is in the visible editor is passed to SASM as the file to start assembling from. However, when working on a multi-file project, it’s common to be working on one of the “included” files, and thus SASM is told to basically start assembling from the middle of the project. This meant that it was up to the user to constantly switch back to the main file before telling the IDE to assemble.
The “Top” file feature is designed to make working with include files as simple as possible. At any point while working on a multi-file project, simply right clicking in the editor selector (the listbox on the left side of the IDE) brings up a context sensitive menu where one of the menu entries reads, “Set as Top File”. Clicking on that option will cause the name in the editor selector to be displayed in boldface, and the IDE will note that this is a “Top” file both internally and in the registry. The information stored in the registry is used to automatically set the status of the file as “Top” the next time it is loaded. The IDE remembers up to 20 “Top” files before removing the oldest entry to make room for a new one.
Regardless of whether a “Top” is loaded or not, the user can choose to assemble starting from any file they want. This allows for the user to have files from different projects open at the same time and still be able to assemble and debug with them. However, when the IDE is told to assemble a non-“Top” file while a “Top” is loaded in an editor, a dialog pops up that reminds them they have a “Top” file loaded. I have attached a JPEG to this forum post that shows a sample of the dialog box.
If the “Top” file is visible already, then the IDE simply assembles the project, starting from the visible “Top” file. You can only have a single “Top” file loaded at any time, and if you no longer want a file to be a “Top”, right clicking in the Editor Selector on the name of the current “Top” file brings up a menu with two related entries:
Set as Normal File removes the “Top” status from the file, but leaves the entry in the registry so the IDE will remember the next time the file is loaded.
Remove from Known Top File List removes the internal “Top” status, as well as removes the entry from the registry.
Since SXBasic does not allow include files, they cannot be set as “Top” files.
I hope you find this useful.
Thanks, PeterM
I think you'll find that it makes working with multiple file projects a lot easier.
Thanks, PeterM
It sounds like what SASM needs is the equivalence of the Unix make file concept. It is initially a bit more challenging to create then a single top file with includes, but it provides a more powerful, and safer, compile (make that assemble) environment.
Jim
That "initial challenge" is exactly why I went this route instead. One of the hallmarks of the SX-Key is the speed you with which you go from "I have an idea" to "I'm writing code" to "I'm debugging/burning". Having to create make files or start special project files is just time that's spent on the unproductive part of the process. Remember, these are assembly code projects for a chip with a few KB of EEPROM, not C++ projects with 100,000 lines of code for a machine with 1 GB of RAM.
The idea is lean and mean programming on a chip running at 50 MHz, but with an IDE that does as much invisible hand holding as possible. Currently, the IDE automatically:
Restores the last set of open files when you start it.
Remembers the "TOP" files automatically
Offers to assembles the "Top" file regardless of which file is visible
Can use template files so that when you start a new project, you get your own personal boilerplate code
Has colored syntax highlighting for both assembly and SX/B
Dumps all the files SASM generates in a special directory to keep your source direcotries uncluttered
And the best part is that is just does all of it this without requiring much or any user intervention. In addition, you can turn off pretty much all of this hand holding if you like doing it the old fashioned way.
Believe me, I considered project files and "make" style files, but feel that the "Top" file provides the most useful IDE behavior for the types of projects the SX-Key is used for. Ultimately, the limiting factor for source code size/complexity is the fact that the chips top out at 4 KB and most people use the SX28 which only has 2KB. Of course, if people start pounding the snot out of the system and need a more complicated system, then I imagine the IDE will grow and modify to accommodate.
Thanks, PeterM
Peter,
Good point. I'm stilling trying to get used to the small size and memory space of microcontrollers. It's a hard change from the "oh heck, there's plenty of memory" mindset of modern Unix systems, to one of counting bits. I have to keep reminding myself.
Jim
I know the feeling. I ping-pong between working on the IDE and SASM, and then working on actual projects using the SX-Key and chips. To make matter worse, every time I start working on a project using the SX-Key, I find something about the IDE that I want to improve. Half the time I find myself stopping the SX project to work on the IDE and make it better. Kind of slows me down a lot...
Thanks, PeterM