Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 01 10:35
    benolayinka commented #442
  • Jan 27 15:16
    benolayinka commented #442
  • Jan 27 14:53
    modlfo opened #444
  • Jan 20 17:13

    soundanalogous on master

    [STM32] Fix version checking S… Merge pull request #443 from fp… (compare)

  • Jan 20 17:13
    soundanalogous closed #443
  • Jan 20 06:54
    fpistm opened #443
  • Jan 16 15:01
    benolayinka commented #442
  • Jan 15 19:38
    dtex commented #442
  • Jan 15 18:48
    benolayinka edited #442
  • Jan 15 18:47
    benolayinka edited #442
  • Jan 15 18:45
    benolayinka opened #442
  • Jan 08 04:18
    soundanalogous commented #441
  • Jan 07 08:36
    Burnich commented #441
  • Jan 07 05:48
    soundanalogous commented #441
  • Jan 07 05:48
    soundanalogous commented #441
  • Jan 07 05:47
    soundanalogous commented #441
  • Jan 06 08:52
    Burnich commented #441
  • Jan 06 08:51
    Burnich commented #441
  • Jan 04 15:54
    soundanalogous commented #441
  • Jan 04 15:53
    soundanalogous commented #441
Clive Galway
@evilC
The problem with this is that the arduino then has exclusive access to the xbox controller - so if, for example, we wish to merge input from the sip/puff device, plus another device onto the same xbox controller, you can't
so what I want to do is read the arduino sip/puff device via something like Fermata, and have my (Windows, C#) code aggregate the input from various of these devices and combine it into one virtual xbox controller
Plus ideally, I want it to be easy for anyone to make an Arduino-based device and have it support my software with a minimum of coding effort by the device builder
In some cases (eg the QuadStick), the arduino firmware is already written and uploaded to the device, so I would like to make it possible for them to add a "fermata mode" which allows the device to either work in it's native manner (Using their existing FW code) or to be polled by my software (Using Fermata)
Clive Galway
@evilC
So in an ideal world, what I would love to be able to do is to say to the hardware developers "You build the arduino, connect up the pins, upload FirmataStandard, and that is it, job done". Then my code detects connected arduinos with Fermata enabled, queries them to find out what inputs are wired up, and makes them available to the end-user for remapping
Jeff Hoefs
@soundanalogous
Firmata just doesn't work that way. Firmata is an abstraction layer for communicating between a microcontroller board and a client software application in a generic way. By that principle the Firmata firmware does not understand a specific application (in this case, specific components wired to specific pins on the board). It does not scale on the firmware side to support this type of use case. With Firmata, you need to initialize the pin states per the attached components client-side (so from your Windows C#) code. If you want do use Firmata, you should create configurations in C# for each unique setup. You'd write a class for each device type and you can use the serial port name as the unique identifier for each device (or the IP address if using Ethernet/Wi-Fi).
Clive Galway
@evilC
Ah, I think I see, so you are saying that depending, for example, on what kind of pot is connected to an analog pin, then the range of values is not normalised?
so even if somehow I could determine that Pin 99 was in use as an analog input pin, I could not determine, purely via software, what the possible range of values is?
Jeff Hoefs
@soundanalogous
Firmata gives you the resolution of the analog pins, it just doesn't tell you which pins a sensor is connected to.
One way you could know which components are attached is to make each component an I2C device. This means for any simple analog or digital component, you'd need to attach an I2C backpack (a separate board - typically something small like an ATTiny) that reads the digital or analog component, and communicates with the main Arduino over I2C. Firmata can then query the devices attached to the I2C bus.
Clive Galway
@evilC
Is firmata.org permanently down, or is it just temporary?
Jeff Hoefs
@soundanalogous
I'm not sure. It's an old sourceforge hosted site and sourceforge recently changed something with DNS. I thought I had updated everything correctly but maybe not. I'll look into it, but this is not an area of expertise for me so it could take a while. I'm curious what you need from firmata.org as it has not been maintained in years.
Actually looks like SourceForge is down, so firmata.org should be back up whenever they fix their servers.
You have to click into any subpage from the main sourceforge page to see if it's still down or not.
Jeff Hoefs
@soundanalogous
Also, most of the content that was on firmata.org is available here: https://github.com/firmata/protocol.
Clive Galway
@evilC
I can't find anything that explains what the various forms of firmata are, and why you would want to use each of them
Clive Galway
@evilC
The reason I was looking for that URL BTW is that it is linked in the Firmata Examples
Clive Galway
@evilC
I cannot find any documentation at all for StandardFirmata
so basically I am trying to work out what is the minimum sequence of commands that I need to issue in my code to subscribe to a digital pin
(With StandardFirmata)
Clive Galway
@evilC
The sample code in SolidSoils\Arduino either does not compile, or is a jumbled mess with half the stuff commented out and no real explanation of what it does
And it randomly stops working - I did have some sample code that used the wiring from the 01.Basics\DigitalReadSerial, plus an LED on pin 10, and last night I had it working with Firmata reading digital pin 2 and turning on/off the LED to show state, but now it will not work properly
I seem to also have to set pin 0 to digital input in order to fire the callback when I push the button connected to pin 2, but the callback eventargs say that pin0 changed state, when it didn't, pin 2 did
Clive Galway
@evilC
SolidSoils/Arduino#24 if anyone can help
Jeff Hoefs
@soundanalogous

By default StandardFirmata initializes all digital pins to output. Digital pin changes are reported on each iteration of the main loop in StandardFirmata. Pin changes are reported only if reporting is enabled for the port that pin belongs to. So to read a digital pin, you need to perform the following steps:

  1. Set the pin mode to INPUT
  2. Enable reporting for the port that contains the pin
  3. Subscribe to digital messages (0x9N where N is the port the pin belongs to)

In firmata port #s start from 0 and pins are allocated to ports in order, so D0-D7 = port 0, D8-15 = port 1, etc.

Regarding which Firmata/midi commands to send and receive, refer to the documentation here: https://github.com/firmata/protocol/blob/master/protocol.md. Specifically see set pin mode (0xF4), report digital port (0xDN where N is the port number) and digital I/O message (0x9N where N is the port number).

Jeff Hoefs
@soundanalogous
| The reason I was looking for that URL BTW is that it is linked in the Firmata Examples
I see that was never updated in the old examples. I'll update the links now to avoid confusion in the future.
Jeff Hoefs
@soundanalogous
Fixed
Clive Galway
@evilC
"Enable reporting for the port that contains the pin" - port?? as in COM port?
oh I see
so to read pin 2 I need to enable port 0
ahh, so I guess that was my misconception, I thought "port" was just another word for pin
Clive Galway
@evilC
So it seems the callback does not actually tell you what changed then, just that something changed, and you have to work out what?
Clive Galway
@evilC
Well I spose that's an implementation in the client library, and not something in the protocol
So I doubt protocol docs or whatever will help me
Maybe you need to make that info a little more front and center? Even now knowing about ports, the only reference I can find to it is a comment in some code on the arduino site
sendDigitalPort(byte portNumber, int portData); //send an 8-bit port in a single digital message
Clive Galway
@evilC
So for every port I get an update for, I have to scan for which one of 8 possible pins changed?
And I have to store the old state to know what changed?
I don't see why that part is shifted to software, it would be way more efficient to do it in hardware surely?
Clive Galway
@evilC
            session = new ArduinoSession(connection);

            session.SetDigitalPinMode(2, PinMode.InputPullup);
            session.SetDigitalReportMode(0, true);
            session.DigitalStateReceived += Session_OnDigitalStateReceived;

...

        private void Session_OnDigitalStateReceived(object sender, FirmataEventArgs<DigitalPortState> eventArgs)
        {
            var isSet = eventArgs.Value.IsSet(2);
            Console.WriteLine($"Message is for port {eventArgs.Value.Port}. Pin2 value= {isSet}");
            session.SetDigitalPin(10, isSet);
        }
Do all the client libs work like this? You get zero delta information, just new state and you need to work out what changed yourself?
So I have a meg with like 56 digital pins, I would need to keep 7 blocks of 8 bit button states to know what changed?
Jeff Hoefs
@soundanalogous
Some firmata client libraries sort that out for you, it really depends on the particular library. The reason we use ports instead of individual pins is throughput. When updating on every iteration of the main loop, it's far more efficient to report 8 pins at a time rather than individually. However a buffering mechanism would solve the same issue, but it was not initially part of the architecture. It is something I'm considering however for Firmata v3.
Clive Galway
@evilC
yeah but for input, latency is way more important
Jeff Hoefs
@soundanalogous
yep far less latency when sending 8 pins at a time
Clive Galway
@evilC
in the send, yes, but up to 8x the processing on the client side
Jeff Hoefs
@soundanalogous
CPU processing speed vs 57600 baud