library development
Peter Verkaik
Posts: 3,956
Ray,
I attached a template source file, together with a library include file.
The library consists of macros to easily include uart,timer,stack,queue,i2c.
Unfortunately SPI is not included (never got around to do that).
The library allows you to define VP's in the ram bank areas.
For identical VP's,·the vp code is inserted only once, but each vp declaration
has its own data area.
For example, if you define 3 transmit uarts, the code for a transmit uart is included
only once, but there are 3 data areas.
Also the·threads in the isr are setup as defined by a ratio number
that you supply with the vp declaration.
See the template source for how vp's are declared.
Assemble and study the generated listing file.
The library is by no·means perfect. I believe the code in it to be correct.
It may give you an idea how a library could be setup. I tried to·put the
different vp's in their own file, but the assembler would not allow more
than 9 includes, so instead I just use 1 file. All code is wrapped into macros,
so no code is generated unless called by the main source.
Please comment on this setup or start a new thread for library development.
It would be nice if the library was made compatible with SX/B (if possible).
The source and include file are both just text files. Can be opened
in sxkey edtor (select file type All files to open the include file)
regards peter
I attached a template source file, together with a library include file.
The library consists of macros to easily include uart,timer,stack,queue,i2c.
Unfortunately SPI is not included (never got around to do that).
The library allows you to define VP's in the ram bank areas.
For identical VP's,·the vp code is inserted only once, but each vp declaration
has its own data area.
For example, if you define 3 transmit uarts, the code for a transmit uart is included
only once, but there are 3 data areas.
Also the·threads in the isr are setup as defined by a ratio number
that you supply with the vp declaration.
See the template source for how vp's are declared.
Assemble and study the generated listing file.
The library is by no·means perfect. I believe the code in it to be correct.
It may give you an idea how a library could be setup. I tried to·put the
different vp's in their own file, but the assembler would not allow more
than 9 includes, so instead I just use 1 file. All code is wrapped into macros,
so no code is generated unless called by the main source.
Please comment on this setup or start a new thread for library development.
It would be nice if the library was made compatible with SX/B (if possible).
The source and include file are both just text files. Can be opened
in sxkey edtor (select file type All files to open the include file)
regards peter
inc
92K
Comments
That solved that problem. Now, I am going to start looking at what you got here, may take awhile. As for the implementation to SX/B, input from other people may be required for this, any ideas. My first attempt at that is failing miserably.
Thanks again
Ray
The first thing I may do is, the .inc file, turn it into a text file so it can be easily printed out within 80 column format. Then I can look and study the print out; I am an old timer, I like to have the paper work in my hands, make notes in the side columns, that sort of stuff.
It is imperative to look at or print the generated .lst file.
That shows what words will be stored at what address.
The listing is namely not in address order.
Compile time variables are used to keep track of data areas and code areas,
and at appropiate locations, labels are generated. For example the isr thread code:
··the addresses for the isr jump table are declared using equ directives (so their location is known).
· When you declare a vp, the location of the isr part of that vp is written
· to the correct isr jump table entry (by a preceeding org statement).
I will give an overview·of the used variables shortly.
regards peter
·
You can load it in the sxkey editor (tabs are used to format the text)
to keep the formatting.
regards peter
Post Edited (Peter Verkaik) : 1/6/2006 6:31:04 PM GMT
Now, creating a library of some common SX/B commands like Samuel is looking into, in asm, now that is a diifferent story. In asm I could see a use for all of the SX/B commands being available. Now, I know their has been a discussion about the structure or format of the command, in asm,·if it could be done using a macro, and a subroutine in an efficient manner, that might be the way to go. I can see a library set up in such a way that it could be called within asm or SX/B and be able to use the contents. For SX/B, the commands could be of the custom variety. The trick I guess is to have a format where the command could be used in asm or SX/B without resorting to a lot of overhead.
For SX/B, the amount of commands are still growing, so, to start creating a whole bunch of custom stuff, may not be the prudent thing to do. Although I do see a possible need for, having created a custom routine, in SX/B, using inline, maybe cleaning it up, putting into the common lib could be usefull.
I have never really gotten into a habit of creating lib's to hold my custom tools. So I usually end up recreating the wheel all the time, because it is easier than to look through all the source code to find that special piece of code. I guess now would be a time to start forming some new habits.
Thanks
Ray
My library was intended for assembly and make it easier to use VP's.
VP's have an isr part that runs independantly and usually do the hardware I/O,
its main code part uses flags and buffers to send and receive data or setting
parameters, for example for PWM. SX/B commands can not create a VP
with a single command, whereas macros can, as this as done by the library.
The mechanisms in the library show a way how to do that.
Normal commands can of course also be written as macros. The library
shows how a single piece of code (eg. a single command) is inserted
only once, any duplicate use of such a command would merely call
this single piece of code. Also note that those pieces of code can be
called from anywhere as a jump to that code is placed in the lower·half
of·a page (SX/B uses this also when you declare a SUB in advance).
With a macro you don't need to declare its use in advance.
So its quite possible to wrap the assembly code of an SX/B command
into a macro.
Like you, I don't think the library can be made SX/B compatible,
as we don't know how SX/B develops in the future. However, SX/B could
implement a mechanism as shown in the library, to have VP commands in SX/B,
much like the Javelin Stamp has. But that is up to the SX/B developers.
But it could be done.
regards peter
So, would somebody care to enlighten me on the subject, I keep thinking that this is something that is very important, and should not be left out of SX/B, or asm for that matter. I might be making a bigger deal of this than should be.
Thanks to anybody that wants to give it shot.
Ray
The family of SX controllers was designed with almost no "built-in" peripherals, like UARTS, ADCs, DACs, I²C/SPI interfaces, timers, etc. (with the exception of a comparator, common to all SXes, and two general purpose timers/counters only available in the SX48/52 devices). The idea behind this design was to compensate the lack of such hardware peripherals by a high processing speed (50 MIPs and more), allowing to mimic peripherals in software. IMO, this is one of the most important SX design features. Instead of searching through tons of data sheets published by other microcontroller manufacturers, just to find the type of controller that might match your current need, there are only a few SX devices available, mostly differing in package type, and number of I/O pins.
The idea behind the SXes is that you can "implant" the peripherals you need for a specific task just by writing the right software (plus, maybe, a few external discrete components attached to I/O pins). Due to the SXes exceptional processing speed, compared to other controllers, this can be achieved in many cases.
So, in general, a Virtual Peripheral is "simply" a piece of code that "mimics" a hardware peripheral in software. Such VP code must not necessarily be implemented as part of an interrupt routine. When timing is not critical, VPs can nicely be implemented in some part of the main program loop. An I²C master VP may be an example.
On the other hand, many peripherals require an exact timing, like timers (this is why they called "timers"), serial receivers/transmitters, etc. Here, another important feature of the SXes comes into play: The RTCC roll-over controlled interrupts. They allow you to execute specific code in exactly timed intervals. As many peripherals have a need for such an exact timing, most of the popular VPs are implemented as part of an interrupt service routine (ISR), like serial asynchronous receivers/transmitters, timers, ADCs, or PWM drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
You said:
So, in general, a Virtual Peripheral is "simply" a piece of code that "mimics" a hardware peripheral in software. Such VP code must not necessarily be implemented as part of an interrupt routine. When timing is not critical, VPs can nicely be implemented in some part of the main program loop. An I²C master VP may be an example.
I think without an isr part, it is no longer a 'peripheral' but just a subroutine. The idea of a peripheral
is that does its thing while the main code continues to do its own, hence a VP must have an isr part,
because that is the only way two pieces of code can appear to run simulteneously. However, if that
subroutine is programmed as a statemechine called frequently from the mainloop (think of this as
a programmed interrupt call), then it can be considered a VP.
regards peter
·
I almost agree with you - in the end - it's just a question of definition. IMO, any code that deals with I/O to replace a peripheral hardware found in other controllers by software can be called a "Vitual Peripheral", no matter if the associated code is fully or partly executed in the ISR, or in the main code. I found the following definition in an older Scenix document:
"Virtual Peripheral concept enables the “software system on a chip” approach. Virtual Peripheral, a
software module that replaces a traditional hardware peripheral, takes advantage of the Scenix
architecture’s high performance and deterministic nature to produce same results as the hardware
peripheral with much greater flexibility.
The speed and flexibility of the Scenix architecture complemented with the availability of the Virtual
Peripheral library, simultaneously address a wide range of engineering and product development
concerns. They decrease the product development cycle dramatically, shortening time to production to
as little as a few days."
I agree with you, most VPs require a deterministic timing, and thus are ISR-controlled. Those who don't, usually are structured a state machines, frequently but not necessarily periodically called from the main loop. Where is does not matter if the state machine is part the main code, or located in a separate subroutine. Important is that the code makes the SX behave as if a piece of hadware would be integrated on the chip handling this peripheral task. As mentioned in my previous post, an I²C master would be an example for a VP that does not require an exact timing, as the communication is solely controlled by the SCL signal generated from the master.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
It is a point of view. One could also say:
A VP is a bunch of code and data, that makes up a logic unit, aka peripheral, with a well defined
software interface, by which the·application communicates with the·peripheral.
The best examples·in my library not using isr code, are the queue and stack.
Both have a data area and two subroutines to store and retrieve data. How these
are implemented is of no concern of the application. The functions are well defined
and·that's what the application uses.
regards peter
·
yes, I absolutely agree. You can look at a VP from "inside" and "outside".
Let's assume a serial transmitter. With (as you said, and this is of high importance) a "well-defined" software interface, the application code "inside" the controller must not care if this serial transmitter is realized in hardware, or in software. Most likely, there is a transmit data register, where the application stores the byte to be sent, and there is some kind of a "busy" flag. As long as this flag is set, the transmitter is busy, and no new data may be written to the transmit register. When it is clear, the application can write another byte to the transmit data register, and then set the busy flag to indicate the transmitter that it has another byte to send. In this example, the interface simply consists of one register, and a flag.
From the "outside", you only "see" a serial out pin going low and high according to the specified serial transfer protocol, and it does absolutely not matter if this is caused by some special hardware inside the controller, or by software, clearing and setting this output pin accordingly.
Besides a well-defined software interface, another important aspect when designing VPs is that their operation must be transparent to the rest of the program code. It it obvious that the VP code must not change any register contents, status flags, etc. causing unpredictable results in other parts of the code. What developers sometimes overlook is the fact that execution of VP code "steals" execution time from the main code, so you can't - for example - use a delay loop in the main code, expecting that this provides a constant delay time when this loop is periodically interrupted to handle the VPs in the ISR.
Well, there is no need telling YOU all that - you are the expert here but maybe, our little discussion is good to provide some ideas for other readers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
After reading the posts for the VP's, I can see a real need for being able to implement VP's within SX/B. In the very near future I want to test and experiment with the Sharp IR sensors, as it turns out the sensor needs access to an ADC chip. So, now if I have an A/D VP, I could eliminate the need for one or multiple amounts of ADC chips. I could do experiments like, running three sensors of one A/D VP, or have three A/D VP's running that would service a·sensor, or ...
As for taking the library concept from theory to real application, I have an idea for this. As soon as I get the big picture resolved,·I will post it, and then we can go from there. I like to use and implement the KISS principle, so I am thinking in terms of something that is real simple to start, but can cover both the asm, and SX/B aspect.
Thanks
Ray
What I am talking about is the pause command·aspect. In SX/B I noticed that the code is not optimized, and it has been stated many times before that SX/B is a learning tool, and the compiler is not optimized. What that means is, when you use the pause command, I will just stick with that command for the time being, in SX/B it is like a macro, the code,·that makes up the pause command, gets used, or expanded, with each use of pause.
So, what I am thinking is that, first off, piddle with the pause part of the listed code so it looks like a command, name the command wait. That way we could have a good example of a macro wrapper implementing a subroutine, that could be the profile for all other entries into the lib. Then discuss where in the main code you would have to put the include statement, and what the structure of the new wait command is supposed to look like within the include file.
The reason I chose the pause or wait as the candidate,·is because once the wait command·gets worked out in asm then it could be tried out as an optimized replacement for the pause command in SX/B. That way it would be a learning experience as to how to use a library with SX/B. I left·the code example·in SX52 format, but it is a very simple task to make it work in SX28 format.
Any ideas, maybe somebody has a better suggestion.
Thanks
Ray
******CODE
For starters I guess:
WAIT macro
call _wait
endmacro
_wait:
Loop··· ;If·I remember correctly this would time in at 1.3 seconds at 50MHz
········· ; one of the improvements could be to make this 1 second at all frequencies.
·decsz Counter1
·· jmp Loop
·decsz Counter2
·· jmp Loop
·decsz Counter3
·· jmp Loop
ret
************************************
;;;
;; Tut003.src
;;;
device sx52
device oschs3····· ;High speed crystal, 1MHz - 75MHz
IRC_CAL IRC_FAST·· ;For use with external crystal/oscillator
freq 50_000_000
reset Main················ ;Label where the program starts
;Data memory
;org $08
·org $0A··········· ;SX52 -> $0A, SX28 -> $08 Data memory
·························· ;························ satrt
Counter1 ds 1
Counter2 ds 1
Counter3 ds 1
;End of data
;Code memory
·org $0············ ;Code memory start position
Main
·mov w,#$1f········ ;
·mov m,w
·mov !rd,#%11111110
Loop
·decsz Counter1
·· jmp Loop
·decsz Counter2
·· jmp Loop
·decsz Counter3
·· jmp Loop
·clrb rd.0
Loop1
···· ·decsz Counter1
·· jmp Loop1
·decsz Counter2
·· jmp Loop1
·decsz Counter3
·· jmp Loop1
·setb rd.0
·jmp Loop
jmp $····· ;I like to use this to end my code
·········· ;at this point it is in endless loop.
end
The parameters for a SX/B command would also be passed to the macro,
and here is the first problem.
SX/B Syntax: PAUSE Value1 {[noparse][[/noparse], | *] Value2}
A macro parameter is either a constant (used as #constant) or a name (used as ??name??)
but it cannot be both. So many SX/B commands can not have a single macro equivalent.
It is possible to define more macros to cover the SX/B parameter formats.
A better option is·to pass a constant that serves as format specifier so the macro
can distinquish between parameter formats.
mPAUSE macro format, value1, value2
if format=0 then use mPAUSE·value1
if format=1 then use mPAUSE value1,value2
etc. for all possible SX/B parameter formats
Secondly, in case of pause, one should not be required to define variables used.
Instead, some temporary system variables should be used.
Note that a SX/B command PAUSE 100
would need to be replaced by
asm
mPAUSE 0,100,0
endasm
in your code, so there (always) is a change in the parameter list.
regards peter
·
At the start of isr I save m and few other registers in the fifo,
and of course these must be restored at the end of the isr.
The error is corrected in the attachement.
regards peter