Code Monkey home page Code Monkey logo

p2-spin-standard-library's Introduction

The P2 Spin Standard Library

The P2 Spin Standard Library is designed to be a general-purpose library with a wide scope of functionality, covering low-level I/O, text processing, device drivers and more for the Parallax Propeller 2 (P2X8C4M64P) MCU. It contains a curated collection of Spin2 objects that have been organized and formatted with a focus on consistency and code reusability.

Usage

There are no special installation steps that need to be carried out, besides downloading this repository. The only salient step is that the library/ subdirectory should be set in FlexSpin's path, using the -I flag on the build commandline.

For example:

flexspin -I /home/myhome/p2-spin-standard-library/library demos/com/Serial-HelloWorld.spin2

API

An ongoing effort is being made to standardize the API for the various device drivers and other objects contained in the library. Manufacturers may not all utilize the same design methodologies and the interface they expose to developers may differ, but this library aims to distill all of it to a common programming interface. Essentially, once you've learned how to operate a particular device driver, all others of the same category would require minimal or no extra effort to learn.

Decriptions of the programming interface for the various classes of library can be found in the API subdirectory. At the time of this writing, they are:

  • display: Displays, e.g., OLED, LCD, VGA
  • driver-basic-structure: Describes common conventions used throughout device driver object files
  • graphics.common: Generic bitmap graphics routines common to dot-matrix type displays
  • input.encoder: Various encoders used for position input data
  • input.pointer: Various pointing devices, e.g.: mouse, trackball, trackpad
  • memory: Various memory technologies, e.g.: EEPROM, FRAM, SRAM, Flash
  • sensor.co2: Carbon dioxide sensors
  • sensor.imu: IMUs and other motion-related sensors, e.g., accelerometers, gyroscopes, magnetometers
  • sensor.power: Sensors for measuring the flow of electricity, power usage
  • sensor.temp_rh: Temperature and humidity sensors
  • signal.adc: Analog to Digital Converters
  • time: Timekeeping device drivers (hardware and emulated), e.g.: RTC
  • wireless.transceiver: RF Packet radios for sending and receiving data wirelessly

Directory structure

  • api/: Descriptions of the Application Programming Interface for each category of object.
  • library/: The library itself - this should be added to the compiler's library path (e.g. flexspin -I/path/to/spin-standard-library/library).
  • library/demos/: Basic demonstrations of drivers and other objects. Utilizes only what's necessary to demonstrate the core functionality of a driver (such as a serial terminal object to display the data). Example: a demo of a sensor will display sensor data on the terminal.
  • library/examples/: More complex demonstrations, forming rudimentary but specific applications. May utilize more objects as needed to demonstrate specific functionality (such as an OLED or LCD). For example: using accelerometer data to produce an inclinometer.
  • library/templates/: "Skeletons" of source code that can be used as a template for an application, or object.

Potential users

I don't recommend the use of this library if you're new to programming, in general. It makes assumptions about some things that an inexperienced programmer may simply not understand, and I don't have the time to maintain the library and support that level of inexperience simultaneously. I'd also hesitate to recommend it if you're looking for code of the utmost efficiency and speed. Consistency and reusability is my primary objective.

Compiler compatibility

The library is developed using FlexSpin. Some objects use features not implemented in other toolchains, such as preprocessor directives, function pointers, object pointers, et al, so will not be compatible with the Propeller Tool, OpenSpin, Brad's Spin Tool/bstc, all of which are unmaintained and in some cases closed-source. Objects in the library may even be written in such a way that the compiler feature is fundamental to the design of the object (this is particularly true with the use of function and object pointers), making it impractical to translate to other toolchains.

Currently, efforts are made towards making sure that the objects build and work when using the PASM2 backend as opposed to the NuCode (bytecode) backend, though now that more software seems to be compatible with it, this could change.

Upon specific request, I may be able to translate to Propeller Tool-compatible source if absolutely necessary. If the source is particularly complex I may decline the request, however - sorry. Please save yourself and me the time and headache - just use FlexSpin. It's available for all major platforms and is actively maintained. Nearly every project in this library is also maintained as SPIN1 in the spin-standard-library for the Propeller 1, which requires twice the time and effort, so please also keep this in mind before asking for support translating to source compatible with other tools. Thanks for understanding !

Testing

You can compile every file in the project with the following script.

./test.sh

Note that some individual drivers may (expectedly) fail to build, if they utilize preprocessor features. This will be reworked in the future.

License

This project is licensed under the MIT license.

Please note this library isn't officialy sanctioned by Parallax, Inc - it is a fork of the original spin-standard-library that has been ported to the Propeller 2.

p2-spin-standard-library's People

Contributors

avsa242 avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

p2-spin-standard-library's Issues

string.integer: HexToStr hangs

The HexToStr() method currently hangs, so methods that use it do as well. Adding to it a call to another method (any) seems to make it work. It seems to be a bug in fastspin, but this has yet to be proven.
A temporary workaround has been added: the first statement of the HexToStr method now calls an empty method aptly called NoOp(), which simply returns nothing.

Hexdump(): highlight range

Add a variant that can highlight (using terminal colors) a user-specified value or string (e.g., for display of something like a memory search).

com.mdio.sme.spin2: Review for correctness and clarity

Just noticed a few things when looking this over:

  • some lines note an io pin is being floated, but the actual instruction used drives it high. Confirm which behavior is actually correct and make the two consistent with one another.
  • some variable names, e.g., _period aren't quite right (really more of a half-period). Review and rename these.

com.i2c.spin2 fails to build (NuCode)

com.i2c.spin2:243: error: Unhandled node type 87 in NuCompileStatement
(may be others)

Find out if this is a legitimate bug in com.i2c.spin2 or a bug in/something that just hasn't been implemented in FlexSpin's NuCode yet.

Parallel I/O engine requires RD line definition

The way it's currently written, the RD mask is set to output/high, regardless of what it's set to. There should be a check for whether this is defined as a valid pin or not, and if not, leave it alone. Read support isn't currently implemented for the only driver that uses this anyway.

Graphics demos: add minimal demos

Add several simple demos that show minimal amounts of code required to get up and running.

UPDATE:
These should also minimize usage of extra features like the preprocessor, so all of the code is visible in one file.

Add repeated-write methods to I2C, SPI engines

Methods to repeatedly write the same byte, word, or long to the device should be added to the I2C and SPI engines. This is useful e.g., for fast fills in a display driver, when a large display buffer can't be used.

Serial driver has no buffering

Despite its speed, the async serial engine can still drop characters at higher data rates. This is noticeable in, e.g., the zmodem object, where line speeds greater than approx 38.4kbps aren't usable because of dropped data.
Implement some sort of optional buffering mechanism.

Certain display types should have a distinct demo

Some display types simply aren't suited to the existing generic GFXDemo.spin, because of e.g. their relatively low pixel count, or a technical reason such as the low refresh nature of electrophoretic displays.

More suitable generic demos should be created for these.

  • Low-res dot-matrix displays
  • Electrophoretic/E-ink/E-paper displays
  • Alphanumeric displays (e.g., 2x16, 4x20)

Graphics drivers FTBFS when GFX_DIRECT is defined (since new common putchar() implementation)

Since the putchar() changes in graphics.common.spin2h, any graphics driver that provides its own putchar() when GFX_DIRECT is defined won't build. It used to be a single function that was built conditionally, but is now a function pointer.
Review each driver to see if it makes sense to even have its own putchar() any longer (at least some of them use whatever plot() is defined as to do the drawing, so it's not as though they're bringing their own pixel drawing code).

Display demos (dot-matrix) broken since common graphics code update

This was done to update one display driver in particular to improve the text handling. Since the API has changed a bit, all of the other graphics driver demos will be broken. These will be fixed soon.

  • ssd130x
  • ssd1331
  • ssd1351
  • st7789
  • ili9341
  • qvga
  • ht16k33
  • hub75
  • il3820
  • il3897
  • smartled

digits parameter ignored in most terminal I/O methods

This was never implemented for any of the binary or decimal number output methods. Only the small implementation of the hexadecimal number output actually supports this.
The number output from these methods is still correct, but there is no padding as indicated by the comment in each method.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.