Bean has been [noparse][[/noparse]quietly] working on PropBASIC and I've been doing some testing for him -- we worked together on SX/B so it makes sense for us to continue that partnership on the initial cut of PropBASIC. Just to show you that a bit of progress has been made it a week, what follows is a real working program.
Interesting notes:
-- pins can be pre-initialized HIGH or LOW
-- SEROUT works and allows variable pin usage; great if you have two devices on different pins at the same baud
No surprise, this looks a lot like SX/B. We added XIN which is easier to use than FREQ.
' =========================================================================
'
' File...... serout_demo.pb
' Purpose... SEROUT demo using Propeller Demo Board
' Author....
' E-mail....
' Started...
' Updated...
'
' =========================================================================
' -------------------------------------------------------------------------
' Device Settings
' -------------------------------------------------------------------------
DEVICE P8X32A, XTAL1, PLL16X
XIN 5_000_000
' -------------------------------------------------------------------------
' I/O Pins
' -------------------------------------------------------------------------
TX PIN 30 HIGH ' output and high (idle)
LED PIN 16 LOW ' output and low
' -------------------------------------------------------------------------
' Constants
' -------------------------------------------------------------------------
Baud CON "T115200"
FirSt CON "A"
Last CON "Z"
' Parallax Serial Terminal (PST) Constants
HOME CON 1
BKSP CON 8
TAB CON 9
LF CON 10
CLREOL CON 11
CLRDN CON 12
CR CON 13
CLS CON 16
' -------------------------------------------------------------------------
' Variables
' -------------------------------------------------------------------------
alpha VAR Long
' =========================================================================
' Subroutine / Function Declarations
' =========================================================================
TX_BYTE SUB 2, 2 ' shell for SEROUT
DELAY_MS SUB 1, 1 ' shell for PAUSE
' =========================================================================
PROGRAM Start
' =========================================================================
Start:
DELAY_MS 10 ' TX idle for 10ms
TX_BYTE TX, CLS
Main:
DO
FOR alpha = First TO Last
TOGGLE LED
TX_BYTE TX, alpha
DELAY_MS 50
NEXT
TX_BYTE TX, CR
LOOP
' -------------------------------------------------------------------------
' Subroutine / Function Code
' -------------------------------------------------------------------------
' Use: TX_BYTE txpin, byteout
' -- shell for SEROUT at fixed baud rate
' -- allows selection of TX pin for multiple devices (e.g., LCD & terminal)
' -- Baud (rate) is set as program constant
SUB TX_BYTE
SEROUT __param1, Baud, __param2
ENDSUB
' -------------------------------------------------------------------------
' Use: DELAY_MS milliseconds
' -- shell for PAUSE
SUB DELAY_MS
PAUSE __param1
ENDSUB
HollyMinkowski said...
I'd love to be able to write a tiny compiler for a controller.
I need a good book about compiler creation.
I would need a "Compiler Construction for Dummies" type of book, not a tome
usable only by CompSci Phd's
Jack Crenshaw's 15-part Let's Build a Compiler may provide be a usefully pragmatic point of view. I found it to be quite approachable.
Good progess.
Are there plans to make BAUD variable, I mean to pass via PAR table.
I know PAR can be used as a value, but on the basic level you could allow
for PAR(i) where i denotes the i_th element of the long array passed to
the compiled PASM code.
For example, if the 2nd entry would be the baud parameter,
we could use SEROUT pin,PAR(1),value
That would allow us to use multiple instances of the same PASM code
but with different parameters (like BAUD).
To get to variable baud rate one would have to pass the bit timing instead of the baud rate; this fine for many of us but I know from experience that even BASIC Stamp users incorrectly set the baudmode value incorrectly and have problems. Perhaps we can have a SEROUT2 that takes four parameters: pin, mode, bit_time, byte. That said, changing baud rates on the fly is fairly infrequent, don't you think?
You misunderstood. I am not talking about changing baud on the fly.
What I mean is to have the ability to pass several values (via PAR)
when starting a cog with compiled pasm code.
Rather than maintaining a lot of 'Uart' PropBasic drivers for multiple
baudrates, maintain 1 such program that you can use for multiple
cogs running multiple uarts. Besides baud one would also pass
the pin.
If bittiming would be required instead of simple 9600 for example,
that could be handled bg the basic code.
This is a universal approach making the compiled code much more
versatile and also allows easy integration of PropBasic with Spin programs,
for those that do not use PASM or want the entire propeller program
in PropBasic.
What I suggest, Peter, is that when Bean releases a new version you give it a try. I'm not sure I understand your idea for implementation -- but then, I rarely do as you and I take very different approaches to programming. The compiler supports ASM...ENDASM so you could create a working model for Bean to work from; that's what I've been doing with ideas I've been throwing out. In fact, I'm "borrowing" some code from FullDuplexSerial.spin to see if I can write a routine called SEROUT2 that works as I suggested above.
I have a project where I am using FullDuplexSerial.spin too create ser[noparse][[/noparse]0], ser, and ser. They have different baud rates, as well as different pin set assignments. So, will propBASIC be able to accomplish the same thing, hopefully using a lot less cogs, then the spin object. And, what will be the estimated BAUD rate limit?
Remember, PropBASIC is like SX/B in that it compiles keywords inline -- so SEROUT gets compiled in place to native assembly. Since PropBASIC supports ASM..ENDASM blocks you can add features as you like (or ask someone to code them for you).
I "liberated" some code from FullDuplexSerial to create this subroutine that supports any pin, variable mode (T, N, OT, ON), and variable baud rate, though to get the variable baud rate you have to pass the bit time (this is easily accomplished by creating bit time constants for the baud rates you want to use). I have tested it up to 2_000_000 baud using PST. To go any faster you'd have to remove the variable mode (e.g., fix to True mode output) to cut down on the cycles required to transmit a bit.
Again, this code is running inline and not buffered, so the program is blocked from doing other things while you're transmitting a byte (just like PBASIC and SX/B).
' Use: SEROUT2 txpin, mode, bittime, byteout
' - variable mode, variable baud
SUB SEROUT2
ASM
mov __temp1, #1 ' pin# to mask
shl __temp1, __param1
test __param2, #%10 wz
test __param2, #%01 wc
if_z_ne_c or outa, __temp1
if_z or dira, __temp1
or __param4, #$100 ' add stop bit
shl __param4, #2 ' add start bit
or __param4, #1 ' force 1 idle bit
mov __temp2, #11 ' bits to tx
mov __temp3, __param3 ' get bit time
add __temp3, cnt ' sync with sys cnt
:txbit2 test __param2, #%10 wz
test __param2, #%01 wc
if_c_and_z xor __param4, #1
shr __param4, #1 wc ' get bit to TX
if_z muxc outa, __temp1
if_nz muxnc dira, __temp1
waitcnt __temp3, __param3 ' time bit, reload
djnz __temp2, #:txbit2 ' update bit count
ENDASM
ENDSUB
Virand, · PropBASIC will run in 1 cog. · You can create PropBASIC "objects" that run in different cogs. Hopefully we'll have time to create the standard objects: Keyboard, Mouse, TV, VGA, etc.
· PropBASIC compiles on the PC. If you want to use the propeller itself for BASIC development you should look at femtobasic.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...
Comments
If I change temp into tempVariable the compiler generates
The label __FOR_tempva is truncated (should be __FOR_tempVariable_1).
regards peter
Interesting notes:
-- pins can be pre-initialized HIGH or LOW
-- SEROUT works and allows variable pin usage; great if you have two devices on different pins at the same baud
No surprise, this looks a lot like SX/B. We added XIN which is easier to use than FREQ.
Lucky for us, Jon is working on some formal documentation too.
I'm on a 10 day cruise starting on Thursday, so that will cut into development time.
Keep the faith, it will be release as soon as we can.
Anyone who has used SX/B will be VERY familiar with PropBASIC. Those that used PBASIC will have a slight learning curve.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...
·
www.scribd.com/doc/47354/Basics-of-Compiler-Design
Well that is 10 days & nights to do prop development without interruptions
Enjoy your break (and where are you going?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Jack Crenshaw's 15-part Let's Build a Compiler may provide be a usefully pragmatic point of view. I found it to be quite approachable.
See it at compilers.iecc.com/crenshaw/..
Do note that Bean may be using an entirely different approach in his PropBASIC.
Daniel
Good progess.
Are there plans to make BAUD variable, I mean to pass via PAR table.
I know PAR can be used as a value, but on the basic level you could allow
for PAR(i) where i denotes the i_th element of the long array passed to
the compiled PASM code.
For example, if the 2nd entry would be the baud parameter,
we could use SEROUT pin,PAR(1),value
That would allow us to use multiple instances of the same PASM code
but with different parameters (like BAUD).
regards peter
You misunderstood. I am not talking about changing baud on the fly.
What I mean is to have the ability to pass several values (via PAR)
when starting a cog with compiled pasm code.
Rather than maintaining a lot of 'Uart' PropBasic drivers for multiple
baudrates, maintain 1 such program that you can use for multiple
cogs running multiple uarts. Besides baud one would also pass
the pin.
If bittiming would be required instead of simple 9600 for example,
that could be handled bg the basic code.
This is a universal approach making the compiled code much more
versatile and also allows easy integration of PropBasic with Spin programs,
for those that do not use PASM or want the entire propeller program
in PropBasic.
regards peter
Ray
I "liberated" some code from FullDuplexSerial to create this subroutine that supports any pin, variable mode (T, N, OT, ON), and variable baud rate, though to get the variable baud rate you have to pass the bit time (this is easily accomplished by creating bit time constants for the baud rates you want to use). I have tested it up to 2_000_000 baud using PST. To go any faster you'd have to remove the variable mode (e.g., fix to True mode output) to cut down on the cycles required to transmit a bit.
Again, this code is running inline and not buffered, so the program is blocked from doing other things while you're transmitting a byte (just like PBASIC and SX/B).
Are there spare cogs to run a video terminal on the Propeller?
Everything's nicer when it's not hooked up to a PC.
Like a digital camera with it's own printer, or ye olde Polaroid, for example.
· PropBASIC will run in 1 cog.
· You can create PropBASIC "objects" that run in different cogs. Hopefully we'll have time to create the standard objects: Keyboard, Mouse, TV, VGA, etc.
· PropBASIC compiles on the PC. If you want to use the propeller itself for BASIC development you should look at femtobasic.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...
·