The 10K pull-up is a little high for I2C but with a light load, short lines, and as long as you don't run the I2C too fast (standard-mode) then it is fine. There is no problem with reducing this value down to much less with a value of around 2.2K or less being preferable if you are using fast-mode and/or driving multiple devices etc. Of course with 10K on the board and 10K externally plus another 10K elsewhere you would have 3.3K effective pull-up which would also work well.
Hi.
I did to use SDSC(512MB,256MB) on sd_driver.
I tested on QuickStart board.
sd_driver_modify_0.1's using pin are P0 - P3.
I use micro 2GB on protoboard's system-SD.
fat-viewer(another SD-card adapter) use sdsc-driver.
If you never use SDSC(512MB,256MB), this don't need.
If anybody out there has been doing or is interested in doing PropForth on a Mac, one item you need is a good terminal program. There is such a beast, Zterm. But, alas, version 1.1b7 dated from 2002 has been the only game in town. 2002 was long before Apple went Intel so its no surprise that Zterm is a PPC binary ... and of course with the recent release of Mac OSX Lion (OSX 10.7) Rosetta is not supported ... bummer ... but wait ... in my search for a replacement I stumbled on the fact that Zterm's author, after 9 years, updated Zterm to a Universal binary.
Zterm version 1.2 is available free at http://homepage.mac.com/dalverson/zterm/. It's not cripple ware and he accepts 'registrations.' I had been using Zterm for 12 years, so I made a donation. I was impressed that he bothered to update 15 year old software.
In PropForth is there any equivalent to AUTOEXEC.BAT ?? I mean is there a reserved wordname, that if defined, then do a 'saveforth,' upon reboot that word will begin executing ??
... and if we do that word right there will be a loop that will look for a keystroke or a pin setting to let us regain control ... or not, if we want it bulletproof.
For a simple terminal program for the Mac, I use goSerial. It's free. It's "no frills', but it gets the job done. For a full-featured terminal program, I use MacWise which is not free, but seems to be priced reasonably ($95) for the feature set (includes Telnet, Kermit, and a variety of terminal emulators).
In PropForth is there any equivalent to AUTOEXEC.BAT ?? I mean is there a reserved wordname, that if defined, then do a 'saveforth,' upon reboot that word will begin executing ??
ONBOOT is the word that is executed at boot time. You can define this word how ever you need. Examples in SD and spineret regression tests.
r> is "pop top of RS to stack" and >r is "push stack top to RS" ? But 1 >r result error.
Prop0 Cog6 ok
1 >r
COM:Prop0 Cog6 RESET - last status: 2 RETURN STACK OVERFLOW
Prop0 Cog6 RESET - last status: 2 RETURN STACK OVERFLOW
Prop0 Cog6 ok
How to use r> and >r?
Hi caskaz
The return stack can ONLY be use WITHIN A DEFINITION. If you use the return stack from the command line, you break the interpreter.
>r (to-return stack) puts a value (from top of data stack) on the return stack. You can only put your temporary values on the return stack within a functin definition.
r> (from-return stack) takes a value off the return stack (and puts it on top of data stack). You can only take values off the return stack that YOU previously put on there.
@r copies the top value off the return stack (to the top of the data stack), but also leaves it on the return stack
YOU MUST consume all the values you put on the return stack before the function ends, or you can crash the interpreter.
In your command line tests above, once it did not crash the interpreter, and once it did crash. In both cases the interpreter was broken, all further execution is undefined, and the prop needs a reboot.
I think this is the correct example for what you want to do.
: test 5 7 >r 1+ r> st? ;
Best advise: Be care with the return stack, only use it when there is no other way.
ONBOOT is the word that is executed at boot time. You can define this word how ever you need. Examples in SD and spineret regression tests.
Improved response:
: old-boot onboot ; <- define a word "old-boot" to do the previous (required) boot-time behavior
: onboot old-boot MyApplication ; <- make a new definition "onboot" to to call the previous boot behavior word, and to call you application word.
At boot time, propforth looks for the most recent definition of onboot, and calls that. the old-boot definition sets up the last of the house keeping, and turn control back to the interpreter.
If there is no word in the input stream, it drops back to the command line.
If your word MyApplication is there, My Application begins executing.
If MyApplication crashes or terminates unexpectedly, it can be made to drop back to the command line.
There is another option to make the kernel HALT upon termination of MyApplication, so that the user does not get access to the interpreter in the event of a crash (for security, etc) but I never use this and I don't know exactly how to set it up. If you need this we can ask Sal when he gets back from his journey, hopefully this month.
... hmmmmmmmm ... I see the writing of an App-Note in my near future ...
In PF 4.6 I see words
onboot
onreset
onreold - (old-onreset ?????)
onbold - (old-onboot ?????)
reboot
reset
Please differentiate, tell me hardware and software conditions under which they come to play.
Am I correct in saying that power cycling and the word 'reboot' are one in the same as far as PF is concerned? The word 'reset' seems to reset current cog .. what else does it do?
I will play with them and write up an AppNote/HOW-TO and submit it to the wiki and you can see if I got it right
: old-boot onboot ; <- define a word "old-boot" to do the previous (required) boot-time behavior
: onboot old-boot MyApplication ; <- make a new definition "onboot" to to call the previous boot behavior word, and to call you application word.
At boot time, propforth looks for the most recent definition of onboot, and calls that. the old-boot definition sets up the last of the house keeping, and turn control back to the interpreter.
If there is no word in the input stream, it drops back to the command line.
If your word MyApplication is there, My Application begins executing.
If MyApplication crashes or terminates unexpectedly, it can be made to drop back to the command line.
OK, I played with this, found out 'the hard way' what happens when you do not include the old onboot word as part of the new onboot word ... PF goes faaaarrrr away! I had to redo the kernal and fs all over again.
I understand onboot and onreset, but I still need coming up to speed for onbold and onreold.
It appears to me now that 'reboot,' power cycling and, hardware reset switch all bring the same software results.
OK, I played with this, found out 'the hard way' what happens when you do not include the old onboot word as part of the new onboot word ... PF goes faaaarrrr away! I had to redo the kernal and fs all over again.
I understand onboot and onreset, but I still need coming up to speed for onbold and onreold.
It appears to me now that 'reboot,' power cycling and, hardware reset switch all bring the same software results.
I THINK:
onboot - does the last word that needs to be executed to start the kernel (interpreter, quit loop, stacks) at boot time. This needs to be done before your application word,
onbold - Sal is "old school" in that it seem imperative to to save a single byte in every weird place, but I guess they add up. onbold is what I would call old-onboot or onboot-old; FYI - Sal pronounces "onbold" as "onboot-old" in discussions.
There IS a difference between onboot and onreset, etc; although I don't know what it is, although each assumes and performs a different level of initialization. I DO know that it is NOT safe to assume the executing any software word is the equivalent of a power cycle. (although I do accept that hardware reset is as effective as power cycle) IE, if something crashes or otherwise goes south, power must be cycled to ensure the issue has been cleared. Perhaps its a ham-fisted approach, but even Sal gets caught where these words do not resolve an execution error, when he thought they would. And this is not a limitation of forth, I'm pretty sure it applies to any micro controller application. But I'm a "nuke them from orbit, its the only way to be SURE" kind of a guy.
Hi.
I built up USB-Host curcuit by using MAX3421E.
I refered MAX3421EKIT's curcuit.
And I translated maxim's sample code to PropForth.
When connected mouse, it seems to work finly.
But USB-memory and scanner don't work.
On Send_packet inside max3421e_0.11_1.f, when executed "80 19 Hwreg" response is 0xd(hrJERR).
Anybody know solution about hrJERR?
---- Connected 2-button mouse ---------
hex
Prop0 Cog6 ok
usb
Waiting for device connect
Low-Speed Device Detected
Issuing USB bus reset
First 8 bytes of Device Descriptor ( 0 NAKS )
12 1 0 1 0 0 0 8
EP0 maxPacketSize is 8 bytes
Issuing USB bus reset
Setting address to 0x07
Device Descriptor ( 0 NAKS )
-----------------
12 1 0 1 0 0 0 8 6E 5 3 0 91 4 1 2 0 1
USB 1.0
This device has 1 configuration
Vendor ID is 0x569
Product ID is 0x3
Language ID String Descriptor is 4 3 9 4
Manuf. string is ELECOM
Product string is ELECOM USB
There is no Serial Number
Configuration Descriptor ( 0 NAKS )
------------------------
9 2 22 0 1 1 4 A0 32
Full Configuration Data
9 2 22 0 1 1 4 A0 32 9 4 0 0 1 3 1
2 5 9 21 0 1 0 1
Configuration 1 has 1 interface
This device is bus powered and uses 64 milliamps
2EndPoint1 I
Config string is HID Mouse
Waiting for device disconnect
Device disconnected
Prop0 Cog6 ok
---- Connected 3-button wheel mouse ---------
usb
Waiting for device connect
Low-Speed Device Detected
Issuing USB bus reset
First 8 bytes of Device Descriptor ( 0 NAKS )
12 1 0 2 0 0 0 8
EP0 maxPacketSize is 8 bytes
Issuing USB bus reset
Setting address to 0x07
Device Descriptor ( 0 NAKS )
-----------------
12 1 0 2 0 0 0 8 CF 1B 7 0 10 0 0 2 0 1
USB 2.0
This device has 1 configuration
Vendor ID is 0x1BB4
Product ID is 0x7
Language ID String Descriptor is 4 3 9 4
There is no Manuf. string
Product string is USB Optical
There is no Serial Number
Configuration Descriptor ( 0 NAKS )
------------------------
9 2 22 0 1 1 0 A0 31
Full Configuration Data
9 2 22 0 1 1 0 A0 31 9 4 0 0 1 3 1
2 0 9 21 10 1 0 1
Configuration 1 has 1 interface
This device is bus powered and uses 62 milliamps
There is no Config string
Waiting for device disconnect
Device disconnected
Prop0 Cog6 ok
---- Connected USB memory ---------
usb
Waiting for device connect
Full-Speed Device Detected
Issuing USB bus reset
First 8 bytes of Device Descriptor ( >>>>> Error >>>>>
FS Timeout
Waiting for device disconnect
Device disconnected
Prop0 Cog6 ok
I don't know the device, but if you are running PropForth4.6 and if you have your the SDdriver running in Cog 0, try 0 cogstop before you test your code.
I tried below;
1.Wires betwen USB A-type connector and MAX3421E(pin20[D-] pin21[D+] replaced twisted wire.
2.I replaceed to propeller NCO-pulse although clock was used ceramic resonator(12MHz) as MAX3421E's clock.
3.USB A-type connector's shield was tied to GND.
But FullSpeed Device error occure.
And I found out Full Configuration Descriptor is strange.
(End point Descriptor is strange)
- pf 5.0 will use the existing hardware configuration for the test bed, and have no test automation implemented. ETA is a couple weeks.
- ETA for pf 5.1 is tentatively targeted for Decemberr 2011. pf 5.1 will consist of a new general hardware configuration that supports full test automation, and demonstrates correct operation of all supported functions. So the regression tests will serve as verification of correct function, examples of use-cases, and training tutorial for intended use of each function. Support will be based on this model. It looks like there will be two spinneret boards (or wiz5100 equivalent) and four "bare" prop chips, and assorted wires and resistors for MSC (highspeed multichannel serial) and regular RS232 serial. This will allow immediate, non-invasive over internet diagnostics and debugging. There is also a possibility of scaled cooperative multiprocessing on this configuration, but implementation will be left to a later release.
Hi.
I think my mistake use NCO to supply MAX3421E's clock.
Protoboard's Xstal is 5MHz.
So NCO output 11999999.99254942Hz.
This cause jitter.
It seems to be ok on LowSpeedDevice.
But not good on FullSpeedDevice.
Using NCO to supply MAX3421E's clock need to replace Protoboard's Xtal to 6MHz.
And PropForth.spin must be also modified.
I think my mistake use NCO to supply MAX3421E's clock.
Protoboard's Xstal is 5MHz. So NCO output 11999999.99254942Hz. This cause jitter.
Using NCO to supply MAX3421E's clock need to replace Protoboard's Xtal to 6MHz.
That sounds similar to other threads reporting USB needs a 6Mhz clock. Did you check how other projects accomplished this? They might have some help for you.
I had started on the "Sieve of Eratosthenes" for parallel processing and recursion experiments, but decided to leave off until the 5.x releases. Many folks have stated these are silly on any microcontroller, prop in particular; but these are still fun and will be on the list later for benchmarking if nothing else. Please continue to keep us posted on your progress, or at least know that this will be bigger in the propforth v5.x time frame.
Also, let us know any feedback for improvements on the docs.
Indeed PropForth is a 'great work, in progress.' Documentation is critical, but from a new user standpoint, we no more get done fully wading through and digesting what documentation there is, than its obsolete. Version 4.x has been replaced by 4.x+1, 20 core words have changed and everything has been restructured.
Now, as a volunteer on the documentation effort, I cannot tell you how many times I have blessed as opposed to cursed my procrastination tendencies, when a HOW-TO I had mentally sketched out would have been wasted because of revisions.
In my gut I get the feeling that 5.0/5.1 is getting us near a relatively stable configuration ... but WHO KNOWS what stroke of divine inspiration the mad genius, Sal Sanci, will have between now and New Year ??!!??!!
I realize we are guests and beneficiaries at the creation of PropForth. But maybe if we had a better idea of where we are going it would help our support efforts. Does 5.1 look like stable configuration or just a way point on the journey?
@Brian - Good question, thanks for your patience and hard work.
The 5.x release is intended to be the final version of the kernel. Sal is pretty accurate with his development and release path.
5.0 will take all the pieces up to and including the paged assembler, and make single unified package. So all the functions that have been demonstrated are to be optimized and included. To reduce the number of unknowns, we are using the "old" (existing) hardware test bed configuration and no test script automation.
5.1 will consist of a new hardware test bed configuration to support automated regression testing. This test bed will allow non-invasive over the internet examination and debugging. It will also be the basis for the automated regression suites. Of course the test bed will be optional. But if you want to run the "stock" regression tests like Sal and I do, this would be where to start. It would also allow someone like Sal to diagnose a running system over the internet, the model is "on-site consulting without travel".
With the 5.x release, we expect the kernel to be stable. Somewhere after 5.0 we will also begin scrubbing the bug list (functions are already implemented) and the documentation (to catch up this the changes). The plan also includes scrubbing the previously release functions, such as VGA (HiRes and LoRes) support, JupiterACE, Hive, debugger, disassembler, etc and bringing all these up to 5.x kernel, and add tests and documentation.
The final step will be to take all the existing non-kernel functions (extensions) from caskaz, Nick, Ron, you, me, and the others and roll them into the regression test suite(s) and make a single download archive package that is periodically re-released as additions are made. By the final step, the entire project should be less of a "Sal's tool" project and more of a "group project" where we all contribute to the regression suite.
I don't know when this will finally happen or if it will work out as described, but that's the idea.
In the time I have been with this project, one theme has been dominant, i.e.that PF, unchanged save for conflicting pin numbers, should run on any Propeller board.The coming development with the dictionary on the SD card seems to shove the ubiquitous Demo Board out into the cold dark night and crowning the Spinneret the new Homecoming Queen!
... or will 5.1 be built in layers that will let you stop when you have gone as far as your target board allows leaving you with the core of 5.1?
An aside here ... I wonder if KenG et al. at Parallax realize what a monster they have created in the Spinneret. I defy anyone to build up a $20 PropProto to a Spinneret equivalent for less than the $60 bucks it costs. If they come up with a WiFi version it will a grand slam home run.
i C@ dup dup bl < swap 7f > or if drop 2e then emit
I think what you are seeing has to do with the TERMINAL program treats ASCII special characters. That is, in one mode the terminal treats all the ascii codes as character to display, and in another mode, the terminal treat characters outside the "normal" ranges (a-z, 0-9, etc) as command codes. Example is value 8 (tab) is "displayed" as BEL and the bell rings (or keyboard beeps), or whare the CF and LF make cursor position change versus displaying the tiny CR LF characters.
Since a given byte can have any value based on bit pattern, 0-255 decimal or 0000 to 1111 binary, about half the time values are those that can be control codes.
The solution you have found changes the "command code" range of values into something that gets displayed as a period. (Just glancing). This is a good way to do it, the dump looks better but we don't see a uniqe character dipsated for each byte value.
The other alternative is to change the terminal program to display command codes instead of interpret command codes. This is easily done, (I did it years ago for the blue ADM VT100 compatiable terminal I worked on in 1987). BUT each terminal program can be different, and it is not necessarily standardized (yet) so Sal did not put this feature in the kernel. If you want to get fancy, the dump program can be modified such that it tells the terminal to change its display mode from "interpret ASCII special characters" mode to "display ASCI spacial characters" mode. This is on my long list of things I am supposed to do but am putting off until the kernel is released.
Its a good excersise in terminal emulator if you or anybody wants to do this extension.
I PF, unchanged save for conflicting pin numbers, should run on any Propeller board.The coming development with the dictionary on the SD card ... Demo Board ... Spinneret
.....
build up a $20 PropProto to a Spinneret ....
OK. You got it nailed.
1) Propforth will always run on ANY existing prop chip to date, regardless of EEPROM memory, from 0 to N k bytes. While propforth supports ROMless slaves, and externded EEPROM, the default kernel to date will always work on the stock demo board and stock protoboard.
2) To load propforth.spin and boot to forth from power up, at least 32k eeprom is required. This is always the default.
3) TO USE EEPROM FILESYSTEM, etc, 64k EEPROM or greater is required. EEPROM files system and EEPROM storage are ALWAY an extension, due to (2)
4) SD support is an extension. The demoboard can load the deafult kernel, add the SD support extension, saveforth, and now contain SD support at boot time. The demoboard can boot and run boot-time scripts as described in the SD regression tests.
5) SPINNERET is being incorporated into the Standard Hardware Testbed to allow a) ethernet access to the target application and b) internet debugging abilities to the testbed. Particularly by Sal on my hardware, with Sal in his lab in Vancouver and my hardware with me in my lab in Chicago. Sal got tired of waiting for me to ship my hardware to him when I have a bug, and tired of paying return shipping. With the EEPROM hardware questions raised in issue 22, we realized that debuggin hardware issues was not limited to me only, and merited a general solution. After 5.1, Sal (or anybody else) will be able to provide debugging over internet, and it will behave exactly as if the unit was on his desk in his shop. (we have to cyce power for him, but that's it). No questions, no waiting. Sal can "just look at it and fix it" much faster than asking question over email, wait for answer, determine answer makes no sense, clarify question, email new question, wait two days, etc. SPINERET configuration is OPTIONAL and will only be required for folks that want Sal to look into their hardware. But, it will also be very handy if folks want to learn propforth by running theregression tests and following the tutorials. Perhaps the BIGGEST advantage of the standard test bed is allowing all users to take advantage of automated regression tests, which totally awsome and high tech. Regression test in general, and automated regression test in particular, are to software as interchangable parts were to manufacturing. To paraphrase Dr. Kleiner, "I can't put enough undue empahasis on the importance of" automated regression test.
6) I have a w5100 board from sparkfun which was used in the original spinforth telnet demo. protoboard + w5100 should be equivalent to spinneret, but I never finished getting it working. The cost is from the wiznet chip. It might turn out to be cheaper to just buy a second spineret, but this will not a priority issue until 5.1 is imminent.
One of my projects is aimed at a small prop board taking a few measurements and then setting a couple switches based upon those measurements. I didn't want to have to lug a laptop around to check progress, I wanted a 4 line by 20 char serial enabled LCD.
Sal gave me some code to get me started and I have been fooling around with it for several days. What I have here is a set of basic words to initialize the serial process in its own cog and words to make and break the iolink that mirrors the main console out to the serial LCD. I have a string print routine and a screen clear. Still to be done is formatted number displays.
fl
\ fswrite lcdserlnk.f
{ LCD Serial Link
Routines to setup a serial process in a cog to permit
writing to a serial enabled LCD. You initialize the
serial cog with 'startLCD' and display text with
'strlnk' (still to be completed - routines for formatted
numbers). All display routines start with a 'maklnk' and
conclude with 'brklnk', which, effectively, turns console
mirroring on then off.
3 October 2011 Brian Riley, Underhill Center, VT, USA
}
{
create console link to LCD using cog 4
maklnk ( -- )
}
: maklnk 4 cogid swap iolink ;
{
break console link to LCD
brklnk ( -- )
}
: brklnk cogid iounlink ;
{
display string ( cstr -- )
- based upon string write word from CasKaz's parallel LCD
routines
- the 10 ms delay just before brklnk MUST be there to give
the iolink routines time to flush its buffer
}
: strlnk
maklnk
C@++ dup if bounds do i C@ emit loop else 2drop then
10 delms brklnk cr
;
{
clear/home screen of LCDpa
clrlcd ( -- )
- "?f" is the string for a Peter Anderson serial
LCD chip, edit this to your flavor
}
: clrlcd c" ?f" strlnk ;
{
initiate serial process in cog 4
startLCD ( -- )
- by using the same pin spec for tx and rx, pin 7,
you get a simple loopback and mirroring of main
console whenever iolink is active
}
: startLCD
7 7 19200 4 startserialcog
10 delms
clrlcd
;
...
Comments
I did to use SDSC(512MB,256MB) on sd_driver.
I tested on QuickStart board.
sd_driver_modify_0.1's using pin are P0 - P3.
I use micro 2GB on protoboard's system-SD.
fat-viewer(another SD-card adapter) use sdsc-driver.
If you never use SDSC(512MB,256MB), this don't need.
Using SD-card(SDSC) is 512MB.
Zterm version 1.2 is available free at http://homepage.mac.com/dalverson/zterm/. It's not cripple ware and he accepts 'registrations.' I had been using Zterm for 12 years, so I made a donation. I was impressed that he bothered to update 15 year old software.
Great news. I'm on a slow road to conversion to Mac and have been looking for a terminal program to use with PropForth!
... and if we do that word right there will be a loop that will look for a keystroke or a pin setting to let us regain control ... or not, if we want it bulletproof.
ONBOOT is the word that is executed at boot time. You can define this word how ever you need. Examples in SD and spineret regression tests.
I have question. I expected [ST:0000000002 0000000002]
Why?
I'm confused.
r> is "pop top of RS to stack" and >r is "push stack top to RS" ?
But 1 >r result error.
How to use r> and >r?
Hi caskaz
The return stack can ONLY be use WITHIN A DEFINITION. If you use the return stack from the command line, you break the interpreter.
>r (to-return stack) puts a value (from top of data stack) on the return stack. You can only put your temporary values on the return stack within a functin definition.
r> (from-return stack) takes a value off the return stack (and puts it on top of data stack). You can only take values off the return stack that YOU previously put on there.
@r copies the top value off the return stack (to the top of the data stack), but also leaves it on the return stack
YOU MUST consume all the values you put on the return stack before the function ends, or you can crash the interpreter.
In your command line tests above, once it did not crash the interpreter, and once it did crash. In both cases the interpreter was broken, all further execution is undefined, and the prop needs a reboot.
I think this is the correct example for what you want to do.
Best advise: Be care with the return stack, only use it when there is no other way.
http://lars.nocrew.org/dpans/dpans3.htm#3.2.3 See 3.2.3.3 Return stack
Improved response:
: old-boot onboot ; <- define a word "old-boot" to do the previous (required) boot-time behavior
: onboot old-boot MyApplication ; <- make a new definition "onboot" to to call the previous boot behavior word, and to call you application word.
At boot time, propforth looks for the most recent definition of onboot, and calls that. the old-boot definition sets up the last of the house keeping, and turn control back to the interpreter.
If there is no word in the input stream, it drops back to the command line.
If your word MyApplication is there, My Application begins executing.
If MyApplication crashes or terminates unexpectedly, it can be made to drop back to the command line.
There is another option to make the kernel HALT upon termination of MyApplication, so that the user does not get access to the interpreter in the event of a crash (for security, etc) but I never use this and I don't know exactly how to set it up. If you need this we can ask Sal when he gets back from his journey, hopefully this month.
In PF 4.6 I see words
onboot
onreset
onreold - (old-onreset ?????)
onbold - (old-onboot ?????)
reboot
reset
Please differentiate, tell me hardware and software conditions under which they come to play.
Am I correct in saying that power cycling and the word 'reboot' are one in the same as far as PF is concerned? The word 'reset' seems to reset current cog .. what else does it do?
I will play with them and write up an AppNote/HOW-TO and submit it to the wiki and you can see if I got it right
OK, I played with this, found out 'the hard way' what happens when you do not include the old onboot word as part of the new onboot word ... PF goes faaaarrrr away! I had to redo the kernal and fs all over again.
I understand onboot and onreset, but I still need coming up to speed for onbold and onreold.
It appears to me now that 'reboot,' power cycling and, hardware reset switch all bring the same software results.
I THINK:
onboot - does the last word that needs to be executed to start the kernel (interpreter, quit loop, stacks) at boot time. This needs to be done before your application word,
onbold - Sal is "old school" in that it seem imperative to to save a single byte in every weird place, but I guess they add up. onbold is what I would call old-onboot or onboot-old; FYI - Sal pronounces "onbold" as "onboot-old" in discussions.
There IS a difference between onboot and onreset, etc; although I don't know what it is, although each assumes and performs a different level of initialization. I DO know that it is NOT safe to assume the executing any software word is the equivalent of a power cycle. (although I do accept that hardware reset is as effective as power cycle) IE, if something crashes or otherwise goes south, power must be cycled to ensure the issue has been cleared. Perhaps its a ham-fisted approach, but even Sal gets caught where these words do not resolve an execution error, when he thought they would. And this is not a limitation of forth, I'm pretty sure it applies to any micro controller application. But I'm a "nuke them from orbit, its the only way to be SURE" kind of a guy.
I built up USB-Host curcuit by using MAX3421E.
I refered MAX3421EKIT's curcuit.
And I translated maxim's sample code to PropForth.
When connected mouse, it seems to work finly.
But USB-memory and scanner don't work.
On Send_packet inside max3421e_0.11_1.f, when executed "80 19 Hwreg" response is 0xd(hrJERR).
Anybody know solution about hrJERR?
If you take an interst in MAX3421E, I recommend sparkfun's board.
http://www.sparkfun.com/products/9947
I don't know the device, but if you are running PropForth4.6 and if you have your the SDdriver running in Cog 0, try 0 cogstop before you test your code.
Just a suggestion
cheers
ron.
I tried below;
1.Wires betwen USB A-type connector and MAX3421E(pin20[D-] pin21[D+] replaced twisted wire.
2.I replaceed to propeller NCO-pulse although clock was used ceramic resonator(12MHz) as MAX3421E's clock.
3.USB A-type connector's shield was tied to GND.
But FullSpeed Device error occure.
And I found out Full Configuration Descriptor is strange.
(End point Descriptor is strange)
Ron, SPI for MAX3421E don't use SD's line.
http://code.google.com/p/propforth/w/list
Summary:
- pf 5.0 will use the existing hardware configuration for the test bed, and have no test automation implemented. ETA is a couple weeks.
- ETA for pf 5.1 is tentatively targeted for Decemberr 2011. pf 5.1 will consist of a new general hardware configuration that supports full test automation, and demonstrates correct operation of all supported functions. So the regression tests will serve as verification of correct function, examples of use-cases, and training tutorial for intended use of each function. Support will be based on this model. It looks like there will be two spinneret boards (or wiz5100 equivalent) and four "bare" prop chips, and assorted wires and resistors for MSC (highspeed multichannel serial) and regular RS232 serial. This will allow immediate, non-invasive over internet diagnostics and debugging. There is also a possibility of scaled cooperative multiprocessing on this configuration, but implementation will be left to a later release.
I think my mistake use NCO to supply MAX3421E's clock.
Protoboard's Xstal is 5MHz.
So NCO output 11999999.99254942Hz.
This cause jitter.
It seems to be ok on LowSpeedDevice.
But not good on FullSpeedDevice.
Using NCO to supply MAX3421E's clock need to replace Protoboard's Xtal to 6MHz.
And PropForth.spin must be also modified.
I orderd Xtal(12MHz) for MAX3421E.
That sounds similar to other threads reporting USB needs a 6Mhz clock. Did you check how other projects accomplished this? They might have some help for you.
In a recent post on the PFIG thread you said ....
Indeed PropForth is a 'great work, in progress.' Documentation is critical, but from a new user standpoint, we no more get done fully wading through and digesting what documentation there is, than its obsolete. Version 4.x has been replaced by 4.x+1, 20 core words have changed and everything has been restructured.
Now, as a volunteer on the documentation effort, I cannot tell you how many times I have blessed as opposed to cursed my procrastination tendencies, when a HOW-TO I had mentally sketched out would have been wasted because of revisions.
In my gut I get the feeling that 5.0/5.1 is getting us near a relatively stable configuration ... but WHO KNOWS what stroke of divine inspiration the mad genius, Sal Sanci, will have between now and New Year ??!!??!!
I realize we are guests and beneficiaries at the creation of PropForth. But maybe if we had a better idea of where we are going it would help our support efforts. Does 5.1 look like stable configuration or just a way point on the journey?
The 5.x release is intended to be the final version of the kernel. Sal is pretty accurate with his development and release path.
5.0 will take all the pieces up to and including the paged assembler, and make single unified package. So all the functions that have been demonstrated are to be optimized and included. To reduce the number of unknowns, we are using the "old" (existing) hardware test bed configuration and no test script automation.
5.1 will consist of a new hardware test bed configuration to support automated regression testing. This test bed will allow non-invasive over the internet examination and debugging. It will also be the basis for the automated regression suites. Of course the test bed will be optional. But if you want to run the "stock" regression tests like Sal and I do, this would be where to start. It would also allow someone like Sal to diagnose a running system over the internet, the model is "on-site consulting without travel".
With the 5.x release, we expect the kernel to be stable. Somewhere after 5.0 we will also begin scrubbing the bug list (functions are already implemented) and the documentation (to catch up this the changes). The plan also includes scrubbing the previously release functions, such as VGA (HiRes and LoRes) support, JupiterACE, Hive, debugger, disassembler, etc and bringing all these up to 5.x kernel, and add tests and documentation.
The final step will be to take all the existing non-kernel functions (extensions) from caskaz, Nick, Ron, you, me, and the others and roll them into the regression test suite(s) and make a single download archive package that is periodically re-released as additions are made. By the final step, the entire project should be less of a "Sal's tool" project and more of a "group project" where we all contribute to the regression suite.
I don't know when this will finally happen or if it will work out as described, but that's the idea.
... or will 5.1 be built in layers that will let you stop when you have gone as far as your target board allows leaving you with the core of 5.1?
An aside here ... I wonder if KenG et al. at Parallax realize what a monster they have created in the Spinneret. I defy anyone to build up a $20 PropProto to a Spinneret equivalent for less than the $60 bucks it costs. If they come up with a WiFi version it will a grand slam home run.
I found out ascii-characters are strange with using "dump".
I re-wrote WORD"(dumpe)".
I think what you are seeing has to do with the TERMINAL program treats ASCII special characters. That is, in one mode the terminal treats all the ascii codes as character to display, and in another mode, the terminal treat characters outside the "normal" ranges (a-z, 0-9, etc) as command codes. Example is value 8 (tab) is "displayed" as BEL and the bell rings (or keyboard beeps), or whare the CF and LF make cursor position change versus displaying the tiny CR LF characters.
Since a given byte can have any value based on bit pattern, 0-255 decimal or 0000 to 1111 binary, about half the time values are those that can be control codes.
The solution you have found changes the "command code" range of values into something that gets displayed as a period. (Just glancing). This is a good way to do it, the dump looks better but we don't see a uniqe character dipsated for each byte value.
The other alternative is to change the terminal program to display command codes instead of interpret command codes. This is easily done, (I did it years ago for the blue ADM VT100 compatiable terminal I worked on in 1987). BUT each terminal program can be different, and it is not necessarily standardized (yet) so Sal did not put this feature in the kernel. If you want to get fancy, the dump program can be modified such that it tells the terminal to change its display mode from "interpret ASCII special characters" mode to "display ASCI spacial characters" mode. This is on my long list of things I am supposed to do but am putting off until the kernel is released.
Its a good excersise in terminal emulator if you or anybody wants to do this extension.
OK. You got it nailed.
1) Propforth will always run on ANY existing prop chip to date, regardless of EEPROM memory, from 0 to N k bytes. While propforth supports ROMless slaves, and externded EEPROM, the default kernel to date will always work on the stock demo board and stock protoboard.
2) To load propforth.spin and boot to forth from power up, at least 32k eeprom is required. This is always the default.
3) TO USE EEPROM FILESYSTEM, etc, 64k EEPROM or greater is required. EEPROM files system and EEPROM storage are ALWAY an extension, due to (2)
4) SD support is an extension. The demoboard can load the deafult kernel, add the SD support extension, saveforth, and now contain SD support at boot time. The demoboard can boot and run boot-time scripts as described in the SD regression tests.
5) SPINNERET is being incorporated into the Standard Hardware Testbed to allow a) ethernet access to the target application and b) internet debugging abilities to the testbed. Particularly by Sal on my hardware, with Sal in his lab in Vancouver and my hardware with me in my lab in Chicago. Sal got tired of waiting for me to ship my hardware to him when I have a bug, and tired of paying return shipping. With the EEPROM hardware questions raised in issue 22, we realized that debuggin hardware issues was not limited to me only, and merited a general solution. After 5.1, Sal (or anybody else) will be able to provide debugging over internet, and it will behave exactly as if the unit was on his desk in his shop. (we have to cyce power for him, but that's it). No questions, no waiting. Sal can "just look at it and fix it" much faster than asking question over email, wait for answer, determine answer makes no sense, clarify question, email new question, wait two days, etc. SPINERET configuration is OPTIONAL and will only be required for folks that want Sal to look into their hardware. But, it will also be very handy if folks want to learn propforth by running theregression tests and following the tutorials. Perhaps the BIGGEST advantage of the standard test bed is allowing all users to take advantage of automated regression tests, which totally awsome and high tech. Regression test in general, and automated regression test in particular, are to software as interchangable parts were to manufacturing. To paraphrase Dr. Kleiner, "I can't put enough undue empahasis on the importance of" automated regression test.
6) I have a w5100 board from sparkfun which was used in the original spinforth telnet demo. protoboard + w5100 should be equivalent to spinneret, but I never finished getting it working. The cost is from the wiznet chip. It might turn out to be cheaper to just buy a second spineret, but this will not a priority issue until 5.1 is imminent.
I updated worddump.
Sal gave me some code to get me started and I have been fooling around with it for several days. What I have here is a set of basic words to initialize the serial process in its own cog and words to make and break the iolink that mirrors the main console out to the serial LCD. I have a string print routine and a screen clear. Still to be done is formatted number displays.
Enjoy ...
@Ron
Sal has started looking at Issue 53. He needs some details on the hardware
Could you add comments directly to issue 53?
Thanks!