Shop OBEX P1 Docs P2 Docs Learn Events
SimpleIDE Libraries — Parallax Forums

SimpleIDE Libraries

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

  • I am sure that the expert C programmers can show you how to do what you want better than I can.

    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
  • Hi Mike,

    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.
  • Mike GreenMike Green Posts: 23,101
    edited 2017-09-17 04:43
    There are several I/O objects I'd like to convert/rewrite for use with SimpleIDE. OneWire is one and the 4-port serial driver is another. Both have large portions in PASM as DAT sections that I'd like to keep mostly unchanged. The interfaces in Spin would need to be redone to behave well with C callers, particularly when using different memory models.

    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
  • In 'C' you can inline assembly but I am not sure if it works the same with PASM.
    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
  • I will try to get back to you on this. There is certainly good info on here already. I'm in the process of moving this week though, so time is at a premium.
  • jazzedjazzed Posts: 11,803
    Mike,

    There are several examples of interfacing with pasm in these folders:
       SimpleIDE/Learn/Simple Libraries/TextDevices/libfdserial
       SimpleIDE/Propeller GCC Demos/toggle/pasm_toggle
       SimpleIDE/Propeller GCC Demos/graphics
       SimpleIDE/Propeller GCC Demos/sidetv
    
    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
  • Thanks all
  • Mike,
    Curious, what versions of PropellerIDE/OS12/FTDI driver are you using on the MacBook Pro?
  • The PropellerIDE I’ve been using is 0.33.3 although I’ve updated it to what’s available in the repository, but haven’t had a chance to try the newer version.

    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.
  • There is a lot to like about PropellerIDE, but the downloader is definitely a bummer. I wonder if the SimpleIDE downloader is portable?

    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.
  • When I have a little time next month, I may try running an older MacOS under Parallels Desktop (a Mac virtualizer) just to run bst ... seems a shame.
  • There is a lot to like about PropellerIDE, but the downloader is definitely a bummer. I wonder if the SimpleIDE downloader is portable?
    The SimpleIDE loader (either proploader or propeller-load depending on the vintage of SimpleIDE) is certainly portable. In fact, I PropellerIDE used to use propeller-load before Brett wrote his own loader to replace it. I suspect it could be converted back if there is no way to fix Brett's loader. Where did Brett go anyway?
  • Tracy AllenTracy Allen Posts: 6,656
    edited 2017-09-19 20:29
    Brett had to move on, I hope to good things.
    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.



  • Hey Mike,

    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.
  • Thanks David! I will probably use FCache for the 1-Wire driver, especially because there's already a Spin-only driver and it will be a useful exercise for me to convert it to C/C++. The 4-port serial driver is a different animal and, given the receive functionality with tight timing, is a better candidate for Assembly-only driver.
  • Ah ha! I finally found the post I wrote up not too long ago showing PropWare's FCache shortcuts: http://forums.parallax.com/discussion/comment/1417032/#Comment_1417032

    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 ")"
    #endif
    
    From here: https://github.com/parallaxinc/PropWare/blob/develop/PropWare/PropWare.h#L64
  • jazzedjazzed Posts: 11,803
    edited 2017-09-23 17:25
    Here are key things you need to know for interfacing C and PASM drivers like pst.spin.

    If 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.
Sign In or Register to comment.