Well if you go to the PropForth download site, you will find them. But the last time I looked the total was 88 wiki and I think that some of them are Sal Sanci's work.
We all just have to overlook some of these inacuracies. Closer to 80. That is still a substantial amount of effort by Prof Braino.
Sorry Loopy I was not clear, I was counting the ALL the pages and included the old pages which are deprecated.
You are right of the 100 pages in the list, only 96 were posted by me; two were posted by Sal and two by Rick.
Yes I have only one wire, it is bi-directional. I attached a file with complete documentation of the board in the above threads. But it might just be simpler to explain. The board is a Parallax product that was made for Hewlett-Packard and they used these to support there industrial side of Inkjet Printers. It is used to apply expiry date stamps and batch codes in automated packaging. So I am not using something that is not in normal commercial use.
Communications require half-duplex 9600 8N1. PropForth may be able to handle this on two wires quite easily, but one-wire is something a bit more difficult.
The board could be said that it acts as a slave.
There is a bit of handshaking. If I send a CR, the board sends back a > to show that I have an active line and that it recognizes the serial baud rate. I can do this without using PropForth, so I know the board works.
After that I can send a <STX> up to 64 ASCII characters <ETX> and the printer head will print all of them.
And then the board sends another > to me to tell me it is ready again.
LOopy, I just got to this, getting caught up. This description sounds like what I wrote for the EMIC2. Grab the EMIC2 file from my Tachyon Forth Apps folder and change the SERIN port from 7 to 6 and change the 'wait' char from ":" to ">" and you should be in business.
@Brian
You may be making this all too easy for me. I've been getting very very deep into how PropForth communicates and programs between all the cogs. I will follow up your suggestion. Even though the mysteries are unfolding, I am still uncertain that bi-directional half duplex can work in PropFoth. I am quite sure that 2 wire duplex is alive and well.
I may even end up with two solutions - yours and mine.
For anyone following along, the EMIC2 does have a Sin and Sout, Brian is suggesting I just adapt the existing Tachyon code to use a single pin of i/o. The is a perfectly legitimate solution.
But I am still wanting to prove the same in PropForth.
Why bother? There are times when you just don't have that extra wire as your chip has run out of pins to use.
Apparently has several Parallax products use the ">" prompt from the 'slave' and then the 'master' sends <stx> some text <etx> as a rather simple handshaking.
I am still uncertain that bi-directional half duplex can work in PropFoth.
....
Apparently has several Parallax products use the ">" prompt from the 'slave' and then the 'master' sends <stx> some text <etx> as a rather simple handshaking.
Did you try using the standard serial and simply assign the same pin as Tx and Rx?
AS I understand it, the Tx and Rx run independently using counters a & B, so the only thing you should notice is an automatic local echo of the character the prop sends.
The only tricky part is plugging in the standard interface from the cog running your chopstick printer control app to the cog running the serial driver. So that would consumer two cogs, and still leave cog6 for you forth prompt, and cog7 running the default serial on pins 30 and 31. SO i think your chopsticks printer system would consume 4 cogs, 2 for the development interface and 2 for the actual application
Sorry Loopy I was not clear, I was counting the ALL the pages and included the old pages which are deprecated.
You are right of the 100 pages in the list, only 96 were posted by me; two were posted by Sal and two by Rick.
I should strive for greater accuracy.
It really isn't all a number's game. You have been writing these Wikis quite consistently over the past two years, while I only posted something on November 11 of this year. (hat approximately marks when I began to read "Starting Forth" in earnest.)
And Sal has the original SpinForth mentioned in a Wiki from April of 2009. There has been a lot of work that has gone into what you and Sal have done. That should be recognized and appreciated.
PropForth is a worthwhile software and a lot of thought has gone into it. But I think we all have noticed that Forth has been set aside by much of the programing community as there has been a huge forced march to get something newer better or faster.
To me, Forth and PropForth have been a huge surprise. Let's just say it is a bit of a diamond in the rough at this point. I'd reached a point where I didn't want to use Spin and had never really learned PASM and was hoping GCC would revive my interest in the Propeller.
And then I discovered that I really found a lot of aspects of Forth very easy to grasp and that it offers the possiblity to learn PASM in short brief passages of code that are used in Forth words.
Mostly, it is very appealing to me.
Of course, there are aspects that are so different from other programing language that they still are controversial. The fact that everyone is creating their own words on top of whatever is provided and whatever someone else claimed necessary is confusing. And it is a part of Forth's history that is infamous. In some ways we have been reliving that because we now have 3 versions of Forth active on the Propeller.
I look at Sal's downloads and there is a lot of work that is over my head. I have no doubt it works well and fully demonstrates the power of PropForth, but I am not exactly sure of what a Fast Hartley Transform is. I do understand what an Analog Computer is, but I thought those were normally built with op amps, not emulated in digital.
Caszak is doing quite well with the kind of things that Parallax normally addresses. He takes a rather demanding support chip and finds his way through the documentation and explores the chip in Forth. And then he can actually write an application in Forth to use it reliably.
Apparently you enjoy writing. For me, technical writing is very demanding painstaking work. I always have to do dozens and dozens of revisions before I really want to show something to the world. I can teach English very well as I deeply understand it, but I found myself very frustrated when I was writing for graduate studieS in linguistics. It would take forever to complete an assignment.
Sal has also written some important and detailed documents, but they are a huge distraction from just writing code and improving code. When your writing code, it is for yourself and the machine. When you write documentation, it is for an audience that you may never fully understand.
I don't particularly like writing so much as I hate "not remembering".
Remembering and keeping facts straight is very difficult for me, so I have to write everything down. When I re-read what I've written, it often makes no sense, so I have to re-write it. Eventually, it gets to where I can reread what I've written, and it makes sense; now I can consult my notes, and I don't have to particularly remember anything. So I've developed this writing habit.
This is because while the material I use everyday becomes old hat, the stuff I use once (and forget) gets lost. I've seen entire products lost this way, the team moves on and forgets what they've done, and cannot support a previous product. "Write Only Code" is not a characteristic of forth, it is a characteristic of poorly managed projects. I run across this at nearly every job I contract.
The key is "getting the information from the person that has it, to the person that needs it, in the most timely, efficient manner".
Who has the information? The Author. Who needs it? The Reader. But documentation is EXPENSIVE. Every minute spent writing the docs subtracts 10 minutes from the authors ability to create. So who else can write the docs? The trainee. The only way to really learn something is to teach it to somebody else. (I forget who said this, maybe I just made it up). The new guy needs to learn the material, and have to go over it thoroughly anyway, if s/he writes it down, we have a receipt that shows the material was studied, and to what degree.
This is where "new guy notes" comes from. The keeper of the knowledge (the mentor) writes a description of what the mentor feels the new person needs to know, and gives this to the new person. The new person reads it and says, "this is incorrect, out of date, and poorly written" and rewrites it (until the new person declares it sufficient). And becomes the new keeper of the knowledge until the next new guy comes along, and mentors the next trainee.
Thus, the documentation and transfer of knowledge is driven by the party that needs the knowledge. The new guy can ask the previous mentor, and if the mentor cannot answer the question, ask his mentor in turn, until the question is resolved. The mentor is much more willing to field questions from a trainee that ask intelligent questions, or at least seem to be trying to get it.
This is the model I am attempting with the propforth project. Unfortunately I write too much these days, and nobody seems to read this far.
Did you try using the standard serial and simply assign the same pin as Tx and Rx?
AS I understand it, the Tx and Rx run independently using counters a & B, so the only thing you should notice is an automatic local echo of the character the prop sends.
The only tricky part is plugging in the standard interface from the cog running your chopstick printer control app to the cog running the serial driver. So that would consumer two cogs, and still leave cog6 for you forth prompt, and cog7 running the default serial on pins 30 and 31. SO i think your chopsticks printer system would consume 4 cogs, 2 for the development interface and 2 for the actual application
Well, rather fortunately I have not yet put the i/o together as there is a jump from the 3.3volt i/o logic of the Propeller to the 5.0 volt i/o logic of the Serial inkjet printer board. That makes the configuration a bit more complex and I am pondering what to do for good protection.
I do have a schematic for using a 2N7000 with pull-ups on the 3.3v side and the 5.0v side that might work well. But for now, I am still running through catching up with what I really don't know about Forth. You guys seem to overlook the fact that I've only been using Forth for less than a month and have spent more time debating than using.
4 cogs seems about right. At least I haven't destroyed any of the parts yet. But the fresh inkjet cartridge that I ordered last Friday is way past the promised two day delivery date. I even gave them a cash deposit of 50%.
The stepper code I provided for the contest can be used to verify two steppers in your Little Robot project if you are using similar unipolar 5v 200ma steppers. But be sure to provide about 7.2 to 7.5 volts for motor power as there is a voltage drop of 1.4v or more due to using the ULN2803 Darlington array. Motor power does NOT require a regulated voltage. I don't think the motors will suffer at 6 volts or less.
Writing for teaching is different than what you do. It is all about helping the reader notice and helping to reinforce remembering what is important. I am writing something for the PropForth that will demonstrate this and it should be done soon. While it helps me learn, it also shows what is not so obvious to others. I guess you are driven by deadlines to complete a writing project, like journalist. Some rise to the challenge, others just do what they have to in order to survive never-ending deadlines.
The problem with your 'new guy' process is that I have suffered from nerve pain in my neck for 40 plus years due to an auto accident at 23. Lenghty typing projects are physcially painful for me. I gave up pursuit of a Masters Degree because it wasn't worth the physical pain. Besides, not every 'new guy' is aware of what will reach the broadest audience. Jon Williams has written Parallax's articles in Nuts and Volts for many years because he does reach the broadest of audiences. If you can write like that, Parallax will keep you extremely busy.
I am never going to become a prolific contributor to PropForth due to physical limitations. I've never been a major contributor of written materials to Parallax.
Keeping lexicons straight in 3 different Forths is not an easy task either when everyone wants to do it their own way. Communications is not about standards, but it is about accepting conventions for the sake of efficency. We seem to be herding cats. Try learning Chinese, Japanese, and Korean at the same time and you will understand why near noone is successful at learning two foreign languages at the same time, much less 3 - there is no time to consilidate and retain what has been presented.
Okay.......... I have run two exercises with a PockeTerm VT100 emulator dumb terminal from Briel Computers. This software provides a dumb terminal on a Propeller Proto Board or a Propeller Demo Board via keyboard and VGA.
As I suspected, there are some interesting behaviors. I might even hazard to say somewhat undocumented.
In setting up a connection between the dumb terminal and the my notebook with the PropForth between, the outgoing keyboard behaves nicely as expected on the dumb terminal's screen.
Also, in doing a stand alone hardwire loop back with the dumb terminal it behaves as expected, exactly the same as the outgoing. No problems with either of those.
When I do incoming to my notebook computer it seems mostly okay, but some keyboard functions are not active. Cursor movements seem to have been filtered out. This should be a straight line from the SERIAL to the console SERIAL. The other direction is using the term application.
And when I set up an entirely independent cog that is linked to serial and connect that to the Dumb terminal, line feeds don't really work and neither do up/down/left/right arrow keys. Everything becomes impossible to read as it all hangs on one line that is repeated overwritten from the left margin. Some code does seem to get entered and interpreted. I can even create words. But I cannot see what I am doing as carriage returns do not add any line feeds.
I seem to vaguely remember that their might be a flag somewhere to turn on line feeds but I am unsure.
I try to do cog? and it outputs in a rather messy way. If I do words, the results are far worse, the PockeTerm software goes wild, is apparently corrupted and I have to reboot everything to restore order.
It seems obvious that the Forth machine in the PropTerm output is some formatting conventions that are hostile to the PockeTerm's VT100 emulation. I don't quite know what or how.
Please don't expect me to make an item by item bug report of this as I wouldn't know where to begin. Sal must have some idea of what PropForth does and does not in terms of output and input. I was just hoping that it would be rather simple. Are Esc sequences used regularly?
Yes, I can dig around in the source code, if I must. The main message here is that running real hard wire loop back test is quite revealing in ways that having PropForth chatting with itself would never be. This is a necessary process to reveal what is.
I suppose that if I retain precise control over what is sent out, I could easily to the Chopstick printer. Since it is not a high volume of traffic it would be very easy to debug. But I had been planning to use the dumb terminal instead of my notebook as my primary workstation for Forth programing. That may not be possible for quite some time.
Good news, the inkjet cartridge finally arrived.
Bad news, I had not considered that the Propeller is 3.3v logic while the Serial Inkjet printer board is 5.0v logic. I may insert a 74ls175 Quad 3-state buffer to handle the Rx and Tx traffic in a safe manner. The Propeller 3.3 i/o can sent to 5.0v logic, but the reception needs to be protected. So it is back to considering 2 pin Serial and some added complexity with the 74ls175 managing traffic.
It is a bit amusing to see how much easier the chopstick printer setup and coding is on a BasicStamp. Serial ports don't go through cogs and so on.
I noticed this it is not easy to overlook, but I guess thats just your way. If you spend some time doing the examples and walking through the source code, its would be MUCH easier.
You write huge volume of words. If you write about your experiments (breifly, as in design, code, results), we would all benefit (including you).
I'll repeat this point again. If I felt comfortable working through source code and assembler, I would have likely gone with something else - GCC, Tachyon, Catalina, or PASM. At some point, the developer has to realize that the user often chooses his higher level language because that user knows less than the developer. And in the Parallax Forums, that kind of relationship is quite normal.
IOW, you seem unaware of that and just expect me to catch up to you. Brevity has not worked well. But yesterday, I did ramble as I was quite exhausted and confused.
I have worked through all the examples where they apply and done so several times, and I am digging through the source code, but I still don't quite understand all the organization of all the various files and references of various kernels. Myself and others have asked for your definition of what a kernel is as it would help use all with recognifizing what source code applies to which. Your relies have been pretty much that a kernel maybe this at times or that at times.
My initial impression was that PropForth's v5.0 provision of a PropForth.htm and tutorials were indications that less advanced users might have an easier and clearer point of entry.
Okay, so I have turned to reading "the source" and focusing on "the kernel". I thought for the sake of clarity that I could work with just the .zip package for v5.03 as a complete snapshot of PropForth. But queries have said to look elsewhere and that I need this or that from the PropForth site as well. So at times I seem to be in a paper chase to find what might be and where it might be.
I am turning to the source code now, but the machine code portions are opaque to me. You mentioned 64bit optimized assembler code for this 32bit Propeller and I've even come across mention of some rather advance Forth optimizations on the PropForth website - something like Peep Hole optimization. I have Googled as you suggested, but Googled doesn't come up with a solid reference on this point. An actual link to something well-written is always more helpful than a search engine.
Not sure if that might make the Forth source so opaque, but it is yet another topic of study.
Why not just come out and say that PropForth is this and that and these are the prequisites for complete understanding? As it is, the impression one gets is that PropForth is 'open source' up to a certain point. Then, much is hidden in overlays of complexity.
~~~~~~~~~
Back to that which I am doing in contrast what I just cannot seem to locate..............
I have been running a series of hardware serial loop back tests and full-duplex communications with Minicom on my Toshiba NB250 notebook and Briel Computer's PockeTerm loaded into a Propeller Demo Board that is suppose to emulate VT100 with its own VGA and keyboard.
A good night's sleep makes computer bugs much clearer.
At this point, I am ready to switch from the PockeTerm v0.905 software to another available VT100 that loads to a Propeller Demo Board.
There are problems with v0.905 - the current download, which I didn't previously have with this product. It provides for two serial channels - one is the normal dumb terminal, the second is suppose to do something fancy with your computer (maybe screen cut and paste exchanges ). I thought I could ignore this 2nd channel, but I must provide for it when I boot or the boot will not complete. I have to have the 2nd serial present and active via a PropTool, or the boot will not work.
Later disconnecting it seemed to work and Minicom in Ubuntu requires that I disconnect it, but there seems to be a background constantly loop polling for this after the disconnect. The USB device indicates activity with a flickering red LED. And that polling may be a source of instability triggered by unknowns that result in the whole dumb terminal crashing.
The easiest thing is to switch software and see if the problems go away. I do this all the time between Linux and Windows to verify if I have a software problem or an underlying hardware problem.
Still, I am pretty sure of these following observations:
1. Hardwire Loopback of my Minicom software has it perform as expected.
2. Hardwire Loopback of my PockeTerm software has it perform as expected.
3. Having Minicom to PropForth to PockeTerm in full duplex serial performs as expected (The two terminal application -- Minicom in Ubuntu and PockeTerm in a Propeller -- may fully support each other), but it may be 99%. I need to continue looking at this and why forwarding through the PropForth behaves when an independent Forth machine in PropForth does not (see #6 below).
4. Having PropForth internally loopback to my Minicom has it perform as expected.
5. Having Minicom to PropForth has it perform as expected.
6. Having an independent PropForth cog via its own serial driver attached to the PockeTerm VT100 is not right, while the PropForth serial console is properly working with cogs 6 & 7, offers limited function due to display not behaving. Keyboard input seems to be received and processed as it should. I strongly suspect I have to add a trap that catches CR and adds an LF to all instances.
The details...............
In #6, I say limited function because the use of 'cog?' and 'words' results were bad.
1. just hitting Return has the Prop0 Cog0 prompt come up, but it seems to do so without issuing a LF and the PockeTerm does not insert one. This may be the source of all the other woes, and initial investigation of the 'source code' for cog? and 'words' indicate that not ANSI control or Escape sequences are included.
(Prof Braino's first suggestion that I look at the extension for these is not worth bothering with. They seem to pertain to adding mostly color selection to the character display and we are concerned with the absence of a fundamental feature ... the Linefeed.)
2.Testing 'cog?' for output should issue a nice multi-line report for all 8 cogs at one to a line, but it gets strewn over the screen, maybe it is attempts carriage returns and over-writes (I might be seeing only the last line over-writing the others), but certainly not linefeeds.
3. Testing 'words' seems to trigger PockeTerm's instability due to the two serial port configuration of this applcation. I cannot seem to locate a way to remove the feature in the source code that requires it to constantly poll the 2nd serial port for activity. And as everyone knows, I don't really read source code well. So I will attempt to resolve the issues by loading another VT100 emulator from a different source (the Propeller seems to have at least two and this is very, very useful in such instances)..
4. Having Minicom to PropForth to PockeTerm in full duplex serial at the same time on Cog 7, 6, & 2 via '2 0 term'performs as expected (The two may - Minicom and PropTerm - fully support each other, and the PropForth appears to faithfully transfer without interfering until CNTL-F breaks the connection.)
5. Having a PropForth internally loop-back to my Minicom has it perform as expected (that is what the provided Tutorial 3.2 presents -- but it doesn't indicate what happens when the outside world tries a loop back ).
So there you have it. I actually think that I can set up a loop that traps CR and adds LF on the PropForth output and that all the problems will go away.
Above all, don't get caught up with unneeded ANSI terminal codes and ESC sequences. Use these sparingly and you will support a lot more devices with a lot less problems. I am trying to use ONLY those codes that are provided within the realm of the 256 choices that ASCII provides as a single byte. And in truth, I am really most concerned with jus the first 128 choices as the second 128 often vary with foreign language expectations.
**************
You have been wanting lists, the above has at least one pretty good one.
I'll repeat this point again. If I felt comfortable working through source code and assembler, I would have likely gone with something else
I'll restate this, yet again, so you might catch it this time.
You don't need assembler or ANY advanced topic at this point. You should AVOID advanced topics till you get there. All beginers should advanced topics at the beginning, it just makes you confused, as you demonstrate.
You MUST step through the propforth source code to understand each word you want to use when you don't understand the word. If you don't, your progress will be slow, as you notice.
If you do something else, like try to use the reference for another language, (like ANSI forth or Tachyon) in place of the propforth references, you will confuse yourself, as you notice.
You must step through the examples if you want to use a word properly. How the heck else are you going to figure out how to use it? If you don't, you will have very slow progress figuring out what the words are an how to use them.
ALL you questions are answered in the material, to the best of my knowledge. If you read them and have further questions, we can work from there. But if you demand that I re-write all the materials just because you don;t feel like reading them, I question the logic. If you won't read whats there, I don't think you'll read any additional materials either.
For example, your questions about serial. Two folks have told you about the non-displayable ASCII character values, and you call it unneeded. Read it, try it, do it, understand it, then determine if it is unnecessary. Folks give you this answer based on what you are asking, why must you dismiss it with out trying? It is a simple answer to you question, if you simply try it.
I'll read the rest of your post later, when I have more time to address it properly.
I'll restate this, yet again, so you might catch it this time.
You MUST step through the propforth source code to understand each word you want to use when you don't understand the word. If you don't, your progress will be slow, as you notice.
......
You must step through the examples if you want to use a word properly. How the heck else are you going to figure out how to use it? If you don't, you will have very slow progress figuring out what the words are an how to use them.
ALL you questions are answered in the material, to the best of my knowledge. If you read them and have further questions, we can work from there. But if you demand that I re-write all the materials just because you don;t feel like reading them, I question the logic. If you won't read whats there, I don't think you'll read any additional materials either.
There seems to be a disconnect here.
1. I was hoping to use use PropForth to learn something about PASM and that is not visble with 64 bit Google optimization.
2. I was of the impression that I was on my own to read the 'serial' and '_serial' word in PASM
3. I have worked through all the examples in the PropForth.htm and the tutorials that have applied to what I has as hardware and what I am trying to achive.
Hopefully, I don't have to buy all the hardware in al the tutorials in order to learn PropForth.
4. I am proceeding on my own.
5. You seem to be thinking I am not get anything, so you keep sending me to source code.
~~~~~~~~~~~~~~~~~
In the meantime.
1. I have switched to Jeff Ledger's VT100 emulation as it is stable with one bug that keeps the cursor on the top line. It only has one serial port to use, so I can move on with real world asynchronous serial in PropForth.
2. I will likely resolve the lack of a LF tonight. A solution might require I add a cog to trap CR code from one Cog and retransmit CR-LF to the SERIAL driver to the outside world
Above all, please don't lump ESC codes together with ASCII CR and LF, or the other ASCII hidden codes such as <STX> and <ETX>.
It really is that simple.
All the ESC codes are an overlay with ESC as merely the preamble of a longer code. Some move the cursor in a video monitor, some clear various portions of the screen, one actually diverts output to a printer, and some format screen characters to different colors. These are a lot of nice stuff, but distracting to sorting out what the actual asynchronous serial port is doing and whether it is supporting a barebones downstream display or not.
I am not demanding that you re-write documents. I just have been a bit surprised and and daunted by what is available. At one point, I volunteered to read and help edit. But that seems to have been misunderstood as demands for information you are not prepared to provide.
As I said before, I'd like to get past this perception that I am too needy. I have just been frustrated. I have repeatedly said I can adjust to what is. And I am demonstrating I can do so.
Since you keep referring to my not doing 'the exercises' can you confirm that the tutorials and the PropForth.htm are a full set? It is possible that I am unaware of some others?
Regarding the tutorials. I am not yet using the EEPROM or SDcard file systems - so those are not done. But everything through Tutorial 2.3 plus Tutorial 3.2 have been done and pretty much assimilated. I've not bothered with the Logic Analyzer at this point as it seemed rather ambitious. But I will go through it to verify that there is or is not material that I've overlooked.
Cheers.
Affirmative, one MUST step through the source code to learn any Forth. I am just not sure which source code applies to the array of items provide in the PropForth .zip file. I primarily start with the .spin file that I loaded for the 64K EEPROM version of v5.03.
Maybe an inventory would be helpful of which files actually associate with which things. Meanwhile, I open files of code, look at them for a while to see if I can figure out why all this is included - and then move on.
FYI to all, Briel Computer's PockeTerm seems to have an incompatibility bug with PropForth as well as another unrelated stabilty problem.
One of my prime desires is to use Forth on the Propeller with a reliable Dumb Terminal rather than having to have a regular computer do that rather mundane task. So I have been doing a lot of real world loop back testing, switching things around, and reloading software.
That's just the way it is, and will always be.
I switched to OddbitCollector's (aka, Jeff Ledger's) VT100 emulation and all the video problems with PropForth went away and so did the unrelated problems. It did have a weird cursor problem, but that is something I could live with. And very oddly, the cursor problem in a hardwire loop back went away when I ran my first trial with the PropForth.
IOW, this VT100 operates very clean in PropForth. I have met my goal.:thumb:
Some of these things are just part of exploring new software - one VT100 program has problems, so I checked another. I also discovered a strategy to fix the problem in the first, but that might require 3 cogs rather than 2 cogs.
@Prof Braino
It could just be that the worst of my learning curve is over. Since I started about November 11th, it hasn't even been a month.
Sal is back from his travels, we were able ti get to Loopy's questions on serial and documentation.
Turns out Sal did not get Propforth to 3M in testing, this was my confusion; only Peter has a forth to 3M to my knowledge. Sal tested propforth sufficiently high to determine that 230400 is the highest speed that ensures stability.
Concerning the serial code: The highlevel source for the serial driver is in
..\V5.03\kernels\BootKernel\ PropForthStartKernel.f
The high level source for _serial is WOULD be in
..\V5.03\kernels\BootKernel\BootOptimizeKernel\ PropForthBootOptimzeAsmSrc.f
But, its not. Turns out there's two things at play here. 1) the plug-in interface is a bit more involved than plain vanilla serial, and evolved in assembler, so the unopt6imized code was NOT included. 2) Serial is in use before its gets rebuilt in the build processor. So the serial support is built and then dropped in in place of the previous suuprot on the fly during the build process. This doesn affect anybody but Sal, but removes our "simple example" for serial from the code. So we are taking steps:
Caskaz has started reworking the serial driver for Loopy's issues. Caskaz found the source, and has started unraveling the assembler. I think he's trying for a simple serial implemnetation, that does not have to deal with the plug in interfaces. So it looks like Caskz will learn the advanced stuff to help on loopp's questions. Thanks Caskaz!
We discussed Loopy's problems with the docs. We figure 90% of readers will approach propforth the same way and have a similar set of problems. To address this, and maybe make it better:
1) I'm going to make a new "intro page" to describe how to find one's way about the documentation
2) We're looking into a method of providing link from the entry for each word in PRopforth.htm to the source code that defines each word.
3) we're looking into posting propforth.htm someplace where we can link to the anchor for each definition in section 9, or any other section as needed.
Incidently, Sal finds that Propforth.htm is the only reference he needs anymore. Propforth.htm contain the stack notes (the "goes-intas" and "comes-outas", and purpose for each function); the actual internals of the function are not needed most of the time.
4) We're looking into making the release have two options
a) a download with just the spin files and extensions as found in ".\V5.03-20120505\"CurrentRelease" that we can "load and go"
b) a download that includes the automation, Go language support, and pre-optimized files for rolling our own kernel.
Even though we know everyone looks at both, and just downloads the biggest file; at least this can give us a notion of which is the simple stuff and which is the advanced stuff.
We figure the biggest issue with the full automation and test suite is setting up one router to allow the IP tests to work. We both recenlty changed intternet providers, and now the previously working tests fail. Since the software and tests are unchnged, issue is traced to the change in routers. Every router is different and must be custom configured. We will work through our hardware to provide a count examples, this should give folks at least a starting point in getting the network set up.
After we document sorting out our networks, and show that the previous tests can run again, we will start release testing for v5.3. We think we can walk through the network stuff next weekend. After that, Sal just needs a couple days to do the final build, and he'll send it out for testing.
My ability to predict the future has proven to be mostly wrong recently. But I'm going to guestimate there at least two weeks work left, and theres a bunch of holidays coming up. We'll either find lots of time to work or we'll be too busy. Hopefully we'll get done before the world ends this year, otherwise we'll try to be ready when the world end again next year.
Frankly, I have never been impressed with 3Mbyte asynchronous serial as it might only be done in loop-back or by making a custom circuit board. My experience with running the SX chips at 80Mhz was that I was more often than not was having to insert wait states and delays to get real things to work.
One can get all involved with the internal speed and not have any connectivity.
The rule of thumb is that if you have asynchronous serial problems, go to a lower baud rate. And the same for any other form of communications - parallel or serial. When you have problems, go to a slower data rate.
Since we have a lot of hobbyist involved, there will always be a lot of construction related problems. DO NOT think every problem is in the code.
If you look at the Tutorial 3.2 supplement that I created for the Forth of the Forth Contest, I found that all the display problems that I was having with cog? and words reports went away by reducing the baud rate to 9600 baud from 57600 baud.
Suggesting that I read the source code for this problem was very disappointing and unhelpful, but I now know that you have very little actual hardware configuration experience.
Nonetheless, the rather amusing result is that I have been spending more time trying to read the code. And I intend to ask less questions in the future. Source code for the Forth words have to be right for the documentation to have a good reference.
The contest entry was created to help PropForth see an alternative way to provide support. I am really am trying to give back as much as I take away from learning and using PropForth.
Thanks for running down these loose ends. There are always others that want to know the answers and good answers mean more popularity.
Above all, work smart rather than just working hard. Don't write something too soon, let the facts appear.
Frankly, I have never been impressed with 3Mbyte asynchronous serial as it might only be done in loop-back or by making a custom circuit board.
The rule of thumb is that if you have asynchronous serial problems, go to a lower baud rate.
If you look at the Tutorial 3.2 supplement that I created for the Forth of the Forth Contest, I found that all the display problems that I was having with cog? and words reports went away by reducing the baud rate to 9600 baud from 57600 baud.
Suggesting that I read the source code for this problem was very disappointing and unhelpful, but I now know that you have very little actual hardware configuration experience.
The contest entry was created to help PropForth see an alternative way to provide support.
Ahem, ahem..... you have a way with words Loopy. I actually USE 3M serial (not loopback nonsense) with Tachyon to Minicom and 3M was the limit of the FTDI chip, not Tachyon. The reason I used 3M was simply to reduce the overhead that the Tachyon cog spent in sending a character, no need for it to be delayed any longer than necessary. But I understand where you are coming from since (dig dig) you had to work around your problem you couldn't solve and using the rule of all-thumbs you kludge it all the way back to the 70's at a break-neck speed of 9600 baud! So I see why you are not impressed....
@Peter
I do understand that 3Gbyte works well with USB ports and cables as they are fashioned for high speed serial and tested for such.
But when I start to solder up my own creations, I never seem to get anywhere near that. Besides, what happens at the end of the line? Both the computer board and the Propeller are just sitting in loops and waiting. The same function works just as nicely at 9600 baud as 3M baud when a human is involved.
I do have to admit that if I were to load up a 4Gbyte SDcard with data that needed transfer to my PC, the 3Mbaud would suddenly become useful. So my way with words may be a bit too compelling.
Not very sure there is an overhead savings one way or the other. Is the cog running threaded multi-tasking code?
But I do know everyone is going to have some beginners wondering why their creation can not work, and it will be that 3Gbytes requires shielded cable and superior board construction.
I used two Parallax Proto Boards with headers soldered on and store-bought 3 wire cable (with connections attached to fit the headers) to set up my serial. It was too fast at 57600 baud. A small reduction may have solved the problem. But since I didn't have time, I just jumped down to 9600 baud to verify that it was NOT an internal PropForth problem.
Once one knows where the problem lies... solutions are much easier. Thus the rule of thumb. And the foremost rule of thumb is find where the problem lies, don't guess.
Of late I am spending way too much time defending whatevery I write. So I guess I'll just write less.
Not very sure there is an overhead savings one way or the other. Is the cog running threaded multi-tasking code?
Propforth (this thread) will begin to support software multitasking in PF 6 or above, when there is enough room to make reasonable use of it. Current releases only (?) have hardware multitrasking, by virtue of the multiple cogs.
The overhead savings is we don't have to wait so long.
But I do know everyone is going to have some beginners wondering why their creation can not work, and it will be that 3Gbytes requires shielded cable and superior board construction.
We are still talking 3megabaud or 230400 is kilo baud as is 9600, I think; but none of these need a special cable as far as I know. I used signle bits of wire, unshielded and not twisted into pairs. This works fine at all baud rates tested, up to 230400 on propforth.
I used two Parallax Proto Boards with headers soldered on and store-bought 3 wire cable (with connections attached to fit the headers) to set up my serial. It was too fast at 57600 baud. A small reduction may have solved the problem. But since I didn't have time, I just jumped down to 9600 baud to verify that it was NOT an internal PropForth problem.
So you verified that your target device that you were TALKING TO does not support anything faster than 9600 baud? I guess thats your problem, then, don't blame your cable. It certainly is within that capabilities of the prop and propforth in particular.
Once one knows where the problem lies... solutions are much easier. Thus the rule of thumb. And the foremost rule of thumb is find where the problem lies, don't guess.Of late I am spending way too much time defending whatevery I write. So I guess I'll just write less.
Write MORE, your posts can be beneficial. And you're good at it. Just try to delay claiming everything is broken until you collected some data or at least run the proper tests. Moving forward, Please describe your issue with sufficient detail to reproduce it, and ask for help. This is the recommended process.
Firstly, I presume overhead savings means that some resourse is saved in order to be available eslewhere.
If the resource is electricity, more power is available for longer running on a battery or a smaller solar panel may be deployed.
If the resource is CPU capacity, doing serial commnications faster and then clocking wait states until the the next transaction is not really saving a resource to be available elsewhere.
That was why the query about multi-threading code on one cog. On the PropForth, a serial cog at high speed baud is no more resource efficent than one at low baud speed if the task is being accomplished in a adequate timeframe at the lower baud rater. There is no net gain of available resources in such a context.
While running at 9600 baud seems to offend all you speed demons, all along I have been working toward completing the chopstick printer project that will only run at 9600 baud 8N1.
My point has been that extreme high speed may be useful, but not always.
And while you assert you are using 230400 baud with simple wires, I have created a Dumb Terminal that tests nicely at 57600 baud in loop back, but cannot be reached by another Propeller with the PropForth loaded at that rate when used with simple wires. I had to go slower.
9600 baud may slower than necessary for the Dumb terminal. Further testing will tell. What I did verify was NOT what you seem to interpret. I verified the Dumb terminal in loop-back is fine at 57600 and the PropForth is fine in loop-back at 57600 ---- but with the wiring I was using, 57600 was too fast. Multi-lined reports such as 'words' or 'cog?' became garbbled. Please read my posting carefully as I go to great efforts to be clear as possilbe.
I am just saying that the 'faster is always better' leads to some perception there are problems in the software, when the problems are in the wiring.
I don't see why everyone has to be rude to the user that needs to use 9600 baud. It is merely a real situation.
Furthermore, 'hardware multitasking via multiple cogs' was not what was being referred to in my query. I was referring specifically to having one cog do two or more tasks at the same time. The SERIAL cogs seem to be fully committed to only handling a full-duplex communication channel and nothing else. One dedicated task, not multi-tasked.
My focus is quite narrow. I am trying to learn Forth and I am only using v5.03 of PropForth at this time. What is or what will be in versions beyond may be interesting, but I can't keep jumping from version to version or waiting for a new feature to learn Forth.
Since this thread is titled to be about v5.0xxxxx, I hope that 5.1, 5.2, 5.3, 6.0 and so on will have separate threads.
I realized that both Tachyon Forth and PropForth want to promote there features, but at some point clear and concise no nonsense support is also a significant feature.
I keep getting pulled back into the Parallax Propeller Forth Debating Society when I am merely trying to contribute real-world experiences and practical know-how as a means to make Forth more appealing to users that are on the side lines.
My rather lengthy suppliment to Tutorial 3.2 mentioned that cog? doesn't keep track of i/o pins and baud rates for Serial port cogs. I just realized that one can write a version of the serial word that would keep all three items as variables for later reference if important.
I guess this is why everyone wants to keep their Forth kernel to a minimum. It is just so easy to start extending and the 32K hub ram is filled up quite soon with wonderful code when you need the space. I may create a .f file of this as an extension for anybody that needs to keep track.
9600 baud is the only rate you should use since it what your print wants.
All propforth versions are the same as far as the user is concerned. only the internal. plumbing and memory foot print is affected, i dont think there is anything code wise the we would notice between versions.you have nothing to worry about.
making your words as a set of extensions is a great idea. many folks will be able to benefit. please post them in the downloads page, and make wiki page with discussion and explanation if you are. so inclined. hopefully more folks will follow your lead.
All well and good. I figure that since I mentioned a problem, I can at least provide an attempted solution.
In this case, the very useful cog? cannot provide the baud rate of a active serial port or which pins are Rx and Tx. One has to capture this information as one starts up the serial cog for each serial cog that is made active. I don't think there is any other way to do it after the serial cog is established.
Once the information is captured, then another word is needed to provide a report. The report could just gather all and everything related to each existing serial cog. There are a few other items... such as the serflag? bit, whether cr or cr/lf is in use, the length of a break for the serial port. I guess I have to try and get all of them in the report to make it of any real value as a tool.
Think.. think .. think
Worked through the MCS tutorial and the Logic Analyser tutorial. But I really thing the Serial loopback tutorial was most important to begin to envision using multiple cogs for things. Just because it uses the internal links in an ambitious manner.
I am also curious if PropForth v3.4 JupiterAce will now work with the MCS.f and allow an interface to a v5.0 loaded Propeller ? I am not sure how this plays out in terms of which makes the most cogs avaiable for other use on the two Propellers involved.
curious if PropForth v3.4 JupiterAce will now work with the MCS.f and allow an interface to a v5.0 loaded Propeller ? I am not sure how this plays out in terms of which makes the most cogs avaiable for other use on the two Propellers involved.
Jupiter ACE is a little more involved due to the assembler implementation f the VGA driver. I think the HiRes VGA uses two cogs? Its the same as the standard spin hi Res VGA driver.
The Earlier versions did not have standard interfaces, so while we could do simple serial on both, parts may be a little different and we can't really do MCS.
But on v5.3, we expect to be able to use a demo board as a forth terminal, and mount an SD, and connect to N romless slave props. I don't know what one would actual do with it at that point, but it might have uses. And of course we could have a Jupiter ACE talk to a protoboard and display the exchange on the teraterm screen. This and the other extensions are planned after the release is tested on published.
Jupiter ACE is a little more involved due to the assembler implementation f the VGA driver. I think the HiRes VGA uses two cogs? Its the same as the standard spin hi Res VGA driver.
The Earlier versions did not have standard interfaces, so while we could do simple serial on both, parts may be a little different and we can't really do MCS.
But on v5.3, we expect to be able to use a demo board as a forth terminal, and mount an SD, and connect to N romless slave props. I don't know what one would actual do with it at that point, but it might have uses. And of course we could have a Jupiter ACE talk to a protoboard and display the exchange on the teraterm screen. This and the other extensions are planned after the release is tested on published.
Thanks.. I spent a lot of time getting a VT100 emulation dumb terminal set up with a PF device. Then I began wondering if 2 Propellers could better deployed via the JuptiterAce. And it looked like an opportunity to see what MCS could do as well. But it seems I am a bit too early to make this leap. So I have the VT100 Dumb Terminal and a PF Propeller for now.
I guess what I am saying is that the JupiterAce will provide a better user interface experience than the VT100 dumb terminal... especially if there is an SDcard for file storage. I guess the MCS interface would be more flexible as well as it would be easy to extend to 3 Props and so on.
Question 1:
I want to list the words in the dictionary after a target word.
Generally the target word would be fence, a nop word at the end of the standard dictionary.
There is a word _words that finds occurrences but not the latter words.
What is the word or how to do it.
Question 2:
How do you reserve some memory space for say an array.
I assume a name is attached so an address for the first element can be found.
Comments
Sorry Loopy I was not clear, I was counting the ALL the pages and included the old pages which are deprecated.
You are right of the 100 pages in the list, only 96 were posted by me; two were posted by Sal and two by Rick.
I should strive for greater accuracy.
LOopy, I just got to this, getting caught up. This description sounds like what I wrote for the EMIC2. Grab the EMIC2 file from my Tachyon Forth Apps folder and change the SERIN port from 7 to 6 and change the 'wait' char from ":" to ">" and you should be in business.
You may be making this all too easy for me. I've been getting very very deep into how PropForth communicates and programs between all the cogs. I will follow up your suggestion. Even though the mysteries are unfolding, I am still uncertain that bi-directional half duplex can work in PropFoth. I am quite sure that 2 wire duplex is alive and well.
I may even end up with two solutions - yours and mine.
For anyone following along, the EMIC2 does have a Sin and Sout, Brian is suggesting I just adapt the existing Tachyon code to use a single pin of i/o. The is a perfectly legitimate solution.
But I am still wanting to prove the same in PropForth.
Why bother? There are times when you just don't have that extra wire as your chip has run out of pins to use.
Apparently has several Parallax products use the ">" prompt from the 'slave' and then the 'master' sends <stx> some text <etx> as a rather simple handshaking.
Did you try using the standard serial and simply assign the same pin as Tx and Rx?
AS I understand it, the Tx and Rx run independently using counters a & B, so the only thing you should notice is an automatic local echo of the character the prop sends.
The only tricky part is plugging in the standard interface from the cog running your chopstick printer control app to the cog running the serial driver. So that would consumer two cogs, and still leave cog6 for you forth prompt, and cog7 running the default serial on pins 30 and 31. SO i think your chopsticks printer system would consume 4 cogs, 2 for the development interface and 2 for the actual application
: waitcnt begin dup cnt@ - 0< until ; : putch 256 or dup + clkfreq@ 9600 / 11 >r cnt@ begin r> 1- dup >r while rot dup 30 lshift outa! 1 rshift swap rot dup rot + waitcnt repeat r> 2drop 2drop ; : test cnt@ 65 putch cnt@ swap - 80 / . ;You will find it in the latest pfth version by D.H
Ron
It really isn't all a number's game. You have been writing these Wikis quite consistently over the past two years, while I only posted something on November 11 of this year. (hat approximately marks when I began to read "Starting Forth" in earnest.)
And Sal has the original SpinForth mentioned in a Wiki from April of 2009. There has been a lot of work that has gone into what you and Sal have done. That should be recognized and appreciated.
PropForth is a worthwhile software and a lot of thought has gone into it. But I think we all have noticed that Forth has been set aside by much of the programing community as there has been a huge forced march to get something newer better or faster.
To me, Forth and PropForth have been a huge surprise. Let's just say it is a bit of a diamond in the rough at this point. I'd reached a point where I didn't want to use Spin and had never really learned PASM and was hoping GCC would revive my interest in the Propeller.
And then I discovered that I really found a lot of aspects of Forth very easy to grasp and that it offers the possiblity to learn PASM in short brief passages of code that are used in Forth words.
Mostly, it is very appealing to me.
Of course, there are aspects that are so different from other programing language that they still are controversial. The fact that everyone is creating their own words on top of whatever is provided and whatever someone else claimed necessary is confusing. And it is a part of Forth's history that is infamous. In some ways we have been reliving that because we now have 3 versions of Forth active on the Propeller.
I look at Sal's downloads and there is a lot of work that is over my head. I have no doubt it works well and fully demonstrates the power of PropForth, but I am not exactly sure of what a Fast Hartley Transform is. I do understand what an Analog Computer is, but I thought those were normally built with op amps, not emulated in digital.
Caszak is doing quite well with the kind of things that Parallax normally addresses. He takes a rather demanding support chip and finds his way through the documentation and explores the chip in Forth. And then he can actually write an application in Forth to use it reliably.
Apparently you enjoy writing. For me, technical writing is very demanding painstaking work. I always have to do dozens and dozens of revisions before I really want to show something to the world. I can teach English very well as I deeply understand it, but I found myself very frustrated when I was writing for graduate studieS in linguistics. It would take forever to complete an assignment.
Sal has also written some important and detailed documents, but they are a huge distraction from just writing code and improving code. When your writing code, it is for yourself and the machine. When you write documentation, it is for an audience that you may never fully understand.
Enough said.
Remembering and keeping facts straight is very difficult for me, so I have to write everything down. When I re-read what I've written, it often makes no sense, so I have to re-write it. Eventually, it gets to where I can reread what I've written, and it makes sense; now I can consult my notes, and I don't have to particularly remember anything. So I've developed this writing habit.
This is because while the material I use everyday becomes old hat, the stuff I use once (and forget) gets lost. I've seen entire products lost this way, the team moves on and forgets what they've done, and cannot support a previous product. "Write Only Code" is not a characteristic of forth, it is a characteristic of poorly managed projects. I run across this at nearly every job I contract.
The key is "getting the information from the person that has it, to the person that needs it, in the most timely, efficient manner".
Who has the information? The Author. Who needs it? The Reader. But documentation is EXPENSIVE. Every minute spent writing the docs subtracts 10 minutes from the authors ability to create. So who else can write the docs? The trainee. The only way to really learn something is to teach it to somebody else. (I forget who said this, maybe I just made it up). The new guy needs to learn the material, and have to go over it thoroughly anyway, if s/he writes it down, we have a receipt that shows the material was studied, and to what degree.
This is where "new guy notes" comes from. The keeper of the knowledge (the mentor) writes a description of what the mentor feels the new person needs to know, and gives this to the new person. The new person reads it and says, "this is incorrect, out of date, and poorly written" and rewrites it (until the new person declares it sufficient). And becomes the new keeper of the knowledge until the next new guy comes along, and mentors the next trainee.
Thus, the documentation and transfer of knowledge is driven by the party that needs the knowledge. The new guy can ask the previous mentor, and if the mentor cannot answer the question, ask his mentor in turn, until the question is resolved. The mentor is much more willing to field questions from a trainee that ask intelligent questions, or at least seem to be trying to get it.
This is the model I am attempting with the propforth project. Unfortunately I write too much these days, and nobody seems to read this far.
Well, rather fortunately I have not yet put the i/o together as there is a jump from the 3.3volt i/o logic of the Propeller to the 5.0 volt i/o logic of the Serial inkjet printer board. That makes the configuration a bit more complex and I am pondering what to do for good protection.
I do have a schematic for using a 2N7000 with pull-ups on the 3.3v side and the 5.0v side that might work well. But for now, I am still running through catching up with what I really don't know about Forth. You guys seem to overlook the fact that I've only been using Forth for less than a month and have spent more time debating than using.
4 cogs seems about right. At least I haven't destroyed any of the parts yet. But the fresh inkjet cartridge that I ordered last Friday is way past the promised two day delivery date. I even gave them a cash deposit of 50%.
The stepper code I provided for the contest can be used to verify two steppers in your Little Robot project if you are using similar unipolar 5v 200ma steppers. But be sure to provide about 7.2 to 7.5 volts for motor power as there is a voltage drop of 1.4v or more due to using the ULN2803 Darlington array. Motor power does NOT require a regulated voltage. I don't think the motors will suffer at 6 volts or less.
Writing for teaching is different than what you do. It is all about helping the reader notice and helping to reinforce remembering what is important. I am writing something for the PropForth that will demonstrate this and it should be done soon. While it helps me learn, it also shows what is not so obvious to others. I guess you are driven by deadlines to complete a writing project, like journalist. Some rise to the challenge, others just do what they have to in order to survive never-ending deadlines.
The problem with your 'new guy' process is that I have suffered from nerve pain in my neck for 40 plus years due to an auto accident at 23. Lenghty typing projects are physcially painful for me. I gave up pursuit of a Masters Degree because it wasn't worth the physical pain. Besides, not every 'new guy' is aware of what will reach the broadest audience. Jon Williams has written Parallax's articles in Nuts and Volts for many years because he does reach the broadest of audiences. If you can write like that, Parallax will keep you extremely busy.
I am never going to become a prolific contributor to PropForth due to physical limitations. I've never been a major contributor of written materials to Parallax.
Keeping lexicons straight in 3 different Forths is not an easy task either when everyone wants to do it their own way. Communications is not about standards, but it is about accepting conventions for the sake of efficency. We seem to be herding cats. Try learning Chinese, Japanese, and Korean at the same time and you will understand why near noone is successful at learning two foreign languages at the same time, much less 3 - there is no time to consilidate and retain what has been presented.
As I suspected, there are some interesting behaviors. I might even hazard to say somewhat undocumented.
In setting up a connection between the dumb terminal and the my notebook with the PropForth between, the outgoing keyboard behaves nicely as expected on the dumb terminal's screen.
Also, in doing a stand alone hardwire loop back with the dumb terminal it behaves as expected, exactly the same as the outgoing. No problems with either of those.
When I do incoming to my notebook computer it seems mostly okay, but some keyboard functions are not active. Cursor movements seem to have been filtered out. This should be a straight line from the SERIAL to the console SERIAL. The other direction is using the term application.
And when I set up an entirely independent cog that is linked to serial and connect that to the Dumb terminal, line feeds don't really work and neither do up/down/left/right arrow keys. Everything becomes impossible to read as it all hangs on one line that is repeated overwritten from the left margin. Some code does seem to get entered and interpreted. I can even create words. But I cannot see what I am doing as carriage returns do not add any line feeds.
I seem to vaguely remember that their might be a flag somewhere to turn on line feeds but I am unsure.
I try to do cog? and it outputs in a rather messy way. If I do words, the results are far worse, the PockeTerm software goes wild, is apparently corrupted and I have to reboot everything to restore order.
It seems obvious that the Forth machine in the PropTerm output is some formatting conventions that are hostile to the PockeTerm's VT100 emulation. I don't quite know what or how.
Please don't expect me to make an item by item bug report of this as I wouldn't know where to begin. Sal must have some idea of what PropForth does and does not in terms of output and input. I was just hoping that it would be rather simple. Are Esc sequences used regularly?
Yes, I can dig around in the source code, if I must. The main message here is that running real hard wire loop back test is quite revealing in ways that having PropForth chatting with itself would never be. This is a necessary process to reveal what is.
I suppose that if I retain precise control over what is sent out, I could easily to the Chopstick printer. Since it is not a high volume of traffic it would be very easy to debug. But I had been planning to use the dumb terminal instead of my notebook as my primary workstation for Forth programing. That may not be possible for quite some time.
Good news, the inkjet cartridge finally arrived.
Bad news, I had not considered that the Propeller is 3.3v logic while the Serial Inkjet printer board is 5.0v logic. I may insert a 74ls175 Quad 3-state buffer to handle the Rx and Tx traffic in a safe manner. The Propeller 3.3 i/o can sent to 5.0v logic, but the reception needs to be protected. So it is back to considering 2 pin Serial and some added complexity with the 74ls175 managing traffic.
It is a bit amusing to see how much easier the chopstick printer setup and coding is on a BasicStamp. Serial ports don't go through cogs and so on.
I noticed this it is not easy to overlook, but I guess thats just your way. If you spend some time doing the examples and walking through the source code, its would be MUCH easier.
You write huge volume of words. If you write about your experiments (breifly, as in design, code, results), we would all benefit (including you).
IOW, you seem unaware of that and just expect me to catch up to you. Brevity has not worked well. But yesterday, I did ramble as I was quite exhausted and confused.
I have worked through all the examples where they apply and done so several times, and I am digging through the source code, but I still don't quite understand all the organization of all the various files and references of various kernels. Myself and others have asked for your definition of what a kernel is as it would help use all with recognifizing what source code applies to which. Your relies have been pretty much that a kernel maybe this at times or that at times.
My initial impression was that PropForth's v5.0 provision of a PropForth.htm and tutorials were indications that less advanced users might have an easier and clearer point of entry.
Okay, so I have turned to reading "the source" and focusing on "the kernel". I thought for the sake of clarity that I could work with just the .zip package for v5.03 as a complete snapshot of PropForth. But queries have said to look elsewhere and that I need this or that from the PropForth site as well. So at times I seem to be in a paper chase to find what might be and where it might be.
I am turning to the source code now, but the machine code portions are opaque to me. You mentioned 64bit optimized assembler code for this 32bit Propeller and I've even come across mention of some rather advance Forth optimizations on the PropForth website - something like Peep Hole optimization. I have Googled as you suggested, but Googled doesn't come up with a solid reference on this point. An actual link to something well-written is always more helpful than a search engine.
Not sure if that might make the Forth source so opaque, but it is yet another topic of study.
Why not just come out and say that PropForth is this and that and these are the prequisites for complete understanding? As it is, the impression one gets is that PropForth is 'open source' up to a certain point. Then, much is hidden in overlays of complexity.
~~~~~~~~~
Back to that which I am doing in contrast what I just cannot seem to locate..............
I have been running a series of hardware serial loop back tests and full-duplex communications with Minicom on my Toshiba NB250 notebook and Briel Computer's PockeTerm loaded into a Propeller Demo Board that is suppose to emulate VT100 with its own VGA and keyboard.
A good night's sleep makes computer bugs much clearer.
At this point, I am ready to switch from the PockeTerm v0.905 software to another available VT100 that loads to a Propeller Demo Board.
There are problems with v0.905 - the current download, which I didn't previously have with this product. It provides for two serial channels - one is the normal dumb terminal, the second is suppose to do something fancy with your computer (maybe screen cut and paste exchanges ). I thought I could ignore this 2nd channel, but I must provide for it when I boot or the boot will not complete. I have to have the 2nd serial present and active via a PropTool, or the boot will not work.
Later disconnecting it seemed to work and Minicom in Ubuntu requires that I disconnect it, but there seems to be a background constantly loop polling for this after the disconnect. The USB device indicates activity with a flickering red LED. And that polling may be a source of instability triggered by unknowns that result in the whole dumb terminal crashing.
The easiest thing is to switch software and see if the problems go away. I do this all the time between Linux and Windows to verify if I have a software problem or an underlying hardware problem.
Still, I am pretty sure of these following observations:
1. Hardwire Loopback of my Minicom software has it perform as expected.
2. Hardwire Loopback of my PockeTerm software has it perform as expected.
3. Having Minicom to PropForth to PockeTerm in full duplex serial performs as expected (The two terminal application -- Minicom in Ubuntu and PockeTerm in a Propeller -- may fully support each other), but it may be 99%. I need to continue looking at this and why forwarding through the PropForth behaves when an independent Forth machine in PropForth does not (see #6 below).
4. Having PropForth internally loopback to my Minicom has it perform as expected.
5. Having Minicom to PropForth has it perform as expected.
6. Having an independent PropForth cog via its own serial driver attached to the PockeTerm VT100 is not right, while the PropForth serial console is properly working with cogs 6 & 7, offers limited function due to display not behaving. Keyboard input seems to be received and processed as it should. I strongly suspect I have to add a trap that catches CR and adds an LF to all instances.
The details...............
In #6, I say limited function because the use of 'cog?' and 'words' results were bad.
1. just hitting Return has the Prop0 Cog0 prompt come up, but it seems to do so without issuing a LF and the PockeTerm does not insert one. This may be the source of all the other woes, and initial investigation of the 'source code' for cog? and 'words' indicate that not ANSI control or Escape sequences are included.
(Prof Braino's first suggestion that I look at the extension for these is not worth bothering with. They seem to pertain to adding mostly color selection to the character display and we are concerned with the absence of a fundamental feature ... the Linefeed.)
2.Testing 'cog?' for output should issue a nice multi-line report for all 8 cogs at one to a line, but it gets strewn over the screen, maybe it is attempts carriage returns and over-writes (I might be seeing only the last line over-writing the others), but certainly not linefeeds.
3. Testing 'words' seems to trigger PockeTerm's instability due to the two serial port configuration of this applcation. I cannot seem to locate a way to remove the feature in the source code that requires it to constantly poll the 2nd serial port for activity. And as everyone knows, I don't really read source code well. So I will attempt to resolve the issues by loading another VT100 emulator from a different source (the Propeller seems to have at least two and this is very, very useful in such instances)..
4. Having Minicom to PropForth to PockeTerm in full duplex serial at the same time on Cog 7, 6, & 2 via '2 0 term'performs as expected (The two may - Minicom and PropTerm - fully support each other, and the PropForth appears to faithfully transfer without interfering until CNTL-F breaks the connection.)
5. Having a PropForth internally loop-back to my Minicom has it perform as expected (that is what the provided Tutorial 3.2 presents -- but it doesn't indicate what happens when the outside world tries a loop back ).
So there you have it. I actually think that I can set up a loop that traps CR and adds LF on the PropForth output and that all the problems will go away.
Above all, don't get caught up with unneeded ANSI terminal codes and ESC sequences. Use these sparingly and you will support a lot more devices with a lot less problems. I am trying to use ONLY those codes that are provided within the realm of the 256 choices that ASCII provides as a single byte. And in truth, I am really most concerned with jus the first 128 choices as the second 128 often vary with foreign language expectations.
**************
You have been wanting lists, the above has at least one pretty good one.
I'll restate this, yet again, so you might catch it this time.
You don't need assembler or ANY advanced topic at this point. You should AVOID advanced topics till you get there. All beginers should advanced topics at the beginning, it just makes you confused, as you demonstrate.
You MUST step through the propforth source code to understand each word you want to use when you don't understand the word. If you don't, your progress will be slow, as you notice.
If you do something else, like try to use the reference for another language, (like ANSI forth or Tachyon) in place of the propforth references, you will confuse yourself, as you notice.
You must step through the examples if you want to use a word properly. How the heck else are you going to figure out how to use it? If you don't, you will have very slow progress figuring out what the words are an how to use them.
ALL you questions are answered in the material, to the best of my knowledge. If you read them and have further questions, we can work from there. But if you demand that I re-write all the materials just because you don;t feel like reading them, I question the logic. If you won't read whats there, I don't think you'll read any additional materials either.
For example, your questions about serial. Two folks have told you about the non-displayable ASCII character values, and you call it unneeded. Read it, try it, do it, understand it, then determine if it is unnecessary. Folks give you this answer based on what you are asking, why must you dismiss it with out trying? It is a simple answer to you question, if you simply try it.
I'll read the rest of your post later, when I have more time to address it properly.
That is the only way , I agree
There seems to be a disconnect here.
1. I was hoping to use use PropForth to learn something about PASM and that is not visble with 64 bit Google optimization.
2. I was of the impression that I was on my own to read the 'serial' and '_serial' word in PASM
3. I have worked through all the examples in the PropForth.htm and the tutorials that have applied to what I has as hardware and what I am trying to achive.
Hopefully, I don't have to buy all the hardware in al the tutorials in order to learn PropForth.
4. I am proceeding on my own.
5. You seem to be thinking I am not get anything, so you keep sending me to source code.
~~~~~~~~~~~~~~~~~
In the meantime.
1. I have switched to Jeff Ledger's VT100 emulation as it is stable with one bug that keeps the cursor on the top line. It only has one serial port to use, so I can move on with real world asynchronous serial in PropForth.
2. I will likely resolve the lack of a LF tonight. A solution might require I add a cog to trap CR code from one Cog and retransmit CR-LF to the SERIAL driver to the outside world
Above all, please don't lump ESC codes together with ASCII CR and LF, or the other ASCII hidden codes such as <STX> and <ETX>.
It really is that simple.
All the ESC codes are an overlay with ESC as merely the preamble of a longer code. Some move the cursor in a video monitor, some clear various portions of the screen, one actually diverts output to a printer, and some format screen characters to different colors. These are a lot of nice stuff, but distracting to sorting out what the actual asynchronous serial port is doing and whether it is supporting a barebones downstream display or not.
I am not demanding that you re-write documents. I just have been a bit surprised and and daunted by what is available. At one point, I volunteered to read and help edit. But that seems to have been misunderstood as demands for information you are not prepared to provide.
As I said before, I'd like to get past this perception that I am too needy. I have just been frustrated. I have repeatedly said I can adjust to what is. And I am demonstrating I can do so.
Since you keep referring to my not doing 'the exercises' can you confirm that the tutorials and the PropForth.htm are a full set? It is possible that I am unaware of some others?
Regarding the tutorials. I am not yet using the EEPROM or SDcard file systems - so those are not done. But everything through Tutorial 2.3 plus Tutorial 3.2 have been done and pretty much assimilated. I've not bothered with the Logic Analyzer at this point as it seemed rather ambitious. But I will go through it to verify that there is or is not material that I've overlooked.
Cheers.
Affirmative, one MUST step through the source code to learn any Forth. I am just not sure which source code applies to the array of items provide in the PropForth .zip file. I primarily start with the .spin file that I loaded for the 64K EEPROM version of v5.03.
Maybe an inventory would be helpful of which files actually associate with which things. Meanwhile, I open files of code, look at them for a while to see if I can figure out why all this is included - and then move on.
One of my prime desires is to use Forth on the Propeller with a reliable Dumb Terminal rather than having to have a regular computer do that rather mundane task. So I have been doing a lot of real world loop back testing, switching things around, and reloading software.
That's just the way it is, and will always be.
I switched to OddbitCollector's (aka, Jeff Ledger's) VT100 emulation and all the video problems with PropForth went away and so did the unrelated problems. It did have a weird cursor problem, but that is something I could live with. And very oddly, the cursor problem in a hardwire loop back went away when I ran my first trial with the PropForth.
IOW, this VT100 operates very clean in PropForth. I have met my goal.:thumb:
Some of these things are just part of exploring new software - one VT100 program has problems, so I checked another. I also discovered a strategy to fix the problem in the first, but that might require 3 cogs rather than 2 cogs.
@Prof Braino
It could just be that the worst of my learning curve is over. Since I started about November 11th, it hasn't even been a month.
It is a long time ago I download propforth, where can I find the latest version?
Jan Kromhout
The link to the wiki at the bottom of my signature has the latest. I think the latest is 5.03 from early Spring.
Sal is back from his travels, we were able ti get to Loopy's questions on serial and documentation.
Turns out Sal did not get Propforth to 3M in testing, this was my confusion; only Peter has a forth to 3M to my knowledge. Sal tested propforth sufficiently high to determine that 230400 is the highest speed that ensures stability.
Concerning the serial code: The highlevel source for the serial driver is in
..\V5.03\kernels\BootKernel\ PropForthStartKernel.f
The high level source for _serial is WOULD be in
..\V5.03\kernels\BootKernel\BootOptimizeKernel\ PropForthBootOptimzeAsmSrc.f
But, its not. Turns out there's two things at play here. 1) the plug-in interface is a bit more involved than plain vanilla serial, and evolved in assembler, so the unopt6imized code was NOT included. 2) Serial is in use before its gets rebuilt in the build processor. So the serial support is built and then dropped in in place of the previous suuprot on the fly during the build process. This doesn affect anybody but Sal, but removes our "simple example" for serial from the code. So we are taking steps:
Caskaz has started reworking the serial driver for Loopy's issues. Caskaz found the source, and has started unraveling the assembler. I think he's trying for a simple serial implemnetation, that does not have to deal with the plug in interfaces. So it looks like Caskz will learn the advanced stuff to help on loopp's questions. Thanks Caskaz!
We discussed Loopy's problems with the docs. We figure 90% of readers will approach propforth the same way and have a similar set of problems. To address this, and maybe make it better:
1) I'm going to make a new "intro page" to describe how to find one's way about the documentation
2) We're looking into a method of providing link from the entry for each word in PRopforth.htm to the source code that defines each word.
3) we're looking into posting propforth.htm someplace where we can link to the anchor for each definition in section 9, or any other section as needed.
Incidently, Sal finds that Propforth.htm is the only reference he needs anymore. Propforth.htm contain the stack notes (the "goes-intas" and "comes-outas", and purpose for each function); the actual internals of the function are not needed most of the time.
4) We're looking into making the release have two options
a) a download with just the spin files and extensions as found in ".\V5.03-20120505\"CurrentRelease" that we can "load and go"
b) a download that includes the automation, Go language support, and pre-optimized files for rolling our own kernel.
Even though we know everyone looks at both, and just downloads the biggest file; at least this can give us a notion of which is the simple stuff and which is the advanced stuff.
We figure the biggest issue with the full automation and test suite is setting up one router to allow the IP tests to work. We both recenlty changed intternet providers, and now the previously working tests fail. Since the software and tests are unchnged, issue is traced to the change in routers. Every router is different and must be custom configured. We will work through our hardware to provide a count examples, this should give folks at least a starting point in getting the network set up.
After we document sorting out our networks, and show that the previous tests can run again, we will start release testing for v5.3. We think we can walk through the network stuff next weekend. After that, Sal just needs a couple days to do the final build, and he'll send it out for testing.
My ability to predict the future has proven to be mostly wrong recently. But I'm going to guestimate there at least two weeks work left, and theres a bunch of holidays coming up. We'll either find lots of time to work or we'll be too busy. Hopefully we'll get done before the world ends this year, otherwise we'll try to be ready when the world end again next year.
One can get all involved with the internal speed and not have any connectivity.
The rule of thumb is that if you have asynchronous serial problems, go to a lower baud rate. And the same for any other form of communications - parallel or serial. When you have problems, go to a slower data rate.
Since we have a lot of hobbyist involved, there will always be a lot of construction related problems. DO NOT think every problem is in the code.
If you look at the Tutorial 3.2 supplement that I created for the Forth of the Forth Contest, I found that all the display problems that I was having with cog? and words reports went away by reducing the baud rate to 9600 baud from 57600 baud.
Suggesting that I read the source code for this problem was very disappointing and unhelpful, but I now know that you have very little actual hardware configuration experience.
Nonetheless, the rather amusing result is that I have been spending more time trying to read the code. And I intend to ask less questions in the future. Source code for the Forth words have to be right for the documentation to have a good reference.
The contest entry was created to help PropForth see an alternative way to provide support. I am really am trying to give back as much as I take away from learning and using PropForth.
Thanks for running down these loose ends. There are always others that want to know the answers and good answers mean more popularity.
Above all, work smart rather than just working hard. Don't write something too soon, let the facts appear.
I do understand that 3Gbyte works well with USB ports and cables as they are fashioned for high speed serial and tested for such.
But when I start to solder up my own creations, I never seem to get anywhere near that. Besides, what happens at the end of the line? Both the computer board and the Propeller are just sitting in loops and waiting. The same function works just as nicely at 9600 baud as 3M baud when a human is involved.
I do have to admit that if I were to load up a 4Gbyte SDcard with data that needed transfer to my PC, the 3Mbaud would suddenly become useful. So my way with words may be a bit too compelling.
Not very sure there is an overhead savings one way or the other. Is the cog running threaded multi-tasking code?
But I do know everyone is going to have some beginners wondering why their creation can not work, and it will be that 3Gbytes requires shielded cable and superior board construction.
I used two Parallax Proto Boards with headers soldered on and store-bought 3 wire cable (with connections attached to fit the headers) to set up my serial. It was too fast at 57600 baud. A small reduction may have solved the problem. But since I didn't have time, I just jumped down to 9600 baud to verify that it was NOT an internal PropForth problem.
Once one knows where the problem lies... solutions are much easier. Thus the rule of thumb. And the foremost rule of thumb is find where the problem lies, don't guess.
Of late I am spending way too much time defending whatevery I write. So I guess I'll just write less.
Propforth (this thread) will begin to support software multitasking in PF 6 or above, when there is enough room to make reasonable use of it. Current releases only (?) have hardware multitrasking, by virtue of the multiple cogs.
The overhead savings is we don't have to wait so long.
We are still talking 3megabaud or 230400 is kilo baud as is 9600, I think; but none of these need a special cable as far as I know. I used signle bits of wire, unshielded and not twisted into pairs. This works fine at all baud rates tested, up to 230400 on propforth.
So you verified that your target device that you were TALKING TO does not support anything faster than 9600 baud? I guess thats your problem, then, don't blame your cable. It certainly is within that capabilities of the prop and propforth in particular.
Write MORE, your posts can be beneficial. And you're good at it. Just try to delay claiming everything is broken until you collected some data or at least run the proper tests. Moving forward, Please describe your issue with sufficient detail to reproduce it, and ask for help. This is the recommended process.
If the resource is electricity, more power is available for longer running on a battery or a smaller solar panel may be deployed.
If the resource is CPU capacity, doing serial commnications faster and then clocking wait states until the the next transaction is not really saving a resource to be available elsewhere.
That was why the query about multi-threading code on one cog. On the PropForth, a serial cog at high speed baud is no more resource efficent than one at low baud speed if the task is being accomplished in a adequate timeframe at the lower baud rater. There is no net gain of available resources in such a context.
While running at 9600 baud seems to offend all you speed demons, all along I have been working toward completing the chopstick printer project that will only run at 9600 baud 8N1.
My point has been that extreme high speed may be useful, but not always.
And while you assert you are using 230400 baud with simple wires, I have created a Dumb Terminal that tests nicely at 57600 baud in loop back, but cannot be reached by another Propeller with the PropForth loaded at that rate when used with simple wires. I had to go slower.
9600 baud may slower than necessary for the Dumb terminal. Further testing will tell. What I did verify was NOT what you seem to interpret. I verified the Dumb terminal in loop-back is fine at 57600 and the PropForth is fine in loop-back at 57600 ---- but with the wiring I was using, 57600 was too fast. Multi-lined reports such as 'words' or 'cog?' became garbbled. Please read my posting carefully as I go to great efforts to be clear as possilbe.
I am just saying that the 'faster is always better' leads to some perception there are problems in the software, when the problems are in the wiring.
I don't see why everyone has to be rude to the user that needs to use 9600 baud. It is merely a real situation.
Furthermore, 'hardware multitasking via multiple cogs' was not what was being referred to in my query. I was referring specifically to having one cog do two or more tasks at the same time. The SERIAL cogs seem to be fully committed to only handling a full-duplex communication channel and nothing else. One dedicated task, not multi-tasked.
My focus is quite narrow. I am trying to learn Forth and I am only using v5.03 of PropForth at this time. What is or what will be in versions beyond may be interesting, but I can't keep jumping from version to version or waiting for a new feature to learn Forth.
Since this thread is titled to be about v5.0xxxxx, I hope that 5.1, 5.2, 5.3, 6.0 and so on will have separate threads.
I realized that both Tachyon Forth and PropForth want to promote there features, but at some point clear and concise no nonsense support is also a significant feature.
I keep getting pulled back into the Parallax Propeller Forth Debating Society when I am merely trying to contribute real-world experiences and practical know-how as a means to make Forth more appealing to users that are on the side lines.
I guess this is why everyone wants to keep their Forth kernel to a minimum. It is just so easy to start extending and the 32K hub ram is filled up quite soon with wonderful code when you need the space. I may create a .f file of this as an extension for anybody that needs to keep track.
All propforth versions are the same as far as the user is concerned. only the internal. plumbing and memory foot print is affected, i dont think there is anything code wise the we would notice between versions.you have nothing to worry about.
making your words as a set of extensions is a great idea. many folks will be able to benefit. please post them in the downloads page, and make wiki page with discussion and explanation if you are. so inclined. hopefully more folks will follow your lead.
In this case, the very useful cog? cannot provide the baud rate of a active serial port or which pins are Rx and Tx. One has to capture this information as one starts up the serial cog for each serial cog that is made active. I don't think there is any other way to do it after the serial cog is established.
Once the information is captured, then another word is needed to provide a report. The report could just gather all and everything related to each existing serial cog. There are a few other items... such as the serflag? bit, whether cr or cr/lf is in use, the length of a break for the serial port. I guess I have to try and get all of them in the report to make it of any real value as a tool.
Think.. think .. think
Worked through the MCS tutorial and the Logic Analyser tutorial. But I really thing the Serial loopback tutorial was most important to begin to envision using multiple cogs for things. Just because it uses the internal links in an ambitious manner.
I am also curious if PropForth v3.4 JupiterAce will now work with the MCS.f and allow an interface to a v5.0 loaded Propeller ? I am not sure how this plays out in terms of which makes the most cogs avaiable for other use on the two Propellers involved.
http://code.google.com/p/propforth/wiki/PropForthFAQ
But I was at work, and didn't have a lot of time. Anybody can ask more questions, any team member may edit it for correctness or to clarify.
Jupiter ACE is a little more involved due to the assembler implementation f the VGA driver. I think the HiRes VGA uses two cogs? Its the same as the standard spin hi Res VGA driver.
The Earlier versions did not have standard interfaces, so while we could do simple serial on both, parts may be a little different and we can't really do MCS.
But on v5.3, we expect to be able to use a demo board as a forth terminal, and mount an SD, and connect to N romless slave props. I don't know what one would actual do with it at that point, but it might have uses. And of course we could have a Jupiter ACE talk to a protoboard and display the exchange on the teraterm screen. This and the other extensions are planned after the release is tested on published.
I guess what I am saying is that the JupiterAce will provide a better user interface experience than the VT100 dumb terminal... especially if there is an SDcard for file storage. I guess the MCS interface would be more flexible as well as it would be easy to extend to 3 Props and so on.
I have more than enough to do and learn.
I want to list the words in the dictionary after a target word.
Generally the target word would be fence, a nop word at the end of the standard dictionary.
There is a word _words that finds occurrences but not the latter words.
What is the word or how to do it.
Question 2:
How do you reserve some memory space for say an array.
I assume a name is attached so an address for the first element can be found.
Thanks
Duane J