Internals
PIC32-Basic is an application that sits on top of Micro-BOS and can be loaded using the X-Modem load of Micro-BOS
Under normal circumstances the system will boot through Micro-BOS and go into the PIC32-Basic application. The memory addresses given here are an example only and are quite likely to change. For the 512k device there is about half of this available for user programs.
The 32k of RAM space is divided up as shown, again the actual values are likely to change. The program and variable RAM is shared, the program grows towards the high address values and the variables grow downwards. When the two meet the RAM is full.
The following system resources are used either the Micro-BOS or PIC32-Basic:
| Resource | Description |
| UART2 | This is connected to the USB virtual COM Port and is the main source of communication |
| JTAG | Is disabled |
| Timer 5 | Set up to cause a high priority interrupt every 200uS, this updates the tick counter and also runs the scheduler. |
| RTC | Is initialised and started |
| RB14* | Used as CTS UART2 but H/W handshaking is disabled by default |
| RB8* | Used as RTS UART2, but H/W handshaking is disabled by default |
| RC15 | Used for SD Microcard LED indicator |
| RF1* | Used as Programming input, tied to +3v3 with 10k resistor |
| RC12 | Connected to card detect on the on board SD card and normally held high with a 10k Resistor |
| RF0 | Chip select for SD card |
| RC13 RC14 |
Used for RTC clock oscillator crystal |
All of the above resources go to making the system work and with the exception of those marked * should not really be altered.
System Defaults
Some aspects of the program can be changed by using special keywords defined as constants. Defaults are loaded at start up or on reset and so remain for as long as the power stays on. They revert back to the default values (shown) at reset. These can be placed in the ‘auto.bas’ file or in Flash.
To change one of the following constants simply define a constant with the same name. The system will recognise the new constant at start up if it is stored in flash or the keyword 'sysreset' can be used to force the new constant to be recognised.
constant SYS_DEF_PORT 2
The default UART is set by the BIOS and is carried over to the application. This changes all of the output to another UART if required. Use this with care as changing to a port that is not connected may require a re-install of Basic.
constant SYS_DEF_PATH "ram;flash"
This controls the search order for subroutines, the default is shown that RAM is searched first, this can be reversed.
constant SYS_STRING_LEN 128
The default length used for string variables including the terminating 0. When a string variable is created it will be created with this length by default, i.e dim a$
constant SYS_FLASH_START <see sys keyword for default>
The beginning of Flash where user, Basic subroutines and constants are stored. This can be moved to make way for other storage requirements.
constant SYS_FLASH_END <see sys keyword for default>
This minus the start determines the total area free for Basic subroutines.
For semi-permanent changes to these defaults the constant can be defined and saved to Flash, for example if it is prefered that the string length be set to 20 then typing the following:
new
constant SYS_STRING_LEN 20
fsave all
This will create a constant and then save it to Flash, when the processor resets it will be discovered at start up and set the default string length to 20. As an alternative it can be placed in a file 'auto.bas':
constant SYS_STRING_LEN 20
function auto
sysreset
endf
The 'auto.bas' file will be opened on reset and the function with the same name will be run (see below). This happens AFTER the defaults have been set and it is possible to reset them in this file to new values. The technique is to set the constants as required and call 'sysreset'. This can of course be done at any time, not just in 'auto.bas'
Auto
This name (filename and function name) is special in that if it is given to a function name or a file name "auto.bas", PIC32-basic will attempt to run it on start up. If there is a file called 'auto.bas' on the SD Card when the board is reset, the file will be opened and a search will be made for a function called auto. If it is there is will be run before any other actions.
If there is a function named 'auto' in flash then this will be run before any further actions. The order in which these to actions take place are RAM, Flash and then File. As the RAM will not contain anything at start up the realistic order is Flash and then File.
Speed
The trade of for interactivity and ease of use is speed. To give some idea of what can be expected the following code may prove useful:
// can be used. The tick counts at 5MHz so 5000 ticks is 1ms
function speed2
dim t_start, t_end, c, t_ms#, lps#
t_start=tick()
c=7*3
t_end=tick()
c=t_end - t_start // ticks
t_ms#=c/5000 // ms for 1 instruction
lps#= 1000/t_ms#
print "ticks=";c;" ms=";format$("#.###", t_ms#);" lps=";format$("####", lps#)
endf
The above uses the tick timer to record the start and finish of the calculation and storage 'c=7*3'. This is then presented in three formats and the results are:
ticks=4163 ms=0.833 lps=1201 RAM
ticks=4193 ms=0.839 lps=1192 FLASH
The Flash timing was carried out after saving speed3 to flash and running it again. No account has been taken of the time it takes to store the tick value and so the results show a slightly pessimistic view in terms of speed.
A more realistic measure of speed would be how fast it would be possible to create an external event.
dim a,b
while 1=1
portb "eos" 0 // set high
portb "eoc" 0 // set low
wend
endf
The above function (port E needs setting to be an op first) alternately sets port E bit 0 to high and low forever. The results are 200uS high and 400uS low.
The above is the actual output from the scope, each division is 200uS.