Wifi bios for MB03+
version 1.6, released: 3.4.2021
News in 1.6.:
- "send_block- fix: now running correctly
- "send_block" and "rece_block" changes:
- key test routine removed for higher speed
- reg A status removed on output
- C/NC added on output
- "turnon_wifi": turns wifi on, or returns wifi state (without setting it on)
version 1.5, released: 11.12.2020
Authors: Busy, Hood
Acknowledgements: LMN, Lanex, Shrek, "Uart" authors (from Specnext)
This Wifi bios is a very simple piece of code but can do a magic. If you write an application bind with this bios, you can quite easily transfer your application to another platform simply by writing a new bios for the platform. Bios is like a software driver for a sound card that we know from a PC world. Bios consists of several useful routines that cooperate with the wifi module
For usage of individual routines, please, see inside the bios files itself.
Now, some more info follow....
Bios goes hand in hand with application. The features of application and bios layer are quite flexible:
- recommended maximum bios length is #1000 bytes (practically unlimited, if you leave plenty of space for it in memory)
- bios can be both, relocable or non relocable
- bios working address range is 0..#FFFF.
First, you will need to load bios to memory together with the application.
Loading the bios should be well configurable (e.g. loading in basic).
10 LOAD "application" CODE adr_app
20 LOAD "wifibios" CODE adr_bios, 4096
30 RANDOMIZE USR adr_bios : REM Bios installation
40 RANDOMIZE USR adr_app : REM Start application*
(*)The first Bios call (CALL adr_bios) may be also called from the application:
CALL adr_bios ;first bios call. Non relocable bioses set all absolute addresses,
;then text version address is returned in HL and BC contains bios
;version information. Relocable bioses only return HL and BC registers.
Practical example in bios code:
org adr_bios ;structure is sequence of JRs to individual routines
get_vers_inst jr get_version_install ;adr_bios+0
ret ;adr_bios+2 (reserved)
wifi_on jr turnon_wifi ;adr_bios+4
wifi_off jr turnoff_wifi ;adr_bios+6
set_baud jr set_baud_rate ;adr_bios+8
ret ;adr_bios+10 (reserved)
clear_rece_buff jr clear_receive_buffer ;adr_bios+12
An example of bios calls definitions:
adr_bios equ ... ;bios starting address
defined in the application, can be any address.
gver_inst equ adr_bios+0
wifi_on equ adr_bios+4
wifi_off equ adr_bios+6
set_baud equ adr_bios+8
clear_rece_buff equ adr_bios+12
The application calls bios routines with standart calls (eg. "call set_baud").
Remark for Baud rate control
Since there can be a lot of different baud rates, it is not reasonable (and maybe not possible)
to hard assign some common baud rates for input values. Instead of this, supported rates belonging
to used hardware are indexed from 0, and number N of these baud rates and one baud rate value
according to input index in range 0..N-1 is returned by call "set_baud" in registers D and BC.
A more complex aplication can enumerate all possible baud rates by calling "set_baud"
with CY=0 and index 0..N-1, captures what value of baud rate belongs to what index and
creates table of possible rates. After user selects baud rate from the table, application
sets selected rate by call "set_baud" with CY=1 and A = index of selected baud rate.
An easier application can keep index of baud date, calls "set_baud" with CY=1 and index
and shows number 10 * BC what means what baud rate is actually selected.
User can increment / decrement this index and application again will
call "set_baud" and shows what baud rate is actually selected.
When "set_baud" returns CY=1 and BC=0, used index means not valid baud rate
and application shound not allow increment / decrement to this index.
Bios is usually a simple piece of code which goes hand in hand with the hw Wifi configuration.
It is like software driver for a sound card that we know from the PC world.
An unique bios have to be written with every new Wifi hw.
Vice versa, if you want another platform application to run on your hw Wifi configuration,
then bios for your hw itself is not enough. You have to take the application and adapt it
for your bios/HW. However, based on this bios concept, the adaptation should be minor and easy to do.
If you need to write services not listed in the specification above, just, continue on offset adr_bios+24.
At the same time, you may increase version number in BC for your new applications
to know the bios has been amended or has a certain service or not.
When writing your bios it is advisable to backup all necessary registers for ease of use.