[Contest Entry] Ethernet interactive development and application portal
prof_braino
Posts: 4,313
Summary: Propforth is used to implement Ethernet interactive development and application portal for one or more props. Application may be accessed remotely for control, monitoring, and development. A host PC is not needed for development after the intial install of the propforthkernel.spin; only a terminal is required (eg. DIGITAL VT100 of similar). Access via terminal emulation on a wireless "smart" phone has been demonstrated.
Supported Functions:
IP support in propforth provides Ethernet access to the propforth interpreter via telnet. This permits development over the web via a telent session.
Use-model is that the spinneret is connected to the target device(s) to control/monitor the target remotely via the web. Four telnet sessions are supported; including the serial session, five simultaneous interactive session are supported by default
RTC support provides realtime clock and NTP synchronization.
Async serial support in propforth provides arbitrary serial channels on any i/o prop pins. This allows one or more props (or any other device) to be connected via a ordinary asynchronous serial connections. We have found 56700 baud to be adequate using long plain wires during testing, but rate up to 115200 were made to work without excessive care. Use-model is that the spinneret is connected to a target driven by another prop to control/monitor the target remotely via the web.
Multi-Channel High Speed Synchronous serial Support provides continuous transfer of 96 bit packets at clock speed between a Master prop and a Slave prop. This allows one or more additional props to be slaved to the master to increase pin and cog resources. The interfacing to the slave is identical to interfacing to the master for user and application.
SD support provides access to an Secure Digital flash card for storage. Propforth treats the SD card as "internal to propforth". This eliminates the need for FAT support and allows access to be fast and small. Of course, this renders the card itself incompatible directly to Windows, it must be accesses via the propforth unit. But SD card being inexpensive, this was not considered an obstacle. The SD card is used as a collection of traditional forth "blocks" 1k in size. Files are a collection of blocks, and can support create, modify, delete, append, directories, and partitions. A given SD card can have exactly 1 file open, but each cog may access many files in sequence. Collisions have not been a problem.
SD support includes "Execution From File". A file may contain FORTH source code, and be loaded and executed. This allows construction of applications of arbitrary size. Since the code is executed from the file, it does not have to occupy dictionary space in the prop's 32k memory. Only execution results need be managed, these may be stored in files on the SD for later use. In cases where files contain additional forth definitions (for clarity of organizational purposes, perhaps) the definitions can be "forgotten" after use, to free the dictionary space.
HTTP server support allows serving web pages over the internet. Web pages may be of arbitrary size if saved on SD or generated on the fly. FORTH words may be executed from web pages, so java type functionality may be implemented by the user. (this has not been fully explored but small examples are provided). An interactive forth session via HTTP is planned but has not been implemented at this time.
Regeneration of Kernel or application from source. The propforth kernel can regenerate its own image or a modified image from source. This permits a more sure remote update, as only the altered source code text need be transmitted, rather than the entire pre-compiled image. Thus the transmitted changes can be verified before the update process is initiated. This technique has been proven reliable in "non-retrievable" and "non-accessible" applications and high security applications, such as space probes and military applications.
USE-CASE 1 Spinneret as controller - Application runs on Spinneret directly, and is monitored, controlled, and reprogrammed via Ethernet.
USE-CASE 2 Spinneret as access mode - Spinneret connects to target embedded controller to provide Ethernet access "as needed"
USE-CASE 3 Spinneret as Ethernet access in multi-prop configuration - multiple prop chips in single logical configuration to provide more than 8 cog and more than 32 i/o pins in a single application.
Usage example 1: An iPhone running telnet Mocha Lite is used with a wireless access point to reach the Spinneret. The Spinneret dictionary is extended and the changes saved to EEPROM. On reboot, the changes are present.
Usage example 2: An iPhone running Safari is used with a wireless access point to reach the Spinneret. The Spinneret HTTP files are updated (via normal means) and the changes saved to SD On reboot, the changes are present.
Supported Functions:
IP support in propforth provides Ethernet access to the propforth interpreter via telnet. This permits development over the web via a telent session.
Use-model is that the spinneret is connected to the target device(s) to control/monitor the target remotely via the web. Four telnet sessions are supported; including the serial session, five simultaneous interactive session are supported by default
RTC support provides realtime clock and NTP synchronization.
Async serial support in propforth provides arbitrary serial channels on any i/o prop pins. This allows one or more props (or any other device) to be connected via a ordinary asynchronous serial connections. We have found 56700 baud to be adequate using long plain wires during testing, but rate up to 115200 were made to work without excessive care. Use-model is that the spinneret is connected to a target driven by another prop to control/monitor the target remotely via the web.
Multi-Channel High Speed Synchronous serial Support provides continuous transfer of 96 bit packets at clock speed between a Master prop and a Slave prop. This allows one or more additional props to be slaved to the master to increase pin and cog resources. The interfacing to the slave is identical to interfacing to the master for user and application.
SD support provides access to an Secure Digital flash card for storage. Propforth treats the SD card as "internal to propforth". This eliminates the need for FAT support and allows access to be fast and small. Of course, this renders the card itself incompatible directly to Windows, it must be accesses via the propforth unit. But SD card being inexpensive, this was not considered an obstacle. The SD card is used as a collection of traditional forth "blocks" 1k in size. Files are a collection of blocks, and can support create, modify, delete, append, directories, and partitions. A given SD card can have exactly 1 file open, but each cog may access many files in sequence. Collisions have not been a problem.
SD support includes "Execution From File". A file may contain FORTH source code, and be loaded and executed. This allows construction of applications of arbitrary size. Since the code is executed from the file, it does not have to occupy dictionary space in the prop's 32k memory. Only execution results need be managed, these may be stored in files on the SD for later use. In cases where files contain additional forth definitions (for clarity of organizational purposes, perhaps) the definitions can be "forgotten" after use, to free the dictionary space.
HTTP server support allows serving web pages over the internet. Web pages may be of arbitrary size if saved on SD or generated on the fly. FORTH words may be executed from web pages, so java type functionality may be implemented by the user. (this has not been fully explored but small examples are provided). An interactive forth session via HTTP is planned but has not been implemented at this time.
Regeneration of Kernel or application from source. The propforth kernel can regenerate its own image or a modified image from source. This permits a more sure remote update, as only the altered source code text need be transmitted, rather than the entire pre-compiled image. Thus the transmitted changes can be verified before the update process is initiated. This technique has been proven reliable in "non-retrievable" and "non-accessible" applications and high security applications, such as space probes and military applications.
USE-CASE 1 Spinneret as controller - Application runs on Spinneret directly, and is monitored, controlled, and reprogrammed via Ethernet.
USE-CASE 2 Spinneret as access mode - Spinneret connects to target embedded controller to provide Ethernet access "as needed"
USE-CASE 3 Spinneret as Ethernet access in multi-prop configuration - multiple prop chips in single logical configuration to provide more than 8 cog and more than 32 i/o pins in a single application.
Usage example 1: An iPhone running telnet Mocha Lite is used with a wireless access point to reach the Spinneret. The Spinneret dictionary is extended and the changes saved to EEPROM. On reboot, the changes are present.
Usage example 2: An iPhone running Safari is used with a wireless access point to reach the Spinneret. The Spinneret HTTP files are updated (via normal means) and the changes saved to SD On reboot, the changes are present.