TAQOZ for implementing a parallel bus
Hi,
first statement: I am a TAQOZ newbie
My task: I want to realize a USB <-> 16 bit parallel bus (similar to ISA or UNIBUS) R/W interface with the Prop 2 using TAQOZ.
Some words like
SENDBUS address data
or
READBUS addres data
should write a word of 16 bit to PIN 0..15 and set also R/W PIN16 to high and also handle Address/Data line at PIN17. etc..
I know that I can easy handle each PIN with Forth, but all the documentation of TAQOZ and Assembler is for a beginner overwhelming.
So I am just looking for some hints, how to handle such a task in the most professional / elegant way.
Is bit banging of each pin the right way? Or is there some command to set 16 bit input / output as a single command?
Many thanks in advance for each reply
Markus
Comments
Is there a USB-Chip in the front end? I imagine it to be difficult to have the USB implemented, at least is will cost much more time then the chip will cost money
Yes, of course, I forgot to say. I want to make my first tests with the P2 evaluation board. 3.3V <-> 5V converters are already attached ...
How will the pc-side look like?
The PC side is an USB port and the idea is to send for example a command
SENDBUS address data
(as metioned in my first posting)
If I send
READBUS address
I expecting a decimal or hex number back via the serial/USB line.
I will realize the PC side in Pascal, Erlang, C, Pyton or whatever...thats not the problem.
The question is: how to realize this on the Propeller 2.
I could do this in SPIN, but I think Forth has already a very fast and stable command interpreter.
Why not using it?
So the question is, how write a word SENDBUS or READBUS in Forth? Setting or reading each single pin is possible of course,
but I am quite sure, that this is not state of the art - but maybe I am wrong.
I believe Forth to be the solution as you can send words to P2 and so dynamically program a solution. On the other hand it could be useful to program the PC in Forth to as then one programming paradigma can be applied and it will make sense to improve both systems by implementing words here and there. One problem I see now is that the free version of 8th has no COM interface, but that may be negociated as Ron seems to be just another Peter ;-)
Hi,
Operand goes always first onto the stack.
Adress outb cog!
To set the adress on port B.
Do some bit banging for handshake and then:
To read 32 bits of port A and print it to the serial, I would look for something like
Ina cog@ .
In https://forums.parallax.com/discussion/173302/taqoz-reloaded-v2-8-word-glossary/p1
I have not tested this.
Good luck, Christof
Thanks for the hint to 8th I never heard before about it.
I have seen serial access is possible in the Hobby+ versions.
Have you ever used it? Is it stable? Is it worth to spend 49 bucks?
Forth on both sides sounds sexy...
Hi Christof,
thanks for your hint! It seems to work!
INA, INB etc. are predefined in TAQOZ and cog@ and cog! work as well.
That solve 90% of my problem - the rest is hard work...
Markus
I can forward a licence, could you send a pm?
is it legal?
sure, I'm a CEO, not a president, and in contact with ron Aaron and we work together, want to expand it. So yes!
In the glossary version 65 I've added a 'Cog Register Layout' table to the section 'Cog / Hub' and added a reminder note in 'Input / Output & Smartpin Basics'.
I also now realise that from switch on, COG7 is running as a vga controller and writing to smartpins P0 to P4 ( check this with an oscilloscope if you like). If vga display is not required, this can be turned off by the command 7 COGSTOP, leaving P0 to P31 completely free for the user. I've added a note about that.
Still learning - Bob
So today, I've been attempting to cancel the vga display that Taqoz Reloaded runs in cog 7 at switch on, so that pins P0 to P4 can be reused for something else. The vga controller outputs on pins P0 to P4. It would be handy to have P0 - P31 completely free for use, especially for bus work like here. Here's some code that I found by trial and error to work:-
I must admit I don't fully understand this - but it does work. It would be part of a user applications initialisation routine. The one snag is that it momentarily sets an output on P0 to P4, which may clash with anything connected to those pins.
Hi Bob,
many thanks for the hint regarding the first pins. I hve read already that this pins are "abused" for VGA, but I had no idea how to disable it.
I have read something about a "512 byte configuration space" for Taqoz - but I can't actual remember where :-(
Hi ErNa
I will revert to you regarding 8th. Yesterday I tried Freepascal on the PC side, with the library Synaser.pas from
synapse.ararat.cz/doku.php/download#synaser_serial_library
Usually this software works fine, but here it resets the P2 board, if I open /dev/ttyUSB0.
I fear its touching RTS and DTR what could have strange results on the USB port.
I have to check with the oscilloscope or/and Wireshark what is happening here.
So next try with 8th ?/!
Many thanks for all the help
Markus
This is what I found (again):
Next task is to find out what page 0 is
I can shed light on 'page 0' - it's the area in hubram, 0 - $58 that holds various internal system settings. If taqoz_20210822 is compiled with the tool flexprop, then a listing can be produced, of which an extract shows 'page 0' - see attached text file. Amongst other things:-
long at $20 holds the smartpin numbers assigned for the vga red green blue and horizontal sync signals - defaults to 03020100 - pins P3 to P0
long at $24 holds the smartpin assigned to vga vertical sync signal - defaults to 4 - pin P4
long at $28 points to the initialisation code for the vga driver
You can read and write these locations e.g. $20 @ .L
So - Peter's post hints at how to change the pin assignments from the default ones above - or disable the vga driver - but the 'elegant' forth code to do that isn't shown.
So now I have got it:
Here some lines from taqoz.lst
The data are in the HUB RAM
Before:
Here you see pull-downs at the first 5 pins for VGA output (the small ddddd)
Now we set address $20, $24, $28 to $0000
REBOOT
Now the pull downs are gone...
Brilliant! I had wondered about illegal settings being the key. You've cracked it. I'll stick a note/attribution in the glossary after testing it out.
Hi,
I am some steps further learning Taquz, 8th etc.
I am now able to toggle pins and words (at least seen on my osszi)
but I have problems to read some data.
If I try to read in one pin I get an u instead a h or H with lsio.
At the input of the Propeller 2 (Pinheader 2 of the P2 Eval board Rev. B PIN 15) there are 3.3 V.
With 0V I get the following answer.
I have at the inputs TI TXS0108E level converters (bidirectional), because I want to interface an old 5V bus.
I assume / fear u = undefined? . Its not described in debug.twc .
The glossary sais: lsio : display all 64 pins states, high low etc
LatiN: et cetera = and so many other opinions and options ;-)
Any pullups or pulldowns required? Any further IO configuration necessary?
Regards
Markus
Happy to see progress, still busy doing other stuff.
Hi everybody,
I am some steps further, but TAQOZ keeps still many many questions open.
II try to learn some common patterns from the TAQOZ source, but for a FORTH beginner its not so easy.
I the source code of TAQOZ I see quite often in the beginning of a file the lines:
I read the few lines in Word Glossary about the word TAQOZ, and tried to understand it, but for what is the
Cx org
command. I guess to start the word
*MANDELBROT*
but how to do it?I tried to use the command TAQOZ for my own bigger word (1000+ lines, mainly data), but I was not able to run it.
Any help or explanation appreciated.
Markus
The code above can be determined by using ctrl F in the Taqoz glossary to look up the words, but here's my explanation:-
IFDEF looks for the word
*MANDELBROT*
in the dictionary. If it is there ( the mandelbrot program has already been compiled into memory ), it executesFORGET *MANDELBROT*
, which deletes all code since and including the word*MANDELBROT*
from memory. This avoids the build up of old copies of the compiled code, every time it is recompiled after fixing a bug. So it's a useful phrase for anyone developing code. You notice the word*MANDELBROT*
defined around line 6 just prints the programs title - it's just a marker word. It could be any name you like.Similarly, before the MANDELBROT code is erased, Cx org, resets a data pointer back to what it was before the MANDELBROT code was compiled - you notice that Cx is defined as a long in the MANDELBROT code around line 33. If this were not included another block of variables would be defined in memory every time MANDELBROT was loaded.
In summary, the code allows MANDELBROT to be repeatedly loaded into memory, without free memory being used up by copies of program and data.
Having multiple copies of a word in memory is otherwise ok. When that word is looked up in the dictionary during a word definition, only the latest copy will be found, as the dictionary is searched in latest to earliest order.
When compiling forth source code the process is very simple like assembling assembly language - a word is either a number or it's a call to a procedure, which then returns. These numbers and calls are threaded together like beads to make your program.
It's best to keep forth definitions very short, so that they can be individually debugged by manually putting input parameters on the stack, executing the new word and looking at output parameters left on the stack. Sounds like you need to split your 1000+ line definition into code and data file and start debugging by using much less data.
Would have been appropriate to read bob's post before posting myself :-(
Yes, hard to understand if you are not familiar with Peter's way of thinking ;-) The glossary needs additional comments that explain how the environment looks like, ...
I assume the piece of code is the start of the new word MANDELBROT so the old one has to be deleted first
Forget needs the nfa (name field address) of the word to forget.
So IFDEF may result in the nfa in a special register Cx ?
My hope is, once I finally begin using TAQOZ, I'll dive more and more into it and gain some basic knowledge. But it is hard ;-)
Maybe someone can help when you show your code as it should work
Hi Bob, Hi ErNa,
many thanks for the explanations. Multiple defined words are really confusing. I didn't know that TAQOZ will call the latest version, thats helpful,
but the FORGET construct shold save me here.
I thinks thats quite important and should be clearly noticed in the doku!
Yes, I guess that will be the next step.
Thanks so far again.
Markus
As I think about it: it should be a nice feature. When developing a word, there is just a second entry, it can be FORGET and the latest version will now be the curren?
As far as I understood it behaves exactly this manner.
Hi my ForthFriends,
my bus communication from the Prop2 to my 16bit bus as described above, worked finally, but I have to say not very stable.
O.k, I have to say the wiring was a ratnest...
So now I have got a well designed PCB board with the P2EDGE instead of the P2EVAL.
For pure layout reasons, the bus was moved from
P0 ... P15
to
P40 ... P55
in principal this should make no problems !(?)
BUT
$0000_FFFF DIRA COG!
worked well with my old design, whereas the nearly same
TAQOZ# $00FF_FF00 DIRB COG! ---<0xe0>
crashes the system...
I have read anywhere that the debugger was using the address of DIRB for any purpose, but I can't imagine that these crashes the system.
Any other idea to write a word to pin 40 to pin 55 in a fast and elegant way in Taqoz?
Any other idea?
Any comment welcome
Markus
Hi,
I would have a look at the state of dirb and outb before changing only the relevant bits, as the upper pins are used for serial and storage access.
Hi Christof,
Bingo!
[18:11:48:966] TAQOZ# $00FF_FF00 DIRB COG! ---<0xe0>
crash!
It seems that PIN58 must be an input.
$FBxx_xxxx = %1111_1011_xxxx_xxxx
Many thanks!
Markus
The flash memory uses P58 / P59 and the SD card (if your P2edge has one) uses P59,P60 and P61. P58 inputs the DO signal from the flash memory.