Propeller SPIN Blink an LED

microcontrolleruser · 2017-10-29 01:30

We're going in!

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.

microcontrolleruser · 2017-10-29 01:54

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.

microcontrolleruser · 2017-10-29 15:10

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!

Mike Green · 2017-10-29 15:39

"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.

microcontrolleruser · 2017-10-29 15:54

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.

tomcrawford · 2017-10-29 16:17

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.

microcontrolleruser · 2017-10-29 16:28

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?

Mike Green · 2017-10-29 16:53

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:

Mike Green · 2017-10-29 16:59

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.

microcontrolleruser · 2017-10-29 17:03

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.

microcontrolleruser · 2017-10-29 17:46

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.

microcontrolleruser · 2017-10-29 18:16

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.

tomcrawford · 2017-10-29 18:22

Couldn't help but notice (in your photo) you don't have the PPDB connected to a wall wart or to a PC.

microcontrolleruser · 2017-10-29 19:00

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.

tomcrawford · 2017-10-29 20:04

Good, Can the IDE find your prop chip?

Mike Green · 2017-10-29 20:21

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).

Mike Green · 2017-10-29 20:27

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.

Cluso99 · 2017-10-29 22:17

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.

tomcrawford · 2017-10-30 00:19

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.

microcontrolleruser · 2017-10-30 00:23

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.

microcontrolleruser · 2017-10-30 00:40

It blinks!

Think I am going to take some time to savor the moment.

Cluso99 · 2017-10-30 01:24

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.

tomcrawford · 2017-10-30 01:54

Blink five times and then stop.

Blink ten times with each time different off period.

Mike Green · 2017-10-30 01:56

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)

microcontrolleruser · 2017-10-30 03:11

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'.

Mike Green · 2017-10-30 03:17

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.

microcontrolleruser · 2017-10-30 04:16

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.

Propeller SPIN Blink an LED

Comments