Shiftout/In VP?????????
SamMishal
Posts: 468
Hi All,
I have seen VPs for UARTs, I2C, etc. BUT I have not
seen any for SHIFTOUT/IN
does any one know where I can get my hands on code
to implement Shiftout/In code, like the stuff in the SX/B and Stamp_Basic
Thanks all
Samuel
·
I have seen VPs for UARTs, I2C, etc. BUT I have not
seen any for SHIFTOUT/IN
does any one know where I can get my hands on code
to implement Shiftout/In code, like the stuff in the SX/B and Stamp_Basic
Thanks all
Samuel
·
Comments
I will soon be using shiftin/out also so this is of some interest to me.
Yes I guess I can rob some code from the List file produced by the SX/B compiler
but I was hoping I would not have to do this since the list files are a bit hard to decipher.
I was doing some research and I think that the SPI Vps are close to what I want except that
they do not have anything to do with M/LSBPRE/POST ....or at least as far as I can see from
reading some code so far.
I hope some one with bigger brains than mine knows of any code or a place I can download some.
I am trying to avoid having to decipher list files from SX/B.
I wish Mr. Gunther had added something about this stuff in his excellent and very handy book.
Regards
Samuel
I have tried this code in SX/B, it compiled and loaded on the SX and ran
I did not test it with actual connection to anything though.
Here is the code and the .LST file with it.
If you can make heads or tails of the code that is generated you are a better man than me.
I am going to be loosing whatever grey cells are left in my already tiny brain
to figure this out.
Here is the stuff, let me know what you make of it.
===============Basic Code==========================
DEVICE········· SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ··········· 4_000_000
·Testin·var byte
· PROGRAM Start
Pgm_ID:
Start:
Main:
·ShiftIn RB.0,RB.1,MSBPRE,Testin
· GOTO Main
============Assembly code============================
· 1··················· ;· *** COMPILED WITH SX/B VERSION 1.21· 04/27/2005 ***
···· 2·················
···· 3· 071B· 0F7F····· DEVICE········· SX28, OSC4MHZ, TURBO, STACKX, OPTIONX ;DEVICE········· SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
···· 4·················
···· 5··················· ; DEFINE SYSTEM VARIABLES
···· 6· =00000000······ __RAM········ EQU· $00
···· 7· =00000004······ __PARAMCNT··· EQU· FSR
···· 8· =00000008······ __PARAM1····· EQU· $08
···· 9· =00000009······ __PARAM2····· EQU· $09
··· 10· =0000000A······ __PARAM3····· EQU· $0A
··· 11· =0000000B······ __PARAM4····· EQU· $0B
··· 12· =000000FA······ __TRISA······ EQU· $FA
··· 13· =000000FA······ TRIS_A······· EQU· $FA
··· 14· =000000FB······ __TRISB······ EQU· $FB
··· 15· =000000FB······ TRIS_B······· EQU· $FB
··· 16· =000000FC······ __TRISC······ EQU· $FC
··· 17· =000000FC······ TRIS_C······· EQU· $FC
··· 18· =000000F5······ __INTPARAMFSR EQU· $F5
··· 19· =00000008······ __REMAINDER·· EQU· $08
··· 20·················
··· 21················· ; Define ShiftIn & ShiftOut Constants
··· 22· =00000000······ LSBFIRST····· EQU· 0
··· 23· =00000001······ MSBFIRST····· EQU· 1
··· 24· =00000000······ MSBPRE······· EQU· 0
··· 25· =00000001······ LSBPRE······· EQU· 1
··· 26· =00000002······ MSBPOST······ EQU· 2
··· 27· =00000003······ LSBPOST······ EQU· 3
··· 28·················
··· 29·················
··· 30· =003D0900······ FREQ 4_000_000·················· ;FREQ··········· 4_000_000
··· 31· =00000004······ __FREQMHZ···· EQU· 4
··· 32·················
··· 33·················
··· 34· =0000000C······ Testin······· EQU· 0x0C········· ;····· Testin· var byte
··· 35·················
··· 36· 07FF· 0A00····· RESET __PROGSTART··············· ;· PROGRAM Start
··· 37· =00000000······ __PROGSTART:···················
··· 38· 0000· 0783······· JNB TO,@__RESTORETRIS········
······· 0001· 0010 0A28
··· 39· 0003· 0663······· JB PD,@__POWERUP·············
······· 0004· 0010 0A15
··· 40· 0006· 0040······· CLR W························
··· 41· 0007· 0059······· MODE $09·····················
··· 42· 0008· 0006······· MOV !RB,W····················
··· 43· 0009· 0024······· MOV FSR,W····················
··· 44· 000A· 005F······· MODE $0F·····················
··· 45· 000B· 0C00······· CJE FSR,#0,@__POWERUP········
······· 000C· 0084 0643 0010 0A15
··· 46· 0010· 0CFF······· CJNE FSR,#$FF,@__RESTORETRIS·
······· 0011· 0084 0743 0010 0A28
··· 47· =00000015······ __POWERUP:·····················
··· 48· 0015· 0065······· CLR RA·······················
··· 49· 0016· 0066······· CLR RB·······················
··· 50· 0017· 0067······· CLR RC·······················
··· 51· 0018· 0C08······· MOV FSR,#$08·················
······· 0019· 0024
··· 52· 001A· 0764······· SB FSR.3·····················
··· 53· 001B· 0584······· SETB FSR.4···················
··· 54· 001C· 0060······· CLR IND······················
··· 55· 001D· 03E4······· IJNZ FSR,@$-3················
······· 001E· 0010 0A1A
··· 56· 0020· 0CFA······· MOV FSR,#TRIS_A··············
······· 0021· 0024
··· 57· 0022· 0CFF······· MOV IND,#255·················
······· 0023· 0020
··· 58· 0024· 02A4······· INC FSR······················
··· 59· 0025· 0020······· MOV IND,W····················
··· 60· 0026· 02A4······· INC FSR······················
··· 61· 0027· 0020······· MOV IND,W····················
··· 62· =00000028······ __RESTORETRIS:·················
··· 63· 0028· 0CFA······· MOV FSR,#TRIS_A··············
······· 0029· 0024
··· 64· 002A· 0200······· MOV !RA,IND··················
······· 002B· 0005
··· 65· 002C· 02A4······· INC FSR······················
··· 66· 002D· 0200······· MOV !RB,IND··················
······· 002E· 0006
··· 67· 002F· 02A4······· INC FSR······················
··· 68· 0030· 0200······· MOV !RC,IND··················
······· 0031· 0007
··· 69· 0032· 0064······· CLR FSR······················
··· 70· 0033· 0010······· JMP @Start···················
······· 0034· 0A37
··· 71· =00000037········ ORG $+2· ; FOR DEBUGGER······
··· 72·················
··· 73· =00000037······ Pgm_ID:························· ;Pgm_ID:
··· 74·················
··· 75·················
··· 76· =00000037······ Start:·························· ;Start:
··· 77·················
··· 78·················
··· 79· =00000037······ Main:··························· ;Main:
··· 80·················
··· 81· 0037· 0CFB······· MOV FSR,#TRIS_B··············· ;····· ShiftIn RB.0,RB.1,MSBPRE,Testin
······· 0038· 0024
··· 82· 0039· 0500······· SETB IND.0···················
··· 83· 003A· 005F······· MODE $0F·····················
··· 84· 003B· 0420······· CLRB IND.1···················
··· 85· 003C· 0200······· MOV !RB,IND··················
······· 003D· 0006
··· 86· 003E· 0018······· BANK $00·····················
··· 87· 003F· 006C······· CLR Testin···················
··· 88· 0040· 0C08······· MOV __PARAM2,#8··············
······· 0041· 0029
··· 89· 0042· 0C05······· MOV __PARAM3,#5··············
······· 0043· 002A
··· 90· 0044· 02EA······· DJNZ __PARAM3,@$·············
······· 0045· 0010 0A44
··· 91· 0047· 0403······· CLC··························
··· 92· 0048· 036C······· RL Testin····················
··· 93· 0049· 0706······· MOVB Testin.0,RB.0···········
······· 004A· 040C 0606 050C
··· 94· 004D· 0C02······· XOR RB,#%00000010············
······· 004E· 01A6
··· 95· 004F· 0C05······· MOV __PARAM3,#5··············
······· 0050· 002A
··· 96· 0051· 02EA······· DJNZ __PARAM3,@$·············
······· 0052· 0010 0A51
··· 97· 0054· 0C02······· XOR RB,#%00000010············
······· 0055· 01A6
··· 98· 0056· 02E9······· DJNZ __PARAM2,@$-20··········
······· 0057· 0010 0A42
··· 99·················
·· 100· 0059· 0010······· JMP @Main····················· ;· GOTO Main
······· 005A· 0A37
·· 101·················
·· 102·················
The SX/B code is just generating the code for the SHIFTIN insitu, no ISR nada.
The insitu code seems to just read the input pin into the 0 bit of the store and RL the store
and then clock the clock pin.
No timing pauses nada, it seems to just do it at the rate of the clock cycle.
But the code has assumed that 4MHz is the speed, so maybe it does not matter at this speed.
I will have to see the posible variations M/LSBPRE/POST and see how the code differs.
I also still have to do it for the SHIFTOUT..........sheeeh
But I think it is simpler than I thought it ought to be.
Sam
The SX/B shiftin/out is only master mode.
The SPI VP's are here (spim.src and spis.src)
http://www.sxlist.com/techref/ubicom/virtperf.htm
The·M/LSBPRE/POST are handled by setting up a cmd byte
from spis.src:
; SPIS supports 4 commands, specified by the 4 MSBits of the
; SPIS_CMD byte:
;
; $1 - GET BYTE in SLAVE mode, define FALLING edge
; $5 - GET BYTE in SLAVE mode, define RISING edge
; $9 - SEND BYTE in SLAVE mode, define FALLING edge
; $D - SEND BYTE in SLAVE mode, define RISING edge
;
from spim.src
; SPIM supports 4 commands, specified by the 4 MSBits of the
; SPIM_CMD byte
;
; $3 - GET WORD in MASTER FAST mode, define FALLING edge;
; $7 - GET WORD in MASTER FAST mode, define RISING edge;
; $B - SEND WORD in MASTER FAST mode, define FALLING edge;
; $F - SEND WORD in MASTER FAST mode, define RISING edge.
;
However, if you only need master mode, SX/B is much simpler to use.
regards peter
·
I noticed in your assembly listing, it shows " ... SX/B version 1.21 ...". You do realize that SX/B is now at v.1.42. The only reason I mention this is because some of the SX/B commands, like serin/serout, had a problem, which got corrected in 1.42.
Since you are pursuing the (expletive)in/(expletive)out command, in assembly, have you thought about the idea of doing it in a macro. That way it would easy for other people to use it and at the same time debug it. Now, if other people, myself included, would think along the same lines, there could be a nifty little library of macros available for everybody to use. You may want to check SXList.com, I think he is trying to develop a files area.
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).
regards peter
First off I think maybe one of the moderators should move this to its own thread. I will not try, I would probably would screw it up.
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.
If and when this becomes its own thread, then I and others can make some comments, do inclusions, ..., etc. Next, as I was looking at the code in the .inc file, as it was scrolling by, during the cut and paste, I can see that a lot of time and effort was put into this document, let me be the first one to say THANK YOU for the effort. More later ...
Thanks
Ray
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Thanks PeterV.
I was looking at this stuff and it looks like the thing I need.
I think your library is great too.
I am actually currently working on something exactly the same
to emmulate all the commands in SX/B e.g. SerIn/Out, ShiftIn/Out, PulsIn/Out etc.
I think all these commands is what made the Stamp very handy. I like the speed price and
felxiblity of the SX and like to program in SASM but all these handy commands in the Stamp
make development of a system and trying out projects very easy and painless.
I think if we had a library of routines that we can quickly use then the SX development would
be as easy. The SX/B compiler helps a lot.
By the way the version I am using is the one that is envoked auto by the SX_Key IDE.
Is there a way I can make it envoke the latest version???????????
The problem with Macros is that they are expanded as code inplace of the macro call.
So if a command is made into a macro and then used multiple times there will be redundant
code all over the place and since the SX's memory is not,lets say, extensive then the macro
solution should be looked at carefully.
I think this is what the SX/B does. Commands like ShiftIn are expanded into code wherever they are
encountered.
Here is my suggestion:
Subroutines should be created and Macros should be defined as wrap-arounds.
That is a subroutine should be developed and that way only the calls to it only would be repeated in the code.
The Macro wrap around is the way into the routines. The macro is passed all the required parameters.
The macro then does any setup required (flags,variables, etc.) and then the macro calls the subroutine.
Of course if the user does not require the subroutines he should not include them in his code.
The limitation on include files is if they are nested only, not if they are linear.
So here is a structure I propose:
-An Include file for All the EQUs and Definitions
-A seperate include file for all the Variable definitions for each Routine. It has to have the correct ORGs.
Attention to Banking, but macros should help with this. IE all variables to be used by the user are Set or
Got by a macro to get/put them.
This way each Variables .inc file is included only if it's subroutines .inc files is included.
(maybe with the correct ORG statements we can have the routines .inc file do both)
-One include file for all the macros for all the library to be included at the top. Since macros are
definitions and are only expanded as code where they are called, there would be no additional
code unless it is needed. Thus this is can be only one big file, not seperate files for each routine.
-A sperate include file for each subroutine to be included under an ORG statement to position the subroutine
were it is desired to have it in the code.....attention to Paging and Top of Page etc. (Macros would help with this)
-An include file for each section of the ISR to be included within the master ISR as desired and if the routine requires it.
conditional directives might be needed to modify the RETIW value (again macros would help here)
This way the Macro Call would look Something like this
ShiftIN Pin,Mode,Value,Size
Of course the user of the library has to know a lot more about how to use the library than just using
a command like in Basic.
A tall order I guess. But I am working on this right now, in my spare time. I hope PeterV's stuff will help.
I will post my stuff when it is ready.
Samuel
I am using the SX_Key IDE ver 3.1 and it has an inbuilt SX/B.
I do not know if I can make it envoke another version of the SX/B.
can anyone help with this.
(I think that I might have figured out how to do this,
just copy the new version exe in the correct directory under the SXKey directory.....
am I correct?)
Now I have to look·for the latest version.......
Samuel
Post Edited (SamMishal) : 1/6/2006 11:51:39 PM GMT
A response to your suggestions:
Subroutines should be created and Macros should be defined as wrap-arounds.
That is a subroutine should be developed and that way only the calls to it only would be repeated in the code.
The Macro wrap around is the way into the routines. The macro is passed all the required parameters.
The macro then does any setup required (flags,variables, etc.) and then the macro calls the subroutine.
>Response: the main macros in my lib are selfcontained subroutines
Of course if the user does not require the subroutines he should not include them in his code.
The limitation on include files is if they are nested only, not if they are linear.
>Response: there IS a limit if I try to include more than 9 files in my lib file, hence I use 1 file
although I wrote seperate files for all main macros.
So here is a structure I propose:
-An Include file for All the EQUs and Definitions
>Response: first part in my lib file (lib_constants.inc)
-A seperate include file for all the Variable definitions for each Routine. It has to have the correct ORGs.
Attention to Banking, but macros should help with this. IE all variables to be used by the user are Set or
Got by a macro to get/put them.
This way each Variables .inc file is included only if it's subroutines .inc files is included.
(maybe with the correct ORG statements we can have the routines .inc file do both)
>Response: This will not work. Each macro must consist of 3 code parts: isr part, init part and main part,
and a data part.
Each of these code parts may access the macro data variables and must therefore have knowledge
of variable names and labels. Therefore a macro subroutine must have all its parts in a single
file. Also keeps maintaining the code simpler.
-One include file for all the macros for all the library to be included at the top. Since macros are
definitions and are only expanded as code where they are called, there would be no additional
code unless it is needed. Thus this is can be only one big file, not seperate files for each routine.
>Response: I do that by including lib_total.inc in the main program file. Inside the library I would
like to have other includes for the main macros, so there are only 2 include levels required. Unfortunately
the number of includes is limited even with 2 include levels.
-A sperate include file for each subroutine to be included under an ORG statement to position the subroutine
were it is desired to have it in the code.....attention to Paging and Top of Page etc. (Macros would help with this)
>Response: In my libfile I generate a jump table at any page start and place code itself towards
the page ends. This resolves overlapping areas and allows code to be called from anywhere.
You don't want to hassle with ORG's.
-An include file for each section of the ISR to be included within the master ISR as desired and if the routine requires it.
conditional directives might be needed to modify the RETIW value (again macros would help here)
>Response: All sections of a main macro should be kept in one file. Don't split up related areas
over multiple files. That will lead to errors and possibly unable to assemble. Also note that
dependecies are to be considered. At the end of my main program I include the code for any used macro
and this includes any additional code·required by the used·macro code.
This way the Macro Call would look Something like this
ShiftIN Pin,Mode,Value,Size
>Response: Yes, and each main macro should have an extensive help text, just as the
Sx/B commands.
I started a new thread "Library development" here:
http://forums.parallax.com/showthread.php?p=565524
Please post any questions/suggestions regarding my library there.
regards peter
You just made Jon cringe. I do not know how long you have been following this forum, but their have been quite a few revisions in SX/B. If I am not mistaken, at one point their were at least three in one month. For now it seems to have stabilized as you can tell by the SX/B date. At the top of this forum there are some 'sticky' posts, that is where you will find the latest, although I would suggest, just to be on the safe side, download the latest SX-Key, and install that. I did that just a few weeks ago, and it does contain the latest version of SX/B.
Their has been some talk that SX/B is in pretty stable form now, and pretty soon their should be another release. Parallax has moved away from giving to much advance notice, everytime· they missed·a date, Parallax would start getting whinning posts with inquries as to·what the problem is.
Thanks
Ray