Propeller Functions Library
jazzed
Posts: 11,803
Hello everyone.
We need to define a library of Propeller functions.
This is a good opportunity for the Alpha community to contribute.
First, we need a list of functions and their Application Program Interface (API)
Then we need to write code for the functions.
A starting point is the Arduino library of functions.
We may add other library functions having PBASIC names.
The Arduino library includes some PBASIC-like functions already.
Please look at this page and think about the arduino functions.
We need a name for our library. Please make suggestions.
Thanks,
--Steve
We need to define a library of Propeller functions.
This is a good opportunity for the Alpha community to contribute.
First, we need a list of functions and their Application Program Interface (API)
Then we need to write code for the functions.
A starting point is the Arduino library of functions.
We may add other library functions having PBASIC names.
The Arduino library includes some PBASIC-like functions already.
Please look at this page and think about the arduino functions.
We need a name for our library. Please make suggestions.
Thanks,
--Steve
Comments
have you in mind a pure C++ Library or a "smaller" C Lib, usable on all <mlmm> targets ?
Reinhard
When comparing the Propeller to the Arduino and other controllers, I've always been jealous of the "built-in" support for SPI and other simple serial protocols. It would be neat to have a library that can do what the Bus Pirate can do (see http://dangerousprototypes.com/docs/Bus_Pirate and http://dangerousprototypes.com/docs/Bus_Pirate) and allow you to control an arbitrary I2C, SPI, 1-wire, and/or raw serial device by declaring the pins and protocol after which you can just send/receive bytes/commands without worrying about the bit-banging.
That is one thing i miss about the Picaxe too. Being able to just go 'readtemp memory_location, pin' Of course that is just me being lazy though
There is a thread by Pedward implementing Arduino Library Functions.
http://forums.parallax.com/showthread.php?136139-CODE-RELEASE-v1-SPIN-objects-to-implement-Arduino-compatible-functions&highlight=arduino
Tom
Reinhard, we are looking at a smaller C library first. Of course functions can be leveraged into C++ for using Serial.read() for example later.
tdlivings, Yes I've seen that. It's a great idea to have for SPIN - maybe we can just port that code and/or use it for a reference.
Yes, I'm enthusiastic about any device any pin also.
In both cases that is C++, which need not imply the libs are getting huge.
The picaxe style API seems like something of a disaster and does not fit well with the C style of open, read, write, close.
My main point really is that we don't have a good general purpose library and we need one.
The arduino library is a nice start, but it's not an end-all. We can easily make other libraries too.
The nice thing about a "library" is people don't have to look at source.
Many people consider that "easy" relatively speaking.
If i can get it to work is that something that could be added to your library? Is that something that would be of interest for you? I am still learning C and fairly new to programming at all, so i am not entirely sure if this is the sort of thing you are asking for.
remember myRobot Lib, I started last year.
http://forums.parallax.com/showthread.php?136358-myrOBOT-Library&p=1056674&viewfull=1#post1056674
Some parts are easy to port to another hardware ( e.g. the pinning for LCD )
But a general purpose with any function on any pin need a good requirement paper.
So I think it is very important to know what the "user" really need, before start coding.
However, if you are interesst, I am gladly disposed to do some contribution.
Reinhard
@sevs, one wire devices are good and anything you have to contribute is appreciated.
It would be great to get a library going that will serve everyone's needs in general ways.
One of Propeller's challenges is finding and showing people an "easy" way to select and use a device.
We have to solve "easy".
I would like someday to say "Propeller serves ABC features in one chip. Just get plugged in! Here's how!"
Dream?
Here is the attached zip.
Reinhard
Agreed about the Arduino libs. I particularly like the ones related to interrupts! (ducking, dodging and hiding)
While it would be nice if the source to the libraries were to remain "open sourced" I agree that the use of library functions make life a lot easier and a list of propeller specific library functions complete with syntax and usage info would be very helpful for those of us just getting started programming C/C++ on the propeller.
A little while back, I made a call for objects to "Goldify" to be put in the Gold Standard. This was also an effort to get an idea of what items people thought would be good to have in a library. When the time was right, I was going to put out a similar call to the community to get APIs for these rolling.
Below is a short compiled list:
===== From the Propeller Library =====
Debug_Lcd
FullDuplexSerial
Keyboard
mouse
TV
TV_Text
VGA
Synth
SPI_Spin
===== Suggestions from the forums ======
i2c
spi
sigma delta
clock
servo controller
stepper motor controller
real random
PID controller
compass/gyro/altimeter
RTC
ping
sd card
1-wire
pwm
Let's scrape the objects for methods and define Application Programming Interfaces (API) for them all.
This would be in addition to a generic interface like provided in other libraries mentioned above.
We can use much of the gold standard for C/C++ but not all.
Library source should have doxygen compatible self-extracting API comments.
Thanks,
--Steve
So...
The propeller.h and cog.h file need to have macros for every possible thing you may want to do with the hardware. I remember seeing a complete lack of macros to set SPRs up.
Then there should be libraries for all types of communication like SPI, I2C, 1 wire, serial, ADC, DAC, etc.
I would avoid making a bunch of libraries that repeat things given the limited C code space.
All upper level stuff should use the lower level libraries.
Making a mistake of coding all the libraries like the how they are in SPIN will cause people just to look away.
IT IS VERY IMPORTANT THAT THERE IS A SOLID FOUNDATION OF CODE FOR MANIPULATING THE HARDWARE AND DOING WHAT OTHER MOST MICROS DO! Avoid the VGA, TV, PS2, and etc. stuff until the solid base foundation is done.
Thanks,
...
For guidance... download and look at Microchip PIC libraries or Atmel AVR libraries... avoid the the throw away code style of the prop tool libraries.
Since you brought up some vague points, I hope you can clarify them.
I assume by SPR setup macros you mean being able to easily set CTRA mode and other bits. Are there other examples?
You need to be more specific. Are you talking about pretty coding style or some functional issue?
Propulsion. It helps you get that Propeller spinning, and moves your project forward.
BitSet - Sets a specific bit in an int
BitClear - Clears a specific bit in an int
SetDir - Clears/Sets a specific bit in DIRA
BitRead - Reads a specific bit in an int
Out - Sends a 1 or 0 out a specified pin. It automatically sets the DIRA bit to output.
In - Reads a specified pin. It automatically sets the DIRA bit to input.
Delay - Delays the program for n clocks of the system clock
PulseOut - sets or clears a specified pin for n clocks then inverts the pin
ShiftOut - Works just like the BS2 Shiftout and can handle 32 bits
ShiftIn - Works just like the BS2 Shiftin and can handle 32 bits
I2C_Init - Sets the sda and scl pins
I2C_IsDevPresent - Checks if there is a device at the given address
I2C_ReadAddrPage - Reads n bytes into an array at a given 16 bit address
I2C_ReadRegPage - Reads n bytes into an array at a given 8 bit register - untested
I2C_ReadPage - Reads n bytes from the first byte of device - untested
I2C_WriteAddrPage - Writes n bytes into an array at a given 16 bit address
I2C_WrieRegPage - Writes n bytes into an array at a given 8 bit register - untested
I2C_WritePage - Write n bytes from the first byte of device - untested
SPI_Init - Sets SPI pins and clock period
SPI - Sends/receives up to 32 bits in any of the 4 modes - not working?
Examples:
adc - uses SPI with a 3208 - Please test this since it doesn't seem to work
blink - blinks a led using PulseOut
clock - uses ShiftIn and ShiftOut with a 1302 clock chip
eeprom - uses I2C to read and write to an eeprom
led_demo - accidentally added. This was the first run of the library
nes - uses ShiftIn to read a NES controller
switch - uses In and Out to light an LED based on a switch on a PPDB
switch5 - reads Parallax's 5 position switch - doesn't use the library .... ooops
trackball - reads Parallax's trackball using In, Out, Delay.
---
For SPRs - I mean that you should have macros to set the CTRA/B registers to any mode already defined. There should be macros to set the FRQA/B registers for the given modes. Some might need to be functions to do the (32*32)/32 calculation needed to get the correct value to put into FRQA/B. Also there should be macros to access PHSA/B given the mode. The same think goes for all other registers.
---
There's a ton of hardware specific code in the propeller SPIN library (hardware that parallax sells). While that is good... it should not be in the main library distribution. Some standard should be imposed for the libraries... e.g. Gold Standard.
IDK... I've just always avoided using parallax's libraries. Something about them put me off. I can't put my finger on it though.
Thanks,
Oh Empathy!
Ok, gotcha. I assume the Propeller Data Sheet CTRx output and input modes are a good starting point. Would be nice for example to have a POSEDGE detector counter macro. Since you have some very specific ideas, it would be nice if you had time to write some macros for them - we can cover the rest.
I'm not crazy about the way it's done now because source code has to be changed to adapt different pin configurations. Other than that though, I believe that we should have device Hardware Abstraction Layer (HAL) code somewhere that can be easily plugged in - some people say Hardware Adaption Layer. I'm not advocating an O/S or other wild ideas be part of this since Propeller is an embedded device, but there should be some design to allow easily changing critical parameters such as pin numbers or other important device specific interface.
One model Ken Gracey and I discussed was a device drag-and-drop GUI maybe as part of an IDE. To support that though would require a minimum set of devices travel with the GUI. To me this would put Propeller in a more competitive position with devices that have a Micro=controller Device Selection GUI. That is, just let the user choose the software parts to plugin rather than having to choose 1 of a hundred variations of a chip.
I thought your schoolwork required you to write your own.
Thanks for your input!
--Steve
You've been busy! We may end up changing some names and adding more stuff, but you have a nice start with examples no less!
Thanks!
--Steve
Thanks,