[C.CC USERS] analogWrite Help

[Matt Jadud]

Hi Aaron,

On Wed, Mar 31, 2010 at 6:57 AM, Aaron Ryan <amrphoto1 at gmail.com> wrote:
> Hello,
> I cannot seem to get the "analogWrite" process to work on my Atmega328.
> Here is the code that I am using to test the process:
>>
>> #INCLUDE "wiring.module"
>>
>> PROC main()
>>
>>   analogWrite(9, 255)

Take a look at

http://projects.cs.kent.ac.uk/projects/kroc/trac/browser/kroc/trunk/tvm/arduino/occam/lavalamp.occ

That is a small program that uses the ADC to feed values into a
process that fades an LED. The semester is wrapping up here at
Allegheny (meaning, we're on the final five week sprint), and my plan
is to update the book with a few more chapters after that. Building
the book out to the point that these kinds of things are covered
(which will cover most of the rest of the language) is my goal.

My suspicion is that you must call beginAnalog(pin) so the pin gets
configured for use with analogWrite(). It might be that we should just
inline beginAnalog() into analogWrite(), or we should include in the
documentation that you must init the pin. This follows (I think) the
actual Wiring libraries, but that doesn't make it "good."

That, of course, does not help you now. For now, definitely ask us
questions. You're just seeing the side effect of "release early,
release often." As much as it might have been nice to hold until
everything is "done," it turns out software and texts are never
"done."

Another way to solve this would be to provide a process like this:

PROC analog.write (VAL INT pin, CHAN BYTE value?)
  SEQ
    -- Perhaps check here that the pin is a valid
    -- PWM pin? That would be good.
    beginAnalog(pin)
    WHILE TRUE
      BYTE v:
      SEQ
        value ? v
        analogWrite(v)
:

That (having not compiled it...) would be a process you could compose
into a network. You might then want a process that handles the
conversion of INT values down to BYTE values. (If you cast an INT to a
BYTE, and are out of range, it is a runtime error.) So, you can start
constructing a pipeline of processes that take your (possibly integer)
values, scale it down to a BYTE, and then pass it off to a process
that does nothing but update an analog pin.

Either or both of these might be completely brain-dead. I wanted to
get an answer out before I headed to the office.

This might scale your incoming integer to the range 0 - 255. It
assumes the full range of INTs, though... if you wanted to scale
integer values in the range 0 - 1023 to 0 - 255, you'd need to modify
this a bit (for example). Again, none of this code was tested in any
way.

PROC clamp.int.to.byte (CHAN INT in?, CHAN BYTE out!)
  WHILE TRUE
    INT v:
    SEQ
      in ? v
      v := ((MAXINT / v) * 255)
      out ! (BYTE v)
:

This process would just read integers and cast them, even if they were
out of range of a BYTE. If this process consumes the number 314, it's
crash city.

PROC cast.int.to.byte (CHAN INT in?, CHAN BYTE out!)
  WHILE TRUE
    INT v:
    SEQ
      in ? v
      out ! (BYTE v)
:

We'll get to casting in the book. It's an annoyance, but it seems to
be something that you run into unavoidably with embedded platforms.

Cheers,
Matt