Shop OBEX P1 Docs P2 Docs Learn Events
Propeller SPIN Blink an LED — Parallax Forums

Propeller SPIN Blink an LED


We're going in! :smile:

Using Prop Pro board. Grey one. Revision A maybe.

Will start looking for lesson for that.

If nothing else I know there is one in PEKit Fundamentals text.

Comments


  • Using Propeller Tool compiler.

    Reading this from Help section.

    About the Propeller Chip Hardware

    Says to read it and How the Propeller Tool Works before blinking an LED.

  • Got the Prop Pro board out. Will look for a power supply. Think it can take up to a 12v.Stamp boards are only up to 7.5

    Found Blink an LED program in Prop Tool Help tutorial.

    Should have that LED blinking soon!
  • "Think it can take up to a 12v?"

    There's a product page for the Propeller Professional Development Board (PPDB) on the main Parallax website. That should give the power supply requirements.
  • microcontrollerusermicrocontrolleruser Posts: 1,194
    edited 2017-10-29 16:12
    Mike

    Okay.

    I will make Pro Board manual an icon on desktop.

    It used to be a download at bottom of product page.

    EDIT

    Have the manual version 1.0 for grey Pro Board.

    Using BOEBot battery pack 6v. It doesn't have cord to trip over. :smile:
  • Parallax took the time to silk-screen "7-12VDC" right below the power jack.

    Do not "make the Pro Board manual on icon". Print it out. Using your printer. On Paper. It is only 3 sheets (double-sided). Print out the schematic as well. Go study them. Say for at least an entire hour. Then ask more questions.

  • Tom

    Have an observation and a question.

    Wasn't paying attention and the first source code says right on it 'Lesson 2'.

    Lesson 1 explains some stuff.

    Says when you put objects in an application it compiles.

    So Propeller tool does compile at some point but interprets when it just a snippet of code?

  • The Propeller tool does compile any Spin code into Spin interpretive code (PUB and PRI sections) and assembles any assembler code to Propeller instructions (in DAT sections). There is a Spin interpreter in on-chip ROM that is loaded into an initial cog by the boot loader, so all programs begin with interpretive code and the Spin interpreter. An instruction (COGNEW usually) is used to copy a block of 512 instructions (and data) into a cog where execution starts at location 0. If you supply less than 512 longs, the rest of the block consists of whatever follows what you've supplied in hub memory (junk in other words). If you want to experiment with assembly, a minimal Spin program to start it would be:
    PUB main
       COGINIT(COGID,@start,0)   {The 0 gets put in PAR register of new cog}
    
    DAT {Assembly program starts at 0}
              org   0
    start:
    
  • Most "real" programs consist mostly of Spin code which is compiled into a very compact and efficiently interpreted interpretive code. Some sections are written in assembly, usually those parts that are very timing dependent or speed dependent. This is in keeping with the observation that 90% of the execution time of almost all programs is spent in about 10% of the code and you can't reliably tell ahead of time which 10% is critical.

  • Mike

    Yep. Like a template. Thanks.

    Here's a picture of Pro Board.

    It came out upside down.

    Daisy chained from PIN 16 to LED. Too lazy to find long jumper wires.
    2560 x 1920 - 938K
  • microcontrollerusermicrocontrolleruser Posts: 1,194
    edited 2017-10-29 17:48
    Mike

    Can you explain that a different way please? EDIT I mean about the Prop. Our posts crossed.

    A PIC you do like this:

    Compile code to hex.

    Download hex to PIC.

    It starts running immediately when it is powered up.

    Can you just say the first thing Propeller tool does?

    Maybe that will clear it up.

  • Mike

    Just to help out I read Help.

    If you have a snippet and load to RAM it works like a PIC.

    More or less.

    Think there is that 'compiles to "interpreter code" ' not hex wrinkle.

    This is leaving out 'COG's'. Stuff about moving 'your program' from hub to cog.
  • Couldn't help but notice (in your photo) you don't have the PPDB connected to a wall wart or to a PC.

  • Tom

    That's the 'still photo studio'.

    12" x 24" piece of ceiling tile from Home Depot.

    Yes. We do use a power supply and a USB cable. :smile:
  • Good, Can the IDE find your prop chip?
  • The documentation covers this, but it runs like this

    The chip powers up or the reset line is allowed to go high.
    The bootloader is started (from masked ROM on-chip) by loading it into cog 0 RAM
    The bootloader looks for a serial port on I/O pins 30/31 (pin 31 high)
    ... if present, negotiates Baud with PC and downloads program to hub RAM
    ... if successful download, starts Spin interpreter in cog 0 on hub RAM contents
    The bootloader looks for I2C EEPROM on I/O pins 28/29
    ... if present, copies 1st 32K of EEPROM to hub RAM
    ... if checksum correct, starts Spin interpreter in cog 0 on hub RAM contents
    If the Spin program in hub RAM contains some assembly code, it (the Spin code) will
    eventually execute one or more COGNEW or COGINIT statements which will be interpreted
    and execute the equivalent COGINIT instruction that will copy a block of hub memory into a
    cog and start that cog running from cog location 0 with that cog's special registers
    (memory mapped) initialized to zero (except PAR which is initialized from the COGINIT).
  • Typically, a section of assembly code runs independently in a cog and communicates through an area in hub RAM. It can also just interact with I/O pins, built-in counters, and the system clock (for timing). If you want to have a toggle switch or push button as the input and LEDs as outputs, you can use the minimal example I gave above and do everything in the assembly code.
  • Cluso99Cluso99 Posts: 18,069
    Here is something you can use as a demo to send serial data to USB and PST (Propeller Serial Terminal program).
    It just repeats the same message.
    Ignore the commented out sections using single or double braces.
  • I spent an hour or so today looking for an official "blink" program and didn't find one.
    {Blink a LED}
    
    CON
            _clkmode = xtal1 + pll16x      'Standard clock mode 
            _xinfreq = 5_000_000           '* crystal frequency = 80 MHz
            
            MyLED = 26                     'pin connected to a LED via a resistor
      
    PUB BeginHere
        dira[MyLed] := 1                 'set direction
        repeat                           'forever
          outa[MyLed] := 1               'set it high
          waitcnt(clkfreq + cnt)         'one second
          outa[MyLed] := 0               'low
          waitcnt(clkfreq/2 + cnt)       'one-half second
    

    So here one is.

  • Tom

    Thanks. It was in one of my posts.

    Propeller Tool/Help/Tutorial/Exercise 3. There is no Exercise 1 or 2 source code.

    BTW Just 'Detected Device' about to compile and run. :smile:

  • It blinks!

    Think I am going to take some time to savor the moment. :smile:
  • Cluso99Cluso99 Posts: 18,069
    edited 2017-10-30 04:05
    Now, for fun, lower the waitcnt and eventually you will not be able to see the led blink due to your eyes. This.often catches beginners.

    To run on the slower Internal RC oscillator, remove the _clkmode and _xinfreq lines.
  • Blink five times and then stop.

    Blink ten times with each time different off period.
  • Mike GreenMike Green Posts: 23,101
    edited 2017-10-30 02:33
    Savor the moment ... now what about assembler?
    CON
          _clkmode = xtal1 + pll16x      'Standard clock mode 
          _xinfreq = 5_000_000           '* crystal frequency = 80 MHz
            
          MyLED = 26                     'pin connected to a LED via a resistor
    
    PUB main
       oneSec := CLKFREQ   { Initialize "constants" in assembly code }
       halfSec := CLKFREQ/2
       COGINIT(COGID,@start,0)   { Doesn't return. Assembly starts in same cog }
    
    { Note that the wait times are relative to the fetch of the CNT value
       just before loop:.  waits after that (using waitcnt) are still relative
       to the initial fetch of the time.  This allows very precise timing
       relative to specific events including precise synchronization to
       external (or internal) events. }
    
    DAT {Assembly program starts at 0}
              org   0
    start  or  dira,MyLEDMask   { dira[MyLED] := 1 }
            mov  timeCnt,oneSec   { one second delay }
            add  timeCNT,CNT   { compute relative to current time }
     
    loop  or  outa,MyLEDMask   { outa[MyLED] := 1 }
            waitcnt timeCNT,halfSec   { wait for 1 second and setup for 1/2 second }
            andn  outa,MyLEDMask   { outa[MyLED] := 0 }
            waitcnt timeCNT,oneSec   { wait for 1/2 second and setup for 1 second }
            jmp     #loop   { jump addresses must be immediate values }
    
    MyLEDMask  long   1 << MyLED   { bitmask for MyLED }
    timeCnt   long   0 { temp variable for WAITCNT }
    oneSec   long   0   { clock ticks per second }
    halfSec   long   0   { clock ticks per half second }
    
    (corrected and tested on Activity Board)

  • Mike

    Thank you for doing that.

    Actually going to bounce over to Stamp 1 Stepper project.

    I am a lightweight around here. Not one of the heavyweights that can knock out the code.

    Plus build hardware at will.

    I'm just one of the 'little guys'. :smile:
  • Still ... when you're done with the stepper project, come back to the Propeller and try out the assembly version of what you already got working. Play with it. Try different delays and I/O pin numbers.

  • Mike

    Appreciate it!

    You will have to pull the weight around here.

    Long sessions at the workbench with the soldering iron and schematics.

    Coding for hours with a box of pizza and sodas.
Sign In or Register to comment.