Bascom and AVR. Editor and Simulator.


The Bascom editor window (File/New or open an existing Bascom program) is used to enter and modify program text. Bascom uses colors to highlight text:
- Green is comment: all text after '. Use comments to clarify program structure, you'll thank yourself when you read a well-commented program after a few months...
- Red is for special characters: *+-,./\:;<>=&^%#@~()[]|?!@{}
- Blue (bold) is for Bascom statements (Any word recognised by Bascom as having special meaning, such as keywords, statements etc.). Example: Waitms 50. Additional help on statements is available by placing the text cursor on the statement text and pressing F1
- Black is for Bascom variables (more on variables)
These colors can be modified in the Options/Environment (tab Font) window:




Bascom claims it has a 'smart' editor. This means that program text is reformatted as you type to make it 'neater'. For example, each separate word in the text is always changed to have the first character in upper case. Also, white space is added around for enhanced readability. You may change this behaviour in: Options/Environment:



and uncheck the "Don't change case" and "Reformat Bas files" entries. (The second entry is to prevent Bascom to reformat Bascom files as they are read in after opening)
While we are looking at the 'environment' settings, select the "IDE" tab:



Bascom will save your changes to the program text >>before<< each and every compile! This is unexpected behaviour in these type of applications. You cannot simply 'try something out' by changing some text and seeing what a recompile will do. After a few of these tries your source code file has probably changed significantly and you cannot escape by ending Bascom without a save. This is not necessarily bad behaviour, it is something you must realise. You may switch of this autosave by unchecking the "Autosave on compile" entry, but then you will have to enter a filename for your source code before each compile!

Syntax errors in Bascom
Syntax errors are errors in the Basic language. If you wanted to type Config, but your finger slipped and the result is Confih. The word Confih is not recognised by Bascom and when compiling, Bascom will report this as an error. Most syntax errors are detected in the compile phase. When errors are found, Bascom will not proceed to produce the bin-file, but will instead report the errors in a bottom window. Let us try this and modify the ledflasher.bas program as follows:



When we compile (F7) the result will be:



Double-click on the first line in the error report window will highlight the corresponding text line:



This makes a quick jump to the offending text line much easier, especially in large programs.
The first line says: "Assignment error...". We apparently forgot to declare a variable and Bascom wants a declaration for each variable you use. More on this later. For now, just remove this line.
The second line says: "Unknown statement...". Again, our fingers slipped on the keyboard, we must add an extra "o" in the Loop statement.
The last line is because Bascom expected the Do statement to be followed somewhere by a Loop statement. Because of the typo, Loop is not found. Correcting the 'Lop' statement would solve this.
Often, one syntax error generates more than one error report. Also, not all error reports are obvious, Bascom could use some improvement in this aspect!
Recompile, and there should be no errors.

Bascom will find syntax errors, but not logical errors! If your thinking is at fault, recheck your brain before recompiling...

Simulating a program
When trying out new ideas, it can be useful to first see if your logic is correct. The Bascom simulator can let you step through a program while showing the status of important controller hardware. You can check the status of input or output pins, the value of variables and hardware registers and program memory. Bascom goes one step further: you can also simulate how hardware attached to the controller influences your program. For example you can simulate an LCD display attached to the controller, send pulses from imaginary buttons or switches to input pins or interrupt pins, connect a voltage source to an ADC-input etc. More on this later.
First, let us see how we can simulate our ledflasher program. Open the ledflasher.bas source file and compile (F7). Bascom generates the bin-file, but also a dbg and obj-file, which are used in the simulator. Start the simulator: Program/Simulate (F2):



The simulator window shows the program text in the bottom part. The upper part has various buttons for simulator commands and tabs for showing variables or registers etc.
When we simulate the program we will 'let it run' in Bascom and we want to show the status of input/output pins after each instruction is simulated. This will slow down the simulator considerably, but for this example it is unimportant. To show the 'hardware', press the LCD button and do the continuous update press the 'Refresh variables' button:



The 'hardware' window appears:



Now, if you press the 'Run program' (F5) button, Bascom starts the simulation, a small blue arrow points the the current program line:



Notice how all LED's on PortD switch on after the line 'PortD = 255' is executed and switch off after the line 'PortD = 0'.
(Note that the hardware simulator shows eight LED's on PortD, where the AT90S2313 only has the seven lower pins wired to the outside world. Also note that the hardware simulator will only show LED's for actual input/output registers available on the selected controller. Try this out by changing the line "$regfile = "2313def.dat"" to "$regfile = "m128def.dat", recompile, restart the simulator, press the LCD button. The ATMega128 has seven input/output registers!)
We can stop the program with the 'Stop program' button. Most often, simply running the program and trying to see what is happening in the hardware simulator window is not very useful. Instead, go through the code with the 'Step into code' (F8) button. The simulator pauses after each line is executed, giving you time to see what happened in the hardware simulator window. Note that simulating the 'waitms 50' line takes much more time than 50 milliseconds. In general, executing wait statements in the Bascom simulator slows down things too much. Insert a line "$sim" after the line "$crystal = 4000000". Recompile, restart the simulator and note that all waits are skipped. Caution: make sure you remove the "$sim" line when you are done with the simulator and want to recompile to send program code to the controller chip. If you forget this, all wait loops in your program are skipped which will result in your program probably not working!

Working with variables.
(If you need to, first read the part on variables)
Start Bascom, do File/New and enter the following text:
$regfile = "2313def.dat"

Dim Counter As Byte

Counter = 1

Do
  Counter = Counter + 1
Loop

End
Compile and start the simulator. In the first cell in the variable tab enter the name of the variable "Counter":



Click on 'Refresh variables'. This will update the variable fields as the program runs. Click repeatedly on 'Step into Code(F8)'. Observe the value of Counter shown in the variable field:



Click on 'Run program(F5)'. Observe the variable Counter increasing until 255, after which it will overflow to 0.

The Locals tab can show the value of variables which are local to a subroutine or function.
The Interrupt tab shows the various interrupts. You may force an external interrupt on the Int0/Int1 input pin.

TOC