i2c without CAN

[deltaphi]

i2c without CAN

[deltaphi]

Hi CuriousTimo,

yes, the Keyboard does wait for an Acknowledgement to be sent and the c6021light does not generate an acknowledgement by itself. Currently, I found that acknowledgements are only available on the CAN bus, typically sent by a Gleisbox. Therefore, Acknowledgements are only forwarded, not generated by the c6021light itself. The benefit of this: The Gleisbox does not generate Acknowledgements when the system is in stop mode - as it can't switch turnouts while the track power is off. The Keyboard will then implicitly notice (or rather, not notice) that the turnout has not been switched.

It would be possible to extend the c6021light to generate a response on I2C. However, the c6021light can not reliably know the Stop/Go state of the system, causing the Keyboard to receive acknowledgements when nothing has been switched.

What is the goal of your setup? Are you planning to run without devices attached to CAN?

Regards
Damian

[CuriousTimo]

Hi Damian,

Thanks for your reply. My goal would be to use the 6040 on a LocoNet standalone system. So much more lightweight than what you are developing I guess. Similar to the Uhlenbrock IB-Switch.

Since a standalone LocoNet system works independently from the DCC railsync controlling the trains it does not really bother with the state of the track power.

In combination with Rocrail, I would be able to dump all the 6040 states to Rocrail when it receives an OPC_GPON message.
Or I could let Rocrail send all its states to LocoNet.

Regards,
Timo

[deltaphi]

Hi Timo,

at least in the latest master with the reworked command line interface, it would be relatively easy to add an option for the c6021light to (blindly?) generate responses on I2C.

What needs doing (roughly):

• Extend DataModel with a new parameter (and EEPROM index) to track whether responses on I2C should be generated.
• Extend RoutingTask::TaskMain, where the I2C Packet is processed, to generate responses based on this parameter.
• Extend ConsoleManager to add a parameter, e.g., "config [get|set] generateI2CTurnoutResponse [on|off]".
• Extend hal:StoreData and hal::LoadData to persist the new parameter.

Would you be interested in implementing this? I'd be happy to review your pull request. If you need more insight into one aspect or the other, feel free to ask.

To note: You may have to slow down the c6021light when sending the responses. In the initial version, I found that sending a reply after the I2C-mandated minimum delay of 4us was not received by the Keyboard. Delaying this time to about 9us from the end of reception of the request made the Keyboard happy. If there is a lot of forwarding going on before the reply is sent, the delay caused by the amount of code executed may be sufficient. A round-trip delay across CAN certainly has been sufficient.

[CuriousTimo]

Thanks! I figured it out.

As a quick test, I have copied and pasted parts of your codebase to set up a one file Arduino sketch.

Reason for this that I can now test and develop it on my LocoNet Nano PCBs.

Over the last few weeks, I have been working on version 3 of my interface. This will have two expansion ports to break out the pins to expansion modules. I have expansion boards for 2x RFID, 16x LEDs (Signals), 16x Mass Detector Feedback on their way from China to be tested. If everything is ok I'll have to update the manual and push everything to GitHub.

Creating a small extension module with an onboard 8v power source to connect my LocoNet board to the Marklin i2c bus would be totally feasable.

V3 Nano LocoNet Board.

2x RFID Expansion Board.

Basically what I did is add a flag at the end of the receiveEvent routine.
When this is set to true it triggers the next loop to send the ack to the 6040 keyboard.

  if(TX == true) {
    delayMicroseconds(9);
    Wire.beginTransmission(i2cRxBuf.msgBytes[0] >> 1);
    Wire.write(kCentralAddr << 1);
    Wire.write(i2cRxBuf.msgBytes[1]);
    Wire.endTransmission();

    TX = false;
  }

This is working but I have to clean it up and use the routines in your library.

at least in the latest master with the reworked command line interface, it would be relatively easy to add an option for the c6021light to (blindly?) generate responses on I2C.

I'm not sure if such an option would benefit your project tough? Since the use case is rather different.

[deltaphi]

at least in the latest master with the reworked command line interface, it would be relatively easy to add an option for the c6021light to (blindly?) generate responses on I2C.

I'm not sure if such an option would benefit your project tough? Since the use case is rather different.

The c6021light is not explicitly intended to be used exclusively with CAN as the Railroad-facing bus - it just so happens that you are the first person to have a different usecase. I would see such an option as a benefit.

Similarly - but more copmlex to solve - The initial version of this software could also be built on Arduino and be used with a CANdiy-Shield (No LocoNet at the time in the software). I have dropped the Arduino support since, as the software has grown in functionality and thus also size - it currently occupies roughly 7k RAM and 30k Flash on the Bluepill. However, if there is interest it would certainly be possible to either bring back a restricted Arduino port or to factor out helpful parts of c6021light as a separate library for use by other projects.

[deltaphi]

Now implemented. See command line interface: config set generateI2CTurnoutResponse.