There's a link to the Tachyon Dropbox in Peter's signature.
Thanks, that's what I was looking for. I usually ignore the stuff in people's signatures. It might be a good idea to add that link to beginning of the Tachyon documents pages in BIG letters.
So I'm breaking into Tachyon again and I've still not figured out how to include PASM code from OBEX into the system... is there an example of how to do this buried in this thread? I specifically wanted to pull the PASM portion of SIDcog into it and Peter had implied it was easy but I'm too thick to see the path.
So I'm breaking into Tachyon again and I've still not figured out how to include PASM code from OBEX into the system... is there an example of how to do this buried in this thread? I specifically wanted to pull the PASM portion of SIDcog into it and Peter had implied it was easy but I'm too thick to see the path.
Can anyone point me to an example?
Regards!
Please make sure you change your thread title to reflect the subject matter, you are discussing the sidcog but the thread is still titled "Spinneret .......".
Now on the subject of the sidcog I had replied at the time and even created a Google doc with most of the code done but I think this was waiting on my target resident obex where TF can find and load pasm objects from upper eeprom. I might be able to convert the sidcog code by passing the compiler generated listing through TF itself which can extract the machine code and write it to a eeprom (or SD) file. I probably would have finished this at the time had you been chasing me about it but I've got plenty of things to do so "no pressure, no results"
Thanks Peter and sorry about the thread header too. I guess I know too little about the underlying operation of the Prop to understand how "machine code" (PASM) gets executed natively, much less under TF. As far as exploring existing PASM code, is it productive to look at the SPI/I2C implementation on TF compared to spin/pasm stuff to understand things better?
As far as "pressure", hell dude, until I'm writing you a check, there's no pressure. Thanks though!
hi D.P. I have an idle Spinneret sitting here waiting for Tachyon as well :-)
I want to use it as the internet gateway to my sensor/actor network I am setting up here.
The kernel, Extend and Wiznet versions are from DROPBOX ?
Original or did you have to adapt things?
As I understand the WIZNET.fth for W5100 does not run with Tachyon2.3 ??
That's why I postponed my Spinneret experiments atm. ( busy with construction site, house in the mountains ..)
Thanks MJB
Here are the files I use on the spinneret. It would be great as Peter says if we get a new driver that supports the 5100 stuff too. That chip will be a buck very soon now and great for simple network devices with a 64K eeprom, prop 1, magjack, basic IO.
The zip file contains Tachyon V2.1 with a modified extend so that both SPI and I2C work well together and the appropriate WIZnet.fth driver include with added support for client sockets i.e. DIP, DPORT words to support destination port and ip.
I am using the spinneret in a UDP client CO2 monitoring application with the Air Sense K30 10K PPM sensor, let me know if you want that finicky K30 I2C base forth driver, what a mess of a device that just doesn't follow its own datasheet. I worked for a week to get the K33 (CO2, TEMP, RH) to work with I2C in spin quite a while back, took me less than 2 hours to get the K30 working with Tachyon. THANKS PETER.
A few days ago mjb mentioned that it would be good to be able to analyse bytecode in realtime so I thought up of a Q&D method that was next to realtime, just a little slower. The BCA loads a small RUNMOD which then redirects doNEXT via unext to the BCA which then looks after those functions plus it uses 256 longs in BUFFERS to count each code. I just got around to really testing now and I happened to have a gate card-reader controller running and grabbed the results and then pasted that into a spreadsheet.
These are the sorted results, just for interest and note that since it just sits around reading the I2C RTC that there are some skewed results.
I sent you the link for the edit document but here's the published Google web page too for anyone who's interested. I'm still getting around to performing a sort by count but to get it to run now you just insert your code between the <BCA code BCA> like this:
Hey all. Finally spending some quality time with Tachyon and having fun. I've "transliterated" a small piece of Jason Dorie's Nokia 5110 spin LCD driver from OBEX (http://obex.parallax.com/objects/700/) to TF. I'm not versed in TF's idioms for things like SPI so this is the best I could do so far. Any tips from TF'ers to make this better?
\ establish pin settings
0 CONSTANT RST
1 CONSTANT SCE
2 CONSTANT DC
3 CONSTANT SDIN
4 CONSTANT SCLK
pub _write ( data -- )
8 0 DO DUP
7 I - SHR 1 AND SDIN PIN!
SCLK DUP
PINCLR
PINSET
LOOP
SCE PINSET DROP
;
pub cwrite ( data -- ) SCE PINCLR 0 DC PIN! _write ;
pub dwrite ( data -- ) SCE PINCLR 1 DC PIN! _write ;
pub goto ( x y -- )
$40 + cwrite
$80 + cwrite
;
pub clear ( byte -- )
0 0 goto
$1F8 0 DO DUP dwrite LOOP
;
pub init ( -- )
\ make pins high before setting direction
RST PINSET
SCE PINSET
DC PINSET
SDIN PINSET
SCLK PINSET
\ set pins to outputs
RST MASK OUTSET
SCE MASK OUTSET
DC MASK OUTSET
SDIN MASK OUTSET
SCLK MASK OUTSET
\ reset the lcd
RST PINCLR
RST PINSET
$21 cwrite \ PD=0=active, V=0=normal mode, H=1=extended commands follow
$C8 cwrite \ Vop=$48 (contrast)
$06 cwrite \ Temp=$02
$12 cwrite \ Bias=$02
$20 cwrite \ PD=0=active, V=0=normal mode, H=0=normal commands follow
$0C cwrite \ DE=10=normal display
\ for testing only use the next two inits
\ $0D cwrite \ DE=11=inverse
\ $09 cwrite \ DE=01=all segments on
0 clear
;
Hey all. Finally spending some quality time with Tachyon and having fun. I've "transliterated" a small piece of Jason Dorie's Nokia 5110 spin LCD driver from OBEX (http://obex.parallax.com/objects/700/) to TF. I'm not versed in TF's idioms for things like SPI so this is the best I could do so far. Any tips from TF'ers to make this better?
\ establish pin settings
0 CONSTANT RST
1 CONSTANT SCE
2 CONSTANT DC
3 CONSTANT SDIN
4 CONSTANT SCLK
pub _write ( data -- )
8 0 DO DUP
7 I - SHR 1 AND SDIN PIN!
SCLK DUP
PINCLR
PINSET
LOOP
SCE PINSET DROP
;
pub cwrite ( data -- ) SCE PINCLR 0 DC PIN! _write ;
pub dwrite ( data -- ) SCE PINCLR 1 DC PIN! _write ;
pub goto ( x y -- )
$40 + cwrite
$80 + cwrite
;
pub clear ( byte -- )
0 0 goto
$1F8 0 DO DUP dwrite LOOP
;
pub init ( -- )
\ make pins high before setting direction
RST PINSET
SCE PINSET
DC PINSET
SDIN PINSET
SCLK PINSET
\ set pins to outputs
RST MASK OUTSET
SCE MASK OUTSET
DC MASK OUTSET
SDIN MASK OUTSET
SCLK MASK OUTSET
\ reset the lcd
RST PINCLR
RST PINSET
$21 cwrite \ PD=0=active, V=0=normal mode, H=1=extended commands follow
$C8 cwrite \ Vop=$48 (contrast)
$06 cwrite \ Temp=$02
$12 cwrite \ Bias=$02
$20 cwrite \ PD=0=active, V=0=normal mode, H=0=normal commands follow
$0C cwrite \ DE=10=normal display
\ for testing only use the next two inits
\ $0D cwrite \ DE=11=inverse
\ $09 cwrite \ DE=01=all segments on
0 clear
;
The built-in SPI instructions were created to make things like this a breeze, and also fast. Also the PINxxx and OUTxxx instructions always set the pin to an output as there is no sense in not making it an output, so there is never a need to explicitly set a pin to an output. Also a good technique to use in any language is not to have multiple routines which basically do the same thing, such as cwrite and dwrite, but have one and just pass the parameter as to which you want, in this case it was a simple 1 or 0 to say whether it was data or control.
Tachyon Forth also allows code "fall-through" in that if you don't place a semi-colon at the end of the definition then it won't exit but execute the next instruction of the next defintion and all TF code is code, there are no code field pointers in the way. So rather than saying 1 lcdwr for characters it just passes the character to lcdch which pushes a 1 and falls through to lcdwr. Of course I could have made 0 lcdwr work like that instead.
Here's my take:
[FONT=courier new]\ establish pin settings
0 == RST
1 == SCE
2 == DC
3 == SDIN
4 == SCLK
pub lcdch ( char -- ) 1
pub lcdwr ( data reg -- ) DC PIN! SCE PINCLR SPIWRB DROP SCE PINSET ;
pub goto ( x y -- )
$40 + 0 lcdwr
$80 + 0 lcdwr
;
pub clear 0
pub lcdfill ( byte -- ) --- it's not really a clear since you specify the character to fill it with
0 0 goto
$1F8 FOR DUP lcdch NEXT
DROP
;
pub init ( -- )
\ make pins high before setting direction
RST PINCLR --- Note* PINxxx and OUTxxx always makes the pin an output
SCE PINSET
DC PINSET
SDIN PINSET
SCLK PINSET
SDIN |< 8 SHL SCLK |< + SPIPINS --- setup masks for SPIWR
\ reset the lcd
RST PINSET --- now release RST which generated a longer reset
$21 0 lcdwr \ PD=0=active, V=0=normal mode, H=1=extended commands follow
$C8 0 lcdwr \ Vop=$48 (contrast)
$06 0 lcdwr \ Temp=$02
$12 0 lcdwr \ Bias=$02
$20 0 lcdwr \ PD=0=active, V=0=normal mode, H=0=normal commands follow
$0C 0 lcdwr \ DE=10=normal display
\ for testing only use the next two inits
\ $0D 0 lcdwr \ DE=11=inverse
\ $09 0 lcdwr \ DE=01=all segments on
clear
;[/FONT]
BTW, the multiple PINSET operations in init could all be replaced with a single OUTSET.
BTW, glad to hear you are having fun!
BTW, try this and have some more fun.
--- configure LCD as a regular output device (improved output could use control character handling)
: LCD ' lcdch uemit W! ;
init
LCD PRINT" HELLO WORLD" CON
I've been having some trouble making sense of the SPI words but searched the forum and learned how they worked (at least in theory) and did have to adjust a few things: SPIPINS in your example doesn't set CE (SCE in my code) and instead I did:
SCE 16 SHL 3 + 8 SHL SCLK + SPIPINS --- setup masks for SPIWR (no MISO hence the "16 SHL" to skip that byte)
*** It seems my logic analyzer compared with the speed of this routing was resulting in "sub-par" logic levels for the device. Removing the analyzer pins yields flawless writes and blazing pixel updates! Nice work! ***
The LCD device I have might not be able to keep up with the rate your code pumps out the bits. I've looked at the output of "init" with a logic analyzer and it looks like proper SPI (albeit @ 4MHz instead of ~35KHz in my code). My LCD "mostly" displays the bytes I write to it but one sure sign writes are getting dropped is that a "lcdfill" doesn't fill the entire screen with the bit pattern I specify, leaving approximately 10 or so bytes of the last row untouched. Short of re-writing SPIWR, is there a way to throttle this to a lower speed?
One thing that did bother me after looking at the analyzer output was that the SCE and SCLK lines seem to come up in a random state after SPIPINS... is this normal? I resorted to setting the pins to the desired start state after SPIPINS to compensate.
As far as vectoring "lcdch" to "uemit" in your printing examples, this doesn't work on the Nokia 5110 style displays, as they have no built-in fonts... and are instead arranged as 84 bytes 6 rows high (yielding a display 84 pixels by 48 pixels), so each "lcdch" puts a 1 pixel wide by 8 pixels high on the display.
Thanks again for your guidance... I'm slowly working up to getting SIDcog into TF and this LCD interfacing is giving me nice visual feedback for learning.
I've been having some trouble making sense of the SPI words but searched the forum and learned how they worked (at least in theory) and did have to adjust a few things: SPIPINS in your example doesn't set CE (SCE in my code) and instead I did:
<snip>
Thanks again for your guidance... I'm slowly working up to getting SIDcog into TF and this LCD interfacing is giving me nice visual feedback for learning.
Actually SPI instructions don't require a chip enable so it's quite redundant as you might not want the CE to return high after a transfer. You could just set the masks manually with:
SCLK |< @SPISCK COGREG!
SDIN |< @SPISCK 1+ COGREG!
So doing it this way means it won't try to set these pins low during setup.
Of course the easy way to throttle the SPI is simply to insert a delay after each write since the actual clock speed seems to work, it's just the transfer rate that needs to be reduced.
So if the clear loop is too fast just try this (adjust delay if necessary):
pub lcdwr ( data reg -- ) DC PIN! SCE PINCLR SPIWRB DROP #10 us SCE PINSET ;
If you added a character generator word then LCD could be made to work like a regular output word. I've done similar things with VGA and graphic LCDs. Let me know if you need some tips with that and also SIDCOG.
BTW, just found the datasheet for the PCD8544 chip and it does work to 4Mbit okay and there is no mention of having to slow it down anywhere.
According to the datasheet it's possible to transmit several bytes in which case a clear screen function would simply be:
0 0 goto SCE PINCLR 0 $1F8 FOR SPIWR NEXT DROP SCE PINSET
which would only take 1.4ms to clear the whole screen!
Been trying to get this first ethernet driver to compile, seems to be just the lack of COGREGS word in the current kernel.
Looks like I can just assign the pins without this I guess.
Since you are talking SPI above anything else I should look for.
Would like to bring the few spinnerets I bought to life with a 2.3 kernel.
Pretty sure that we should just be able to take W5200.fth and convert it down to suit the W5100. I may have some time tonight so I will have a look. The old COGREGs word was replaced with SETPINS which is used by SPIPINS and MODPINS.
Passing a mask to specify up to 4 pin is handy but I may add words that allow us to specify the 4 parameters like this:
myCE mySI mySO myCK SPIPINS
and then for the mask I would:
mySPIMASK SPIMASK
Yes, I looked back at my W5100 code but other than half the memory and sockets which is not important the only real difference is the SPI framing in that W5100 always operates in 32-bit transfer mode which included the address each time, slow but sure. So I have started by copying the W5200.fth file into W5100.fth and changing the SPI interface layer using the newer SPI instructions that are part of the primary bytecode instructions. The W5200 is a lot snappier, especially if I get around to running at a faster SPI rate later but I also have the W5500 to do too, and that very soon.
Yes, I looked back at my W5100 code but other than half the memory and sockets which is not important the only real difference is the SPI framing in that W5100 always operates in 32-bit transfer mode which included the address each time, slow but sure. So I have started by copying the W5200.fth file into W5100.fth and changing the SPI interface layer using the newer SPI instructions that are part of the primary bytecode instructions. The W5200 is a lot snappier, especially if I get around to running at a faster SPI rate later but I also have the W5500 to do too, and that very soon.
Okay, I've got the 5100 compiling with a V2.3 kernel and will test it later today. This will work okay until the new driver/s are ready. Appreciate the efforts.
Okay, I've got the 5100 compiling with a V2.3 kernel and will test it later today. This will work okay until the new driver/s are ready. Appreciate the efforts.
Okay, I've got the 5100 compiling with a V2.3 kernel and will test it later today. This will work okay until the new driver/s are ready. Appreciate the efforts.
just had my first experiments with SD/EASYFILE working - great
D.P. I'd love to have a look on the changes you made in the W5100.fth file
My Spinneret still is waiting ...
Have you thought about using the parallel interface?
Since it is hardwired on the spinneret, it is of no other use anyhow.
And should be quite faster than SPI. (just realized W5200 is up to 80MHz SPI vs. 4MHz the W5100 - which is 20!!)
Parallel could give a speedup by 10 I would guess.
just had my first experiments with SD/EASYFILE working - great
D.P. I'd love to have a look on the changes you made in the W5100.fth file
My Spinneret still is waiting ...
Have you thought about using the parallel interface?
Since it is hardwired on the spinneret, it is of no other use anyhow.
And should be quite faster than SPI. (just realized W5200 is up to 80MHz SPI vs. 4MHz the W5100 - which is 20!!)
Parallel could give a speedup by 10 I would guess.
Yes, it might be worthwhile to use the parallel interface considering that the pins are already dedicated on the Spinneret then. So there's no reason why a Spinneret couldn't be used as a webserver as well as FTP an Telnet. I've just added the extra STOR functionality to FTP to allow me to upload files so I have been playing with editing the home page on LibreOffice and then FTPing up to the Prop after which I can view it.
BTW, the W5200 is quoted as running up to 80MHz SPI but I understand that around 33MHz is the tested limit. Same goes for the W5500 but I will be looking at a tight coupling with P2 to achieve full theoretical speed if possible.
Was about to try my hacked W5100 WizNet.fth driver with a current kernel: V2.3 140606-2000 and the current Extend.fth, but after loading extend before BACKUP it goes into a reboot boot loop until I press reset.
This is on a spinneret. I've been working with 2.1 kernels with no problem, also the V2.3 kernel seems fully functional as well?
Was about to try my hacked W5100 WizNet.fth driver with a current kernel: V2.3 140606-2000 and the current Extend.fth, but after loading extend before BACKUP it goes into a reboot boot loop until I press reset.
This is on a spinneret. I've been working with 2.1 kernels with no problem, also the V2.3 kernel seems fully functional as well?
Can't see why you would be having that problem but I've updated the Dropbox files just in case. There was one little thing to do with constants that relied on the position of the bytecode for a constant but other than that it should be fine. EXTEND.fth was modified to detect this though.
Can't see why you would be having that problem but I've updated the Dropbox files just in case. There was one little thing to do with constants that relied on the position of the bytecode for a constant but other than that it should be fine. EXTEND.fth was modified to detect this though.
I had a look at Peters W5200.fth, Spinneret schema and W5100 datasheet.
To me it looks like there are only minor changes/additions required.
replace those low level routines with parallel ones:
---
Peter, do I miss anything?
D.P. did you notice s.h. relevant?
That's basically it and later on I will probably transfer the block send routines from easynet over to the drivers instead. I will send you a link to the new W5100.fth which I haven't started working with yet but just setting up the page which was copied from W5200.fth.
Comments
https://docs.google.com/document/d/1PZv3hyan4qsEiFwgVmObLN7NPGw5aymfUSQeZSy-Nvg/pub
Massimo
Can anyone point me to an example?
Regards!
Please make sure you change your thread title to reflect the subject matter, you are discussing the sidcog but the thread is still titled "Spinneret .......".
Now on the subject of the sidcog I had replied at the time and even created a Google doc with most of the code done but I think this was waiting on my target resident obex where TF can find and load pasm objects from upper eeprom. I might be able to convert the sidcog code by passing the compiler generated listing through TF itself which can extract the machine code and write it to a eeprom (or SD) file. I probably would have finished this at the time had you been chasing me about it but I've got plenty of things to do so "no pressure, no results"
As far as "pressure", hell dude, until I'm writing you a check, there's no pressure. Thanks though!
-joe
Here are the files I use on the spinneret. It would be great as Peter says if we get a new driver that supports the 5100 stuff too. That chip will be a buck very soon now and great for simple network devices with a 64K eeprom, prop 1, magjack, basic IO.
The zip file contains Tachyon V2.1 with a modified extend so that both SPI and I2C work well together and the appropriate WIZnet.fth driver include with added support for client sockets i.e. DIP, DPORT words to support destination port and ip.
I am using the spinneret in a UDP client CO2 monitoring application with the Air Sense K30 10K PPM sensor, let me know if you want that finicky K30 I2C base forth driver, what a mess of a device that just doesn't follow its own datasheet. I worked for a week to get the K33 (CO2, TEMP, RH) to work with I2C in spin quite a while back, took me less than 2 hours to get the K30 working with Tachyon. THANKS PETER.
Enjoy
These are the sorted results, just for interest and note that since it just sits around reading the I2C RTC that there are some skewed results.
EGATE software running - system info
CODE
NAME
COUNT
93:
CLOCK
117085896
E2:
NEXT
52039352
A3:
SHRINP
39011640
7E:
BYTE
20654363
11:
NOP
19527126
C1:
YCALL
18734587
0F:
EXIT
16953988
8A:
CON
15999567
89:
0
13336702
A6:
SHROUT
13297219
9A:
INPUTS
12736736
17:
DUP
10178693
21:
SWAP
9720988
CE:
IF
9108331
C2:
XCALL
9031175
14:
DROP
8685744
83:
8
7323679
97:
OUTCLR
7317844
42:
SHR
6508626
D6:
FOR
6505507
4E:
REV
6504772
59:
0=
6257384
BF:
VCALL
5686467
1A:
OVER
5077834
8C:
VAR
4878459
25:
ROT
4876571
B8:
I
4350596
6A:
C!
4350415
DC:
LOOP
4340910
C0:
ZCALL
4332014
29:
+
4207290
95:
OUTSET
3800051
3A:
AND
3615721
62:
C@
3458983
CD:
UNTIL
3167818
FB:
UM*
2977644
04:
XOP
2510320
5F:
C@++
2358507
5C:
>
2324733
57:
=
2196607
64:
W@
1839204
85:
4
1633370
66:
@
1630539
16:
?DUP
1383374
2B:
1-
1277622
2C:
1+
1257434
7D:
WORD
1050279
84:
1
1005054
EB:
REG
895974
86:
2
736835
13:
2DROP
543457
D2:
ADO
541536
7B:
LONG
541366
4C:
2*
513905
87:
3
443141
0D:
0EXIT
279914
8F:
IN@
274867
72:
!
272809
BC:
CALL
270744
F3:
DELTA
270688
50:
MASK
270683
98:
OUTPUTS
270683
1C:
3RD
180464
28:
-
172347
40:
XOR
172111
3E:
OR
16125
81:
BL
10629
C9:
AGAIN
10416
ED:
REG
9263
88:
ON
8124
68:
C+!
7759
DB:
+LOOP
5827
54:
>N
5728
44:
SHL
4831
33:
U/MOD
4712
E9:
R>
4018
E6:
>R
4017
36:
NIP
2810
82:
16
2526
55:
>B
2326
6E:
W!
1261
77:
CLR
894
31:
NEGATE
822
BA:
LSTACK
818
D5:
DO
769
CA:
ELSE
685
6C:
W+!
447
76:
SET
438
07:
STREND
108
D7:
>L
93
D9:
L>
93
2F:
?NEGATE
31
4A:
2/
18
7C:
TRYPE
5
35:
U/
2
EDIT: Or how about just what happens when we run 10 iterations of the Sieve of Eratosthenes:
where has !BCA & .BCA from EXTEND gone to?
I sent you the link for the edit document but here's the published Google web page too for anyone who's interested. I'm still getting around to performing a sort by count but to get it to run now you just insert your code between the <BCA code BCA> like this:
\ establish pin settings 0 CONSTANT RST 1 CONSTANT SCE 2 CONSTANT DC 3 CONSTANT SDIN 4 CONSTANT SCLK pub _write ( data -- ) 8 0 DO DUP 7 I - SHR 1 AND SDIN PIN! SCLK DUP PINCLR PINSET LOOP SCE PINSET DROP ; pub cwrite ( data -- ) SCE PINCLR 0 DC PIN! _write ; pub dwrite ( data -- ) SCE PINCLR 1 DC PIN! _write ; pub goto ( x y -- ) $40 + cwrite $80 + cwrite ; pub clear ( byte -- ) 0 0 goto $1F8 0 DO DUP dwrite LOOP ; pub init ( -- ) \ make pins high before setting direction RST PINSET SCE PINSET DC PINSET SDIN PINSET SCLK PINSET \ set pins to outputs RST MASK OUTSET SCE MASK OUTSET DC MASK OUTSET SDIN MASK OUTSET SCLK MASK OUTSET \ reset the lcd RST PINCLR RST PINSET $21 cwrite \ PD=0=active, V=0=normal mode, H=1=extended commands follow $C8 cwrite \ Vop=$48 (contrast) $06 cwrite \ Temp=$02 $12 cwrite \ Bias=$02 $20 cwrite \ PD=0=active, V=0=normal mode, H=0=normal commands follow $0C cwrite \ DE=10=normal display \ for testing only use the next two inits \ $0D cwrite \ DE=11=inverse \ $09 cwrite \ DE=01=all segments on 0 clear ;The built-in SPI instructions were created to make things like this a breeze, and also fast. Also the PINxxx and OUTxxx instructions always set the pin to an output as there is no sense in not making it an output, so there is never a need to explicitly set a pin to an output. Also a good technique to use in any language is not to have multiple routines which basically do the same thing, such as cwrite and dwrite, but have one and just pass the parameter as to which you want, in this case it was a simple 1 or 0 to say whether it was data or control.
Tachyon Forth also allows code "fall-through" in that if you don't place a semi-colon at the end of the definition then it won't exit but execute the next instruction of the next defintion and all TF code is code, there are no code field pointers in the way. So rather than saying 1 lcdwr for characters it just passes the character to lcdch which pushes a 1 and falls through to lcdwr. Of course I could have made 0 lcdwr work like that instead.
Here's my take:
[FONT=courier new]\ establish pin settings 0 == RST 1 == SCE 2 == DC 3 == SDIN 4 == SCLK pub lcdch ( char -- ) 1 pub lcdwr ( data reg -- ) DC PIN! SCE PINCLR SPIWRB DROP SCE PINSET ; pub goto ( x y -- ) $40 + 0 lcdwr $80 + 0 lcdwr ; pub clear 0 pub lcdfill ( byte -- ) --- it's not really a clear since you specify the character to fill it with 0 0 goto $1F8 FOR DUP lcdch NEXT DROP ; pub init ( -- ) \ make pins high before setting direction RST PINCLR --- Note* PINxxx and OUTxxx always makes the pin an output SCE PINSET DC PINSET SDIN PINSET SCLK PINSET SDIN |< 8 SHL SCLK |< + SPIPINS --- setup masks for SPIWR \ reset the lcd RST PINSET --- now release RST which generated a longer reset $21 0 lcdwr \ PD=0=active, V=0=normal mode, H=1=extended commands follow $C8 0 lcdwr \ Vop=$48 (contrast) $06 0 lcdwr \ Temp=$02 $12 0 lcdwr \ Bias=$02 $20 0 lcdwr \ PD=0=active, V=0=normal mode, H=0=normal commands follow $0C 0 lcdwr \ DE=10=normal display \ for testing only use the next two inits \ $0D 0 lcdwr \ DE=11=inverse \ $09 0 lcdwr \ DE=01=all segments on clear ;[/FONT]BTW, the multiple PINSET operations in init could all be replaced with a single OUTSET.
BTW, glad to hear you are having fun!
BTW, try this and have some more fun.
I've been having some trouble making sense of the SPI words but searched the forum and learned how they worked (at least in theory) and did have to adjust a few things: SPIPINS in your example doesn't set CE (SCE in my code) and instead I did:
*** It seems my logic analyzer compared with the speed of this routing was resulting in "sub-par" logic levels for the device. Removing the analyzer pins yields flawless writes and blazing pixel updates! Nice work! ***
The LCD device I have might not be able to keep up with the rate your code pumps out the bits. I've looked at the output of "init" with a logic analyzer and it looks like proper SPI (albeit @ 4MHz instead of ~35KHz in my code). My LCD "mostly" displays the bytes I write to it but one sure sign writes are getting dropped is that a "lcdfill" doesn't fill the entire screen with the bit pattern I specify, leaving approximately 10 or so bytes of the last row untouched. Short of re-writing SPIWR, is there a way to throttle this to a lower speed?
One thing that did bother me after looking at the analyzer output was that the SCE and SCLK lines seem to come up in a random state after SPIPINS... is this normal? I resorted to setting the pins to the desired start state after SPIPINS to compensate.
As far as vectoring "lcdch" to "uemit" in your printing examples, this doesn't work on the Nokia 5110 style displays, as they have no built-in fonts... and are instead arranged as 84 bytes 6 rows high (yielding a display 84 pixels by 48 pixels), so each "lcdch" puts a 1 pixel wide by 8 pixels high on the display.
The picture @ http://thegaragelab.com/galleries/microboard/nokia_lcd_memory.png might explain it better than my words.
Thanks again for your guidance... I'm slowly working up to getting SIDcog into TF and this LCD interfacing is giving me nice visual feedback for learning.
Actually SPI instructions don't require a chip enable so it's quite redundant as you might not want the CE to return high after a transfer. You could just set the masks manually with:
SCLK |< @SPISCK COGREG!
SDIN |< @SPISCK 1+ COGREG!
So doing it this way means it won't try to set these pins low during setup.
Of course the easy way to throttle the SPI is simply to insert a delay after each write since the actual clock speed seems to work, it's just the transfer rate that needs to be reduced.
So if the clear loop is too fast just try this (adjust delay if necessary):
pub lcdwr ( data reg -- ) DC PIN! SCE PINCLR SPIWRB DROP #10 us SCE PINSET ;
If you added a character generator word then LCD could be made to work like a regular output word. I've done similar things with VGA and graphic LCDs. Let me know if you need some tips with that and also SIDCOG.
BTW, just found the datasheet for the PCD8544 chip and it does work to 4Mbit okay and there is no mention of having to slow it down anywhere.
According to the datasheet it's possible to transmit several bytes in which case a clear screen function would simply be:
0 0 goto SCE PINCLR 0 $1F8 FOR SPIWR NEXT DROP SCE PINSET
which would only take 1.4ms to clear the whole screen!
Looks like I can just assign the pins without this I guess.
Since you are talking SPI above anything else I should look for.
Would like to bring the few spinnerets I bought to life with a 2.3 kernel.
Pretty sure that we should just be able to take W5200.fth and convert it down to suit the W5100. I may have some time tonight so I will have a look. The old COGREGs word was replaced with SETPINS which is used by SPIPINS and MODPINS.
Passing a mask to specify up to 4 pin is handy but I may add words that allow us to specify the 4 parameters like this:
myCE mySI mySO myCK SPIPINS
and then for the mask I would:
mySPIMASK SPIMASK
http://openmicrolab.com/wp/wp-content/uploads/1/cfile3.uf.1221F0404EE59A7B11507B.pdf
Impressive the 80 instead 4 MHz SPI clock and 32 instead of 16kB RAM + 8 Sockets
Changes: Different SPI command format, so driver is not fully compatible.
Yes, I looked back at my W5100 code but other than half the memory and sockets which is not important the only real difference is the SPI framing in that W5100 always operates in 32-bit transfer mode which included the address each time, slow but sure. So I have started by copying the W5200.fth file into W5100.fth and changing the SPI interface layer using the newer SPI instructions that are part of the primary bytecode instructions. The W5200 is a lot snappier, especially if I get around to running at a faster SPI rate later but I also have the W5500 to do too, and that very soon.
Okay, I've got the 5100 compiling with a V2.3 kernel and will test it later today. This will work okay until the new driver/s are ready. Appreciate the efforts.
D.P. I'd love to have a look on the changes you made in the W5100.fth file
My Spinneret still is waiting ...
Have you thought about using the parallel interface?
Since it is hardwired on the spinneret, it is of no other use anyhow.
And should be quite faster than SPI. (just realized W5200 is up to 80MHz SPI vs. 4MHz the W5100 - which is 20!!)
Parallel could give a speedup by 10 I would guess.
Yes, it might be worthwhile to use the parallel interface considering that the pins are already dedicated on the Spinneret then. So there's no reason why a Spinneret couldn't be used as a webserver as well as FTP an Telnet. I've just added the extra STOR functionality to FTP to allow me to upload files so I have been playing with editing the home page on LibreOffice and then FTPing up to the Prop after which I can view it.
BTW, the W5200 is quoted as running up to 80MHz SPI but I understand that around 33MHz is the tested limit. Same goes for the W5500 but I will be looking at a tight coupling with P2 to achieve full theoretical speed if possible.
This is on a spinneret. I've been working with 2.1 kernels with no problem, also the V2.3 kernel seems fully functional as well?
Can't see why you would be having that problem but I've updated the Dropbox files just in case. There was one little thing to do with constants that relied on the position of the bytecode for a constant but other than that it should be fine. EXTEND.fth was modified to detect this though.
I'll give it a try and postback.
UPDATE: no joy
"140602 Add in delays into I2CSTART and I2CSTOP, add timeout for @EEWAIT."
I'll fire up the Spinneret and get back to you
Well that worked just fine? Thanks.
To me it looks like there are only minor changes/additions required.
replace those low level routines with parallel ones:
The single read / write
\ Write to the WIZnet register via SPI
pub WIZX! ( data address cnt -- )
\ Read from the WIZnet register via SPI
pri WIZX@ ( address cnt -- data )
and the block read / write
\ Read a block of memory from the WIZnet
pub LREAD ( src dst cnt -- )
\ Write a block to the WIZnet - 3.2ms/512 bytes = = 6.25us/byte = 160kB/sec
pub LWRITE ( src dst cnt -- )
and an Init:
\ Init the SPI for the WIZnet chip
pub !WIZIO
Clean layering has it's benefits ;-)
The block operations can be done with the fast auto increment mode of the indirect address mode.
##### in WIZNET.fth for the W5100 I see:
\ Write to the WIZnet register via SPI
pub WIZ! ( data address -- )
\ Read from the WIZnet register via SPI
pub WIZ@ ( address -- data )
\ Init the SPI for the WIZnet chip
pub !WIZIO
Peter, do I miss anything?
D.P. did you notice s.h. relevant?
That's basically it and later on I will probably transfer the block send routines from easynet over to the drivers instead. I will send you a link to the new W5100.fth which I haven't started working with yet but just setting up the page which was copied from W5200.fth.