SimpleIDE Libraries
Mike Green
Posts: 23,101
in Propeller 1
I've been having terrible problems with PropellerIDE's loader on my MacBook Pro. Most of the stuff I'd like to work on involves large executables ... close to 32K. The loader gets errors near the end of the download to almost any type of Prop1. I've gotten to where I compile on the MacBook and then startup Linux on a little HP laptop just to do the download. SimpleIDE seems to work better and I may transfer my attention to BlockyProp and C. I would like to be able to use some Spin library objects, particularly the 4-port serial driver, 1-wire driver, SPI flash driver, and others needed for the PKS (Propeller Keyfob System). Can someone point me to references on adding new assembly drivers to C and other suggestions for adding library routines. I'd like to make these additions compatible with BlocklyProp if possible. I know C although it's been years since I've used it.
Comments
In the first link below, Andy and a few others taught me how to turn the assembly language from the SPIAsm.spin object into a library function to be used in a C program with SimpleIDE (the spin object is in the Prop Tool Library).
forums.parallax.com/discussion/157441/can-spi-in-simple-libraries-be-speeded-up/p1
In the thread below, (near the end of the first page) I converted tonyp12's PASM 17 segment LED driver for the PPDB into SimpleIDE library functions.
http://forums.parallax.com/discussion/134106/updated-17seg-led-driver-for-ppdb-now-available/p1
As far as I know since these are separate libraries that are not in the SimpleIDE libraries, they can't be used with Blockly.
Tom
Just some clarification, are you trying to add the DAT section of existing Spin drivers, or are you writing brand new code using assembly, or are you writing brand new code that could be written in C or assembly, so long as it runs in COG RAM and acts like a "driver"? C/C++ certainly has a lot more options for how to do all this. If you're not up to speed with all the choices, feel free to say so and I can elaborate on all the different options.
It would be nice to get documentation on including assembly and C in libraries, rules for writing assembly, etc. I'm not really up to speed on anything other than simple C programs using SimpleIDE
instructables.com/contest/audio2017/?utm_source=newsletter&utm_medium=email
There is an older thread with regarding a similar question. There might be something useful in there for you:
67.104.29.60/discussion/155853/objects-in-spin-and-asm-can-use-in-c-program/p2
There is a 'spin2cpp' tool that you may find useful:
https://github.com/totalspectrum/spin2cpp
There are several examples of interfacing with pasm in these folders: I don't recall any formal documentation written for this type of project.
You would probably recognize what is happening in the examples looking at the pasm first.
--Steve
Curious, what versions of PropellerIDE/OS12/FTDI driver are you using on the MacBook Pro?
MacOS is latest beta of High Sierra although I’ve been having the same problem since Sierra.
The FTDI driver is the latest from their website. Same problem though with Apple’s driver.
I too have been running propellerIDE v0.33.3, on a 2015 MacBook Air, OS 10.12.3, with the latest FTDI driver. (Apple driver disabled). I tried the most recent release of PropellerIDE, but it locked up.
V0.33.3 does quite often fail on the first Run or Write attempt, but will usually go through for me on the second, or third or fourth ... try, the cantankerousness being roughly proportional to how long since the last MacBook restart. I haven't noticed a correlation to bigger programs. But I quite often work sequentially with different boards, each of which has its own FT231X chip, and PropellerIDE and CoolTerm both open for program/test. Things have to be done in exactly the right order, or the current com assignment will go AWOL. I keep a 7-port hub plugged into the Mac usb port, and when one USB assignment disappears, I move to the next port on the hub, and that gets it going again. When all 7 of are AWOL, I move to the second USB port on the Mac, and that gives 7 more chances. FUBAR. Okay, I should use the PC, which works fine without any of that mess. I also have an older Mac running Snow Leopard and bst, and that still works great for the things only bst can do.
state-of-the-lamestation-address-and-propelleride-too
The IDE came too late into my awareness. At the time I was still holding stubbornly onto an older Mac running bst and other core programs that are now either upgraded or moving inexorably to the dustbin.
I've been working all morning with development using a single board/FT231. Never more than a second try to get PropellerIDE to load. Changed the USB port once, because the port I was using yesterday for the same board had disappeared. Other days, especially when programming to multiple FT231s, it simply won't cooperate. I'm not convinced where the problem lies.
Is it with the squirrely Apple serial ports (whichever driver, Apple or FTDI), or is it with the application programs? It's good to hear that proploader or propeller-load are okay.
I wanted to point you to this thread, where I compiled all the different ways that Spin and C/C++ programs can be merged into a single binary: http://forums.parallax.com/discussion/157563/combining-spin-and-c/p1
I know that isn't quite what you were looking for, but I suspect it might be relevant enough to help you out a bit. On top of that, you'll also want to look into and understand the following so that you can make the best choice for your libraries:
FCache
Inline assembly
Assembly-only driver (.S)
C/C++ run natively as a driver (.cogc/.cogcpp)
I'm personally not a big fan of the driver option, though they certainly have their place. Use these "drivers" is a direct Spin comparison because you write a totally distinct section of code and then, at runtime, that snippet of code is loaded into a COG and run independently. This is extremely different from the fcache and inline assembly solutions. Inline assembly lets you write assembly in the middle of your C/C++ application, and fcache lets you take up to 64 instructions and cache them in COG RAM for short bursts of native-code-execution, bypassing the CMM or LMM interpreter. My favorite is combining inline assembly with FCache, as is evidenced by its widespread use throughout PropWare.
Long story short, PropWare has the following preprocessor macros defined. Assuming you're not relying on PropWare, I'd encourage you to copy/paste this to the top of your app... it makes inline assembly + FCache a LOT easier:
#ifdef __PROPELLER_COG__ #define FC_START(start, end) #define FC_END(end) #define FC_ADDR(to, start) to #else #define FC_START(start, end) \ " fcache #(" end " - " start ")\n\t" \ " .compress off\n\t" \ start ":\n\t" #define FC_END(end) \ " jmp __LMM_RET\n\t" \ end ":\n\t" \ " .compress default\n\t" #define FC_ADDR(to, start) "__LMM_FCACHE_START+(" to " - " start ")" #endifFrom here: https://github.com/parallaxinc/PropWare/blob/develop/PropWare/PropWare.h#L64If you consider the project SimpleIDE/Learn/Simple Libraries/TextDevices/libfdserial, you will note that the libfdserial.side project includes pst.spin in it along with C and H files. The libfdserial.c file is a unit test fixture for verifying the functionality of the fdserial library. The fdserial.c file is the main fdserial library file which includes minumum infrastructure for fdserial features, and fdserial_utils.c has extra convenience functions that will not be included in the library if the functions are not called. The fdserial.h file provides prototypes for compile time checking to prevent silly run-time coding mistakes like wrong number of arguments in function calls, etc.... The pst.spin file is converted into a "C object" file for use by the fdserial library.
Key points:
-- 1. When pst.spin is included in a simpleide .side project like libfdserial.side, an object is created for fdserial called pst_firmware.o.
-- 2. Object file pst_firmware.o contains a single array named binary_pst_dat_start with support symbols.
-- 3. The fdserial.c source references the "included" binary_pst_dat_start with the line "extern int binary_pst_dat_start[];" in the fdserial_open function. Array binary_pst_dat_start[] contains all of the PASM code, but not the spin code.
-- 4. The pst cog is started with cognew((void*)binary_pst_dat_start, (void*)fdptr). The term (void*) just means we are using a generic type for the compiler and there is no type checking of the variable because spin/pasm doesn't do types in the compile time sense and there is no way to force compile time checks on the types.
-- 5. The fdptr is a "reference" to the statically allocated FDSERIAL struct for communications between the C code and the PASM.
-- 6. The PASM must be manipulated by the C code, I.E. C can not set PASM variables at compile time.
A good alternative to the method outlined above was provided by David Betz with his SpinWrap project for C/C++ which actually runs Spin code in an interpreter whose methods can be called by C code. This can result in smaller code than C can produce even with CMM mode, but runs at Spin's speed and uses at least one extra COG. It is beyond me (like other befuddling Parallax decisions) why this was not formally adopted by Parallax, as it was a no-brainer generally speaking.