 |
|
 |
| Parallax Forums > Public Forums > SX Microcontrollers, SX/B Compiler and SX-Key Tool > library development | Forum Quick Jump
|
|  Peter Verkaik Registered Member
        Date Joined Jul 2004 Total Posts : 3933 | Posted 1/6/2006 9:04 AM (GMT -8) |   | 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
File Attachment : lib_total.inc 92KB (text/plain)This file has been downloaded 412 time(s). File Attachment : project_template.src 15KB (application/octet-stream)This file has been downloaded 296 time(s). | | Back to Top | | |
    |  Rsadeika Registered Member
        Date Joined Feb 2005 Total Posts : 679 | Posted 1/7/2006 11:14 AM (GMT -8) |   | | I have looked through your code, and sort of get a general feel for what you were trying to accomplish. Trying to create a library of VP's to be used with SX/B, well, I do not know if it's worth the time and energy. Meaning, all of the trouble that you would have to go through in order to get it to work correctly, you should just do it in asm.
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 | | Back to Top | | |
 |  Peter Verkaik Registered Member
        Date Joined Jul 2004 Total Posts : 3933 | Posted 1/7/2006 2:05 PM (GMT -8) |   | 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
| | Back to Top | | |
  |  Guenther Daubach Registered Member

       Date Joined Jul 2004 Total Posts : 1326 | Posted 1/7/2006 5:23 PM (GMT -8) |   | Let me try to make a definition for a VP (Virtual Peripheral) - please post your comments when you think I'm wrong...
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 | | Back to Top | | |
  |  Guenther Daubach Registered Member

       Date Joined Jul 2004 Total Posts : 1326 | Posted 1/8/2006 4:04 AM (GMT -8) |   | 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 | | Back to Top | | |
  |  Guenther Daubach Registered Member

       Date Joined Jul 2004 Total Posts : 1326 | Posted 1/8/2006 7:11 AM (GMT -8) |   | Hi 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ünther | | Back to Top | | |
 |  Rsadeika Registered Member
        Date Joined Feb 2005 Total Posts : 679 | Posted 1/8/2006 10:06 AM (GMT -8) |   | Thanks, I certainly got a better understanding of a VP. Now, thinking about the library, I think that probably the VP's would be in a separate library, and commands, or custom stuff would be in another file. Since their is a nine file limit, their has to be some thought put into how and what goes into what file.
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
| | Back to Top | | |
 |  Rsadeika Registered Member
        Date Joined Feb 2005 Total Posts : 679 | Posted 1/8/2006 12:51 PM (GMT -8) |   | So, here is my idea, below I have inserted a piece of code that I used in another thread. This is the standard pause, turn on an led, and then pause, turn off the led. The reason I chose this example is because it is pretty simple in code style, and it has an element to it where it could be used in asm, and SX/B
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
| | Back to Top | | |
 |  Peter Verkaik Registered Member
        Date Joined Jul 2004 Total Posts : 3933 | Posted 1/8/2006 10:54 PM (GMT -8) |   | To replace a SX/B command XXXX I would suggest use a macro name mXXXX. 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 {[, | *] 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
| | Back to Top | | |
 | Forum Information | Currently it is Tuesday, February 09, 2010 3:18 AM (GMT -8) There are a total of 415,988 posts in 57,637 threads. In the last 3 days there were 78 new threads and 885 reply posts. View Active Threads
| | Who's Online | This forum has 18517 registered members. Please welcome our newest member, try388. 50 Guest(s), 7 Registered Member(s) are currently online. Details Rsadeika, Graham Stabler, humanoido, Bob Lawrence (VE1RLL), Rick Brooks, JohnandElspeth, mikestefoy |
Forum powered by dotNetBB v2.42EC SP2.02 dotNetBB © 2000-2010 |
|
|