@samuell - The boot ROM starts up at RCFAST, just a bit over 20MHz. The boot image on SD switches to 180MHz so it will indeed draw more current!
As for the inductors squealing that is usually an indication that your USB supply is insufficient and most of the time this is due to a poor cable rather than any limitations of the USB port. Use a thicker/shorter cable or a "charger" type cable. Measure your 5V on the ES board to confirm. I've thrown out a whole batch of cables due to their being only good as a "data" cable. I even made up a cable resistance checker to weed out the bad ones. (BTW, I stripped one of the bad cables and found that the power wires were the same wound foil strip they use for the signal lines, a total disgrace! Normally these two wires are thicker multistrand cable.)
The power cable is a real issue. I was worried there was a problem with my ES when I couldn't get it to come up to TaqOZ until I tried a shorter, thicker power cable. This seems to be a much larger issue for P2 than it was for P1, for obvious reasons.
Peter,
Please explain what P2 commands are invoked by the
1ma SOURCE OPEN DRAIN
code that you had shown.
Thanks
Tom
That's nice and easy. Essentially I have taken the values from CIOHHHLLL bit-fields in the smartpin and extended Forth in such a way that I can now use these new words to "describe" the pin mode. I already do this now for instance when I switch a pin to nco mode at a desired frequency with "40 PIN 1 KHZ" which is an easy way to configure a pin, I'm sure you would agree. (We could make it more conventional and arcane if you like).
The OPEN DRAIN version I used that you quoted was a mistake in the way it was used but I will go through some valid examples.
1ma SOURCE
The 1ma word is simply a constant:
%100 := 1ma
So all this does is leave a value on the stack but SOURCE expects a 3-bit value that it applies to the HHH bit-field in the smartpin value that is being assembled and exists only as a variable at this stage. In fact "40 PIN" not only selects the pin but also clears this _pinmode variable in preparation.
SOURCE takes the 1ma constant value where PINM shifts it up by the specified 11 bits and will SET the bits in _pinmode
: PINM << _pinmode SET ;
: SOURCE 11 PINM ;
At this point nothing has happened except that a pin has been selected, a variable cleared and bit-fields set. Same goes for the SINK parameter but if you don't specify any fields than FAST (or normal in fact) is selected since the bit-field value is %000 for this. Let's assume all we have said altogether is:
40 PIN 1ma SOURCE
Then let's see what the _pinmode variable contains:
TAQOZ# 40 PIN 1ma SOURCE --- ok
TAQOZ# _pinmode @ .BIN --- %00000000000000000010000000000000 ok
Nothing, except the bit that selects the smartpin's 1ma source drive %100 and normal FAST sink %000
If now I apply a smartpin function such as HZ, it will merge the NCO function value with any other bits in _pinmode before selecting the smartpin with WRPIN and also write the calculated NCO frequency value with WYPIN (as well as writing a value of 1 to WXPIN).
Maybe that was a bit long winded but when you understand the principle of extending the language to create a language or syntax then you are starting to understand and think in Forth, rather than "coding".
Now when you read "40 PIN 1ma SOURCE 100 HZ" it is made up of 3 groups composed of (value function) with 40 and 1ma and 100 being values and PIN SOURCE and HZ being the function. While it can be expressed in one line, it could just as easily be broken up to 6 lines or combined on a line with other hopefully relevant code.
Back to OPEN DRAIN which I used incorrectly in the "language" I just developed
OPEN leaves a value of %111 which as either HHH or LLL bit-fields will disconnect or float the source/sink but OPEN is a better word to describe it in this context. DRAIN is simply a function that is an alias of SOURCE
Expand that with the value and we have OPEN SOURCE which simply writes the %111 value to the HHH of our internal _pinmode variable. As mentioned before, the default values for HHH and LLL are %000 which is FAST so there is no need to say FAST SINK although it may help to do so for readability.
FURTHER EXAMPLES:
40 PIN 150K SOURCE --- this has a very weak pull-up but FAST SINK by default
40 PIN 150K SOURCE FAST SINK --- same as above
40 PIN FAST SOURCE FAST SINK --- Redundant and unnecessary since nothing is actually set and this is the default.
40 PIN 100ua SOURCE OPEN SINK --- Will only source 100ua when the output is HIGH (good for linear charging of a cap)
40 PIN 1K5 SOURCE 1K5 SINK --- Weak driver - equivalent to having a normal CMOS output with a 1K5 in series with it.
What would I need to do in TAQOZ (current or later ROM) to switch serial console output and input to different pins?
I was able to patch the current ROM manually and got Monitor, Debugger and TAQOZ to use a ProPlug connected to one header of the EVAL board. It basically works, but as soon as I try lsio TAQOZ looses my patched in pins.
My guess is that lsio switches the pins into digital mode and upon switching back reactivates the old pins.
Since I basically have TAQOZ running under serial control from my own program I could send a oneliner to fix the issue, but I don't now what to send.
So @"Peter Jakacki" please help, how to switch the console to different Pins in TAQOZ and survive lsio? and how to change the input selector for the receive pin permanently? my patched version reads a smart pin next to it...
What would I need to do in TAQOZ (current or later ROM) to switch serial console output and input to different pins?
I was able to patch the current ROM manually and got Monitor, Debugger and TAQOZ to use a ProPlug connected to one header of the EVAL board. It basically works, but as soon as I try lsio TAQOZ looses my patched in pins.
My guess is that lsio switches the pins into digital mode and upon switching back reactivates the old pins.
Since I basically have TAQOZ running under serial control from my own program I could send a oneliner to fix the issue, but I don't now what to send.
So @"Peter Jakacki" please help, how to switch the console to different Pins in TAQOZ and survive lsio? and how to change the input selector for the receive pin permanently? my patched version reads a smart pin next to it...
Enjoy!
Mike
I will make it easier to change it in V2 and make it persistent but in V1.1 you can have an autostart routine that patches the tx_pin in the cog which is only loaded on a reset normally. In V1.1 that location is $18D.
08748 18d 0000003e txpin long tx_pin
Obviously you could do a <mypin> $183 COG! or you could even do a <mypin> $8748 ! to write it to the boot image and save that back. Actually a faster way is you can FOPEN _BOOT_P2.BIX and then simply type <mypin> $8748 SD! and FLUSH to write it back! (even simpler and it "should" work).
Play with that and in the meantime I will check what is required for the rxpin and append this post shortly. Perhaps I may just make it easier in V2 as I said and upload a new image.
If only we had a TAQOZ TEAM - to help fill in the gaps and build apps.
Count me in Peter!
1) I suggest that we create a TAQOZ repository on https://github.com/parallaxinc/ so that people who want to contribute code and docs and fix errors could make pull requests. It would just be a matter of creating a repo from your dropbox folder and converting the doc to markdown.
2) I started making a driver for a Nokia 5110 LCD. Your current SPI driver is too fast at 180MHz for the LCD, I had to set the clock speed at SLOW (40 MHz) to make it work. What would you suggest? Making a second SPI driver in Forth with adjustable speed?
3) For the Nokia 5110, there is a font I need to put in memory. Each character is 5 bytes. What is the best way to initialize an array in memory with Forth?
I saw the code below but I don't quite understand the [C] and GRAB.
CREATE FONT5X7
$60 7 * ALLOT
FONT5X7 $60 7 * ERASE
pre ,,
[C] GRAB
$20 - 7 * FONT5X7 + SWAP ( adr str ) 1+
7 FOR
0 OVER 5 ADO 2* I C@ 1 AND OR LOOP ( adr str val )
3RD C! ( adr str ) 5 + SWAP 1+ SWAP
NEXT
2DROP
;
" 00000000000000000000000000000000000" $20 ,,
" 00100001000010000100001000000000100" $21 ,,
" 01010010100101000000000000000000000" $22 ,,
I also tried to test the TABLE word, but it does not seem to work with TAQOZ? (it fails after the second |)
I just remembered that you asked a few questions but I had to dig back into the thread again to find it!
1) yes, we could do a TAQOZ repo especially if we can do it as a pinned repo since it is in ROM.
2) Write a driver in TAQOZ itself rather than using the optimized assembly code in the kernel. It is very very simple to do, just bash some bits out.
3) TAQOZ uses wordcode which is either a cog or hubexec address plain and simple, or it is a high level call to more threaded code, or if it is usually >$F800 then it is further decoded as a short 10-bit literal, or a conditional branch etc. Since wordcode is exactly 16-bits long then any call to word aligned (purposely) threaded code always falls on an even address so TAQOZ uses the lsb to indicate a jump instead of a call which is also very useful for ELSE AGAIN REPEAT type unconditional branches etc.
What does that have to do with creating a table of bytes? It just means we can never have the current code compilation pointer on an odd address since all code, even interactive code, is normally compiled and then executed. The only difference with interactive code is that the code space is reused again but compiles at code's end the same as a definition etc.
That's why TABLE is now preallocated using a byte count value as in 128 7 * TABLE FONT5X7 although you are quoting an early structure that was created manually but does the same thing (but hides the details). I then create a compiler helper word (that is later forgotten and removed) that scans a string and value to write the bit pattern into that table. None of this affects the word alignment since it has been preallocated.
[C] is an immediate to force the compilation of another immediate word GRAB which forces any interactive code to execute thus leaving their values on the stack. Actually, I'm sure I could make that simpler now, it's more of a leftover.
I will fill in the rest of this post later (dinner calls).
BACK AGAIN
I just checked the table structure I use now and it doesn't use [C] GRAB so that must have been the transitional version I used when I changed over to preallocating tables and filling them in later. But you can still create a table the old way that builds up, in fact have a look at TAQOZ2V0.FTH and you will see this:
It was easy enough to create the ,, word to read 4 bytes and compile them in one shot to keep word alignment. The reason that the ,, uses the [C] GRAB is because the exact place that the temporary code is compiled is the exact place that the table has to be built, so it has to GRAB all the code that is temporarily compiled there and execute it which in this case results in permanent compilation of constants. The code pointers are then advanced after each line and by changing the TAQOZ prompt to reveal the code pointer we can watch it unfold (see if you can grok this).
btw - this version of TAQOZ is inserting a --- between the user input and its response so that it easier to see what is what.
TAQOZ# : CODEPROMPT HERE .W ." : " ; --- ok
TAQOZ# ' CODEPROMPT uprompt W! --- ok
$511A: 0 TABLE atable --- ok
$511C: 12 34 + . --- 46 ok
$511C: 12 34 56 78 ,, --- ok
$5120: $511C QD ---
0511C: 0C 22 38 4E 41 01 1C 51 BC 16 4E 00 4E 00 C8 15 '."8NA..Q..N.N...'
0512C: 0A FC B9 FE D5 00 85 00 70 00 D5 00 01 F8 94 00 '........p.......' ok
$5120: HERE QD ---
05120: A8 14 BC 16 4E 00 4E 00 4E 00 C8 15 0A FC B9 FE '....N.N.N.......'
05130: D5 00 85 00 70 00 D5 00 01 F8 94 00 7B 00 DD 00 '....p.......{...' ok
$5120: ' HERE .W --- $14A8 ok
$5120: ' QD .W --- $16BC ok
$5120: HERE $10 DUMPW ---
05120: 14A8 F810 16DE 004E 004E 15C8 FC0A FEB9 '......N.N.......' ok
$5120:
It was kinda useful to create a word that would print the code pointer and revector the TAQOZ prompt by storing the code address of that routine into the uprompt vector. Straight away the prompt is exactly what I wanted. When I create an empty TABLE we can see how that used up a single wordcode which is in fact the code that returns the address following it by popping the return stack and pushing it onto the data stack, and never returning back there again but instead leaving a pointer to any structure that we may create.
When I typed in some temporary interactive code with 12 34 + . it never permanently allocated code memory but the pointer stayed the same at $511C. However when I now type the same numbers plus a couple more then use the immediate ,, word it grabbed and built up the 4 bytes into a long that was compiled with the , word.
pre ,, [C] GRAB 3 FOR 8<< + NEXT [C] , ;
The last few lines in my test was just to reveal the termporary code that is compiled so the code address of HERE is $14A8 and the last line I dumped you can see that at $5120 followed by a wordcode that encodes $10 as a short 10-bit literal, then DUMPW and then $004E which is EXIT so that the code can return to the console. Then the code pointer is restored back to $5120.
Welcome to "Fudge the TAQOZ compiler on the go" 101
I already patch long tx_pin in the rom before I let COG0 softly slide into TAQOZ after starting my program in COG1.
It does work except lsio, that seems to reset the pin somehow.
But I am not really able to decipher the Boot Rom Spin contained TAQPZ words used at lsio.
And it would be really nice if you could make this more easy in the second ROM. The basic goal is to set rx and tx to different pins and allow to set the rxpin selector to allow taqoz rx running on its designed pin reading the next pin used by another cog as smart pin tx.
This all allows to use TAQOZ as serial sub system running in its own COG from any other language by treating it as a serial device. And one could use all TAQOZ features from Basic, C, Blockly, assembler, Spin, or whatever else by just using 4 smartpins, one COG and leaving enough space on the bottom of RAM for TAQOZ to exist.
I basically have this running, except lsio killing my patches...
Peter,
Thanks for the insight to the inner workings. I've got to read that a few more times while interacting with TAQOZ. My goal is to understand the smart pins and how I can use them.
I find that the best way to see how things work is to start a definition working in a new cog and send / receive parameters to/from it via global variables from cog 0 and print responses.
I know I'll have more questions as I go.
At times it is useful to be able to print 64-bit results of mixed operations and that capability has been in TAQOZ from the start. There is a little known operator <D> that takes the high 32-bits and load it into a holding register which is normally zero but all routines that use the number print routine take into account.
But if we wanted to enter a double number it was awkward although hex numbers are easy to break up into two 32-bit parts, not so with decimal numbers. Traditionally in Forths that support it, placing a decimal point in a number signifies that this should be handled as a 64-bit double number. The trouble is that TAQOZ allows any mix of symbols within the number for a whole variety of reasons and so to keep the flexibility and also at the same time follow some convention I process any number that ends in a decimal point as a double number.
I will add more support for double numbers within reason and this already includes D@ and D! (I prefer the D instead of 2@ 2!) and a D. to print a double number. Other double number operators are 2DUP 2DROP 2SWAP. Maybe I might change D@ D! to 2@ 2! in that case then but 2. for print?
Here are a couple of examples:
TAQOZ# 123456789070710678. --- ok
TAQOZ# 2DUP D. --- 123456789070710678 ok
TAQOZ# .S ---
DATA STACK (2)
1 $01B6_9B4B 28744523
2 $A9AB_8796 -1448376426 ok
TAQOZ# 1000 UM// D. --- 123456789070710 ok
TAQOZ# . --- 678 ok
TAQOZ# $ABAD.DEED-DEAD.BEEF. --- ok
TAQOZ# .S ---
DATA STACK (2)
1 $ABAD_DEED -1414668563
2 $DEAD_BEEF -559038737 ok
TAQOZ# HEX --- ok
TAQOZ$ D. --- ABADDEEDDEADBEEF ok
TAQOZ$
My Nokia 5110 LCD driver is working well! It was easy to redirect TAQOZ output to the LCD using uemit vector. Is there a way to have uemit outputting to the my LCD and the console at the same time?
My Nokia 5110 LCD driver is working well! It was easy to redirect TAQOZ output to the LCD using uemit vector. Is there a way to have uemit outputting to the my LCD and the console at the same time?
: EMIT_N5110 ' PUT_CHAR_5110 uemit W! ;
Normally uemit is zeroed and this selects the default serial console but you can always reference this device as CONEMIT. Therefore all you need to do is create a new hybrid device:
: BOTH EMIT: DUP CONEMIT EMIT_N5110 ;
If you can use the latest image on SD then please do that as that supports EMIT: so this simplifies creating character I/O devices.
I decided I'd better look at how much memory the compressed file takes since I need to be prepared to commit at some point soon to the new boot ROM. I did a simple compress of the 128k image I used and it was too high at 51k. No way, but I remembered that the BACKUP just saves all the first 128k and there are all kinds of buffers and temporary storage in there. So I trimmed out those areas in the image and now it compresses to 15.5k. While that is still a little too high I know that I haven't stripped private headers from the dictionary (the ones that aren't required any longer) and I could very easily trim a lot of the verbose strings I use in the disk utilities to something just as readable. Then there are code fragments that would probably not be used, although I'd probably still like the idea of keeping the PS/2 keyboard as well as most of the VGA utilities including the 5X7 font table.
To test out decompression at boot I could easily do a _BOOT_P2.BIX file that just ran the decompression routine on the LZMA file. It should also load a lot faster even from the current slow load ROM.
So I think I can get it down into the 12k region. So far, so good.
Peter, I'm having trouble changing the clock speed on V2 (extended with TAQOZ2V0.FTH). It was working fine with V1.1
I noticed that too, must be a minor thing so I will get that fixed up shortly.
@samuell - if you used the P2-ES image then it should work. Make sure it is <this one>
Hi Peter,
I've tried the new image, and it now prints correctly. However, DIR shows _BOOT_P2.BIX filename with strange characters where the name should be. Please, see the image attached.
Also, I've noticed that I can't change speed without messing up the terminal. Even "CRUISE" messes up the characters. I've confirmed that the board stays at 180MHz (by sending "32 PIN 90 MHZ" and verifying that the pin still outputs at 90 MHz).
There's a new V2 image in the Dropbox folder you can try which corrects the clock speed problem. I've now also fixed the divider to 1 and any clock frequencies selected will be forced to a multiple of that, just to keep things simple. You can however manually specify the clock settings and you can have a look at the source for CLOCK to get a better idea (i.e. uses 15PF PLLEN 1 XIDIV etc).
This image starts up at 115200 baud at 80MHz since the SD seems to behave better on the P2-ES board at a lower clock rate but just type CRUISE to switch to 180MHz if you also want to use VGA. The P2-ES seems to work fine at 340MHz otherwise but I need to make some changes so that the VGA frequency will also switch and hopefully the SD will still work.
@samuell - rather than posting a whole screenshot where only part of it is relevant, just select and copy the text then paste it into the forum using the 'C' code tags.
I think I'm making some progress in improving the operating speed of the SD card on the ES. Looking closely at the waveforms and even though the clock is not as square as it could be I decided to pad the the read routines with an extra nop just to give the P2 enough setup time to read the data and that seems to have done the trick. While I would like it as fast as possible at the slower speeds I think it is a small sacrifice to make. I need to do some further testing though.
TAQOZ# ECO --- ok
TAQOZ# .SPEEDS ---
SECTOR READ SPEEDS.............. 851us,803us,803us,803us,803us,803us,803us,803us,
BLOCK READ RATE................. 842kB/second @80MHz ok
TAQOZ# CRUISE --- ok
TAQOZ# .SPEEDS ---
SECTOR READ SPEEDS.............. 489us,440us,440us,440us,440us,440us,440us,440us,
BLOCK READ RATE................. 1,893kB/second @180MHz ok
TAQOZ# TURBO ---� ok
TAQOZ# .SPEEDS ---
SECTOR READ SPEEDS.............. 420us,371us,371us,371us,371us,371us,371us,371us,
BLOCK READ RATE................. 2,523kB/second @240MHz ok
TAQOZ# HYPER --- ok
TAQOZ# .SPEEDS ---
SECTOR READ SPEEDS.............. 360us,311us,311us,312us,311us,311us,311us,311us,
BLOCK READ RATE................. 3,570kB/second @340MHz ok
I think I'm making some progress in improving the operating speed of the SD card on the ES. Looking closely at the waveforms and even though the clock is not as square as it could be I decided to pad the the read routines with an extra nop just to give the P2 enough setup time to read the data and that seems to have done the trick. While I would like it as fast as possible at the slower speeds I think it is a small sacrifice to make. I need to do some further testing though.
Sounds great - it is common to pad/tune code with NOPs in order to better balance clock behaviour.
In doing so, you also gain better tolerance to users PCB layouts, and any ROM code is going to need to be quite PCB layout Tolerant.
That makes the high-cap traces of the P2 Eval, a good test.
That makes the high-cap traces of the P2 Eval, a good test.
Is this due to the 3x 47pf Caps that are fitted to the P2 Eval board on the SD card pins, CMD, CS and CLK ?
They were requested for I/O stability of the P2-ES chip, and will not be needed on the production chip.
I would be happy to remove (or reduce in value) some or all of those from an Eval board and run a test script..?
In that case, please share a test script and I'll post the scope image of those 3 pins.
Edit: Just found this other thread. Seems this might be a test script...
Send out a CMD8 (with CRC) and read the response.
TAQOZ# $87 sdcrc C! $1AA 8 CMD 1 = IF SD4@ .W THEN --- $01AA ok
That makes the high-cap traces of the P2 Eval, a good test.
Is this due to the 3x 47pf Caps that are fitted to the P2 Eval board on the SD card pins, CMD, CS and CLK ?
They were requested for I/O stability of the P2-ES chip, and will not be needed on the production chip.
I would be happy to remove (or reduce in value) some or all of those from an Eval board and run a test script..?
In that case, please share a test script and I'll post the scope image of those 3 pins.
I used 10pF (maybe they were 18pF) on my P2D2 but if you have the PCB files I can track down the components fairly easily then. It's the clock line I've been mostly worried about and I have taken quite some captures at different frequencies which is why I decided to retard the read timing.
That may have more to do with the clock speed but I guess I could add something to it that checked the current clock speed and timed accordingly. However there is a constant in the cog location before WSLED that you can change manually. Just try the next line and that should do it I think.
CLKHZ 250000 U/ ' WSLED 1- COG!
The code in cog tat needs adjustment.
wsdly long sys_clk/2500000
WSLED rdbyte r2,##wsdly
The new image boots, but doesn't seem to accept any keywords. Even typing "WORDS" causes it to output "???" and then "--- ok". I've noticed that the P2 runs hot, and I think 300MHz might be a bit too much. Is it because of VGA?
Comments
As for the inductors squealing that is usually an indication that your USB supply is insufficient and most of the time this is due to a poor cable rather than any limitations of the USB port. Use a thicker/shorter cable or a "charger" type cable. Measure your 5V on the ES board to confirm. I've thrown out a whole batch of cables due to their being only good as a "data" cable. I even made up a cable resistance checker to weed out the bad ones. (BTW, I stripped one of the bad cables and found that the power wires were the same wound foil strip they use for the signal lines, a total disgrace! Normally these two wires are thicker multistrand cable.)
Please explain what P2 commands are invoked by the code that you had shown.
Thanks
Tom
That's nice and easy. Essentially I have taken the values from CIOHHHLLL bit-fields in the smartpin and extended Forth in such a way that I can now use these new words to "describe" the pin mode. I already do this now for instance when I switch a pin to nco mode at a desired frequency with "40 PIN 1 KHZ" which is an easy way to configure a pin, I'm sure you would agree. (We could make it more conventional and arcane if you like).
The OPEN DRAIN version I used that you quoted was a mistake in the way it was used but I will go through some valid examples. The 1ma word is simply a constant: So all this does is leave a value on the stack but SOURCE expects a 3-bit value that it applies to the HHH bit-field in the smartpin value that is being assembled and exists only as a variable at this stage. In fact "40 PIN" not only selects the pin but also clears this _pinmode variable in preparation.
SOURCE takes the 1ma constant value where PINM shifts it up by the specified 11 bits and will SET the bits in _pinmode
At this point nothing has happened except that a pin has been selected, a variable cleared and bit-fields set. Same goes for the SINK parameter but if you don't specify any fields than FAST (or normal in fact) is selected since the bit-field value is %000 for this. Let's assume all we have said altogether is: Then let's see what the _pinmode variable contains: Nothing, except the bit that selects the smartpin's 1ma source drive %100 and normal FAST sink %000
If now I apply a smartpin function such as HZ, it will merge the NCO function value with any other bits in _pinmode before selecting the smartpin with WRPIN and also write the calculated NCO frequency value with WYPIN (as well as writing a value of 1 to WXPIN).
Maybe that was a bit long winded but when you understand the principle of extending the language to create a language or syntax then you are starting to understand and think in Forth, rather than "coding".
Now when you read "40 PIN 1ma SOURCE 100 HZ" it is made up of 3 groups composed of (value function) with 40 and 1ma and 100 being values and PIN SOURCE and HZ being the function. While it can be expressed in one line, it could just as easily be broken up to 6 lines or combined on a line with other hopefully relevant code.
Back to OPEN DRAIN which I used incorrectly in the "language" I just developed
OPEN leaves a value of %111 which as either HHH or LLL bit-fields will disconnect or float the source/sink but OPEN is a better word to describe it in this context. DRAIN is simply a function that is an alias of SOURCE
Expand that with the value and we have OPEN SOURCE which simply writes the %111 value to the HHH of our internal _pinmode variable. As mentioned before, the default values for HHH and LLL are %000 which is FAST so there is no need to say FAST SINK although it may help to do so for readability.
FURTHER EXAMPLES:
40 PIN 150K SOURCE --- this has a very weak pull-up but FAST SINK by default
40 PIN 150K SOURCE FAST SINK --- same as above
40 PIN FAST SOURCE FAST SINK --- Redundant and unnecessary since nothing is actually set and this is the default.
40 PIN 100ua SOURCE OPEN SINK --- Will only source 100ua when the output is HIGH (good for linear charging of a cap)
40 PIN 1K5 SOURCE 1K5 SINK --- Weak driver - equivalent to having a normal CMOS output with a 1K5 in series with it.
I was able to patch the current ROM manually and got Monitor, Debugger and TAQOZ to use a ProPlug connected to one header of the EVAL board. It basically works, but as soon as I try lsio TAQOZ looses my patched in pins.
My guess is that lsio switches the pins into digital mode and upon switching back reactivates the old pins.
Since I basically have TAQOZ running under serial control from my own program I could send a oneliner to fix the issue, but I don't now what to send.
So @"Peter Jakacki" please help, how to switch the console to different Pins in TAQOZ and survive lsio? and how to change the input selector for the receive pin permanently? my patched version reads a smart pin next to it...
Enjoy!
Mike
I will make it easier to change it in V2 and make it persistent but in V1.1 you can have an autostart routine that patches the tx_pin in the cog which is only loaded on a reset normally. In V1.1 that location is $18D. Obviously you could do a <mypin> $183 COG! or you could even do a <mypin> $8748 ! to write it to the boot image and save that back. Actually a faster way is you can FOPEN _BOOT_P2.BIX and then simply type <mypin> $8748 SD! and FLUSH to write it back! (even simpler and it "should" work).
Play with that and in the meantime I will check what is required for the rxpin and append this post shortly. Perhaps I may just make it easier in V2 as I said and upload a new image.
I just remembered that you asked a few questions but I had to dig back into the thread again to find it!
1) yes, we could do a TAQOZ repo especially if we can do it as a pinned repo since it is in ROM.
2) Write a driver in TAQOZ itself rather than using the optimized assembly code in the kernel. It is very very simple to do, just bash some bits out.
3) TAQOZ uses wordcode which is either a cog or hubexec address plain and simple, or it is a high level call to more threaded code, or if it is usually >$F800 then it is further decoded as a short 10-bit literal, or a conditional branch etc. Since wordcode is exactly 16-bits long then any call to word aligned (purposely) threaded code always falls on an even address so TAQOZ uses the lsb to indicate a jump instead of a call which is also very useful for ELSE AGAIN REPEAT type unconditional branches etc.
What does that have to do with creating a table of bytes? It just means we can never have the current code compilation pointer on an odd address since all code, even interactive code, is normally compiled and then executed. The only difference with interactive code is that the code space is reused again but compiles at code's end the same as a definition etc.
That's why TABLE is now preallocated using a byte count value as in 128 7 * TABLE FONT5X7 although you are quoting an early structure that was created manually but does the same thing (but hides the details). I then create a compiler helper word (that is later forgotten and removed) that scans a string and value to write the bit pattern into that table. None of this affects the word alignment since it has been preallocated.
[C] is an immediate to force the compilation of another immediate word GRAB which forces any interactive code to execute thus leaving their values on the stack. Actually, I'm sure I could make that simpler now, it's more of a leftover.
I will fill in the rest of this post later (dinner calls).
BACK AGAIN
I just checked the table structure I use now and it doesn't use [C] GRAB so that must have been the transitional version I used when I changed over to preallocating tables and filling them in later. But you can still create a table the old way that builds up, in fact have a look at TAQOZ2V0.FTH and you will see this: It was easy enough to create the ,, word to read 4 bytes and compile them in one shot to keep word alignment. The reason that the ,, uses the [C] GRAB is because the exact place that the temporary code is compiled is the exact place that the table has to be built, so it has to GRAB all the code that is temporarily compiled there and execute it which in this case results in permanent compilation of constants. The code pointers are then advanced after each line and by changing the TAQOZ prompt to reveal the code pointer we can watch it unfold (see if you can grok this).
btw - this version of TAQOZ is inserting a --- between the user input and its response so that it easier to see what is what.
TAQOZ# : CODEPROMPT HERE .W ." : " ; --- ok TAQOZ# ' CODEPROMPT uprompt W! --- ok $511A: 0 TABLE atable --- ok $511C: 12 34 + . --- 46 ok $511C: 12 34 56 78 ,, --- ok $5120: $511C QD --- 0511C: 0C 22 38 4E 41 01 1C 51 BC 16 4E 00 4E 00 C8 15 '."8NA..Q..N.N...' 0512C: 0A FC B9 FE D5 00 85 00 70 00 D5 00 01 F8 94 00 '........p.......' ok $5120: HERE QD --- 05120: A8 14 BC 16 4E 00 4E 00 4E 00 C8 15 0A FC B9 FE '....N.N.N.......' 05130: D5 00 85 00 70 00 D5 00 01 F8 94 00 7B 00 DD 00 '....p.......{...' ok $5120: ' HERE .W --- $14A8 ok $5120: ' QD .W --- $16BC ok $5120: HERE $10 DUMPW --- 05120: 14A8 F810 16DE 004E 004E 15C8 FC0A FEB9 '......N.N.......' ok $5120:It was kinda useful to create a word that would print the code pointer and revector the TAQOZ prompt by storing the code address of that routine into the uprompt vector. Straight away the prompt is exactly what I wanted. When I create an empty TABLE we can see how that used up a single wordcode which is in fact the code that returns the address following it by popping the return stack and pushing it onto the data stack, and never returning back there again but instead leaving a pointer to any structure that we may create.
When I typed in some temporary interactive code with 12 34 + . it never permanently allocated code memory but the pointer stayed the same at $511C. However when I now type the same numbers plus a couple more then use the immediate ,, word it grabbed and built up the 4 bytes into a long that was compiled with the , word.
The last few lines in my test was just to reveal the termporary code that is compiled so the code address of HERE is $14A8 and the last line I dumped you can see that at $5120 followed by a wordcode that encodes $10 as a short 10-bit literal, then DUMPW and then $004E which is EXIT so that the code can return to the console. Then the code pointer is restored back to $5120.
Welcome to "Fudge the TAQOZ compiler on the go" 101
I already patch long tx_pin in the rom before I let COG0 softly slide into TAQOZ after starting my program in COG1.
It does work except lsio, that seems to reset the pin somehow.
But I am not really able to decipher the Boot Rom Spin contained TAQPZ words used at lsio.
And it would be really nice if you could make this more easy in the second ROM. The basic goal is to set rx and tx to different pins and allow to set the rxpin selector to allow taqoz rx running on its designed pin reading the next pin used by another cog as smart pin tx.
This all allows to use TAQOZ as serial sub system running in its own COG from any other language by treating it as a serial device. And one could use all TAQOZ features from Basic, C, Blockly, assembler, Spin, or whatever else by just using 4 smartpins, one COG and leaving enough space on the bottom of RAM for TAQOZ to exist.
I basically have this running, except lsio killing my patches...
Enjoy!
Mike
Thanks for the insight to the inner workings. I've got to read that a few more times while interacting with TAQOZ. My goal is to understand the smart pins and how I can use them.
I find that the best way to see how things work is to start a definition working in a new cog and send / receive parameters to/from it via global variables from cog 0 and print responses.
I know I'll have more questions as I go.
Thanks
Tom
At times it is useful to be able to print 64-bit results of mixed operations and that capability has been in TAQOZ from the start. There is a little known operator <D> that takes the high 32-bits and load it into a holding register which is normally zero but all routines that use the number print routine take into account.
But if we wanted to enter a double number it was awkward although hex numbers are easy to break up into two 32-bit parts, not so with decimal numbers. Traditionally in Forths that support it, placing a decimal point in a number signifies that this should be handled as a 64-bit double number. The trouble is that TAQOZ allows any mix of symbols within the number for a whole variety of reasons and so to keep the flexibility and also at the same time follow some convention I process any number that ends in a decimal point as a double number.
I will add more support for double numbers within reason and this already includes D@ and D! (I prefer the D instead of 2@ 2!) and a D. to print a double number. Other double number operators are 2DUP 2DROP 2SWAP. Maybe I might change D@ D! to 2@ 2! in that case then but 2. for print?
Here are a couple of examples:
P2D2 V2 IMAGE
(defaults to 240MHz)
What would be the correct baud for this new image? I see this printing strange characters at 115200 baud.
Kind regards, Samuel Lourenço
I noticed that too, must be a minor thing so I will get that fixed up shortly.
@samuell - if you used the P2-ES image then it should work. Make sure it is <this one>
My Nokia 5110 LCD driver is working well! It was easy to redirect TAQOZ output to the LCD using uemit vector. Is there a way to have uemit outputting to the my LCD and the console at the same time?
Normally uemit is zeroed and this selects the default serial console but you can always reference this device as CONEMIT. Therefore all you need to do is create a new hybrid device: If you can use the latest image on SD then please do that as that supports EMIT: so this simplifies creating character I/O devices.
To test out decompression at boot I could easily do a _BOOT_P2.BIX file that just ran the decompression routine on the LZMA file. It should also load a lot faster even from the current slow load ROM.
So I think I can get it down into the 12k region. So far, so good.
I've tried the new image, and it now prints correctly. However, DIR shows _BOOT_P2.BIX filename with strange characters where the name should be. Please, see the image attached.
Also, I've noticed that I can't change speed without messing up the terminal. Even "CRUISE" messes up the characters. I've confirmed that the board stays at 180MHz (by sending "32 PIN 90 MHZ" and verifying that the pin still outputs at 90 MHz).
Kind regards, Samuel Lourenço
This image starts up at 115200 baud at 80MHz since the SD seems to behave better on the P2-ES board at a lower clock rate but just type CRUISE to switch to 180MHz if you also want to use VGA. The P2-ES seems to work fine at 340MHz otherwise but I need to make some changes so that the VGA frequency will also switch and hopefully the SD will still work.
Since the link changes when the file changes, here is the folder it's in.
@samuell - rather than posting a whole screenshot where only part of it is relevant, just select and copy the text then paste it into the forum using the 'C' code tags.
TAQOZ# ECO --- ok TAQOZ# .SPEEDS --- SECTOR READ SPEEDS.............. 851us,803us,803us,803us,803us,803us,803us,803us, BLOCK READ RATE................. 842kB/second @80MHz ok TAQOZ# CRUISE --- ok TAQOZ# .SPEEDS --- SECTOR READ SPEEDS.............. 489us,440us,440us,440us,440us,440us,440us,440us, BLOCK READ RATE................. 1,893kB/second @180MHz ok TAQOZ# TURBO ---� ok TAQOZ# .SPEEDS --- SECTOR READ SPEEDS.............. 420us,371us,371us,371us,371us,371us,371us,371us, BLOCK READ RATE................. 2,523kB/second @240MHz ok TAQOZ# HYPER --- ok TAQOZ# .SPEEDS --- SECTOR READ SPEEDS.............. 360us,311us,311us,312us,311us,311us,311us,311us, BLOCK READ RATE................. 3,570kB/second @340MHz okIn doing so, you also gain better tolerance to users PCB layouts, and any ROM code is going to need to be quite PCB layout Tolerant.
That makes the high-cap traces of the P2 Eval, a good test.
Running all the way to 340MHz is impressive.
The output looks very clean at 340MHz but I am only using multiples of the XIN frequency so I can keep the divider to 1.
Is this due to the 3x 47pf Caps that are fitted to the P2 Eval board on the SD card pins, CMD, CS and CLK ?
They were requested for I/O stability of the P2-ES chip, and will not be needed on the production chip.
I would be happy to remove (or reduce in value) some or all of those from an Eval board and run a test script..?
In that case, please share a test script and I'll post the scope image of those 3 pins.
Edit: Just found this other thread. Seems this might be a test script...
Send out a CMD8 (with CRC) and read the response.
TAQOZ# $87 sdcrc C! $1AA 8 CMD 1 = IF SD4@ .W THEN --- $01AA ok
http://forums.parallax.com/discussion/comment/1462854/#Comment_1462854
I used 10pF (maybe they were 18pF) on my P2D2 but if you have the PCB files I can track down the components fairly easily then. It's the clock line I've been mostly worried about and I have taken quite some captures at different frequencies which is why I decided to retard the read timing.
In case you don't have Diptrace, I'll post an image in a moment...
That may have more to do with the clock speed but I guess I could add something to it that checked the current clock speed and timed accordingly. However there is a constant in the cog location before WSLED that you can change manually. Just try the next line and that should do it I think.
The code in cog tat needs adjustment.
The new image boots, but doesn't seem to accept any keywords. Even typing "WORDS" causes it to output "???" and then "--- ok". I've noticed that the P2 runs hot, and I think 300MHz might be a bit too much. Is it because of VGA?
Kind regards, Samuel Lourenço