What must change in the RS485 Lib for "without complement"?

Hallo,

I would like delete this complement feature. Transfer time is too long. But this CRC feature is nice.
Nick Gammon Lib.

I have modified the sendComplemented function to this

void RS485::sendComplemented (const byte what)
{
  fWriteCallback_ (what);   
}  // end of RS485::sendComplemented

and the update function to this, the convert part in the default branche

bool RS485::update ()
  {
  // no data? can't go ahead (eg. begin() not called)
  if (data_ == NULL)
    return false;
  
  // no callbacks? Can't read
  if (fAvailableCallback_ == NULL || fReadCallback_ == NULL)
    return false;

  while (fAvailableCallback_ () > 0) 
    {
    byte inByte = fReadCallback_ ();
    
    switch (inByte)
      {
        
        case STX:   // start of text
          haveSTX_ = true;
          haveETX_ = false;
          inputPos_ = 0;
          firstNibble_ = true;
          startTime_ = millis ();
          break;
        
        case ETX:   // end of text (now expect the CRC check)
          haveETX_ = true;   
          break;
        
        default:
          // wait until packet officially starts
          if (!haveSTX_)
            break;   
          		            
            currentByte_ = inByte;         
		  		  
          // if we have the ETX this must be the CRC
          if (haveETX_)
            {
            if (crc8 (data_, inputPos_) != currentByte_)
              {
              reset ();
              errorCount_++;
              break;  // bad crc  
              } // end of bad CRC
            
            available_ = true;
            return true;  // show data ready
            }  // end if have ETX already
          
          // keep adding if not full
          if (inputPos_ < bufferSize_)
            data_ [inputPos_++] = currentByte_;
          else
            {
            reset (); // overflow, start again
            errorCount_++;
            }
        
          break;
        
      }  // end of switch
    }  // end of while incoming data 
  
  return false;  // not ready yet
  } // end of RS485::update

Problem ist, no receive data, all are 0.
Why? What ist wrong?

RS485_non_blocking.h (2.67 KB)

RS485_non_blocking.cpp (4.95 KB)

Yes, but the complement feature is what lets you send 8-bit binary. Since after complementing each nibble is:

0F, 1E, 2D, 3C, 4B, 5A, 69, 78, 87, 96, A5, B4, C3, D2, E1, F0

That means you can send 0x00 like this:

0x0F 0x0F

Without that it will confuse 0x02 as the start of a packet, 0x03 as the end of a packet and so on.

If you are going to get rid of complements, you basically need to rewrite. Somehow you need to know where a packet starts (as any incoming data could now be data). If you restrict yourself to (say) digits like 0 to 9, then it won't be too bad, but you still need to take a byte per digit (eg. 0 will be '0' and so on).

Hallo,

okay, I [u]not[/u] delete this complement feature. :) Worst case szenario: What does the Lib with data lost during transfer? Give a new transfer again? How many cycles?

It doesn't do anything. The sender won't know the receiver discarded a packet for some reason (eg. bad CRC). You conceivably have one-way transmission, as I did with a radio-controlled car.

The idea of the CRC is to detect bad data (so the car doesn't drive over a cliff, for example). In my scenario the user was constantly sending commands to the car via a controller, so the occasional discarded packet would not be an issue.

Hallo Nick,

okay, I think I understand this. With bad data on Receiver, the Receiver data are invalid > effect is the same as no data receive or no data send.

Okay, I use a answer timeout in the Master. The can send again after timeout.

Best Thanks.

With bad data on Receiver, the Receiver data are invalid > effect is the same as no data receive or no data send.

That's right. Same as receiving noise.

Hallo Nick,

all right all okay. Best Thanks for your help.

Good Night. :)

PS: and upload your updated Lib for all ... ;)

Hallo again,

I would like your Lib export to Atmel Studio. I programm a ATtiny841 directly. I have delete "#include "Arduino.h" and change byte to *uint8_t *

The Build Message say:

Severity Code Description Project File Line Error recipe for target 'main.o' failed Error expected identifier before '*' token WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 19 Error ISO C++ forbids declaration of 'size_t' with no type [-fpermissive] WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 19 Error 'size_t' declared as function returning a function WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 19 Error 'WriteCallback' does not name a type WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 31 Error 'WriteCallback' has not been declared WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 62 Error class 'RS485' does not have any field named 'fWriteCallback_' WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 65 Error 'NULL' was not declared in this scope ATtiny841_8MHz_Cal_003 WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 67

Can you say me what I must change, please?

Error 'NULL' was not declared in this scope ATtiny841_8MHz_Cal_003 WorkSpace_ATtiny841\lib\src\RS485_nonBlocking.h 67

I don't know. NULL is usually declared in C++.

Hallo,

yes, is usually. Okay, I see ...

Thanks.

Hallo Nick,

the solution is, an “#include <stdio.h>” in the main.cpp. :slight_smile:
Atmel Studio is more stupid as the Arduino IDE. :grin:

Well that’s strange because Arduino.h includes stdlib.h.

stdlib.h includes stddef.h.

stddef.h has a #define for NULL in it.

Hallo Nick,

aha, very interesting. Thanks.