leventerkok / harduino Goto Github PK

Due to http://hackage.haskell.org/trac/ghc/ticket/7299, we resort to using sleep on Mac to implement the delay function.. Get rid of this kludge when the corresponding GHC bug is fixed.

:-( Was really hoping to play with this on windows...

System.Hardware.Arduino.SamplePrograms.Blink> blink
** hArduino:ERROR: toEnum{PinMode}: tag (11) is outside of enumeration's range (0,6)
*** Make sure your Arduino is connected to /dev/cu.usbmodemFD131
*** And StandardFirmata is running on it!

I get above failure when i am testing "blink". Firmatatest is running fine. I am a bit newbie and i couldn't debug this. On the other side i didn't change the code. Could there be a chance that new versions of standartfirmata is not compatible ? I used

OS X : 10.11.3
Firmata : 2.5.2
ghc : 7.10.2
Serialport 0.4.7
Arduino Uno

Above configuration was working with Haskino, thats why i suspect with Firmata in which haskino was using a configurable version.

Because the serialport library is still alpha, I would suggest you add an explicit version in the cabal dependency list: serialport == 0.4.5

Apologies if this is user error as I've been away from Haskell for quite a while, but I am getting a compile error trying to run the "blink" sample program. Using hArduino 0.9 and GHC 7.6.3, compiling the sample program results in:

$ ghc Blink.hs
[1 of 1] Compiling System.Hardware.Arduino.SamplePrograms.Blink ( Blink.hs, Blink.o )

Blink.hs:21:17: parse error on input `delay'

Any ideas what I'm doing wrong?

Thanks!

If we receive a Ctrl-C call, then we quite the program. Which is fine when we have an executable since it kills the spawned listener thread and everything is cleaned up. However, if we run the Arduino program inside GHCi, then catching the signal returns to the GHCi prompt, and (apparently) doesn't kill the forked listener thread. This causes issues if the same program is run again (which is the typical use case from the GHCi command line), since we know have two listener threads..

It'd be nice to see if there's a way to avoid this, by explicitly killing the listener thread for instance.

There's at least one: CPP. Search and nuke unneeded ones.

The implementation of pulseIn and pulseOut is inherently inaccurate.

The issue exists for both functions, as the Firmata communication overhead inherently adds inaccuracy to measurements. However, I've found that pulseOut is relatively OK for practical uses. However, pulseIn is unlikely to be useful for any sort of fine measurement (as would be required for distance sensing sensors, for instance), due to the extreme accuracy needed for such an application.

There's a proposal out there to add a pulseIn function to Firmata: rwaldron/johnny-five#18

We should track the status there and start using it once it gets merged to mainline Firmata. (If ever.)

Analog and digital pins currently use the same "name space", meaning that the user has to know how many digital pins he has so he can correctly compute the analog pin number. However, hArduino already tracks this information in its capabilities mapping, so it would be nice to use the type-system to allow users "safe" access to these pins without requiring them to know how many digital pins there are.