Propforth 5.0 is available for download
prof_braino
Posts: 4,313
Please notice - v5.0 is no longer the current release. Please see thread http://forums.parallax.com/showthread.php/146693-Propforth-v5.5-is-available-for-download
Propforth 5.0 is available for download
http://code.google.com/p/propforth/downloads/list
Propforth 5.0 Release Candidate 6 has been cleared for release. The date stamp on the release is Jan 9, 2012.
Propforth 5.0 has been stable since November 2011, and no user facing bugs have been found in the kernel since then.
There have been several issues with the regression tests, the tutorials, and documentation which cause generation of new release candidate packages; but these have been addressed and have not resulted in changes to the kernel itself.
The PropForth development team believes that 5.0 represents the final version of the propforth kernel. While other releases are planned for extensions and documentation, the kernel itself is not expected to change.
PropForth.HTML
The file PropForth.HTML is included in the download archive. PropForth.HTML is the focus of user documentation. New revisions of this file will be released in response to answers to user questions. Users are asked to read Propforth.HTML and provide comments and questions. Additional documentation will be driven by answers to user questions, as we've done previously. HINT: Read PropForth.HTML
Normal Kernels
There are three (3) standard kernel configurations in this release.
The three standard kernels are
(1) the optimized development kernel with no file support.
(2) the optimized development kernel with EEPROM file support.
(3) the optimized development kernel with SD file support
PropForthDevKernel.spin is the normal application developer staring point if files system in NOT required.
PropForthDevKernel.spin contain the typical developer extensions from the developer extensions module PropForthDevKernel.f.
PropForthOptimizeBootFsrdKernel.spin is the normal application developer staring point if EEPROM file system is desired;
most modifications are done via the boot.f file. PropForthOptimizeBootFsrdKernel.spin contains PropForthDevKernel.f extensions. Additional Extension are added from EEPROM, either automatically via boot.f, or manually by the user.
PropForthSDKernel.spin is the normal application developer staring point, for SD file system applications. PropForthSDKernel.spin contains PropForthDevKernel.f extensions. PropForthSDKernel.spin does NOT Contain EEPROM support. Both EEPRM and SD files are POSSIBLE, but we determined two files systems were confusing. Instructions for adding dual files system support will be added in order of request.
In all normal cases, modifications to kernel functionality are done via extension loaded from the files systems,
either automatically via boot.f, or manually from the user.
Typical Extensions
The developer extension word build? will list the build_ words. The builds_ words are markers we put in to show which extension packages are added.
IP (ethernet) is added via a set of extensions and a new boot.f file. This contain the telnet support.
The telnet terminal is the current "best way" to load large source files, as the flow control is built into the ethernet hardware.
http server is a set of extensions that provide web page support. The developer can create web pages that call forth words. The web page support is not another terminal interface at this time; it is more similar in functionality to java scripts on web pages.
Modifying the kernels
If cases arise where a user needs to modify the spin files, separate instructions are to be provided, in order of request received. These are several intermediate kernels also provided, these are only used in regenerating the the standard kernels, and we didn't work out the clearest instructions. We didn't do this yet due to lack of time.
Separate instruction for "Building your Own Custom Kernels" is targeted to be a section of the manual.
Other notes
FYI - The release contain one known issue that does not impact normal operations.
The word spinImage can only be run once, and requires a reboot after execution per Issues 136, 138, 139.
This is to be changed in 5.1, so that spinImage may be repeatedly executed and generate identical ouput each time.
The spinImage word is only used when regenerating the optimized Boot kernel spin files during regression testing,
and is not used in any other context.
Propforth 5.0 is available for download
http://code.google.com/p/propforth/downloads/list
Propforth 5.0 Release Candidate 6 has been cleared for release. The date stamp on the release is Jan 9, 2012.
Propforth 5.0 has been stable since November 2011, and no user facing bugs have been found in the kernel since then.
There have been several issues with the regression tests, the tutorials, and documentation which cause generation of new release candidate packages; but these have been addressed and have not resulted in changes to the kernel itself.
The PropForth development team believes that 5.0 represents the final version of the propforth kernel. While other releases are planned for extensions and documentation, the kernel itself is not expected to change.
PropForth.HTML
The file PropForth.HTML is included in the download archive. PropForth.HTML is the focus of user documentation. New revisions of this file will be released in response to answers to user questions. Users are asked to read Propforth.HTML and provide comments and questions. Additional documentation will be driven by answers to user questions, as we've done previously. HINT: Read PropForth.HTML
Normal Kernels
There are three (3) standard kernel configurations in this release.
The three standard kernels are
(1) the optimized development kernel with no file support.
(2) the optimized development kernel with EEPROM file support.
(3) the optimized development kernel with SD file support
PropForthDevKernel.spin is the normal application developer staring point if files system in NOT required.
PropForthDevKernel.spin contain the typical developer extensions from the developer extensions module PropForthDevKernel.f.
PropForthOptimizeBootFsrdKernel.spin is the normal application developer staring point if EEPROM file system is desired;
most modifications are done via the boot.f file. PropForthOptimizeBootFsrdKernel.spin contains PropForthDevKernel.f extensions. Additional Extension are added from EEPROM, either automatically via boot.f, or manually by the user.
PropForthSDKernel.spin is the normal application developer staring point, for SD file system applications. PropForthSDKernel.spin contains PropForthDevKernel.f extensions. PropForthSDKernel.spin does NOT Contain EEPROM support. Both EEPRM and SD files are POSSIBLE, but we determined two files systems were confusing. Instructions for adding dual files system support will be added in order of request.
In all normal cases, modifications to kernel functionality are done via extension loaded from the files systems,
either automatically via boot.f, or manually from the user.
Typical Extensions
The developer extension word build? will list the build_ words. The builds_ words are markers we put in to show which extension packages are added.
IP (ethernet) is added via a set of extensions and a new boot.f file. This contain the telnet support.
The telnet terminal is the current "best way" to load large source files, as the flow control is built into the ethernet hardware.
http server is a set of extensions that provide web page support. The developer can create web pages that call forth words. The web page support is not another terminal interface at this time; it is more similar in functionality to java scripts on web pages.
Modifying the kernels
If cases arise where a user needs to modify the spin files, separate instructions are to be provided, in order of request received. These are several intermediate kernels also provided, these are only used in regenerating the the standard kernels, and we didn't work out the clearest instructions. We didn't do this yet due to lack of time.
Separate instruction for "Building your Own Custom Kernels" is targeted to be a section of the manual.
Other notes
FYI - The release contain one known issue that does not impact normal operations.
The word spinImage can only be run once, and requires a reboot after execution per Issues 136, 138, 139.
This is to be changed in 5.1, so that spinImage may be repeatedly executed and generate identical ouput each time.
The spinImage word is only used when regenerating the optimized Boot kernel spin files during regression testing,
and is not used in any other context.
Comments
THANKS
Modifying the basic kernel PropForthDevKernel.spin can be achieved without changing the spin spin source. After the final FORTH source code extensions are loaded into the interpreter, the new dictionary image can be saved back to EEPROM using the SAVEFORTH word, as before.
The usage of PropForthSDKernel.spin is a bit different. For various reasons, saveforth would tend to break the SD kernel. When using the SD kernel, consider PropForthSDKernel.spin as the "bios" on the system. We don't want to mess with changing PropForthSDKernel.spin, instead we load different sets of extensions using scripts.
Consider that the SD card offers pretty much unlimited space for source code (to be used as "scripts") and data (for example for logging). Any kernel + application must fit into 32K RAM to run on the prop. BUT, Propforth allows us to "forget" an application chunk when it has finished its job. A new application can be run, and also "forgotten" when it has completed its job. So we can have as many "application chunks" as we want, and swap them in and out as often as we like.
If the SD kernel is treated as bios, and the highest level forth scripts are arranged as "program scripts", we can have as many programs as we like, all that is needed is a "supervisor program" that can figure out which set of scripts to run at a given set of circumstances. A script can be made to "forget itself" when it has completed its function, and return control to the "supervisor program" who calls the next script to load.
A file can be set up as a "scratch area". This is just chunks of SD blocks to be used as temporary storage, like RAM. It will not be as fast as actual RAM, but since the over head is so low, its been fast enough (so far), and free (the SD card is already there). We can make the size of this "SD-RAM file" any size we want, up to the limit of the SD and other files needed on the SD.
The SD kernel is configured to look for and load a file named boot.f on system restart. During development, if we keep boot.f last, we can remove the last file loaded with fsdrop, and load a new development boot.f. If the file we are developing is the file prior to boot.f, we can fsdrop that one too. (Since the file system is not dynamic, we can only drop the last file; after fsdrop we can fsdrop whatever is the current last file.) So we can fsdrop our development file, load a new development file, load and new boot.f, reboot and test the next cycle.
After development, all the files are located as the beginning of the SD (locations and sizes need to be established, since the SD file system is NOT dynamic), the remainder of the SD can be used (as one or more big files) for data storage, such as logging.
In summary, PropForthSDKernel.spin can be the firmware "bios", the SD scripts can be "loadable programs", the SD can be treated as RAM, and we can have programs and data files of unlimited size (unlimited from the perspective of the prop, but of course limited by the physical size of the SD).
We think this model for the SD file system has some potential. Please give it a try.
I loaded up the SD kernel without any problems on a Spinneret and have been running some basics without problems.
My intent in choosing the Spinneret was to load one with the IP server and one with the HTTP server and expose them on the web to play with. So far, I haven't been able to find any IP extensions. Were they left out of the release package accidentally or on purpose? I can try with the 4.6 extensions and see how they work but I was really hoping for 5.0 with full Spinneret support.
Other than that, Mrs. Lincoln, so far, we're really enjoying the play!
Thank Sal for this. We tried the "users document theirr own discoveries" method, where I wrote up wiki docs as I went along; but over the course of the last year we determined that the basics have to be laid out by the designer. Sal didn't want to write another book on forth, but he is really the only person that could write about propforth.
OK, this is the bit about the documentation not being finished. Its all there, its just not done right [yet]. Previously, I had an idea that the regression tests, documentation, and the tutorials could all be the same files, and we would only have one thing to maintain and get triple duty from it. The regression test HAVE to be exactly what Sal needs to test the software, and that is not necessarily what I would want to show to somebody trying to learn. But, since you are jumping to the Advanced section (and this was pretty much written for you), you can try this bit out:
Under \kernels\doc\tutorials
Find and run a) tutorial-5.1 IP+Telnet.txt
and b) tutorial-5.2 HTTP.txt
You will see that in order to run 5.1, you first need to run 4.1, and for that you first need to run 2.1, and for that you need to read the Hardware.txt and Getting started.txt
[This was not the way I wanted it, but it IS what I asked for, because I didn't ask clearly; and part of the reason it took so long to get the release out.]
Any-who, if you run 5.1 on one spinneret, and run 5.2 on another spinneret, you will have exercised all functions involved in the Ethernet extensions, and know as much or more than I know.
Please comment and/or describe your findings, your progress will be the basis for the Ethernet section in the next version of propforth.html.
I actually use the Spinneret as a IP2Serial bridge , so here is my boot.f (in case someone is interested) which starts a second Serial cog (Cog0) with the Pins 26/27 at 115200 baud and connects it to Cog4(0) which hosts the IP SERVER:
I made the following additions to the
kernels/BootKernel/BootOptimizeKernel/BootOptimizeFsrdKernel/sd/ip/boot.f
(1) Right after the:
\ IP & TELNET CONFIG PARAMETERS END
c" serial.f" _fsload
(2) And at the end:
\ Start the serial to server and connect it to channel 0 (port 23)
c" boot.f STARTING tty" _bmsg
0 cogreset
h10 delms
c" 26 27 115200 serial" 0 cogx
h100 delms
c" _serial" (forget)
1 0 sersetflags
100 delms
4 0 0 0 (ioconn)
0 0 4 0 (ioconn)
...
It works great while I have all the Propforth fun on Port 24-26 the Port 23 greets me with:
PropForth v5.0 2012JAN09 14:30 0
Debian GNU/Linux 6.0 castle ttyS0
castle login:
The plan was to work through Propforth.HTML and add sections in the order of the turorials. The material builds on the previous material in more or less the order presented. Then we plan to bring forward all the old extensions that had been frozen during kernel development. These are the VGA support, Jupiter ACE, logging, etc. Also in the queue are the detailing instructions for user building (and testing) a custom kernel, and detailed instructions for converting user forth words into optimized paged (on the fly swap to memory) assembler.
Sal is already has a process for adding more props, and hanging devices on the ROMLESS prop pins, and launching drivers and applications. But he hasn't "dumbed it down" so I can duplicate it. So this is in hte queue, but we don't have well defined schedule, so we are going to take things as they come.
We think the hardware test bed configuration (hardware.txt) captures the least common denominator of propforth configurations and their intercommunication: standard protoboard, standard ethernet (spinneret), and standard ROMLESS prop. If one can get this to work, one can pretty much do everything that propforth does, and build from there.
We are also looking at the model where the prop talks to sensors and actuators, and data is offloaded to another processor for crunching (In this case, crunching means doing all the things for which the prop isn't the optimal choise, such as database, fancy user interfaces, heavy graphics processing, 64 bit or greater floating point, and general computational intensive applications.)
To this end we are looking at the GO language. Both GO and Propforth use communications channels similar to CAR Hoare's Communicating Sequential Processes (CSP). If we are lucky propforth will be able to connect to GO as easy as connecting to a remote cog. If we can talk to GO on a laptop, perhaps we port a Raspberry Pi , etc. But this is all conjecture at this point, and I don't know anyone using GO yet, although Google seems to think it has potential. Until we find evidence favoring other options, we are looking into Propforth on prop + GO on workstation as the "large" application model.
If anybody has insight on GO or related, please post!
Hi weibel
Thanks!
Would you like to share your set up on the linux end? And maybe pointer for folks having trouble with settle up router and firewall, etc?
The instructions assume the stuff beyond propforth is already set up, and this in not always the case, and I'm not so good at explaining network configuration.
http://code.google.com/p/propforth/issues/detail?id=140
Teraterm works fine on my widows box,
Anybody have info on setting up the terminal client on linux?
https://wiebel.scorpius.uberspace.de/space/blog/Out_of_Band_managing_for_my_Qnap_TS-109_Pro_II/
Ok, I'll try to explain
On the network side things are simple.
Netmask for ALL is /24 aka 255.255.255.0, gateway for all but the router is the router's IP 192.168.1.1
The core components are:
- A Router setup as 192.168.1.1 (providing dhcp for the 192.168.1.100+ Range)
- My Qnap NAS/Server (castle) setup with a static 192.168.1.10
- The Spinneret is configured at 192.168.1.5
- My Notebook via Wlan 192.168.1.23
It's the easiest way to let the spinneret be a part of your "real" net, as long as its private and you have a router, there are only very few security concerns. Having it this way there is no need at all to modify your routing or your IP addresses.Some ports are forwarded to the server (22,80 ...) also I can enable a port forwarding to the spinneret from the outside world if the need should arise, but as I have no authentication implemented in propforth nor is there any cryptography available, that's not always on.
At the Moment the Spinneret is fed by the Qnap server itself via USB shared with the propplug. So the develpement can be done completely remote. The main feature is the connection of Pin 26 and 27 to the native UART on the Mainboard of the QNAP. (you can find details in the links on my blog entry). Normally that UART is not meant to be used by the customer, so One need to open up the Case to get Debian running and anytime net access fails for whatever reason. Having an out-of-band management available is a real nice to have.
A few words about the remote programming:
As there are very few tools available to get things onto the propeller for an ARM enviroment and pyloader failed for some reason, I was on the hunt for some comfy solution. netcat or socat came in mind to tunnel the serial communication over the net, which works fine for "normal" data, but it turned out the timing needed by the loaders (bst, propellent, you name it) is much to harsh for my trusty "*cats" so I found usbip to be quite a sharp sword for that situation. It basically takes the Propplug (FTDI) from the USB Stack of the Server (QNAP) and let it pop up on the client side (my Laptop) which shows the FTDI Device right in dmesg so I had a locally available /dev/ttyUSB0 to work with. Made me quite happy.
I had some fear to get things together on the software side but after I decided to give propforth a try it really was just a walkt hrough the tests (now tutorial) and giving the thing a serial cog and some (ioconn) and ... done. Actually I was even a bit frustrated to see my plans of a week full of propeller coding gone in just an evening of propfoth.
I hope you don't mind me reusing this post as an further blog entry.
- wiebel
This triggered a BIG discussion, with a couple of very interesting impacts.
BACKSPACE AND DELETE
BS (delete character to left of cursor) and DEL (delete character to right of cursor) (on the input command line).
We talked about this today. The kernel supports Backspace BS ctl-h (h08),and does NOT support DEL (h7F). This is by design, for "simplest to get the job done", in this case a "kernel minimum interface". It is possible at add DEL, or to switch from BS to DEL; but this is non-trival and would have a high impact on all users and the kernel.; and so is left to individual users (but not advised in this manner, see below).
The recommendation is that DEL behavior be implemented in the LINE EDITOR EXTENSION package. I nominate weibel to drive the line editor extension effort.
LINE EDITOR
We are considering taking this "kernel minimum interface" a step further. If we have a line editor extension we could move all line input functions here. This would allow the basic input stream in the kernel to be faster and unneeded editing functions would no longer slow applications (as it is only needed by the developer, and not by application interfaces). So, when a line editor package is available, the basic kernel input would be a binary stream of characters, with no editing at all by default, and full line editing would be available in the development extensions. This would not be implemented until v5.1 at the earliest.
This fits in with the CSP channels for interfacing to GO. It looks like using GO on the PC to interface to propforth will allow using the linux or DOS shell command line editor to pre-process the string given to the forth prompt. The result will be that the kernel interface will be faster, and the line edit functions handed off to the PC. In cases of stand alone propforth, the same (full) line edit functionality will be available to the developer at no noticeable speed impact (more details to follow as development proceeds).
MEMORY MAP I/O
The last bit is a memory map I/O scheme. A typical virtual memory management scheme in forth is to have several (4 to 10) disk block size pages as a disk buffer. When a disk block is needed, it is read into memory. When it is altered, it is marked as "updated". When new page is to be read from disk, the oldest updated page is written back to disk before the new page is read. Also, a given page can be "flushed" back to disk when a set of modifications is complete. This allows minimal traffic for disk transfers, and gives the user and application the illusion that all data is in memory, regardless of size. In practice, it is very rare for a user or developer to notice delay from disk transfer bottleneck; we have to set up special conditions to show and test the impacts.
NOTE: the virtual memory scheme does NOT allow us to write programs on the prop as if we were writing for a x86 PC, and is not intended to.
Result: Issue 140 has been marked "Per Design". No changes will be made as the result of this issue, as it is not bug.
weibel has been nominated to start in on line editor, if he is interested. This could dovetail with Ron Suttcliffe's (file) editor work.
Sal is preparing the GO serial interface instruction for us, we might have something posted by next week (201200318)
_sttop, _stptr, r@, and key? to $C_stTop, $C_stPtr, RS@, and fkey? respectively.
I also tested the sd file system. However, I note that there appears to be no commands to remove a file.
How do we delete the last saved file?
NickL
Thanks Nick!
fsdrop removes the last file; actually it leaves the blocks intact, just sets the pointers back to the end of the previous file.
see tutorial-5.1 IP+Telnet.txt
fsdrop is the same command in SD as in EEPROM, the thought was one would (necessarily) be finished futzing with the EEPROM before moving on the to SD.
Actually, in this release, we have (EEPROM filesystem) OR (SD filesystem). Having SD filesystem on top of the EEPROM file system was unnecessary complexity for the kernel development, but having both is of course still possible.
for special project i need on the serial port ODD parity and a break signal.
I have realised it in PropForth 4.0 by changing PropForth.spin a little bit (around the label serentryPFA)
In PF 5.0 i didn't find ad hoc the point where i can change it.
Or any other suggestion to do this in a more clean way?
The break should be not too long max about 2 signs at 9600 baud rate (quite slow) .
Also i would need 8bit + ODD parity.
Any suggestions?
Markus
You shouldn't have to change the spin file. This would make your terminal for your development prompt wonky too.
If it were me, I would try just try hanging the serial off any pins below 28, and just set those particular I/O line as 9600, odd, . Then, write the break routine in forth (later optimize to assembler if needed), and have just the cog running that serial terminal do the break. Unless I'm missing something, I usually don't have to mess with the serial terminals.
Are you connecting direct, or do you need to go thru some transceiver hardware?
I understand that i can do the break in Forth / Assembler.
But is 9600baud 8bit ODD parity (=9bit + Stop) possible by default?
I haven't seen it PropForth 4.5
Markus
There is actually a big chunk of "part 2" documentation for advanced users to modifying the default kernel functions. We left this off at the time in favor of getting the release out sooner. We thought there would be time before the advanced questions. Since the documentatin is to be driven by user requests, I guess we're starting the advanced sections now.
I will open an issue to add the preoptimzed source for serial.f. This will also trigger a set of optimization instructions, and eventually need to include instructions to cover the full set of optimizations. It will take some time, but we can start with serial.f and use it in the examples.
Issue 142 has been added. This one might take a while, we'll try to get you going as quick as possible.
I thinks all this serial stuff will be interesting for others, too.
I will wait patiently for the serial.f docs..
Markus
Where is Forth source file for PropForthDevKernel and PropForthEEpromKernel and PropForthSDKernel?
I was looking for all of the .f files the other day - it is under the kernels directory in the release package
C:\Spin-PASM\V5.0\kernels\BootKernel\PropForthKernel.f
C:\Spin-PASM\V5.0\kernels\BootKernel\BootOptimizeKernel\BootOptimizeDevKernel\PropForthDevKernel.f
From these kernels, it appears you can build the individual specific kernels by adding in the needed .f files in these directories.
There are .SPIN versions of a few different kernels provided but anything specific appears to require building from the pieces you want to include.
I haven't had time to dig into the kernel much more than this. It's on my stack of things to do. That daytime job keeps getting in the way!
@Caskaz,
What mindrobots said EXCEPT there is a whole bunch of stuff in the middle that we didn't document properly yet.
In order to generate the optimized kernels with the optimized files system included, there are a couple step that need to happen.
See
tutorial-8.x aaaaa.txt
The tutorials section 8 are the EXACT STEPS Sal uses to regenerate the spin files, and then these feed back into the the regression tests at 1.1 to ensure that everything works.
IF you can execute ALL the section 8 tests, you can regenerate the kernels. If you skip any steps, success is not guaranteed.
The way it works (rule of thumb) is:
When you make changes to the kernel (spin files) if you can run the regression suite, and regenerate the kernel AGAIN and get the exact same files, you know everything probably works as you want it.
BUT - there is a new step to make the optimized spin image files. The word is spinImage. This word is very touchy and right now can only be run once, as it has a stack error when it finishes.
This is an easy fix, but involves a code change, and we didn't want to delay the show for another month since the Manual regression cycle takes (me) a long time.
The doc for this is part of the answer for Markus. The docs are the hardest part, we are hoping userrs will post issues, we will create new sections to propforth.html in response to those issues, and users will review the results. After a couple times, users can add new section to the documentation, and the the community handle the propforth.html as a living document.
The next release will contain support for the automated regression suit, and should make this whole process more transparent and within the grasp of more users.
SERIAL is necessarily built into the kernel, but we tend to use it all over the place in various (modified) forms. To allow the default SERIAL to be present in the kernel , and to allow modification to the kernel default at the same time, SERIAL is a loadable module.
There are two parts the the serial function: _serial and serial
The "internal" part is in the definition _serial (with an underscore). This does that internal kernel operation for serial communications. Generally, we don't want to call _serial or any of its subfunctions directly.
The "external" part is in the definition serial (with no underscore). This is the function the user or application calls to interface to the function.
The external word serial is the "interface", this is the word "packages up" the function and is how to get at _serial.
INTERNAL _serial
The high level source code for _serial is in
..\kernels\BootKernel\BootOptimizeKernel\
PropForthBootOptimzeAsmSrc.f
Rename file PropForthBootOptimzeAsmSrc.f and modify it as necessary for your particular needs.
This is actually assembler code (and was based on forth definitions in previous versions). This serial code has been optimized to the extent that it is no longer useful to go back to a high forth version for this function.
serial assembler code starts at line 775 actually at label:
build_BootOpt :rasm
serial assembler code ends at line 1104
;asm _serial
EXTERNAL serial
The high level source code for serial is in
..\kernels\BootKernel
PropForthStartKernel.f
The are some serial related constants at lines 54 through 60
The high level forth definition for serial is at line 2459
what serial does:
1) changes baud to number of cock cycles
2) takes the string to be displayed in cog? and sets it up
3) takes cog and marks it as no longer available (4 state nc!)
4) sets flags (HC08 is 1 done expand CRFL)
5) set break length to 0
6) starts _serail
INTERFACE to _serial VIA serial
Please notice the the difference between _serial and serial is
A) _serial take number of clocks per bit
see ..\kernels\doc\tutorials
tutorial-3.2 Serial Loopback.txt
For instructions how to start a serial connection
DOCUMENTATION EXPERIMENT
We are hoping that the user community will contribute to the documentation. The idea is that as each user question is resolved, the user that receives the answer helps us "write it up" such that other folks can understand it, and this gets added to the PROFORTH.html document.
@Markus - Please give this a look, and see if this gets you any further along. Please ask more questions, we will work with you till you feel you understand the functions sufficiently to do what you want.
If Markus (and the rest of us) can help us write up the documentation for this function to ensure that it is sufficiently clear and complete, Sal will add to PROPFORTH.html. We want to give this "user question driven" documentation model a try, to off-load Sal and limit effort to questions that are have been asked. (Trying to anticipate every possible question didn't work out previously).
EDIT - Started a page to capture the draft for the section in propforth.html on serial
http://code.google.com/p/propforth/wiki/SERIAL
I re-write 2_wire_LCD for PF5.
Wow! Looks like you've already figured out the base 64 encoding for the assembler code. Good work.
I never did set this up last time, I could not find a transistor you used in your circuit. Is there an alternate version with more common parts? I was thinking of trying something like this
http://www.rentron.com/Myke1.htm http://sites.google.com/site/zoranrilak/drive-an-hd44780-lcd-with-just-two-wires
Would that work? I'd like to test your code and add it to the extensions list.
I think any NPN-transistor is ok.
Curcuit of refered HTML need different code. This use shift resister.
My curcuit use counter(TC4040).
Myke Predko's curcuit is less parts than mine.
I will write code for this curcuit.
Maybe it don't need assembler word
I re-write A/D convert for PF5.
fl hex \ a cog special register [ifndef ctra h1F8 wconstant ctra ] [ifndef frqa h1FA wconstant frqa ] [ifndef phsa h1FC wconstant phsa ] 0 wconstant adcpin 1 wconstant fbpin variable result \ a_adc A/D-conversion ( result_addr cycles -- ) lockdict create a_adc forthentry $C_a_lxasm w, h121 h113 1- tuck - h9 lshift or here W@ alignl h10 lshift or l, z2WiZuB l, z1SyLI[ l, z2Wi[3B l, z1SyLI[ l, z2WiPak l, z20iP[V l, z3riP[V l, z2WiPiv l, z24iPeE l, z20iPmD l, z8FPfW l, z1SV04P l, 0 l, 0 l, freedict : sigma_delta 1 frqa COG! fbpin dup pinout 9 lshift h24000000 or adcpin or ctra COG! \ A/D start Sampling rate 1kHz result 13880 a_adc ; : adc c" sigma_delta" 5 cogx begin result L@ . cr A delms \ 10msec 0 until ; decimal { fl hex [ifndef phsa h1FC wconstant phsa ] \ sigma-delta A/D conversion \ ( n1 n2 -- ) n1:result address n2:cycles build_BootOpt :rasm \ read interval mov __interval , $C_stTOS spop \ read A/D result address mov __result , $C_stTOS spop mov $C_treg1 , cnt add $C_treg1 , __interval __1 waitcnt $C_treg1 , __interval mov $C_treg2 , phsa sub $C_treg2 , $C_treg3 add $C_treg3 , $C_treg2 wrlong $C_treg2 , __result jmp # __1 __interval 0 __result 0 ;asm a_adc }You are the best. A/D in assembler on the final PF kernel has been a landmark goal for years.