Word"fl" use free-area to compile source. So buffer reserve 832bytes and "fl" can't operate.
To prevent this, you write codes between "fl" and "wvariable buffer d830 allot" Reserve-bytes depend on codes-amount.
Sal's response in issue 196:
"fl allocates all free memory except 128 bytes, and buffers the incoming code in that memory. The memory is "freed" as the characters are interpreted. So if you use fl, memory will be limited to the number of characters interpreted so far +128 - dictionary use. Usually this is ok, but in cases as above it becomes a problem."
onreset and onboot have no explaination within the PropForth.htm.
My first impression was that I had to have 64k eeprom to use these.. 32k might be unsupported. But now I am thinking that they might not be dependent on extra eeprom. That they just might refer to another word previously defined in dictionary.
Having said that I need to run some tests to verify. Something like the following...
Okay, here is a knotty problem. I am fastloading 1430 bytes of a lookup table to EEprom 63000-=64330, and I get good results in Linux and Minicom... But this does NOT work in a Windows and TeraTerm solution.
Any suggestions on the Best... not just any old .. way to resolve it. I decided it was just easiest to lower the Baud rate of the PropForth as it appears when the jump from 57600 baud to 228200 was made.. large EEprom writes may not have been considered.
I have asked the fellow with the Windows/TeraTerm to drop his baud rate to 19200 and see it it all clears up.
****** WARNING ******
If you run a test, this file will overwrite addresses 63000-64430 of the EEprom. This will NOT conflict with with the PF file system if existing files are not written to that area. But if existing files existed the that area, they will be lost.
... good results in Linux and Minicom... But this does NOT work in a Windows and TeraTerm solution.
...
I have asked the fellow with the Windows/TeraTerm to drop his baud rate to 19200 and see it it all clears up.
The issue my lie with the third person:
What PC? (speed memory os, etc)
What else is running on the PC?
What else is connected to the PC?
I would not hazard any guess except to say that its probably something dumb like printer, scanner, dumb smart phone, AOL, and all the associated crapware; and these are choking all usability out of the machine. This was the issue last week when a user had trouble loading EEprom in propforth.
Either that, or there is a bug in the propforth kernel that no one has noticed all this time (which actually happens quite often, but usually only Sal finds them).
I have askked the third person to provide me with the exact version of Window (XP, Vista, 7...) and something about the computer, but no response to those requests.
He does get good partial loads, and had more success with added delays of 2 ms / character and 10 ms / line. Rather than go back and forth searching for the right amount of delays, i just requested that he reduce the baud rate to 19200 and see if the PropForth fl would be happy with every bit being slower.
Any suggestions on the Best... not just any old .. way to resolve it.
Sal notes in comment 2 of issue 198 - the file as written has lots of spaces. This make is too big for the cog to buffer it. Remove the spaces and it loads fine.
Simplest is best.
Also, you should be able to use normal baud rate 230400. If it doesn't load, baud rate is not the problem.
Interesting... The original did not use fl and needed the added spaces to work fine. I just added spaces to make it work as a tweek and that allowed it to perform well as it seemed that discarding the extra spaces allowed EW! the time required to do a full write cycle properly.
So without the 'fl' it appears the spaces are not an issue and maybe useful, but with the 'fl' spaces overrun buffers established in PF.
~~~~~~~~~
I will pass the info on and see if the end user had any success at 19200 in spite of the fact that what you indicate is that it should not fix anything
Interesting... The original did not use fl and needed the added spaces to work fine. I just added spaces to make it work as a tweek and that allowed it to perform well as it seemed that discarding the extra spaces allowed EW! the time required to do a full write cycle properly.
So without the 'fl' it appears the spaces are not an issue and maybe useful, but with the 'fl' spaces overrun buffers established in PF.
~~~~~~~~~
I will pass the info on and see if the end user had any success at 19200 in spite of the fact that what you indicate is that it should not fix anything
Thanks for the quick reply.
No, I did NOT say it won't fix anything. I said if it works at normal baud on one I would bet that it work identically on the other, so a differnt mechanism would be the issue.
If you run at a slower baud, propforth has MORE TIME to peform dictionatry commit, etc; this might be how it can work without fl. You can STILL create over run (by doing lots of time intensive action iclose together) you just have to be aware to work withing the parameters.
In PF 6, there will be proper flow control, fl will go away and overr runs will not happen. Then we can have issues with the third party apps tht do not porperly implement their end of flow control.
No, I did NOT say it won't fix anything. I said if it works at normal baud on one I would bet that it work identically on the other, so a differnt mechanism would be the issue.
If you run at a slower baud, propforth has MORE TIME to peform dictionatry commit, etc; this might be how it can work without fl. You can STILL create over run (by doing lots of time intensive action iclose together) you just have to be aware to work withing the parameters.
In PF 6, there will be proper flow control, fl will go away and overr runs will not happen. Then we can have issues with the third party apps tht do not porperly implement their end of flow control.
So are you saying that running at a slower baud just might offer further improvement?
Both work at your normal baud on my Linux and minicom solution, neither at your normal baud work on the other users Windows and Teraterm solution. ( I just can't seen to determine which Windows the user is using or how much DRAM and so forth.)
Happy to hear fl will go away forever... maybe whatever replaces might be called 'autoload'.
Still, my dilemma is obvious...
A. Find a way for this to work
B. Abandon an EEprom lookup table solution with PropForth 5.5
So are you saying that running at a slower baud just might offer further improvement?
I'm say normal works for everyone else, YOU are responsible for figuring out what is different on your unique situation. If you fill in the rest of the details it would help us help you; guessing based on partial information only goes so far. So choose what ever is easiest for you.
Sal has tested your conditions as provided, and has shown that it already works when used as instructed. Unless was we enough information to reproduce an error, we have nothing to work on, and mark it "PerDesign", works in conformance to the requirements.
Just for the sake of closure, I am mentioning how the 715 lines of EW! achieved a successful load in EEprom 63000-64430 in one operation.
It can easily be done.
The user selectively Cut and paste only the insertion code, NO fl and NO comments. He did not change the baud. It all went in, he then successfully wrote a PropForth word to wipe clean the EEprom form h8000 to hFFFF by providing a +loop that incremented by 2 and wrote a -1 via EW!.
And finally, he reloaded and verified the lookup table was correctly installed a 2nd time via using edump.
My request for clarification that slowing Baud rates might improve was in no way intended to be subversive. I am just trying to figure out what the Buffers really are capable of in PropForth. Beside, the 230400 baud rate is too high for using Brad's Spin Tool for a serial console.
I still know nothing about his hardware or version of Windows.
It seems that using 'fl' in this context creates problems.
*******
In any event, I am finished with seeking Forum support for PropForth as I cannot seem to get answers to issues or contribute to the discussion without offending Prof Braino regardless of my intentions being good.
I reserve the right to have my own opinions and preferences about software and hardware. I have merely tried to look at all versions of Forth on the Propeller in terms of what the really can do and how easy or difficult they are to learn.
I am NOT saying that Sal Sanci has failed to produce a good product. I am saying that the weak link for me and maybe only me is that I have to ask Prof Braino questions from time to time. This seems to lead off into the weeds.
No worries, just fix the parts that are causing your issue, as previously described.
To reiterate: You see loading with fl works on linux with minicon, we've demonstrated it works on windows, so fl clearly is not the problem, once you remove the white space and stop overfilling the buffer.
There is an issue only on the windows system you are using. An issue peculiar to your specific system is most likely due to other software interfering with the USB.
Adding delays and pasting fewer lines also works, for the same reasons described. This is the hard way, it is recommended that you just fix the cause of the problem, which, again, is not fl, as demonstrated by you.
prof_braino, how is the fastload mode exited? The fl word is used to start the fastload mode, but there doesn't seem to be an explicit word that terminates it. It might be that something in Loopy's code is causing the fastload mode to be exited early, which would cause the buffers to overflow. Maybe Loopy's problem is caused by something sent by the Windows box that is causing the fastload mode to terminate. Could the windows CR, LF characters at the end of a line be causing this?
fl looks for a line starting with three periods and containing only 3 periods - that stops it
I was wondering which version of TeraTerm was being used - there's an old one that doesn't do so well with high speed connections and a newer one that works well.
I don't have my Windows laptop handy to check the two versions. It's something worth checking, the old one gave me fits with Tachyon loading.
mindrobots, are you sure about the "..." sequence. I looked at the definition for (fl), which is the word that does the buffering, and I didn't see that.
It appears that it exits the fastload mode when it encounters a long time between characters. It uses the variable _wkeyto to determine how many times it will call key? without a new character before it exits. _wkeyto contains a value of 8192. I don't know how much time that translates to, but I'm guessing this is the cause of Loopy's problem. On a Windows system there might be occasional large gaps of time between characters on the serial port. This would cause the Prop to go out of the fastload mode before it reaches the end of the serial data.
This is made worse by the fact Loopy is writing to EEPROM, which takes a few msecs per write. The interpreter falls behind, and the input serial buffer overflows. Loopy, you might be able to resolve this by compiling your EEPROM writes into a word, execute the word, and then forget it. Your code would look something like this:
Well, I certainly did NOT place ' ... ' at the end of the fl. I can now see clearly that is the case. Pleae consider documenting any and all paired Forth words. Since PropForth is non-standard... some are missing and others are entirely new.
This may indeed have been the cause of it not working properly. But with having to hunt for different pieces here and there and everywhere the ... was omitted. These three dots are something that is easily overlooked or later forgotten the way things are listed in a long list.
I reported the problem. Submitted the exemplar code. And was promptly admonished for doing so. Obviously entirely my fault.
I have learned my lesson and to use ALLOT and avoid look up table in EEprom. Just use EEprom as a file system.
I suspect that a recent, if not the latest version of TeraTerm was used as I recommended it and gave a link to download.
I am going over to ANS Forth for a while... a long while.
Loopy, did you try my suggestion? I don't think "..." is used to terminate the fastload mode. I don't see it used anywhere in Sal's code, and he does use fl in a number of places. I think you've encountered an undocumented timeout feature in fastload. Try my suggestion without fl, and see if that works. You might need to add more spaces to give the interpreter time to catch up.
EDIT: I hope the ". . ." that I used in the suggested code in my previous post didn't confuse you. I didn't mean to insert the "..." that mindrobots mentioned, but they represented the rest of your EEPROM code that I omitted. I've struck out the ". . ." to reduce the confusion.
Sal is still preparing for PF6 beta, multitasking requires fastious trouble shooting, EVERY glitch must be investgated as getting the same timing twice is not possible. So far all errors have been "fingerr errors", typing mistakes or wrong wire, etc. He's got two rigging running all the time, one logging and one doing vetocr calculations and checking against known results. Same idea as Prime95 torture test, but simpler.
I decided LittleRobot will specify NiMH AA btteries, and these will not be included in the kit. I'll bring AA alkalines, and use 3 AA + a dummy cell (1-3/4" machine bolt) for testing in the workshops.
A future custom design will likely use the cheap ($1.75) DC-DC converters erco and others recommend, Sal said he had 2 of 20 that needed to be reflowed so will have to obtain a toaster oven and clean out a corner of the braino-lab to set one up.
I have 1 LittleRobot workshop booked for 12 seats, and another pending for 20-50 seats. I met a Cub Scouts dad that might want 18 seats, but he hasn't sent an email yet so this doesn't count as pend yet.
Sal gave me a start on a simple mapping algorithm to deal with small targets and oblique angles: take 10 reading. If the average is within a few percent, its a good reading, if not its a noisy reading. By filling in a grid (of No Readings) with Good reading and
Noisy readings, we can figure out where to go and where not to go. This will be in the programming add-on pages for LittleRobot.
I have my C guy starting in on openCV to add vision to the bots. Seems we can call the C code from Go, and so we continue to plan for vision on a RPi/beaglebone; and accutator control via prop. Might be a tad more to it, so don't expect anything fancy for a bit.
Issue 195 SR04 errors
Harware issue, Fixed with NiMH batteries for proper voltage, 10k resistor on echo out
Issue 198
The issue has two parts: One, the amount of text was overflowing the buffer. Two, there is an issue with the user windows PC.
The first issue has been addressed. We have not recieved and new information, so we can't do much on the second part.
I'll leave it open a little longer just in case, but so far this is "PerDesign".
FOR THE PROJECT in progress. just omitting the fl completely and removing the comment between { and } loaded fine.
I am a bit confused now as I haven't started digging through the PropForth documents to find out where ... is shown as a required part of anything. I just presumed others had verified.
So the project can move ahead. I doubt if I will take this approach again, but it has been excellent in terms of being a problem solving example for the new user. We are beyond it and he is busy with the actual program code... which is very short.
I tend to agree with him, do not use fl to load a list into EEPROM. The added spaces before EW! appear to occupy the Propeller enough so that the last write to eeprom is finished before the next EW! arrives.
Crude but simple.
Forth has always been close to machine code and has not buffered the learner from crashing the system. Learning to not crash the system and why is just part of the unique insights that Forth offers. Topics like this never come up in Basic. Debugging an interpreted language causes sudden weird behaviors.
fl looks for a line starting with three periods and containing only 3 periods - that stops it
CAUTION the "..." ends the fswrite command, this is the word that creates a file in the current file system, eeprom or SD, depenting on the kernel loaded.
fswrite MyFile.txt
< many lines of code>
...
fl just goes until the input ends or something blows up (undefined word, etc)
When text is pasted with fl, the prompt changes from cog6 to cog5 as the inputstream is interpreted; when the stream ends for what ever reason, the prompt return as cog6 again. If you don't paste in the last line terminator, (typically the examples from the wiki get pastes without any terminator on the last line) the interpreter will wait until you hit an enter to complete the last line.
One of the LittleRobot programs bot.f would paste in and stop about 3/4 the way through, I didn't figure out why yet. I think there is something in the rendered page that is different from regular text. There could be bug but I have not been able to nail down reproducing it.
The stepper file is 18104 bytes, so I can see how that might be too big to fit in memory. Removing all the spaces get's it down to 9,341 bytes so maybe it would fit with in fastload mode that way. Loopy, how much space do you have before you try to load the EEPROM code? It's probably better not to use the fastload mode at all since it requires so much memory in your case.
Inserting spaces and not using fl is probably the best way to go. You need at least 4 msec worth of data per EEPROM write. At 9600 baud that's only 4 characters. At 57,600 it would be 15 characters per line. At 115,200 it's 29, and at 230,400 it's 58.
The stepper file is 18104 bytes, so I can see how that might be too big to fit in memory.
When you think about it, best way to go might be to break the file into two, and load them only after the other using fast load. It will fit in the buffer and you can run at full speed (what ever you r system is) with no delays, and you can use the version with all the extra comments. Its only two fast operations instead of all the delays, etc.
"I'm say normal (baud) works for everyone else, YOU are responsible for figuring out what is different on your unique situation. If you fill in the rest of the details it would help us help you; guessing based on partial information only goes so far. So choose what ever is easiest for you.
Sal has tested your conditions as provided, and has shown that it already works when used as instructed. Unless was we enough information to reproduce an error, we have nothing to work on, and mark it "PerDesign", works in conformance to the requirements." ... per Prof Braino to Loopy.
++++++++++++++++++++
"One of the LittleRobot programs bot.f would paste in and stop about 3/4 the way through, I didn't figure out why yet. I think there is something in the rendered page that is different from regular text. There could be bug but I have not been able to nail down reproducing it." per Prof Braino to others.
And so, you seem to have changed your story depending on who you talked to.
fl appears to have a real problem and I am very disappointed that my reporting is taken as more doubtful than others.
Do whatever you want, but I am completely finished with PropForth.
normal (baud) works... If you fill in the rest of the details ....choose what ever is easiest for you. ...we have nothing to work on, and mark it "PerDesign", .
One (notice ONE, not all, not any other)... would ... stop about 3/4 the way through, I didn't figure out why yet.... There could be bug...
Loopy, your stubbornness is epic.
Propforth is by no means perfect, but you have not found any bug we can fix yet despite your insistence.
We CAN load EEprom with fl, it works great, just don't overstuff the buffer, you've proven overstuffing the buffer won't work, and fl works per design. You could slow the transfer via low baud rate and delays, and extra spaces. That is how it was done in early versions, and is very slow, which is why it was fixed. Given the choice of doubling your load time for ALL interaction or splitting your eeprom file into a couple smaller chunks SHOULD be an easy decision.
There MIGHT be something to the glitch I saw, but if we can't reproduce it, and it doesn't happen to anyone else, there is nothing to fix. If the issue is with my PC, changes to the kernel won't fix it.
You are welcome to do things opposite what is recommended, you can do anything you want. But when you do, is it the tool's fault that your results differ from those of the recommended method?
It is not about PropForth being perfect.
It is not about documents being perfect.
You are PropForth to the end user community as all support seems to go through you in both directions as there is no other means to reach Sal Sanci.
It is a bit unusual.
Responses from you can and do vary in odd ways. Yes I am very stubborn when my credibility is depreciated unfairly. I explored the fl problem for two weeks before passing it on. You quickly dismissed it as 'only me'.
Just try to be fair to all that seek support honesty...
PropForth is what you make it as well as what Sal does.
To really be the best, your role is equally important.
I have just found real problems and their resolution will enhance PropForth - first the inability of true half-duplex, and now problem of fl dropouts.
I backed out of being delegated a large agenda of PropForth writing and editing because it was just too much.
prof_braino, the description for fl should explicitly state that the data that is buffered in hub RAM in the unused area after the dictionary. It currently says that it is buffered in a cog, which would imply that it's buffered in the cog's RAM. Also, the description should state that the amount of data pasted in the serial terminal should be less than the unused space - 128 bytes. Does PropForth support the unused word? If so, the user can be instructed to type "unused" to see how much space is available for buffering.
It would also be good to document the fact that the fastload mode is exited when there is a gap of N msecs in the serial data. I don't know what the value of N is, but it's basically the amount of time it takes for PropForth to call key? and decrement a timeout count 8192 times in a begin loop. I guessing the timeout time is on the order of 10 to 100 msecs.
This additional information in the documentation may have saved Loopy a lot of time and frustration.
Comments
Sal's response in issue 196:
"fl allocates all free memory except 128 bytes, and buffers the incoming code in that memory. The memory is "freed" as the characters are interpreted. So if you use fl, memory will be limited to the number of characters interpreted so far +128 - dictionary use. Usually this is ok, but in cases as above it becomes a problem."
fl will go away in PR6
Sals response on 197:
The concept is correct, but this will run on every cog that gets reset, probably not what you want.
: onreset3 onreset blinky ;
Will only run on cog3 (change 3 to whatever cog number) run the original reset and then run blinky.
http://code.google.com/p/propforth/wiki/flfastload
and deprecated the old page. http://code.google.com/p/propforth/wiki/flfastloadword which, upon reading, was confusing to me, and I wrote it! Hopefully the new page is better.
http://code.google.com/p/propforth/wiki/onreset
Any suggestions on the Best... not just any old .. way to resolve it. I decided it was just easiest to lower the Baud rate of the PropForth as it appears when the jump from 57600 baud to 228200 was made.. large EEprom writes may not have been considered.
I have asked the fellow with the Windows/TeraTerm to drop his baud rate to 19200 and see it it all clears up.
****** WARNING ******
If you run a test, this file will overwrite addresses 63000-64430 of the EEprom. This will NOT conflict with with the PF file system if existing files are not written to that area. But if existing files existed the that area, they will be lost.
Opened issue 198 http://code.google.com/p/propforth/issues/detail?id=198
There should be no difference between Minicom and Teraterm. And teraterm just works.
The issue my lie with the third person:
What PC? (speed memory os, etc)
What else is running on the PC?
What else is connected to the PC?
I would not hazard any guess except to say that its probably something dumb like printer, scanner, dumb smart phone, AOL, and all the associated crapware; and these are choking all usability out of the machine. This was the issue last week when a user had trouble loading EEprom in propforth.
Either that, or there is a bug in the propforth kernel that no one has noticed all this time (which actually happens quite often, but usually only Sal finds them).
We'll look at this on tomorrow's call.
He does get good partial loads, and had more success with added delays of 2 ms / character and 10 ms / line. Rather than go back and forth searching for the right amount of delays, i just requested that he reduce the baud rate to 19200 and see if the PropForth fl would be happy with every bit being slower.
He said he will get back to me this weekend.
Sal notes in comment 2 of issue 198 - the file as written has lots of spaces. This make is too big for the cog to buffer it. Remove the spaces and it loads fine.
Simplest is best.
Also, you should be able to use normal baud rate 230400. If it doesn't load, baud rate is not the problem.
So without the 'fl' it appears the spaces are not an issue and maybe useful, but with the 'fl' spaces overrun buffers established in PF.
~~~~~~~~~
I will pass the info on and see if the end user had any success at 19200 in spite of the fact that what you indicate is that it should not fix anything
Thanks for the quick reply.
No, I did NOT say it won't fix anything. I said if it works at normal baud on one I would bet that it work identically on the other, so a differnt mechanism would be the issue.
If you run at a slower baud, propforth has MORE TIME to peform dictionatry commit, etc; this might be how it can work without fl. You can STILL create over run (by doing lots of time intensive action iclose together) you just have to be aware to work withing the parameters.
In PF 6, there will be proper flow control, fl will go away and overr runs will not happen. Then we can have issues with the third party apps tht do not porperly implement their end of flow control.
So are you saying that running at a slower baud just might offer further improvement?
Both work at your normal baud on my Linux and minicom solution, neither at your normal baud work on the other users Windows and Teraterm solution. ( I just can't seen to determine which Windows the user is using or how much DRAM and so forth.)
Happy to hear fl will go away forever... maybe whatever replaces might be called 'autoload'.
Still, my dilemma is obvious...
A. Find a way for this to work
B. Abandon an EEprom lookup table solution with PropForth 5.5
I'm say normal works for everyone else, YOU are responsible for figuring out what is different on your unique situation. If you fill in the rest of the details it would help us help you; guessing based on partial information only goes so far. So choose what ever is easiest for you.
Sal has tested your conditions as provided, and has shown that it already works when used as instructed. Unless was we enough information to reproduce an error, we have nothing to work on, and mark it "PerDesign", works in conformance to the requirements.
It can easily be done.
The user selectively Cut and paste only the insertion code, NO fl and NO comments. He did not change the baud. It all went in, he then successfully wrote a PropForth word to wipe clean the EEprom form h8000 to hFFFF by providing a +loop that incremented by 2 and wrote a -1 via EW!.
And finally, he reloaded and verified the lookup table was correctly installed a 2nd time via using edump.
My request for clarification that slowing Baud rates might improve was in no way intended to be subversive. I am just trying to figure out what the Buffers really are capable of in PropForth. Beside, the 230400 baud rate is too high for using Brad's Spin Tool for a serial console.
I still know nothing about his hardware or version of Windows.
It seems that using 'fl' in this context creates problems.
*******
In any event, I am finished with seeking Forum support for PropForth as I cannot seem to get answers to issues or contribute to the discussion without offending Prof Braino regardless of my intentions being good.
I reserve the right to have my own opinions and preferences about software and hardware. I have merely tried to look at all versions of Forth on the Propeller in terms of what the really can do and how easy or difficult they are to learn.
I am NOT saying that Sal Sanci has failed to produce a good product. I am saying that the weak link for me and maybe only me is that I have to ask Prof Braino questions from time to time. This seems to lead off into the weeds.
To reiterate: You see loading with fl works on linux with minicon, we've demonstrated it works on windows, so fl clearly is not the problem, once you remove the white space and stop overfilling the buffer.
There is an issue only on the windows system you are using. An issue peculiar to your specific system is most likely due to other software interfering with the USB.
Adding delays and pasting fewer lines also works, for the same reasons described. This is the hard way, it is recommended that you just fix the cause of the problem, which, again, is not fl, as demonstrated by you.
fl looks for a line starting with three periods and containing only 3 periods - that stops it
I was wondering which version of TeraTerm was being used - there's an old one that doesn't do so well with high speed connections and a newer one that works well.
I don't have my Windows laptop handy to check the two versions. It's something worth checking, the old one gave me fits with Tachyon loading.
It appears that it exits the fastload mode when it encounters a long time between characters. It uses the variable _wkeyto to determine how many times it will call key? without a new character before it exits. _wkeyto contains a value of 8192. I don't know how much time that translates to, but I'm guessing this is the cause of Loopy's problem. On a Windows system there might be occasional large gaps of time between characters on the serial port. This would cause the Prop to go out of the fastload mode before it reaches the end of the serial data.
This is made worse by the fact Loopy is writing to EEPROM, which takes a few msecs per write. The interpreter falls behind, and the input serial buffer overflows. Loopy, you might be able to resolve this by compiling your EEPROM writes into a word, execute the word, and then forget it. Your code would look something like this:
This may indeed have been the cause of it not working properly. But with having to hunt for different pieces here and there and everywhere the ... was omitted. These three dots are something that is easily overlooked or later forgotten the way things are listed in a long list.
I reported the problem. Submitted the exemplar code. And was promptly admonished for doing so. Obviously entirely my fault.
I have learned my lesson and to use ALLOT and avoid look up table in EEprom. Just use EEprom as a file system.
I suspect that a recent, if not the latest version of TeraTerm was used as I recommended it and gave a link to download.
I am going over to ANS Forth for a while... a long while.
EDIT: I hope the ". . ." that I used in the suggested code in my previous post didn't confuse you. I didn't mean to insert the "..." that mindrobots mentioned, but they represented the rest of your EEPROM code that I omitted. I've struck out the ". . ." to reduce the confusion.
Sal is still preparing for PF6 beta, multitasking requires fastious trouble shooting, EVERY glitch must be investgated as getting the same timing twice is not possible. So far all errors have been "fingerr errors", typing mistakes or wrong wire, etc. He's got two rigging running all the time, one logging and one doing vetocr calculations and checking against known results. Same idea as Prime95 torture test, but simpler.
I decided LittleRobot will specify NiMH AA btteries, and these will not be included in the kit. I'll bring AA alkalines, and use 3 AA + a dummy cell (1-3/4" machine bolt) for testing in the workshops.
A future custom design will likely use the cheap ($1.75) DC-DC converters erco and others recommend, Sal said he had 2 of 20 that needed to be reflowed so will have to obtain a toaster oven and clean out a corner of the braino-lab to set one up.
I have 1 LittleRobot workshop booked for 12 seats, and another pending for 20-50 seats. I met a Cub Scouts dad that might want 18 seats, but he hasn't sent an email yet so this doesn't count as pend yet.
Sal gave me a start on a simple mapping algorithm to deal with small targets and oblique angles: take 10 reading. If the average is within a few percent, its a good reading, if not its a noisy reading. By filling in a grid (of No Readings) with Good reading and
Noisy readings, we can figure out where to go and where not to go. This will be in the programming add-on pages for LittleRobot.
I have my C guy starting in on openCV to add vision to the bots. Seems we can call the C code from Go, and so we continue to plan for vision on a RPi/beaglebone; and accutator control via prop. Might be a tad more to it, so don't expect anything fancy for a bit.
Issue 195 SR04 errors
Harware issue, Fixed with NiMH batteries for proper voltage, 10k resistor on echo out
Issue 196
Updated the page for fl (fast load) fl http://code.google.com/p/propforth/wiki/flfastload
Closing issue as "PerDesign"
Issue 197
Add a wiki page for onreset
http://code.google.com/p/propforth/wiki/onreset
Close issue as fixed
Issue 198
The issue has two parts: One, the amount of text was overflowing the buffer. Two, there is an issue with the user windows PC.
The first issue has been addressed. We have not recieved and new information, so we can't do much on the second part.
I'll leave it open a little longer just in case, but so far this is "PerDesign".
No, we saw he has too many characters, that overflows the buffer. Remove the extra spaces and it loads fine.
I am a bit confused now as I haven't started digging through the PropForth documents to find out where ... is shown as a required part of anything. I just presumed others had verified.
So the project can move ahead. I doubt if I will take this approach again, but it has been excellent in terms of being a problem solving example for the new user. We are beyond it and he is busy with the actual program code... which is very short.
I tend to agree with him, do not use fl to load a list into EEPROM. The added spaces before EW! appear to occupy the Propeller enough so that the last write to eeprom is finished before the next EW! arrives.
Crude but simple.
Forth has always been close to machine code and has not buffered the learner from crashing the system. Learning to not crash the system and why is just part of the unique insights that Forth offers. Topics like this never come up in Basic. Debugging an interpreted language causes sudden weird behaviors.
CAUTION the "..." ends the fswrite command, this is the word that creates a file in the current file system, eeprom or SD, depenting on the kernel loaded.
fl just goes until the input ends or something blows up (undefined word, etc)
When text is pasted with fl, the prompt changes from cog6 to cog5 as the inputstream is interpreted; when the stream ends for what ever reason, the prompt return as cog6 again. If you don't paste in the last line terminator, (typically the examples from the wiki get pastes without any terminator on the last line) the interpreter will wait until you hit an enter to complete the last line.
One of the LittleRobot programs bot.f would paste in and stop about 3/4 the way through, I didn't figure out why yet. I think there is something in the rendered page that is different from regular text. There could be bug but I have not been able to nail down reproducing it.
Inserting spaces and not using fl is probably the best way to go. You need at least 4 msec worth of data per EEPROM write. At 9600 baud that's only 4 characters. At 57,600 it would be 15 characters per line. At 115,200 it's 29, and at 230,400 it's 58.
Didn't mean to mislead you down the wrong rabbit hole.
Too many languages, too little brain.
When you think about it, best way to go might be to break the file into two, and load them only after the other using fast load. It will fit in the buffer and you can run at full speed (what ever you r system is) with no delays, and you can use the version with all the extra comments. Its only two fast operations instead of all the delays, etc.
Sal has tested your conditions as provided, and has shown that it already works when used as instructed. Unless was we enough information to reproduce an error, we have nothing to work on, and mark it "PerDesign", works in conformance to the requirements." ... per Prof Braino to Loopy.
++++++++++++++++++++
"One of the LittleRobot programs bot.f would paste in and stop about 3/4 the way through, I didn't figure out why yet. I think there is something in the rendered page that is different from regular text. There could be bug but I have not been able to nail down reproducing it." per Prof Braino to others.
And so, you seem to have changed your story depending on who you talked to.
fl appears to have a real problem and I am very disappointed that my reporting is taken as more doubtful than others.
Do whatever you want, but I am completely finished with PropForth.
Loopy, your stubbornness is epic.
Propforth is by no means perfect, but you have not found any bug we can fix yet despite your insistence.
We CAN load EEprom with fl, it works great, just don't overstuff the buffer, you've proven overstuffing the buffer won't work, and fl works per design. You could slow the transfer via low baud rate and delays, and extra spaces. That is how it was done in early versions, and is very slow, which is why it was fixed. Given the choice of doubling your load time for ALL interaction or splitting your eeprom file into a couple smaller chunks SHOULD be an easy decision.
There MIGHT be something to the glitch I saw, but if we can't reproduce it, and it doesn't happen to anyone else, there is nothing to fix. If the issue is with my PC, changes to the kernel won't fix it.
You are welcome to do things opposite what is recommended, you can do anything you want. But when you do, is it the tool's fault that your results differ from those of the recommended method?
And yours as well.
It is not about PropForth being perfect.
It is not about documents being perfect.
You are PropForth to the end user community as all support seems to go through you in both directions as there is no other means to reach Sal Sanci.
It is a bit unusual.
Responses from you can and do vary in odd ways. Yes I am very stubborn when my credibility is depreciated unfairly. I explored the fl problem for two weeks before passing it on. You quickly dismissed it as 'only me'.
Just try to be fair to all that seek support honesty...
PropForth is what you make it as well as what Sal does.
To really be the best, your role is equally important.
I have just found real problems and their resolution will enhance PropForth - first the inability of true half-duplex, and now problem of fl dropouts.
I backed out of being delegated a large agenda of PropForth writing and editing because it was just too much.
So good luck with your approach and ambitions.
It would also be good to document the fact that the fastload mode is exited when there is a gap of N msecs in the serial data. I don't know what the value of N is, but it's basically the amount of time it takes for PropForth to call key? and decrement a timeout count 8192 times in a begin loop. I guessing the timeout time is on the order of 10 to 100 msecs.
This additional information in the documentation may have saved Loopy a lot of time and frustration.