Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 19 04:45
    vindicatorr opened #477
  • Jan 10 10:43
    fhainz commented #417
  • Jan 05 00:46
    kxm-alb edited #476
  • Jan 05 00:43
    kxm-alb edited #476
  • Jan 05 00:41
    kxm-alb edited #476
  • Jan 05 00:40
    kxm-alb edited #476
  • Jan 05 00:38
    kxm-alb edited #476
  • Jan 05 00:37
    kxm-alb opened #476
  • Dec 23 2020 07:18
    PizzaProgram closed #473
  • Dec 23 2020 07:18
    PizzaProgram commented #473
  • Dec 05 2020 08:29
    soundanalogous labeled #475
  • Dec 04 2020 12:14
    robobibble opened #475
  • Dec 02 2020 18:34
    dtex commented #471
  • Dec 02 2020 07:48
    xiebin2014 closed #467
  • Dec 02 2020 07:48
    xiebin2014 commented #467
  • Dec 01 2020 02:39
    PizzaProgram commented #471
  • Dec 01 2020 01:56
    PizzaProgram commented #471
  • Dec 01 2020 01:53
    PizzaProgram commented #471
  • Nov 30 2020 06:22
    Jorgeruiz97 commented #470
  • Nov 30 2020 02:08
    zfields commented #470
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
Clive Galway
@evilC
if the 8th pin of a port changes, I need to make 7 pointless checks to find that out
you could send more efficiently - in the above use case you only need to send two values to tell me that pin 56 changed to 1
for a port you are sending 8
but I spose what, you must always send a byte or something?
still, by switching to PIN/STATE you lose 50% bandwidth at most, but you could gain a bunch of CPU cycles at the host
maxing out the CPU of the arduino is no big deal
Jeff Hoefs
@soundanalogous
Well it depends on how much the CPU is doing. Firmata is a general protocol. You could have an application that does far more than check a few digital pin values.
Clive Galway
@evilC
input + arduino often means gaming
Jeff Hoefs
@soundanalogous
Currently there is no definition in the protocol for reading an individual digital pin. Once that is added you can do whatever you want in firmware.
firmata/protocol#68
Clive Galway
@evilC
I don't think my suggestion would require deprecating ports
Jeff Hoefs
@soundanalogous
Ports wouldn't be deprecated
A new feature would be added that enables reporting individual pins in addition to ports
A firmware implementation would use one method or the other
Clive Galway
@evilC
At the moment, a packet for a given port always holds all values for the pins in that port yeah, as 8 bits?
Jeff Hoefs
@soundanalogous
correct
1 bit per pin
Clive Galway
@evilC
so port 0 might be like 001234567
but in binary of course
so all I am saying is maybe allow a mode like 00110
Jeff Hoefs
@soundanalogous
That's how it works today
Clive Galway
@evilC
meaning "Port 0/ Pin 0 changed to 1 / Pin 1 changed to 0
but it can be sparse
ah I see, bits
duh