I'm mostly done with my smartpin SPI driver.
there is 8 different modes
CLOCK POLARITY [0/1]
CLOCK PHASE [0/1]
MSB TX/RX FIRST OR LSB TX/RX FIRST
When CPOL is 0, the clock signal is normally low and is driven up/down on each pulse
When CPOL is 1, the clock signal is normally high and is driven down/up on each pulse
When CPHA is 0, the data bit is ready before the first edge and is setup on the second edge
When CPHA is 1, the data bit is setup on the first edge and read/written on the second edge
To be able to make the CPHA to work, I had to setup synchronous serial transmit to 9 bits, because the way the synchronous serial works, LSB is always present on the output pin before any clock when the smartpin is activated with DIR set to 1
I also setup MOSI to 100uA drive mode. Some SPI chips have their MOSI/MISO tied together inside the IC (SIO) so this allow me to short the MOSI and MISO and SIO pin together on the Prop and SPI slave. When data is written to the slave, MISO and SIO are tri-stated so the MOSI can drive both input. When the slave starts to write data to the prop, SIO drive is stronger than the MOSI drive so MISO can effectively read the slave. See the test below.
8 := CLK
9 := MOSI
10 := MISO
11 := SS
15000 := FREQ
CLKHZ FREQ / := N_PULSES
N_PULSES 2/ 16 << N_PULSES OR := CLK_PULSE_TIME
%0000_0_0_0_000_000 8 << %1_00100_0 OR := CPOL0
%0000_0_0_1_000_000 8 << %1_00100_0 OR := CPOL1
: SPI_CLK_SETUP ( MODE -- ) CLK PIN WRPIN CLK_PULSE_TIME WXPIN L ;
: CPOL0_CPHA1_SETUP
CPOL0 SPI_CLK_SETUP
MOSI PIN %0000_0111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_1110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %100111 WXPIN
;
: CPOL1_CPHA1_SETUP
CPOL1 SPI_CLK_SETUP
MOSI PIN %0000_1111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_0110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %100111 WXPIN
;
: CPOL0_CPHA0_SETUP
CPOL0 SPI_CLK_SETUP
MOSI PIN %0000_1111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_0110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %000111 WXPIN
;
: CPOL1_CPHA0_SETUP
CPOL1 SPI_CLK_SETUP
MOSI PIN %0000_0111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_1110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %000111 WXPIN
;
: SEND_CPHA1_MSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F REV 23 >> WYPIN L
MISO PIN L
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F REV
;
: SEND_CPHA0_MSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F REV 24 >> WYPIN L
MISO PIN L
N_PULSES 4/ WAITX
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F REV
;
: SEND_CPHA1_LSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F 2* WYPIN L
MISO PIN L
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F 24 >>
;
: SEND_CPHA0_LSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F WYPIN L
MISO PIN L
N_PULSES 4/ WAITX
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F 24 >>
;
test with DS1302 SPI RTC
--- ok-- DS1302 RTC + 31 BYTES RAM TEST
--- ok-- SETUP CLOCK POLARITY, PHASE AND LSB TRANSMIT FIRST
TAQOZ# : SEND SEND_CPHA0_LSB ; --- ok
TAQOZ# CPOL0_CPHA0_SETUP --- ok
--- ok-- CLEAR WRITE-PROTECT BIT
TAQOZ# SS PIN H --- ok
TAQOZ# $8E SEND .BYTE --- 8E ok
TAQOZ# $00 SEND .BYTE --- 00 ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- WRITE $AA TO FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C0 SEND .BYTE --- C0 ok
TAQOZ# $AA SEND .BYTE --- AA ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- WRITE $BB TO 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C2 SEND .BYTE --- C2 ok
TAQOZ# $BB SEND .BYTE --- BB ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C1 SEND .BYTE --- C1 ok
TAQOZ# $00 SEND .BYTE --- AA ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C3 SEND .BYTE --- C3 ok
TAQOZ# $00 SEND .BYTE --- BB ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- SET WRITE-PROTECT BIT
TAQOZ# SS PIN H --- ok
TAQOZ# $8E SEND .BYTE --- 8E ok
TAQOZ# $FF SEND .BYTE --- FF ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- TRY TO WRITE $CC TO FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C0 SEND .BYTE --- C0 ok
TAQOZ# $CC SEND .BYTE --- CC ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- TRY TO WRITE $DD TO 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C2 SEND .BYTE --- C2 ok
TAQOZ# $DD SEND .BYTE --- DD ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C1 SEND .BYTE --- C1 ok
TAQOZ# $00 SEND .BYTE --- AA ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C3 SEND .BYTE --- C3 ok
TAQOZ# $00 SEND .BYTE --- BB ok
TAQOZ# SS PIN L --- ok
TAQOZ#
@"Peter Jakacki" could you help me a little bit with cleaning my driver source code so that there is a bit less copy/pasted code. I'm not too sure how to approach that and your Forth code always look simpler
I'm mostly done with my smartpin SPI driver.
there is 8 different modes
CLOCK POLARITY [0/1]
CLOCK PHASE [0/1]
MSB TX/RX FIRST OR LSB TX/RX FIRST
When CPOL is 0, the clock signal is normally low and is driven up/down on each pulse
When CPOL is 1, the clock signal is normally high and is driven down/up on each pulse
When CPHA is 0, the data bit is ready before the first edge and is setup on the second edge
When CPHA is 1, the data bit is setup on the first edge and read/written on the second edge
To be able to make the CPHA to work, I had to setup synchronous serial transmit to 9 bits, because the way the synchronous serial works, LSB is always present on the output pin before any clock when the smartpin is activated with DIR set to 1
I also setup MOSI to 100uA drive mode. Some SPI chips have their MOSI/MISO tied together inside the IC (SIO) so this allow me to short the MOSI and MISO and SIO pin together on the Prop and SPI slave. When data is written to the slave, MISO and SIO are tri-stated so the MOSI can drive both input. When the slave starts to write data to the prop, SIO drive is stronger than the MOSI drive so MISO can effectively read the slave. See the test below.
8 := CLK
9 := MOSI
10 := MISO
11 := SS
15000 := FREQ
CLKHZ FREQ / := N_PULSES
N_PULSES 2/ 16 << N_PULSES OR := CLK_PULSE_TIME
%0000_0_0_0_000_000 8 << %1_00100_0 OR := CPOL0
%0000_0_0_1_000_000 8 << %1_00100_0 OR := CPOL1
: SPI_CLK_SETUP ( MODE -- ) CLK PIN WRPIN CLK_PULSE_TIME WXPIN L ;
: CPOL0_CPHA1_SETUP
CPOL0 SPI_CLK_SETUP
MOSI PIN %0000_0111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_1110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %100111 WXPIN
;
: CPOL1_CPHA1_SETUP
CPOL1 SPI_CLK_SETUP
MOSI PIN %0000_1111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_0110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %100111 WXPIN
;
: CPOL0_CPHA0_SETUP
CPOL0 SPI_CLK_SETUP
MOSI PIN %0000_1111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_0110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %000111 WXPIN
;
: CPOL1_CPHA0_SETUP
CPOL1 SPI_CLK_SETUP
MOSI PIN %0000_0111_000_0000_000_101_101 8 << %01_11100_0 OR WRPIN %101000 WXPIN
MISO PIN %0000_1110_000_0000_000_111_111 8 << %01_11101_0 OR WRPIN %000111 WXPIN
;
: SEND_CPHA1_MSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F REV 23 >> WYPIN L
MISO PIN L
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F REV
;
: SEND_CPHA0_MSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F REV 24 >> WYPIN L
MISO PIN L
N_PULSES 4/ WAITX
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F REV
;
: SEND_CPHA1_LSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F 2* WYPIN L
MISO PIN L
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F 24 >>
;
: SEND_CPHA0_LSB ( TX_BYTE -- RX_BYTE )
MOSI PIN F WYPIN L
MISO PIN L
N_PULSES 4/ WAITX
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F 24 >>
;
test with DS1302 SPI RTC
--- ok-- DS1302 RTC + 31 BYTES RAM TEST
--- ok-- SETUP CLOCK POLARITY, PHASE AND LSB TRANSMIT FIRST
TAQOZ# : SEND SEND_CPHA0_LSB ; --- ok
TAQOZ# CPOL0_CPHA0_SETUP --- ok
--- ok-- CLEAR WRITE-PROTECT BIT
TAQOZ# SS PIN H --- ok
TAQOZ# $8E SEND .BYTE --- 8E ok
TAQOZ# $00 SEND .BYTE --- 00 ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- WRITE $AA TO FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C0 SEND .BYTE --- C0 ok
TAQOZ# $AA SEND .BYTE --- AA ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- WRITE $BB TO 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C2 SEND .BYTE --- C2 ok
TAQOZ# $BB SEND .BYTE --- BB ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C1 SEND .BYTE --- C1 ok
TAQOZ# $00 SEND .BYTE --- AA ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C3 SEND .BYTE --- C3 ok
TAQOZ# $00 SEND .BYTE --- BB ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- SET WRITE-PROTECT BIT
TAQOZ# SS PIN H --- ok
TAQOZ# $8E SEND .BYTE --- 8E ok
TAQOZ# $FF SEND .BYTE --- FF ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- TRY TO WRITE $CC TO FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C0 SEND .BYTE --- C0 ok
TAQOZ# $CC SEND .BYTE --- CC ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- TRY TO WRITE $DD TO 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C2 SEND .BYTE --- C2 ok
TAQOZ# $DD SEND .BYTE --- DD ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ FIRST RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C1 SEND .BYTE --- C1 ok
TAQOZ# $00 SEND .BYTE --- AA ok
TAQOZ# SS PIN L --- ok
TAQOZ# --- ok
--- ok-- READ 2ND RAM REGISTER
TAQOZ# SS PIN H --- ok
TAQOZ# $C3 SEND .BYTE --- C3 ok
TAQOZ# $00 SEND .BYTE --- BB ok
TAQOZ# SS PIN L --- ok
TAQOZ#
@"Peter Jakacki" could you help me a little bit with cleaning my driver source code so that there is a bit less copy/pasted code. I'm not too sure how to approach that and your Forth code always look simpler
When I read this yesterday I thought about replying,
but Peter will come up with s.th. better anyhow so I didn't.
Since he did not answer yet now my 2c.
Considerations are as always: size vs speed vs nice to read ;-)
I assume speed is not a major concern here since it is only the smartpin setup
and the actual transmission is independent of it.
For speed your code is probably a good choice with everything inlined.
Size:
it looks at least this code
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F
is the same in all four so it could be factored out and just called.
nice to read:
Having four different mode dependent WORDS might require a case / switch
somewhere in the calling code dependent on the modes.
So why not just make the modes config switches implemented e.g. as a
byte _msb --- for msb / lsb switching
1 _msb C! --- or 0 _msb C! or ~ ~~ if implemented
--- if you like with shortcuts
pub !MSB _msb ~~ ;
pub !LSB _msb ~ ;
pub MSB? _msb C@ ;
--- and
byte _cpha --- for CPHA0/ CPHA1 switching
0 _cpha C! --- or 1 _cpha C! or ~ ~~ if implemented
--- and with shortcuts
pub CPHA0 0 _cpha C! ;
pub CPHA1 1 _cpha C! ;
--- or
pub CPHA! _cpha C! ;
--- so you can write
0 CPHA! --- or
1 CPHA!
pub CPA0? _cpha C@ NOT ;
then it can be made in one
: SPI!@ ( TX_BYTE -- RX_BYTE )
MOSI PIN F
MSB? If REV 24 >> THEN
CPA0? IF 2* THEN
WYPIN L
MISO PIN L
CPA0? IF N_PULSES 4/ WAITX THEN
CLK PIN 8 WYPIN WAITPIN
MOSI PIN F
SS PIN H
MISO PIN RDPIN F
MSB? If REV ELSE 24 >> THEN
;
@MJB @FredBlais - Hah, I did have a quick look at it yesterday and saw plenty of redundancy but for me I like to "extend" the language rather than write functions. The other thing is that I prefer factoring functions into those words so that they can be arranged into a phrase rather than one long concatenated word but then that phrase can have a name and so becomes another word in the language. Also in my experience it is best to have runtime configuration rather than having to change the source so that we can set the frequency and pins in code.
BTW @MJB - I can't seem to remember the post you mentioned but I will trawl through the thread and get back to you, sorry.
This is my quick take on the code so far but this will be refined when I get to have a proper look at it. The transfer functions look too bulky and slow though which means that when you use a much higher transfer frequency it will be bogged down with overhead. This is where the built-in TAQOZ SPI instructions are very efficient and run about 1/10th of the main clock frequency but with almost zero overhead as in writing a byte:
TAQOZ# $12 LAP SPIWB LAP .LAP --- 136 cycles= 566ns @240MHz ok
Here's where I'm at so far with Fred's code. I'm glad he has taken a look at what's required for SPI bus because to tell the truth I hadn't bothered so far
While the smartpin SPI could be useful it might also be of limited use as a master since most peripherals have some lower clock limit anyway but certainly this mode is very useful if the P2 is a slave. However I look forward to being corrected because it means there is a better way
P.S. @FredBlais - I will take another look at using Git since you have set it up so well
I will be busy getting the new P2D2 hardware out this week but in the meantime here is an updated TAQOZ you can loaded onto your SD card. It includes VGA and PS/2 as well as a decompiler which you can use this way:
Just rename P2.ROM to _BOOT_P2.BIX and copy to your SD card so it will boot at 115,200 baud. Normally I run mine at 3M, the limit of the USB chip. Take note that MOUNT at present seems a little bit slow since it does an actual cluster scan to check for free and used clusters, but I might change that next time.
@DaveJenson - Here's the current source for the driver and right near the start there you will see:
--- user can change led display pins on the fly
pub PLEXPIN ( pin -- ) >!
pri leds 8 ;
So use PLEXPIN to change the base pin (it actually changes the leds constant .
This driver assumes the 5X7 FONT is loaded in as part of VGA.FTH
TAQOZ
{
PLEXLED.FTH
SIMPLE CHARACTER I/O FOR P2-ES LED MATRIX
228 bytes of code including table
top view 7 columns x 8 rows
}
*** CHARLIEPLEX DECODE TABLE ***
0 TABLE plx --- create a table for 56 encoded high/low pairs
$73747576 , $67707172 , $62636465 , $56576061 , $51525354 , $45464750 , $40414243 ,
$34353637 , $27303132 , $23242526 , $16172021 , $12131415 , $05060710 , $01020304 ,
*** PHYSICAL LED DRIVER ***
--- user can change led display pins on the fly
pub PLEXPIN ( pin -- ) >!
pri leds 8 ;
--- light an LED (only one at a time)
pri XYLED ( x y -- ) 3 << + plx + C@ DUP 7 AND leds + LOW 4 >> leds + HIGH ;
*** LED PIXEL BUFFER ***
private
14 bytes ledbuf --- holds displayed character + new character to be scrolled in
byte scol --- columns to scroll
--- scroll the matrix by one column left
pri SCROLL ledbuf 7 ADO I C@ I 7 + C@ 8<< + 2/ DUP I C! 8>> I 7 + C! LOOP ;
*** LED REFRESH & SCROLLING TASK ***
--- run this task in a cog -
--- NOTE: a background timer could call the central part of this every 1ms and still not notice any flicker
pri PLEX.TASK
BEGIN
3 FOR --- scroll counter
7 0 DO ledbuf I+ C@
8 0 DO DUP I |< AND IF I J XYLED THEN 200 us 0 DIRA COG! LOOP
DROP LOOP
NEXT
scol C@ IF scol C-- SCROLL THEN
AGAIN
;
*** PLEXLED CHARACTER OUTPUT DEVICE ***
--- Make the PLEXLED the console output device
pub PLEXLED
EMIT:
pub PLEXCH ( ch -- )
1 TASK W@ 0= IF ' PLEX.TASK 1 RUN ledbuf 15 ERASE THEN
--- lookup font and transfer to ledbuf when scrolling is done
7 * FONT5X7 + ledbuf 7 + 7
BEGIN scol C@ 0= UNTIL CMOVE
7 scol C!
;
*** COMBO SERIAL + PLEXLED OUTPUT ***
--- combine the PLEXLED with the serial console
pub CONLED EMIT: DUP CONEMIT PLEXCH ;
*** DEBUG words ***
{
: PP ( char -- ) PLEXCH ;
: HELLO PLEXLED BEGIN ." HELLO WORLD! " KEY UNTIL CON ;
: DEMO PLEXLED BEGIN ." PARALLAX P2" 2 s KEY UNTIL CON ;
}
END
@"Peter Jakacki"
Thanks. I can now display stuff on the LED Matrix. I'm assuming the _BOOT_P2.BIX has the 5X7 VGA font. (I can see the font5X7 word.)
However, when I try to send a character to the matrix, I have found that the character displayed is off by 28. For instance, to display "A" (41 hex), I need to send 25 hex.
@"Peter Jakacki"
Thanks. I can now display stuff on the LED Matrix. I'm assuming the _BOOT_P2.BIX has the 5X7 VGA font. (I can see the font5X7 word.)
However, when I try to send a character to the matrix, I have found that the character displayed is off by 28. For instance, to display "A" (41 hex), I need to send 25 hex.
What did I miss?
Nothing, I think I changed the font table in between and so all you have to do is subtract $1C anytime before you lookup the font table as I do here:
pub PLEXLED
EMIT:
pub PLEXCH ( ch -- )
1 TASK W@ 0= IF ' PLEX.TASK 1 RUN ledbuf 15 ERASE THEN
--- lookup font and transfer to ledbuf when scrolling is done
$1C - 7 * FONT5X7 + ledbuf 7 + 7
BEGIN scol C@ 0= UNTIL CMOVE
7 scol C!
;
Peter, not to carry this OT, but does the ROM have an internal font?
The P1 had twice as much ROM and it had a font table but with only 16K of ROM for the P2 there is no room left over especially after TAQOZ. Now if only we had 32k of ROM or more..... 😁🤔
Aldi had some 128GB Sandisk microSD cards available for $40 so I picked one up today just to try formatting to FAT32 on P2. These reveal a manufactured date of November 2018. I formatted it with 64KB clusters for this test. Works well!
Nice Peter. Certainly a good price!
I presume you can read and write files ok on the pc with Linux?
Do you have a Windoze pc to try that also? Windoze may not like 64KB clusters?
Aldi had some 128GB Sandisk microSD cards available for $40 so I picked one up today just to try formatting to FAT32 on P2. These reveal a manufactured date of November 2018. I formatted it with 64KB clusters for this test. Works well!
Peter,
Was that a Sandisk 128 Ultra, Ultra Plus, Extreme or Extreme Pro?
It is a SanDisk Ultra microSDXC UHS-1 Class 10. I can read 64kB clusters in Linux no problem and also on Win10 systems although I know the earlier Windows could only handle 32kB clusters.
I even picked up a Canon SX620HS compact x25 zoom camera for $129. The 128GB card will probably end up in my phone although I seem to have plenty of storage there already.
This is the latest image for the P2 EVAL board that includes VGA, PS/2, FAT32 and disk utilities, BMP viewer, BMV video and WAV audio player etc. This is configured to startup at 300MHz and 921600 baud.
Just rename P2.ROM to _BOOT_P2.BIX and put it on your card.
I've also zipped up a whole heap of audio files that I converted earlier today along with the videos I've been using and any other file including BMPs that I have on my card. The file is about 2.5GB and while it is not small, neither is it unduly large by today's standards. This is your chance to try out TAQOZ like I do.
.
.
Just rename P2.ROM to _BOOT_P2.BIX and put it on your card.
.
.
Would you be so kind as to list the hardware and PIN locations you are using? (Just so we new users can get started faster!)
Are you using the P2-ES expansion cards?
Where are you attaching them to the P2-ES board?
etc...
Thanks!
I am impressed with what you are able to do with this hardware and want to experience it for myself.
@DaveJenson - I try to make software runtime configurable, usually via some kind of SETPIN word such as SDPINS for the SD etc. There's also a config boot block in the first 128 bytes or so of memory that holds the boot configuration for TAQOZ, so this can be changed too. However for the VGA and audio I have my board plugged into P0..7 and the A/V board has 6 and 7 connected to audio out.
btw - if you are downloading source code directly into the new TAQOZ you don't need to worry about line delays anymore if you use the TAQOZ and END words which not only place the console into not echoing source and only reporting line numbers and messages, but it also loads directly into upper RAM first before performing a load of source from that RAM. So it is fast!
So what's the future of TAQOZ as a development environment? I'm heading towards using it in a commercial product myself and wondering if it is worthwhile anymore to worry about making it suitable for anyone else to actually use seriously.
Seeing that Forth is NOT one of the languages that is available for the P2 despite being able to do more than just blink an led, I wonder if i am just waving the wrong flag.
I do what i do the way i do for the same reason i use the prop instead of an ARM, i can make all kinds of simple or complex stuff and have fun doing it, quickly, without struggling forever and growing old before getting it to work.
So what's the future of TAQOZ as a development environment? I'm heading towards using it in a commercial product myself and wondering if it is worthwhile anymore to worry about making it suitable for anyone else to actually use seriously.
Seeing that Forth is NOT one of the languages that is available for the P2 despite being able to do more than just blink an led, I wonder if i am just waving the wrong flag.
I do what i do the way i do for the same reason i use the prop instead of an ARM, i can make all kinds of simple or complex stuff and have fun doing it, quickly, without struggling forever and growing old before getting it to work.
I'm not sure what you are asking here, and also unclear on how you separate Rom-TAQOZ which will be in every P2, from some post-boot loaded expanded TAQOZ version ?
(I think your SD playback work, is using an expanded-TAQOZ ?)
Rom-TAQOZ is already in P2 (so I do not comprehend 'Seeing that Forth is NOT one of the languages that is available for the P2') , and that certainly is useful for testing and may even be used in cases where users want to access smart pins via scripts.
For more complete commercial use, that will depend on the developer's experience (and their manager's too... ) .
What does it need added to 'make it suitable for anyone else to actually use seriously' ?
If you wanted to gauge Forth's pulse generally, one litmus test would be to see if there are critical mass projects on raspPi ? A quick search finds a 2013 git, but 6 yr old files.
The best language leverage results, when it can run on more than one host.
That puts Basic, C, Python etc in a stronger position, than Spin or TAQOZ
When you show me/us sample code it works extremely efficient and easy. However coming to grips with forth seems way more difficult.
Currently there are way too many things to do on P2 so i think we are all concentrating on things we love to do. Perhaps as we get more users who don’t have pet projects, more may take up TAQOZ.
What we will need is a lot of good docs with examples. I know there is some already.
I am hopeful that we can see an uptake in users as you have done a fantastic job here. Perhaps as newbies start out with P2, the intro to TAQOZ in ROM will rub off and they will want to investigate further. Those ROM routines were magic for me to checkout that the P2 was indeed working. So we will need a nice little primer for this when the new silicon becomes available.
The compact version of TAQOZ in ROM is mainly for hardware debugging but of course could also be used to program the prop without any other tools other than a terminal and perhaps an editor.
The TAQOZ in taking about is the extended version that will go on being extended. When i said it is not one of the P2 languages, i meant it is not mentioned officially. When i question the future of it, this had to do with how it is to be used. If i am the only one writing and documenting and using it then it doesn't make any sense to waste all that extra effort catering for users and trying to promote it.
I see that my commercial products will take up a lot of my time and i could just concentrate on that. Is anybody actually interested in using it? I see lots and lots of excitement over various languages but I'm primarily interested in what i can do with the P2.
I'm planning a commercial product that will use TAQOZ extensively.
I'm currently caught up in too many other aspects at the moment but that is where I am going :-)
I'm planning a commercial product that will use TAQOZ extensively.
I'm currently caught up in too many other aspects at the moment but that is where I am going :-)
J
Good to know, I am sometimes (most of the time) left wondering if I should bother at all since there seems to be more interest in languages than there is in actually using the P2 for real projects, both hobby and commercial.
While it might be great to have extensive tutorials and documentation for TAQOZ, that just isn't possible at present since "the same guy" that developed it has done so that he can develop product while having fun. Despite sharing ALL my design files, software, hardware, documentation, photos, videos etc, TAQOZ hardly seems to register above the forum static. What I have is a P2 system that goes far beyond evaluating externally compiled snippets of code, but interactively compiles and debugs from the P2 itself, runs FAT32 and command line disk utilities, VGA and PS/2 keyboards, audio and video playback, Ethernet FTP/HTTP/TELNET servers, and the list goes on. But my commercial project doesn't really depend upon anyone of these, they are just there to support it and to be taken advantage of.
If anyone wanted to help with documentation for instance, then it requires playing with TAQOZ, learning, and trying out ideas rather than needing to ask how to modify code. For instance, I have lots of notifications of anonymous users suggesting "add indent" and other kinds of formatting but what matters is not the formatting, it's the content. Write up something in a separate section or even in a separate document that can be incorporated and eventually nicely formatted later.
At present I will concentrating on new P2D2 hardware, support boards, and application specific boards so there might not be as much happening with TAQOZ itself at present since it already works, and very well at that. Build it and they will come they say. Well, it is built.
Hello Peter, I'm, we are, extremly grateful for the work, you are doing as this is the way, it should be, but is not yet. Creating foundations is never easy and sometimes in vain. But nothing should exist, not founded on first principles. This only leads to confusion and chaos. Like we see in the world of verbose software. We shall not give up to push forward what we know to be of value and use walls only to keep us on track and prevent us from following false prophets that just intend to gain immoral profits by showing simple minded people (like you and me) you can do what you want if only you are rich. I'm burried in my daily work and hope to contribute to Tachyon soon, at least, make more and effective use of it.
Like ErNa, I am, also very grateful and impressed by the work you are doing for TAQOZ and Tachyon Forth for for the P1 and P2, and thank you for that. learned Forth many many years ago when I was in university, and really liked the brevity, extensibility, and power of the language. Unfortunately I never had the opportunity to use Forth in my work after graduating, however I am now planning to learn Tachyon and use it to automate several functions at a small marina during this boating season. There will be several P1's to control functions like entry gates, lighting, grounds watering, etc.. and those P1's will communicate with a P2 to monitor the system and record events. Really looking forward to the challenge, and hope to be able to make a contribution to the documentation and sample code while doing this.
The compact version of TAQOZ in ROM is mainly for hardware debugging but of course could also be used to program the prop without any other tools other than a terminal and perhaps an editor.
The TAQOZ as in rom, certainly needs to be well documented, with easily pasted demo's, as every single P2 will be including that.
P2 Users will be very interested in what they can, and cannot do, at the TAQOZ prompt they can easily get to on P2
The TAQOZ in taking about is the extended version that will go on being extended. When i said it is not one of the P2 languages, i meant it is not mentioned officially. When i question the future of it, this had to do with how it is to be used. If i am the only one writing and documenting and using it then it doesn't make any sense to waste all that extra effort catering for users and trying to promote it.
...
What I have is a P2 system that goes far beyond evaluating externally compiled snippets of code, but interactively compiles and debugs from the P2 itself, runs FAT32 and command line disk utilities, VGA and PS/2 keyboards, audio and video playback, Ethernet FTP/HTTP/TELNET servers, and the list goes on.
That sounds like a quite separate item, and maybe even needs a separate name, or a clear differentiator suffix ? (maybe TAQOZ-EV & TAQOZ-R ?)
DOCs & demos for this extended version needs to be in a separate area, to avoid otherwise confusing users about just what the P2-ROM is capable of.
Comments
there is 8 different modes
CLOCK POLARITY [0/1]
CLOCK PHASE [0/1]
MSB TX/RX FIRST OR LSB TX/RX FIRST
When CPOL is 0, the clock signal is normally low and is driven up/down on each pulse
When CPOL is 1, the clock signal is normally high and is driven down/up on each pulse
When CPHA is 0, the data bit is ready before the first edge and is setup on the second edge
When CPHA is 1, the data bit is setup on the first edge and read/written on the second edge
To be able to make the CPHA to work, I had to setup synchronous serial transmit to 9 bits, because the way the synchronous serial works, LSB is always present on the output pin before any clock when the smartpin is activated with DIR set to 1
I also setup MOSI to 100uA drive mode. Some SPI chips have their MOSI/MISO tied together inside the IC (SIO) so this allow me to short the MOSI and MISO and SIO pin together on the Prop and SPI slave. When data is written to the slave, MISO and SIO are tri-stated so the MOSI can drive both input. When the slave starts to write data to the prop, SIO drive is stronger than the MOSI drive so MISO can effectively read the slave. See the test below.
test with DS1302 SPI RTC
@"Peter Jakacki" could you help me a little bit with cleaning my driver source code so that there is a bit less copy/pasted code. I'm not too sure how to approach that and your Forth code always look simpler
Source code : https://github.com/speccy88/TAQOZ/blob/master/src/forth/protocol/SPI.FTH
When I read this yesterday I thought about replying,
but Peter will come up with s.th. better anyhow so I didn't.
Since he did not answer yet now my 2c.
Considerations are as always: size vs speed vs nice to read ;-)
I assume speed is not a major concern here since it is only the smartpin setup
and the actual transmission is independent of it.
For speed your code is probably a good choice with everything inlined.
Size:
it looks at least this code is the same in all four so it could be factored out and just called.
nice to read:
Having four different mode dependent WORDS might require a case / switch
somewhere in the calling code dependent on the modes.
So why not just make the modes config switches implemented e.g. as a then it can be made in one
I hope I didn't miss a case ...
BTW @MJB - I can't seem to remember the post you mentioned but I will trawl through the thread and get back to you, sorry.
This is my quick take on the code so far but this will be refined when I get to have a proper look at it. The transfer functions look too bulky and slow though which means that when you use a much higher transfer frequency it will be bogged down with overhead. This is where the built-in TAQOZ SPI instructions are very efficient and run about 1/10th of the main clock frequency but with almost zero overhead as in writing a byte:
Here's where I'm at so far with Fred's code. I'm glad he has taken a look at what's required for SPI bus because to tell the truth I hadn't bothered so far
While the smartpin SPI could be useful it might also be of limited use as a master since most peripherals have some lower clock limit anyway but certainly this mode is very useful if the P2 is a slave. However I look forward to being corrected because it means there is a better way
P.S. @FredBlais - I will take another look at using Git since you have set it up so well
Thanks for your help.
I was having a little bit of fun yesterday displaying the 5x7 font on an old MAN2A/TIL305 IC
http://www.decadecounter.com/vta/tubepage.php?item=33
There is lots of Freds code a bit hidden in the scrolling [ code ] box.
And I only commented on the SEND part, not the SETUP (didn't really study SmartPins yet)
I think I'm done with the smartpin SPI driver.
Ideas from both of you are there!
https://github.com/speccy88/TAQOZ/blob/master/src/forth/protocol/SPI.FTH
Just rename P2.ROM to _BOOT_P2.BIX and copy to your SD card so it will boot at 115,200 baud. Normally I run mine at 3M, the limit of the USB chip. Take note that MOUNT at present seems a little bit slow since it does an actual cluster scan to check for free and used clusters, but I might change that next time.
For P2-EVAL users, if you want to stop the SD from booting, just switch P59^ on (3rd switch). For P2D2 you will need to put a pullup on P59.
I finally got around to playing with the LED Matrix board. Please remind me how to tell TAQOZ where to find the pins for this board?
Thanks!
This driver assumes the 5X7 FONT is loaded in as part of VGA.FTH
`
Thanks. I can now display stuff on the LED Matrix. I'm assuming the _BOOT_P2.BIX has the 5X7 VGA font. (I can see the font5X7 word.)
However, when I try to send a character to the matrix, I have found that the character displayed is off by 28. For instance, to display "A" (41 hex), I need to send 25 hex.
What did I miss?
Nothing, I think I changed the font table in between and so all you have to do is subtract $1C anytime before you lookup the font table as I do here:
The P1 had twice as much ROM and it had a font table but with only 16K of ROM for the P2 there is no room left over especially after TAQOZ. Now if only we had 32k of ROM or more..... 😁🤔
I presume you can read and write files ok on the pc with Linux?
Do you have a Windoze pc to try that also? Windoze may not like 64KB clusters?
Peter,
Was that a Sandisk 128 Ultra, Ultra Plus, Extreme or Extreme Pro?
I even picked up a Canon SX620HS compact x25 zoom camera for $129. The 128GB card will probably end up in my phone although I seem to have plenty of storage there already.
Just rename P2.ROM to _BOOT_P2.BIX and put it on your card.
I've also zipped up a whole heap of audio files that I converted earlier today along with the videos I've been using and any other file including BMPs that I have on my card. The file is about 2.5GB and while it is not small, neither is it unduly large by today's standards. This is your chance to try out TAQOZ like I do.
FULL SD CARD FILES 2.4GB ZIP
Would you be so kind as to list the hardware and PIN locations you are using? (Just so we new users can get started faster!)
Are you using the P2-ES expansion cards?
Where are you attaching them to the P2-ES board?
etc...
Thanks!
I am impressed with what you are able to do with this hardware and want to experience it for myself.
btw - if you are downloading source code directly into the new TAQOZ you don't need to worry about line delays anymore if you use the TAQOZ and END words which not only place the console into not echoing source and only reporting line numbers and messages, but it also loads directly into upper RAM first before performing a load of source from that RAM. So it is fast!
Seeing that Forth is NOT one of the languages that is available for the P2 despite being able to do more than just blink an led, I wonder if i am just waving the wrong flag.
I do what i do the way i do for the same reason i use the prop instead of an ARM, i can make all kinds of simple or complex stuff and have fun doing it, quickly, without struggling forever and growing old before getting it to work.
I'm not sure what you are asking here, and also unclear on how you separate Rom-TAQOZ which will be in every P2, from some post-boot loaded expanded TAQOZ version ?
(I think your SD playback work, is using an expanded-TAQOZ ?)
Rom-TAQOZ is already in P2 (so I do not comprehend 'Seeing that Forth is NOT one of the languages that is available for the P2') , and that certainly is useful for testing and may even be used in cases where users want to access smart pins via scripts.
For more complete commercial use, that will depend on the developer's experience (and their manager's too... ) .
What does it need added to 'make it suitable for anyone else to actually use seriously' ?
If you wanted to gauge Forth's pulse generally, one litmus test would be to see if there are critical mass projects on raspPi ? A quick search finds a 2013 git, but 6 yr old files.
The best language leverage results, when it can run on more than one host.
That puts Basic, C, Python etc in a stronger position, than Spin or TAQOZ
Currently there are way too many things to do on P2 so i think we are all concentrating on things we love to do. Perhaps as we get more users who don’t have pet projects, more may take up TAQOZ.
What we will need is a lot of good docs with examples. I know there is some already.
I am hopeful that we can see an uptake in users as you have done a fantastic job here. Perhaps as newbies start out with P2, the intro to TAQOZ in ROM will rub off and they will want to investigate further. Those ROM routines were magic for me to checkout that the P2 was indeed working. So we will need a nice little primer for this when the new silicon becomes available.
The TAQOZ in taking about is the extended version that will go on being extended. When i said it is not one of the P2 languages, i meant it is not mentioned officially. When i question the future of it, this had to do with how it is to be used. If i am the only one writing and documenting and using it then it doesn't make any sense to waste all that extra effort catering for users and trying to promote it.
I see that my commercial products will take up a lot of my time and i could just concentrate on that. Is anybody actually interested in using it? I see lots and lots of excitement over various languages but I'm primarily interested in what i can do with the P2.
I'm currently caught up in too many other aspects at the moment but that is where I am going :-)
J
Good to know, I am sometimes (most of the time) left wondering if I should bother at all since there seems to be more interest in languages than there is in actually using the P2 for real projects, both hobby and commercial.
While it might be great to have extensive tutorials and documentation for TAQOZ, that just isn't possible at present since "the same guy" that developed it has done so that he can develop product while having fun. Despite sharing ALL my design files, software, hardware, documentation, photos, videos etc, TAQOZ hardly seems to register above the forum static. What I have is a P2 system that goes far beyond evaluating externally compiled snippets of code, but interactively compiles and debugs from the P2 itself, runs FAT32 and command line disk utilities, VGA and PS/2 keyboards, audio and video playback, Ethernet FTP/HTTP/TELNET servers, and the list goes on. But my commercial project doesn't really depend upon anyone of these, they are just there to support it and to be taken advantage of.
If anyone wanted to help with documentation for instance, then it requires playing with TAQOZ, learning, and trying out ideas rather than needing to ask how to modify code. For instance, I have lots of notifications of anonymous users suggesting "add indent" and other kinds of formatting but what matters is not the formatting, it's the content. Write up something in a separate section or even in a separate document that can be incorporated and eventually nicely formatted later.
At present I will concentrating on new P2D2 hardware, support boards, and application specific boards so there might not be as much happening with TAQOZ itself at present since it already works, and very well at that. Build it and they will come they say. Well, it is built.
Like ErNa, I am, also very grateful and impressed by the work you are doing for TAQOZ and Tachyon Forth for for the P1 and P2, and thank you for that. learned Forth many many years ago when I was in university, and really liked the brevity, extensibility, and power of the language. Unfortunately I never had the opportunity to use Forth in my work after graduating, however I am now planning to learn Tachyon and use it to automate several functions at a small marina during this boating season. There will be several P1's to control functions like entry gates, lighting, grounds watering, etc.. and those P1's will communicate with a P2 to monitor the system and record events. Really looking forward to the challenge, and hope to be able to make a contribution to the documentation and sample code while doing this.
The TAQOZ as in rom, certainly needs to be well documented, with easily pasted demo's, as every single P2 will be including that.
P2 Users will be very interested in what they can, and cannot do, at the TAQOZ prompt they can easily get to on P2
That sounds like a quite separate item, and maybe even needs a separate name, or a clear differentiator suffix ? (maybe TAQOZ-EV & TAQOZ-R ?)
DOCs & demos for this extended version needs to be in a separate area, to avoid otherwise confusing users about just what the P2-ROM is capable of.