Congratulations Brian on winning the challenge. Though time was short you have completed your project (and it was all about the projects!) totally in Forth without a skerrick of assembler and neatly coded and practical too. Any other Grizzly Adam'es out there will no doubt follow your 21st century pioneering closely
For all the rest of the entrants and ones who may not have gotten an entry in, well done! Remember that you have only a week left to submit an entry into the "Forth of the Forth" (in December) challenge. If there are only four contestants then they will be guaranteed to receive a prize. If your project needs much more time than that then don't despair as I intend to hold this "Forth of the Forth" challenge in 2013 for the 4th of the 4th.
BTW, someone mentioned that Tachyon's auxiliary serial routines were coded in assembler but that can't be true because it doesn't use another cog and there isn't room in the kernel for it. However they work similar to the PBASIC version but up to 250K baud.
[FONT=courier new]pub SEROUT ( data pin -- )
MASK DUP OUTSET SWAP \ ensure pin is an output (very first time perhaps)
2* \ Include start bit (0)
baudcnt @ DELTA \ setup delay and wait
9 FOR WAITCNT SHROUT NEXT \ data bits
DROP WAITCNT OUTSET \ final stop bit
;
\ Bit-bashed Serial input - receive asynchronous data
pub SERIN ( pin -- data )
MASK DUP INPUTS DUP
baudcnt @ 2/ SWAP WAITPNE DELTA
baudcnt @ DELTA \ delay to sample 1 bit later in 1st data bit
0 8 FOR SHRINP WAITCNT NEXT
NIP #24 SHR \ right justify 8-bit data
;
[/FONT]
First off, Loopy gets a more than honorable mention for his determination in attempting this while also learning Forth. Plus his dogged tenacity to dig through code and words looking for that elusive half-duplex serial connection!! Let's cheer him on for the Forth of December contest because when you search your heart, you really know you too want a set of printed chopsticks and want to see the video!!
Thank you all for the praise ... but I sure hope has room for the other people who deserve a share of the glory. When I came to Forth on the Propeller I had been FORTH-critter for about 15-20 years ... now WHOA ... before anyone starts muttering 'ringer' let me explain that this represented 8-12 months experience 20 times over! I restarted learning Forth "the right way!" so many times that I lost count.
Along came PropForth and Doug (Braino) became something of a mentor and Prop Forth started me on the road to learning Forth the right way for real. Last summer along comes PeterJ with this new thing called Tachyon. In Peter I found something of a kindred soul whose wants and needs for embedded Forth seem to run along with mine ... he graciously assumed the role as mentor and learned how to criticize my un-Forthlike way of coding without bruising my ego too much. (This is why I was so pleased that Rick's use of the word 'elegant' about my code ... SEE! Peter ... all those middle of the night emails actually bore fruit!) Also along the way I struck up a correspondence with one of our resident Forth gurus, Nick Lordi. We were collaborating on a project until Hurricane Sandy took out his basement and much of the first floor. We had finished up the hardware and I am working on extending Nick's software and plan to enter it in Peter's challenge in both our names.
Too numerous to mention by name is our Greek chorus of Forth-lurkers who have contributed countless tidbits to my Forth education.
And last ....... but far from least KenG and the band at Parallax who gave us this nurturing environment to grow this crazy virtual family in cyberspace.
That might have been me, sort of. I wasn't referring to the auxiliary routines at that point but the main routines....
Yes, but I think it was in relation to application programming and using "assembler" or some mangled version thereof which is even worse for readability and just plain cog hungry. The code I saw looked scary and just taking the opportunity to show any other non-Forthers that it doesn't have to be complicated and it's just as simple though faster than the PBASIC version. I think there is some Spin code that's equivalent but it's only good to about 19.2K baud.
BTW, someone mentioned that Tachyon's auxiliary serial routines were coded in assembler but that can't be true because it doesn't use another cog and there isn't room in the kernel for it. However they work similar to the PBASIC version but up to 250K baud.
Peter, Tachyon's performance is very impressive. Your inner loops for SERIN and SEROUT are very compact. Someday I'll have to look at how you implemented SHROUT and SHRINP. My implementation of the SHROUT functionality contains a lot of stack manipulation.
...and the WINNER is just by the slightest edge...BRIAN and his Smart Shallow Well Pump Timer
Congratulations to Brian! About two weeks ago he was visiting Parallax for a day and we went to lunch at Lucille's BBQ where he told us everything about the Forth project. We learned about some of the well pump/solar design surrounding his home at the same time.
Brian, contact Jim and I via e-mail and let us know what kind of goodies you'd like. I promised a Propeller Human Interface Board (just coming off production line now, pending testing and kitting) but if you prefer something different that's also fine.
Cogratulations to Brian....
The differences in asynchronous serial port infrastructure on the various Forths on Propeller are quite significant.
PropForth does NOT have a Forth stack machine and an asynch serial port working at the same time on one cog. If that model could be done or if a dedicated cog serial driver could handle 8 or more serial configurations and multiplex to other cogs, you would have a quite useful model.
I guess that 3mbits over Bluetooth is useful if you use Bluetooth. My own interests lie in hardware and impedances in hardwire slow things down.
Prof Braino says that he and Sal 'tripped over a wire' in their speed tests. But it just could be his way of saying that he never considered wireless applications that offer higher baud rates than wire might ever do. Rather amusing..........
And all that speed may be useful in some contexts, but as I have demonstrated - if you can't get another serial port up and running, what's the point of it all?
Documentation and tutorials are about helping the novice notice what is important, not just working papers for your own studies. Andy Lindsay seems to excel at such. Follow his lead.
I have updated the code files on my original project post - Message #66. The new code has some extensive refactoring and additions... as I said earlier debouncing pushbuttons in an 80 MHz prop running Peter's blistering achy on is never a dull moment. I used some strategically placed 100-300 msec pauses. Optimizing was a real treat!
I have stack problem in two places that may take some heavy sweat. Its great that Tachyon doesn't crash out for stack over/under flow .... however the price is longer time to diagnose stack problems .... sigh
I have updated the code files on my original project post - Message #66. The new code has some extensive refactoring and additions... as I said earlier debouncing pushbuttons in an 80 MHz prop running Peter's blistering achy on is never a dull moment. I used some strategically placed 100-300 msec pauses. Optimizing was a real treat!
I have stack problem in two places that may take some heavy sweat. Its great that Tachyon doesn't crash out for stack over/under flow .... however the price is longer time to diagnose stack problems .... sigh
Are you expecting us to work too! I had to click 3 times and scroll instead of just clicking once to find that post!!!!
THREE WHOLE CLICKS .... WoW ... is it possible to incur hernia doing that?
Poor Peter he may have to wait to get this, yet another, code update fixing two simple and one spectacular stupidity on my part. All this wonderful improvement caan be had at the trivial cost of ONE CLICK
Peter, Tachyon's performance is very impressive. Your inner loops for SERIN and SEROUT are very compact.
Someday I'll have to look at how you implemented SHROUT and SHRINP.
My implementation of the SHROUT functionality contains a lot of stack manipulation.
from Tachyon V2.1 ... the lowest level is always ASM ;-)
{ *** SERIAL I/O OPERATORS *** }
{
To maximize the speed of I/O operations especially serial I/O such as ASYNCH, I2C and SPI etc there are special
operators that avoid pushing and popping the stack and instead perform the I/O bit by bit and leave the
latest shifted version of the data on the stack.
}
' Assembles with last bit received as msb - needs SHR to right justify if asynch data
' SHRINP ( iomask dat -- iomask dat*2 )
SHRINP shr tos,#1
test tos+1,INA wz
if_nz or tos,msb
jmp #doNEXT
{ This is optimized for when you are sending out multiple bits
as in asynchronous serial data or I2C
Shift data one bit right into output via iomask - leave mask & shifted data on stack (looping)
400ns execution time including bytecode read and execute }
' SHROUT ( iomask dat -- iomask dat/2 )
SHROUT shr tos,#1 wc ' Shift right and get lsb
muxc OUTA,tos+1 ' reflect state to output
jmp #doNEXT
from Tachyon V2.1 ... the lowest level is always ASM ;-)
{ *** SERIAL I/O OPERATORS *** }
{
To maximize the speed of I/O operations especially serial I/O such as ASYNCH, I2C and SPI etc there are special
operators that avoid pushing and popping the stack and instead perform the I/O bit by bit and leave the
latest shifted version of the data on the stack.
}
' Assembles with last bit received as msb - needs SHR to right justify if asynch data
' SHRINP ( iomask dat -- iomask dat*2 )
SHRINP shr tos,#1
test tos+1,INA wz
if_nz or tos,msb
jmp #doNEXT
{ This is optimized for when you are sending out multiple bits
as in asynchronous serial data or I2C
Shift data one bit right into output via iomask - leave mask & shifted data on stack (looping)
400ns execution time including bytecode read and execute }
' SHROUT ( iomask dat -- iomask dat/2 )
SHROUT shr tos,#1 wc ' Shift right and get lsb
muxc OUTA,tos+1 ' reflect state to output
jmp #doNEXT
Well we certainly hope that at the lowest level it is assembler!!!!!!!!! (or do you know a different way??)
In this case it is the way it is done after analyzing where the overheads are and then crafting instructions to handle these common tasks.
Well we certainly hope that at the lowest level it is assembler!!!!!!!!! (or do you know a different way??)
In this case it is the way it is done after analyzing where the overheads are and then crafting instructions to handle these common tasks.
Hi Peter - I didn't want to join the 'pure Forth vs. ASM' war ...
I love reading your code and understanding the low levels. And I fully agree on doing the low level in ASM ... what else :-)
I just wantet to point Dave Hein to the code he was asking for.
Just 7 lines of PASM to get this speed improvement for all the serial protocols - this is great.
Markus
Hi Peter - I didn't want to join the 'pure Forth vs. ASM' war ...
I love reading your code and understanding the low levels. And I fully agree on doing the low level in ASM ... what else :-)
I just wantet to point Dave Hein to the code he was asking for.
Just 7 lines of PASM to get this speed improvement for all the serial protocols - this is great.
Markus
Unfortunately I sometimes come across as being very serious but in fact I have a good chuckle and will not hold back from digging an elbow into the unfortunate someones ribs if the opportunity affords itself
But many times I'm actually replying to the forum to that casual reader who comes across the post and may get the wrong idea perhaps. Pedantic and didactic perhaps but hardly ruffled.
Sometimes pedantic is the only way to help someone notice something they just can recognize. Still the friendliness of the Parallax Forums seems to eventually carry the day.
And the chopstick printer project lives on. The store called 30 minutes ago to tell me that my inkjet cartrige has arrived.
Meanwhile, I have been doing two exercises in pursuit of how to verify that the PropForth will really communicate sucessfully with bi-directional half-duplex serial. Everyone thinks it can be done with either Tachyon or PropForth, but I am not so sure.
These exercises are in full-duplex to make sure I can discover problems in a straight forward configuration before tackling the more exotic bi-directional half-duplex with a jump form 3.3v logic to 5.0v logic.
For the first exercise,
I have set up a Dumb Terminal using a Propeller Demo Board, a VGA, and a keyboard with PockeTerm software from Briel Computers. It is a VT100 emulation program.
And then I have used my original Propeller Demo Board working via Minicom and loaded with PropForth v5.03 to communicate with the Dumb Terminal through its provided serial driver. That exercise was quite worthwhile. Channels are open and working in both directions.
Both directs are adequately communicating, but it appears that PropForth filters some of the full range of ASCII. At this point, it seems to handle incoming and outgoing okay. I am having difficulty with Carriage returns and Line feeds. The connectionis a bit tricky because if you wire it backwards, both the Dumb Terminal and your Minicom with faithfully echo your own transmission. You think you have a good setup, but nothing is working in full duplex.
But the second exercise simple has the Dumb Terminal connect independent to a cog with the Forth machine running and it is quite obvious I am not get what should be a faithful loopback.
I need to investigate this more to determine what's what. It seems a bit silly to not allow all 256 bytes to transfer. I might even be imagining this. But at this point I need to use backspace to clear the entire screen and I get stuck at the bottom of the screen in the Dumb terminal as cursor control in not availaable. Also, columns of new lines do not line up.
It could be the configuration of PockeTerm as well, but it works fine in a hardwire loopback to itself. So I think not.
But the second exercise simple has the Dumb Terminal connect independent to a cog with the Forth machine running and it is quite obvious I am not get what should be a faithful loopback.
You should be able to use the exact steps from the tutorial, and only use one cog instead of two. If you could post your steps and results we could take a look.
I need to investigate this more to determine what's what. It seems a bit silly to not allow all 256 bytes to transfer. I might even be imagining this. But at this point I need to use backspace to clear the entire screen and I get stuck at the bottom of the screen in the Dumb terminal as cursor control in not available. Also, columns of new lines do not line up.
It could be the configuration of PockeTerm as well, but it works fine in a hardwire loopback to itself. So I think not.
Can you test with Minicon in place of PocketTerm, that is swap them? I did not notice this type of issue.
Could you give more detail on what you mean by 256 bytes? The buffer is only 1 character, but it is so fast the buffer is always cleared and empty before the next character is ready. ( coming in at 9600, and it has plenty of time to wait going out) Is it the recieve buffer on Pocket Term overflowing? Just need to to tell propforth to stop sending too many chars at once?
You should be able to use the exact steps from the tutorial, and only use one cog instead of two. If you could post your steps and results we could take a look.
Can you test with Minicon in place of PocketTerm, that is swap them? I did not notice this type of issue.
Could you give more detail on what you mean by 256 bytes? The buffer is only 1 character, but it is so fast the buffer is always cleared and empty before the next character is ready. ( coming in at 9600, and it has plenty of time to wait going out) Is it the recieve buffer on Pocket Term overflowing? Just need to to tell propforth to stop sending too many chars at once?
@ Prof Braino,
I won't bother to respond to all this in the Forum as there are some things that you seem not to understand. I am writing up something that you can follow item by item, like your tutorials.
I am not working through the Serial Loopback Tutorial. I am extending what it does to real hardware. ASCII code is made up of 256 bytes. The majority of them are either special charcters or not visible. It appears that the PropForth either may not be passing all the codes, only the visible ones or is trapping something like Esc sequences in its own way.
I don't understand it and am not sure how I will come to understand it, so you are going to have investigate as well. This has been a good week's worth of work for me.
I have no idea of what the ANSI terminal text extension does. I just use what's in the /docs in .zip file for v5.03.
( *** PBASIC STYLE SERIAL I/O *** )
\ Set the baudrate for SEROUT and SERIN
pub SERBAUD ( baud -- )
CLKFREQ SWAP / baudcnt !
;
\ Bit-bashed Serial output - transmit asynchronous data
pub SEROUT ( data pin -- )
MASK DUP OUTSET SWAP
$100 OR 2* \ ( mask data ) stop and start bits
#10 baudcnt @ DELTA
FOR SHROUT WAITCNT NEXT
2DROP
;
\ Bit-bashed Serial input - receive asynchronous data
pub SERIN ( pin -- data )
MASK DUP INPUTS DUP
baudcnt @ 2/ SWAP WAITPNE DELTA
baudcnt @ DELTA \ delay to sample 1 bit later in 1st data bit
0 #8 FOR SHRINP WAITCNT NEXT
NIP #24 SHR \ right justify 8-bit data
;
\ Change output device back to the default CONSOLE
pub CON
uemit W~
;
both set the io direction in the first line, so can be used on the same pin.
EMIT can easily be revectored to use SEROUT and CON reverts back to console IO.
In your case I understand you would read until you get the "<" then send a command,
switch to read again until next "<" ... nothing special here
on PropFoth I can not comment because of no experience ...
maybe it would be very interresting to have a propforth and a tachyon version ...
with the later I can assist a very little ...
MJB
There is no real rush. I am just trying to get some real basis in the features I most desire to use. Serial ports is one of them. There is no any rush to finish the chopstick printer either, though the project has really helped me find out how a project evolves and teaches me Forth.
After being frustrated and looking around, I see there are several VT100 emulators for the Propeller. So I can switch to another one if I have the wrong one. Maybe tomorrow. This is all part of the learning curve.
Apparently everyone has decided to support some Esc sequences and not others. Apparently PropForth also has an additional module of ANSi characters not normally used. It didn't look like what I need. What I need is the ones that are always in use. By everyone, I mean both the developers of the various versions of Forth and the developers of the VT100 applications. Everyone seems rather independent, so it is all case-by-case. I was hoping that I might quickly find out why some often used reports in PropForth don't display well, it isn't going to happen.
I suppose I should first hook up the VT100 directly to the notebook in Putty with VT100 emulation and see how the terminal works with software that is really trying to provide a complete emulation. That is yet another project.
I suspect this has something to do with Esc sequences for cursor position Tabs, Linefeeds, and Carriage Returns. Also, I seem to be missing a Delete in some situations. I am too tired to think about it and I am sure I will be fresher tomorrow.
ASCII code is made up of 256 bytes. The majority of them are either special charcters or not visible.
yes. I heard this rumor when I implemented the ANSI escape codes extension a couple years back.
It appears that the PropForth either may not be passing all the codes, only the visible ones or is trapping something like Esc sequences in its own way.
Incorrect. But close. Propforth passes the values fine (unless you changed it, which you didn't). When a dumb terminal or emulator is behaving normally, it does what you observe. Please look here http://ascii-table.com/ansi-escape-sequences-vt-100.php
I don't understand it
Thats ok. At least you know what you don't know. Read the materials and this will go away.
and am not sure how I will come to understand it,
I'm sure if you just read the materials and then read it again more carefully it will come to you
so you are going to have investigate as well.
Done. Please see the above link, or MJB's posted code it is the same thing more or less
I have no idea of what the ANSI terminal text extension does.
Its easier when you read it. and try the examples.
I would guess propforth is working as it always has, the characters are getting through ok, and your terminal is behaving correctly; but you didn't yet set up the terminal to handle the codes you are sending the way you want to handle them.
Since I am using the 'cog? report' and the 'words report' as format tests... I am strictly looking at what those output and why both become messed up.
These two items have shown themselves to be very important to anyone using PropForth interactively.
Working on studying Esc codes that are not in actual use while ignoring reports that I need is a rather wasteful approach. And again I am wondering where 'the examples' are.. if not in the PropForth.htm or the tutorials or the actual source code, then where o where.
I do understand that PropForth provides extension for such Escape codes - but I am not sure if the context applies to a Dumb Terminal or solely to the Juptiter Ace project with the same Propeller providing keyboard and VGA or to just about everything.
Your above excerpts of my text are rather interesting. Wrong interpretation of my posting. I'll try to write better and try to write less.
You have put the focus on ANSI Esc sequences while I am just trying to find the underlying choices made in standard PropForth to support its more important multi-line, multi-column reports. These all are fine in Minicom, but not in the two VT100 emulators I have. I've already determined that one of the two is not appropriate for PropForth. The other one shows promise as at least the LF problem has gone away.
You might just consider that I thought I might be contributing so useful information about using a Propeller-based VT100 solution to PropForth.
It doesn't really matter as I pretty much can work it out on my own.
Comments
For all the rest of the entrants and ones who may not have gotten an entry in, well done! Remember that you have only a week left to submit an entry into the "Forth of the Forth" (in December) challenge. If there are only four contestants then they will be guaranteed to receive a prize. If your project needs much more time than that then don't despair as I intend to hold this "Forth of the Forth" challenge in 2013 for the 4th of the 4th.
BTW, someone mentioned that Tachyon's auxiliary serial routines were coded in assembler but that can't be true because it doesn't use another cog and there isn't room in the kernel for it. However they work similar to the PBASIC version but up to 250K baud.
[FONT=courier new]pub SEROUT ( data pin -- ) MASK DUP OUTSET SWAP \ ensure pin is an output (very first time perhaps) 2* \ Include start bit (0) baudcnt @ DELTA \ setup delay and wait 9 FOR WAITCNT SHROUT NEXT \ data bits DROP WAITCNT OUTSET \ final stop bit ; \ Bit-bashed Serial input - receive asynchronous data pub SERIN ( pin -- data ) MASK DUP INPUTS DUP baudcnt @ 2/ SWAP WAITPNE DELTA baudcnt @ DELTA \ delay to sample 1 bit later in 1st data bit 0 8 FOR SHRINP WAITCNT NEXT NIP #24 SHR \ right justify 8-bit data ; [/FONT]Congratulations Brian! Very good work.
Congrats to all. Loopy's my newest forum hero. He did a commendable job in many respects, especially with his many glib and informative postings during the contest while the clock was ticking. HUZZAH indeed! http://forums.parallax.com/showthread.php?143900-WINNER!!-Forthers-Thanksgiving-Challenge-it-s-all-about-the-projects-baby!!!&p=1144705&viewfull=1#post1144705
And all the other contestants are winners in my book!
That might have been me, sort of. I wasn't referring to the auxiliary routines at that point but the main routines....
Along came PropForth and Doug (Braino) became something of a mentor and Prop Forth started me on the road to learning Forth the right way for real. Last summer along comes PeterJ with this new thing called Tachyon. In Peter I found something of a kindred soul whose wants and needs for embedded Forth seem to run along with mine ... he graciously assumed the role as mentor and learned how to criticize my un-Forthlike way of coding without bruising my ego too much. (This is why I was so pleased that Rick's use of the word 'elegant' about my code ... SEE! Peter ... all those middle of the night emails actually bore fruit!) Also along the way I struck up a correspondence with one of our resident Forth gurus, Nick Lordi. We were collaborating on a project until Hurricane Sandy took out his basement and much of the first floor. We had finished up the hardware and I am working on extending Nick's software and plan to enter it in Peter's challenge in both our names.
Too numerous to mention by name is our Greek chorus of Forth-lurkers who have contributed countless tidbits to my Forth education.
And last ....... but far from least KenG and the band at Parallax who gave us this nurturing environment to grow this crazy virtual family in cyberspace.
Congratulations to Brian! About two weeks ago he was visiting Parallax for a day and we went to lunch at Lucille's BBQ where he told us everything about the Forth project. We learned about some of the well pump/solar design surrounding his home at the same time.
Brian, contact Jim and I via e-mail and let us know what kind of goodies you'd like. I promised a Propeller Human Interface Board (just coming off production line now, pending testing and kitting) but if you prefer something different that's also fine.
Ken Gracey
Thanks again for for putting a pot-o-gold at the end of my contest rainbow!
Just to warn you, there are more project challenges in the wings!!!
The differences in asynchronous serial port infrastructure on the various Forths on Propeller are quite significant.
PropForth does NOT have a Forth stack machine and an asynch serial port working at the same time on one cog. If that model could be done or if a dedicated cog serial driver could handle 8 or more serial configurations and multiplex to other cogs, you would have a quite useful model.
I guess that 3mbits over Bluetooth is useful if you use Bluetooth. My own interests lie in hardware and impedances in hardwire slow things down.
Prof Braino says that he and Sal 'tripped over a wire' in their speed tests. But it just could be his way of saying that he never considered wireless applications that offer higher baud rates than wire might ever do. Rather amusing..........
And all that speed may be useful in some contexts, but as I have demonstrated - if you can't get another serial port up and running, what's the point of it all?
Documentation and tutorials are about helping the novice notice what is important, not just working papers for your own studies. Andy Lindsay seems to excel at such. Follow his lead.
http://forums.parallax.com/showthread.php?138399-Propforth-5.0-is-available-for-download&p=1145119&viewfull=1#post1145119
I have stack problem in two places that may take some heavy sweat. Its great that Tachyon doesn't crash out for stack over/under flow .... however the price is longer time to diagnose stack problems .... sigh
We're such a happily dysfunctional little family sometimes!!! :0)
Thanks for taking one for the team by providing that link, Peter!!
Poor Peter he may have to wait to get this, yet another, code update fixing two simple and one spectacular stupidity on my part. All this wonderful improvement caan be had at the trivial cost of ONE CLICK
from Tachyon V2.1 ... the lowest level is always ASM ;-)
{ *** SERIAL I/O OPERATORS *** } { To maximize the speed of I/O operations especially serial I/O such as ASYNCH, I2C and SPI etc there are special operators that avoid pushing and popping the stack and instead perform the I/O bit by bit and leave the latest shifted version of the data on the stack. } ' Assembles with last bit received as msb - needs SHR to right justify if asynch data ' SHRINP ( iomask dat -- iomask dat*2 ) SHRINP shr tos,#1 test tos+1,INA wz if_nz or tos,msb jmp #doNEXT { This is optimized for when you are sending out multiple bits as in asynchronous serial data or I2C Shift data one bit right into output via iomask - leave mask & shifted data on stack (looping) 400ns execution time including bytecode read and execute } ' SHROUT ( iomask dat -- iomask dat/2 ) SHROUT shr tos,#1 wc ' Shift right and get lsb muxc OUTA,tos+1 ' reflect state to output jmp #doNEXTWell we certainly hope that at the lowest level it is assembler!!!!!!!!! (or do you know a different way??)
In this case it is the way it is done after analyzing where the overheads are and then crafting instructions to handle these common tasks.
Hi Peter - I didn't want to join the 'pure Forth vs. ASM' war ...
I love reading your code and understanding the low levels. And I fully agree on doing the low level in ASM ... what else :-)
I just wantet to point Dave Hein to the code he was asking for.
Just 7 lines of PASM to get this speed improvement for all the serial protocols - this is great.
Markus
Unfortunately I sometimes come across as being very serious but in fact I have a good chuckle and will not hold back from digging an elbow into the unfortunate someones ribs if the opportunity affords itself
But many times I'm actually replying to the forum to that casual reader who comes across the post and may get the wrong idea perhaps. Pedantic and didactic perhaps but hardly ruffled.
Meanwhile, I have been doing two exercises in pursuit of how to verify that the PropForth will really communicate sucessfully with bi-directional half-duplex serial. Everyone thinks it can be done with either Tachyon or PropForth, but I am not so sure.
These exercises are in full-duplex to make sure I can discover problems in a straight forward configuration before tackling the more exotic bi-directional half-duplex with a jump form 3.3v logic to 5.0v logic.
For the first exercise,
I have set up a Dumb Terminal using a Propeller Demo Board, a VGA, and a keyboard with PockeTerm software from Briel Computers. It is a VT100 emulation program.
http://www.brielcomputers.com/wordpress/?cat=25
And then I have used my original Propeller Demo Board working via Minicom and loaded with PropForth v5.03 to communicate with the Dumb Terminal through its provided serial driver. That exercise was quite worthwhile. Channels are open and working in both directions.
Both directs are adequately communicating, but it appears that PropForth filters some of the full range of ASCII. At this point, it seems to handle incoming and outgoing okay. I am having difficulty with Carriage returns and Line feeds. The connectionis a bit tricky because if you wire it backwards, both the Dumb Terminal and your Minicom with faithfully echo your own transmission. You think you have a good setup, but nothing is working in full duplex.
But the second exercise simple has the Dumb Terminal connect independent to a cog with the Forth machine running and it is quite obvious I am not get what should be a faithful loopback.
I need to investigate this more to determine what's what. It seems a bit silly to not allow all 256 bytes to transfer. I might even be imagining this. But at this point I need to use backspace to clear the entire screen and I get stuck at the bottom of the screen in the Dumb terminal as cursor control in not availaable. Also, columns of new lines do not line up.
It could be the configuration of PockeTerm as well, but it works fine in a hardwire loopback to itself. So I think not.
I'll keep you updated as I discover more.
Can you you give any detail on this? The ANSII_testminal Text support extension
http://propforth.googlecode.com/files/ANSI%20Escape%20Sequences20120704-1652.f
had no such problem when I tested it. Aside from the number base designation formatting, it has not changed since it was written.
...
You should be able to use the exact steps from the tutorial, and only use one cog instead of two. If you could post your steps and results we could take a look.
Can you test with Minicon in place of PocketTerm, that is swap them? I did not notice this type of issue.
Could you give more detail on what you mean by 256 bytes? The buffer is only 1 character, but it is so fast the buffer is always cleared and empty before the next character is ready. ( coming in at 9600, and it has plenty of time to wait going out) Is it the recieve buffer on Pocket Term overflowing? Just need to to tell propforth to stop sending too many chars at once?
@ Prof Braino,
I won't bother to respond to all this in the Forum as there are some things that you seem not to understand. I am writing up something that you can follow item by item, like your tutorials.
I am not working through the Serial Loopback Tutorial. I am extending what it does to real hardware. ASCII code is made up of 256 bytes. The majority of them are either special charcters or not visible. It appears that the PropForth either may not be passing all the codes, only the visible ones or is trapping something like Esc sequences in its own way.
I don't understand it and am not sure how I will come to understand it, so you are going to have investigate as well. This has been a good week's worth of work for me.
I have no idea of what the ANSI terminal text extension does. I just use what's in the /docs in .zip file for v5.03.
here the serial io words from Tachyon
( *** PBASIC STYLE SERIAL I/O *** ) \ Set the baudrate for SEROUT and SERIN pub SERBAUD ( baud -- ) CLKFREQ SWAP / baudcnt ! ; \ Bit-bashed Serial output - transmit asynchronous data pub SEROUT ( data pin -- ) MASK DUP OUTSET SWAP $100 OR 2* \ ( mask data ) stop and start bits #10 baudcnt @ DELTA FOR SHROUT WAITCNT NEXT 2DROP ; \ Bit-bashed Serial input - receive asynchronous data pub SERIN ( pin -- data ) MASK DUP INPUTS DUP baudcnt @ 2/ SWAP WAITPNE DELTA baudcnt @ DELTA \ delay to sample 1 bit later in 1st data bit 0 #8 FOR SHRINP WAITCNT NEXT NIP #24 SHR \ right justify 8-bit data ; \ Change output device back to the default CONSOLE pub CON uemit W~ ;both set the io direction in the first line, so can be used on the same pin.EMIT can easily be revectored to use SEROUT and CON reverts back to console IO.
In your case I understand you would read until you get the "<" then send a command,
switch to read again until next "<" ... nothing special here
on PropFoth I can not comment because of no experience ...
maybe it would be very interresting to have a propforth and a tachyon version ...
with the later I can assist a very little ...
MJB
Eventually I will look into Tachyon.
There is no real rush. I am just trying to get some real basis in the features I most desire to use. Serial ports is one of them. There is no any rush to finish the chopstick printer either, though the project has really helped me find out how a project evolves and teaches me Forth.
After being frustrated and looking around, I see there are several VT100 emulators for the Propeller. So I can switch to another one if I have the wrong one. Maybe tomorrow. This is all part of the learning curve.
Apparently everyone has decided to support some Esc sequences and not others. Apparently PropForth also has an additional module of ANSi characters not normally used. It didn't look like what I need. What I need is the ones that are always in use. By everyone, I mean both the developers of the various versions of Forth and the developers of the VT100 applications. Everyone seems rather independent, so it is all case-by-case. I was hoping that I might quickly find out why some often used reports in PropForth don't display well, it isn't going to happen.
I suppose I should first hook up the VT100 directly to the notebook in Putty with VT100 emulation and see how the terminal works with software that is really trying to provide a complete emulation. That is yet another project.
I suspect this has something to do with Esc sequences for cursor position Tabs, Linefeeds, and Carriage Returns. Also, I seem to be missing a Delete in some situations. I am too tired to think about it and I am sure I will be fresher tomorrow.
( ANSI.fth ) TACHYON \ ********************************* ANSI TERMINAL SUPPORT ****************** 0 CONSTANT black 1 CONSTANT red 2 CONSTANT green 3 CONSTANT yellow 4 CONSTANT blue 5 CONSTANT magenta 6 CONSTANT cyan 7 CONSTANT white : ESC ( ch -- ) $1B EMIT EMIT ; : ESCB ( ch -- ) "[" ESC EMIT ; : ESCH ( ch -- ) "#" ESC EMIT ; : FG ( col -- ) "3" : COL ESCB "0" + EMIT "m" EMIT ; : BG ( col -- ) "4" COL ; : DHT "3" ESCH ; : DHB "4" ESCH ; : NARROW "5" ESCH ; : WIDE "6" ESCH ; : CUR ( cmd n -- ) "[" ESC SWAP : .PAR SWAP #10 .NUM EMIT ; : XY ( x y -- ) ";" SWAP CUR "H" .PAR ; : HOME "H" ESCB ; : ERSCN "2" ESCB "J" EMIT ; : ERLINE "2" ESCB "K" EMIT ; : CLS HOME ERSCN ; : CURSOR ( on/off -- ) "?" ESCB ." 25" IF "h" ELSE "l" THEN EMIT ; : PLAIN "0" : ATR ( ch -- ) ESCB "m" EMIT ; : REVERSE $37 ATR ; : BOLD $31 ATR ; : MARGINS ( top bottom -- ) $5B ESC SWAP ";" .PAR "r" .PAR ; : HLINE ( x y n -- ) >L XY L> : HORZ ( n -- ) FOR $C4 EMIT NEXT ; : VLINE ( x y n -- ) >L XY L> : VERT ( n -- ) FOR $B3 EMIT $0A EMIT $08 EMIT NEXT ; { found bug in ITEMS ---- fixed in rev120809.1620 } : BOX ( x3 y2 w1 h0 -- ) 4 ITEMS \ HORIZONTAL LINES 3 ITEM@ 2 ITEM@ XY $DA EMIT ( + TOP LEFT ) 1 ITEM@ 2 - HORZ 0 EMIT $BF EMIT ( TOP LINE + top right ) 3 ITEM@ 2 ITEM@ 0 ITEM@ + XY $C0 EMIT ( + bottom left ) 1 ITEM@ 2 - HORZ $D9 EMIT ( BOTTOM LINE + bottom right ) \ VERTICAL LINES 3 ITEM@ 2 ITEM@ 1+ XY 0 ITEM@ 1- VERT ( LEFT VERT ) 3 ITEM@ 1 ITEM@ + 1- 2 ITEM@ 1+ XY 0 ITEM@ 1- VERT \ $D9 EMIT ( bottom right ) ; : DEMO CLS 8 0 DO 10 I + 10 I + 20 10 BOX 2 +LOOP CR ; END { $BF = TOP RIGHT CORNER $C0 = BOTTOM LEFT $DA = TOP LEFT $D9 = BOTTOM RIGHT }This works for the terminal and by redirecting EMIT on any output or serial channelyes. I heard this rumor when I implemented the ANSI escape codes extension a couple years back.
Incorrect. But close. Propforth passes the values fine (unless you changed it, which you didn't). When a dumb terminal or emulator is behaving normally, it does what you observe. Please look here http://ascii-table.com/ansi-escape-sequences-vt-100.php
Thats ok. At least you know what you don't know. Read the materials and this will go away.
I'm sure if you just read the materials and then read it again more carefully it will come to you
Done. Please see the above link, or MJB's posted code it is the same thing more or less
Its easier when you read it. and try the examples.
Please look here http://en.wikipedia.org/wiki/ANSI_escape_code for more info
I would guess propforth is working as it always has, the characters are getting through ok, and your terminal is behaving correctly; but you didn't yet set up the terminal to handle the codes you are sending the way you want to handle them.
These two items have shown themselves to be very important to anyone using PropForth interactively.
Working on studying Esc codes that are not in actual use while ignoring reports that I need is a rather wasteful approach. And again I am wondering where 'the examples' are.. if not in the PropForth.htm or the tutorials or the actual source code, then where o where.
I do understand that PropForth provides extension for such Escape codes - but I am not sure if the context applies to a Dumb Terminal or solely to the Juptiter Ace project with the same Propeller providing keyboard and VGA or to just about everything.
Your above excerpts of my text are rather interesting. Wrong interpretation of my posting. I'll try to write better and try to write less.
You have put the focus on ANSI Esc sequences while I am just trying to find the underlying choices made in standard PropForth to support its more important multi-line, multi-column reports. These all are fine in Minicom, but not in the two VT100 emulators I have. I've already determined that one of the two is not appropriate for PropForth. The other one shows promise as at least the LF problem has gone away.
You might just consider that I thought I might be contributing so useful information about using a Propeller-based VT100 solution to PropForth.
It doesn't really matter as I pretty much can work it out on my own.
No need to reply. Enjoy yourself.