Author Topic: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION  (Read 37045 times)

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« on: January 07, 2015, 06:47:30 AM »
Hi Tom, What is the likelihood that the RFM69 library, be updated to support the new SPI API's ?

My understanding (see thread) is that Arduino 1.5.8 includes the new SPI capability, and the ethernet libraries have been updated with the new SPI functions, so updating the RFM69 libraries would

http://forum.arduino.cc/index.php?topic=273369.0

I would like to setup a W5100 ethernet RFM69 gateway, on a single moteino. I don't mind contributing to the effort / testing anyway I can.

Kiwi

« Last Edit: February 29, 2016, 05:27:08 PM by Felix »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Moteino & W5100 ethernet SPI support
« Reply #1 on: January 07, 2015, 08:49:26 AM »
Hi Tom, What is the likelihood that the RFM69 library, be updated to support the new SPI API's ?

My understanding (see thread) is that Arduino 1.5.8 includes the new SPI capability, and the ethernet libraries have been updated with the new SPI functions, so updating the RFM69 libraries would

http://forum.arduino.cc/index.php?topic=273369.0

I would like to setup a W5100 ethernet RFM69 gateway, on a single moteino. I don't mind contributing to the effort / testing anyway I can.

Kiwi
Hi Kiwi!
We should probably move this to a new thread, however, I've skimmed the current code in the proposed SPI library and I'm not seeing that it really adds anything more to the way that Felix has set up the select()/unselect() functions.  I'll look at it in more detail when I get a chance, but I'm sort of caught up in my own code at this point.

BTW, I'm currently using Arduino IDE 1.5.7 so I'm not sure what the issue would be running under 1.5.8 other than changing the RFM69 library to the new SPI library and that doesn't seem like it would be a big effort.  I'd be glad to help but I probably can't add much time this week.  Like you, I wouldn't mind having an Ethernet option, but I'm also wary of running out of memory even with the code I have.  I keep getting 'low memory' warnings on my builds and have to tweak to make them go away...
« Last Edit: January 07, 2015, 04:42:14 PM by Felix »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #2 on: January 07, 2015, 07:14:53 PM »
Kiwi,
I'll get the 1.5.8 IDE and check out the new functions.  In principal the beginTransaction() and endTransaction() methods should be a direct replacement for select() and unselect() although the referenced object is different. And we'll need to add a method call to setup the new SPI configuration settings, but that should be easy to fold in.

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #3 on: January 08, 2015, 12:36:45 AM »
Kiwi,
I'll get the 1.5.8 IDE and check out the new functions.  In principal the beginTransaction() and endTransaction() methods should be a direct replacement for select() and unselect() although the referenced object is different. And we'll need to add a method call to setup the new SPI configuration settings, but that should be easy to fold in.

Tom
I would agree it doesn't seem like a big change, but it would make the library play nice with the Ethernet, and other such libraries that adopt the SPI library. However I think there are some gotcha's, the receiveDone() method is a bit unusual.

The issue isn't with the RFM library (as Felix disable interrupts), it is with other libraries that may not do the same and risk being interrupted (while actively doing SPI) by and RFM69 interrupt.

I typically have the latest 1.0.x and 1.5.x Arduino applications installed, with suitable renaming of the Application Package (on OS X) I don't have an issue. The application package bundles all the components, except your own contributed libraries an code. Not sure how windows handles it.

Kiwi

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #4 on: January 08, 2015, 08:57:07 AM »
<...snip>
I would agree it doesn't seem like a big change, but it would make the library play nice with the Ethernet, and other such libraries that adopt the SPI library. However I think there are some gotcha's, the receiveDone() method is a bit unusual.
I agree and think we should pursue this.  The only question is when...  I'm too tied up right now, but I'm willing to review anything you do if you want to start a fork.
The issue isn't with the RFM library (as Felix disable interrupts), it is with other libraries that may not do the same and risk being interrupted (while actively doing SPI) by and RFM69 interrupt.
Yeah, this was the part I found confusing about the transaction proposal.  It only masked its own interrupt, leaving the transactions interruptable by other SPI devices (unless I misunderstood the code I admittedly just skimmed).
I typically have the latest 1.0.x and 1.5.x Arduino applications installed, with suitable renaming of the Application Package (on OS X) I don't have an issue. The application package bundles all the components, except your own contributed libraries an code. Not sure how windows handles it.

Kiwi
Cool!  Thanks!  I'll give it a try.

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #5 on: January 08, 2015, 05:35:17 PM »
Yeah, this was the part I found confusing about the transaction proposal.  It only masked its own interrupt, leaving the transactions interruptable by other SPI devices (unless I misunderstood the code I admittedly just skimmed).
I haven't read the new SPI code, I assumed that whenever a beginTransaction() was called that interrupts would be masked for any/all other PINS that have been registered, to prevent the interrupt (from the other SPI device) occurring until after then endTransaction() is called.

YES I agree time is a problem, If I get to it will fork (on GItHub) and post link back to this forum

Kiwi

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #6 on: January 08, 2015, 09:01:58 PM »
Yeah, this was the part I found confusing about the transaction proposal.  It only masked its own interrupt, leaving the transactions interruptable by other SPI devices (unless I misunderstood the code I admittedly just skimmed).
I haven't read the new SPI code, I assumed that whenever a beginTransaction() was called that interrupts would be masked for any/all other PINS that have been registered, to prevent the interrupt (from the other SPI device) occurring until after then endTransaction() is called.

YES I agree time is a problem, If I get to it will fork (on GItHub) and post link back to this forum

Kiwi
Don't 'break your back on this.  I had a major setback on my current project today and may now actually have some time to work on this.  I'll know more tomorrow.

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #7 on: January 10, 2015, 08:07:53 AM »
@Kiwi,
before we go forking ourselves (pun intended), I think we should establish the scope of the project.

Clearly the motivation is to align RFM69 with the new SPI changes, but there are a few other things that need to be established before we start on this:

  • First and foremost, the new library should be backward compatible with existing IDEs.  There should be only one library distributed and the code within the library should deal with IDE version differences, not the user of the library.
  • There are some clean up items that should be done:
    • Certainly cleaning out the unnecessary static declarations would be worthwhile (whether anyone would have multiple instances or not, it just makes for cleaner code)
    • IMO, there are a significant number of non-volatile registers that are accessed unnecessarily when modifying bit fields.  This creates inefficient SPI accesses as well as increasing the amount of interrupt mask/unmask operations.  Using shadow registers within the radio object would eliminate this overhead/risk.
    • The recent deadlock changes need to be reviewed, especially from the point of view of SPI transaction changes.  I think this is important to get right and we might recruit some of the guys who worked on that.
    • I've made some changes to the library to automatically adjust transmit power levels but I think we should keep those out of this project for the time being.  I'll manage those changes separately.


That's all I could think of at the moment, but let's refine and agree on this list before we start attacking the code...
Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #8 on: January 10, 2015, 06:42:06 PM »
@Kiwi,
I don't know whether to be embarrassed, happy, or what, but I just discovered that I've been using version 1.5.8 on my Linux laptop already!  I'm looking at the SPI library now and see that transaction support is there AND, it appears at first glance, that the library DOES collate all the interrupts into a single mask. I won't be surprised to see that they do mask on every 'transaction', whether it's 'your' interrupt or not.  Will let you know after I dig a bit further.

Maybe I should use my Linux laptop BEFORE I have my Scotch... (or Sauvignon Blanc as the case may be)...

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #9 on: January 11, 2015, 05:51:46 AM »
Hi Tom, I got my Moteinos a couple of days ago, soldered and connected to a standard ethernet shield, so in a position to move forward. Where are you up to?

I would agree with your statement about backward compatibility. Note spi.h defines #define SPI_HAS_TRANSACTION 1 - for exactly that purpose. In terms of code cleanup:
- Static Declarations is an isolated fix, it has no bearing on the functionality in the code, so YES agreed.
- Non Volatiles. While I agree in principle it is a functional change, if this is changed IMHO it may introduce subtle bugs, my preference would be to exclude this
- Deadlock. I don't know about this issue, but if the resolution involved SPI locking/unlocking then YES should be addressed.

... AND, it appears at first glance, that the library DOES collate all the interrupts into a single mask. I won't be surprised to see that they do mask on every 'transaction', whether it's 'your' interrupt or not.  ...
I haven't looked at the library but would expect ALL SPI registered interrupts would be masked on beginTransaction. Interrupts are non-predictable...

Kiwi.

EDIT: I just did a basic update of the RFM library to add beginTransaction() support, and will leave it running overnight with a gateway sketch just dumping my local RF network traffic (360 messages/hour), will report back if its still running in the morning.
« Last Edit: January 11, 2015, 07:24:00 AM by kiwisincebirth »

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #10 on: January 11, 2015, 08:23:39 AM »
Hi Tom, I got my Moteinos a couple of days ago, soldered and connected to a standard ethernet shield, so in a position to move forward. Where are you up to?

I would agree with your statement about backward compatibility. Note spi.h defines #define SPI_HAS_TRANSACTION 1 - for exactly that purpose. In terms of code cleanup:
- Static Declarations is an isolated fix, it has no bearing on the functionality in the code, so YES agreed.
- Non Volatiles. While I agree in principle it is a functional change, if this is changed IMHO it may introduce subtle bugs, my preference would be to exclude this
- Deadlock. I don't know about this issue, but if the resolution involved SPI locking/unlocking then YES should be addressed.

... AND, it appears at first glance, that the library DOES collate all the interrupts into a single mask. I won't be surprised to see that they do mask on every 'transaction', whether it's 'your' interrupt or not.  ...
I haven't looked at the library but would expect ALL SPI registered interrupts would be masked on beginTransaction. Interrupts are non-predictable...

Kiwi.

EDIT: I just did a basic update of the RFM library to add beginTransaction() support, and will leave it running overnight with a gateway sketch just dumping my local RF network traffic (360 messages/hour), will report back if its still running in the morning.
Kiwi,
I'm not in a position to test Ethernet, I don't have the adapter, although I probably should (which adapter are you using?), but it will be a while before I'd be able to incorporate into this project. 

The deadlock code is now incorporated into the RFM69-Master but I 'feel' that it needs a bit more scrutiny. While it didn't change the SPI calls, it did change the timing WHEN those calls were made, including calls from within the RFM69 interrupt handler.

Regarding availability, I'm available for code review and changes, but probably won't be in a position to test for a few weeks since I'm traveling next Friday and will need a couple of days to prep for that.  I should be returning in about 2 1/2 weeks.

Re your test, did you replace the noInterrupts()/interrupts() calls in the select/unselect methods or simply add the begin/endTransaction() methods?

Finally, I'm pretty passionate about removing the unnecessary SPI calls via shadow registers, but I accept your position on this WRT this project and will address this change independently.

Thanks,
Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #11 on: January 11, 2015, 05:07:01 PM »
Hi there Tom, I am using the standard arduino Ethernet shield with W5100 chipset. From a Moteino  perspective this board chip are 3V3 compatible, so can be directly connected to the moteino pins.

Good news, is my gateway test worked, 10 hours of operation without issue that I can see. Next step is to include some Ethernet running at same time.

Will post code for review tonight, most change is in select() unselect()

Kiwi

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #12 on: January 12, 2015, 06:17:24 AM »

Hi Felix

Hi Tom

I have made a small improvement to the RFM69 library, as discussed in the above thread.

In summary

The purpose of this change is to support improvements to the core Arduino SPI libraries that have been first released in Arduino 1.5.8

In summary the SPI changes improve reliability when there are multiple slave devices on the same SPI bus. This is by creating exclusion zones (transactions) around SPI interaction, managing different SPI configuration, and preventing interrupts where the interrupt handler uses SPI.

The full description of the changed SPI libraries is here

http://dorkbotpdx.org/blog/paul/spi_transactions_in_arduino

I can confirm the Ethernet libraries in 1.5.8 have been enhanced with these changes, so by upgrading the RFM libraries, then these two should work more reliably together, this is the main use case I want to support.

My changed RFM69 library is on GitHub. It is backwards compatible with traditional (legacy) SPI libraries, by #ifdef compiler directive.

https://github.com/kiwisincebirth/RFM69.

The main change in the RFM library is in the select() and unselect() methods, with a further small change in the init() method, where there interrupt handler is attached.

There is a small fix in readAllRegs() method to remove an unnecessary (duplicated) unselect() method call.

Lastly in the receiveDone() method, a call the interrupts() method has been added before every return statement. This is to ensure interrupts are fully enabled before the function ends. Previously this was implicit via a sub-functon calling unselect(), but this cannot be relied upon in the amended unselect(). The new SPI libraries disable (mask) only the interrupts that it knows need to be masked, rather then globally disable all interrupts.

It is lastly this last change that needs the most review, as I am not across the reason for disabling interrupts globally in this way, with the new SPI libraries this may not even be needed.

I am still testing it, and invite others to do the same. I will confirm once I have a amount of “multiple device” testing done. But the library ran successfully for 20 hours, running a gateway sketch, handling 360 messages an hour.

I have resisted the urge to tidy up other areas of the code (removing static declarations), concentrating on Just what IS needed. I know Tom has other cleanups and improvements he wishes to do.

I would like to consider this to be included for inclusion in the main library.

Regards

Kiwi

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #13 on: January 12, 2015, 08:49:09 AM »

<...snip>

https://github.com/kiwisincebirth/RFM69.

The main change in the RFM library is in the select() and unselect() methods, with a further small change in the init() method, where there interrupt handler is attached.

There is a small fix in readAllRegs() method to remove an unnecessary (duplicated) unselect() method call.

Lastly in the receiveDone() method, a call the interrupts() method has been added before every return statement. This is to ensure interrupts are fully enabled before the function ends. Previously this was implicit via a sub-functon calling unselect(), but this cannot be relied upon in the amended unselect(). The new SPI libraries disable (mask) only the interrupts that it knows need to be masked, rather then globally disable all interrupts.

It is lastly this last change that needs the most review, as I am not across the reason for disabling interrupts globally in this way, with the new SPI libraries this may not even be needed.

<snip...>
@Kiwi,
I just donwloaded your updates and will review today.  Re the global interrupts() call, ISTM this is unnecessary and, in the 'wrong' circumstances(ie a processor with more interrupt sources/levels), could create problems.  It seems like it would be unnecessary since you do pair begin/endtransactions and this should keep the keep the proper interrupt levels unmasked (assuming the new SPI library does ;-)

Again, I'll get back to you later today.
Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #14 on: January 12, 2015, 05:55:14 PM »

<...snip>

https://github.com/kiwisincebirth/RFM69.

The main change in the RFM library is in the select() and unselect() methods, with a further small change in the init() method, where there interrupt handler is attached.

There is a small fix in readAllRegs() method to remove an unnecessary (duplicated) unselect() method call.

Lastly in the receiveDone() method, a call the interrupts() method has been added before every return statement. This is to ensure interrupts are fully enabled before the function ends. Previously this was implicit via a sub-functon calling unselect(), but this cannot be relied upon in the amended unselect(). The new SPI libraries disable (mask) only the interrupts that it knows need to be masked, rather then globally disable all interrupts.

It is lastly this last change that needs the most review, as I am not across the reason for disabling interrupts globally in this way, with the new SPI libraries this may not even be needed.

<snip...>
@Kiwi,
I just donwloaded your updates and will review today.  Re the global interrupts() call, ISTM this is unnecessary and, in the 'wrong' circumstances(ie a processor with more interrupt sources/levels), could create problems.  It seems like it would be unnecessary since you do pair begin/endtransactions and this should keep the keep the proper interrupt levels unmasked (assuming the new SPI library does ;-)

Again, I'll get back to you later today.
Tom
@Kiwi,
I looked over the code and everything looks good EXCEPT the changes in receiveDone(), which I'll get to in a moment.   

The #ifdef approach works well without a lot of messiness.  Good job and good approach in select().

Re receiveDone, the problem I see is that the 'transaction' is now more than just a SPI sort of thing.  receiveDone() disables interrupts so that it can perform an atomic test and execute on the mode and payloadlen, but then relies on this to be 'fixed' at the end of the unselect() on either the setMode() or receiveBegin() calls.  This MIGHT be ok, if the logic in the begin/endtransaction isn't state dependent, ie, that interrupts are already disabled.  Like your counting approach, this could be a problem if the transaction logic simply restores the 'previous' state.  I'm not sure the current version does, probably due to the simplicity of the processor interrupt logic, it just seems 'unbalanced' to me. 

If we accept that the endtransaction will re-enable interrupts, then the comments in the code indicate that receiveBegin() will 'unselect' (and therefore re-enable interrupts), hence your addition here is not necessary.

What are your thoughts?


Tom
PS: I'm really glad you fixed the spelling error on line 204, that really bugged me!   :D  JK!!!

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #15 on: January 13, 2015, 11:23:06 AM »
Hi there Tom, I am using the standard arduino Ethernet shield with W5100 chipset. From a Moteino  perspective this board chip are 3V3 compatible, so can be directly connected to the moteino pins.

Good news, is my gateway test worked, 10 hours of operation without issue that I can see. Next step is to include some Ethernet running at same time.

Will post code for review tonight, most change is in select() unselect()

Kiwi
@Kiwi,
is the W5100 shield you're using have the Interrupt jumper (a little solder pad) bridged or open?  Do you know if the ethernet library is making the SPI.usingInterrupt() call (and which interrupt number it's using)?

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #16 on: January 13, 2015, 09:07:32 PM »

@Kiwi,
I looked over the code and everything looks good EXCEPT the changes in receiveDone(), which I'll get to in a moment.   

The #ifdef approach works well without a lot of messiness.  Good job and good approach in select().

Re receiveDone, the problem I see is that the 'transaction' is now more than just a SPI sort of thing.  receiveDone() disables interrupts so that it can perform an atomic test and execute on the mode and payloadlen, but then relies on this to be 'fixed' at the end of the unselect() on either the setMode() or receiveBegin() calls.  This MIGHT be ok, if the logic in the begin/endtransaction isn't state dependent, ie, that interrupts are already disabled.  Like your counting approach, this could be a problem if the transaction logic simply restores the 'previous' state.  I'm not sure the current version does, probably due to the simplicity of the processor interrupt logic, it just seems 'unbalanced' to me. 

If we accept that the endtransaction will re-enable interrupts, then the comments in the code indicate that receiveBegin() will 'unselect' (and therefore re-enable interrupts), hence your addition here is not necessary.

What are your thoughts?
Tom
My belief is the receive done method needs to be changed. Either the interrupts() removed, or balanced as I have done in GitHub

The reason it has to change is that the endtransaction() method in SpI library do not reenable  interrupts. you can see more clearly what is happening in the begintransaction() spi method. This method is design to mask interrupts for the interrupt pins that have been registered via usinginterrupts(), but not disable interrupts entirely. This allows timer0 millis() to continue to function.

Thus if we rely on end transaction to reenable interrupts then this won't happen.

The approach that I have taken, assumes that the blocking of interrupts is necessary for the atomic locking to occur, if not it should be removed.

 Since the disabling of interrupts and masking of interrupts i think are  done on different registers there shouldn't be an issue. Also so long as the two mechanisms happen in matching pairs, don't overlap instead one surrounds the other we should be ok,

 I.e.  Spi end transaction is called and restores the interrupt state when begintransaction was called, then the receive done method enables the interrupts

Hope the makes sense.

Ps I am away from home for a couple of days, so can't check Ethernet board

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #17 on: January 13, 2015, 09:15:00 PM »

<...snip>My belief is the receive done method needs to be changed. Either the interrupts() removed, or balanced as I have done in GitHub

The reason it has to change is that the endtransaction() method in SpI library do not reenable  interrupts. you can see more clearly what is happening in the begintransaction() spi method. This method is design to mask interrupts for the interrupt pins that have been registered via usinginterrupts(), but not disable interrupts entirely. This allows timer0 millis() to continue to function.

Thus if we rely on end transaction to reenable interrupts then this won't happen.

The approach that I have taken, assumes that the blocking of interrupts is necessary for the atomic locking to occur, if not it should be removed.

 Since the disabling of interrupts and masking of interrupts i think are  done on different registers there shouldn't be an issue. Also so long as the two mechanisms happen in matching pairs, don't overlap instead one surrounds the other we should be ok,

 I.e.  Spi end transaction is called and restores the interrupt state when begintransaction was called, then the receive done method enables the interrupts

Hope the makes sense.

Ps I am away from home for a couple of days, so can't check Ethernet board
Your explanation is very clear.  I understand your point.  I'm hoping to have some time tomorrow to look at it and will reply once I have a sense of what is there (or more questions).

Thanks for answering so thoroughly.

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #18 on: January 14, 2015, 01:39:28 AM »
@Kiwi,
is the W5100 shield you're using have the Interrupt jumper (a little solder pad) bridged or open?  Do you know if the ethernet library is making the SPI.usingInterrupt() call (and which interrupt number it's using)?

Tom
I have just read some forum posts, and delved into the Arduino library itself. And NO interrupts are not supported by the standard ethernet library, the bridging pin you refer to could be used ONLY with a redeveloped library. 

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #19 on: January 14, 2015, 07:41:32 AM »
@Kiwi,
is the W5100 shield you're using have the Interrupt jumper (a little solder pad) bridged or open?  Do you know if the ethernet library is making the SPI.usingInterrupt() call (and which interrupt number it's using)?

Tom
I have just read some forum posts, and delved into the Arduino library itself. And NO interrupts are not supported by the standard ethernet library, the bridging pin you refer to could be used ONLY with a redeveloped library.
Great!  Thanks for looking into this.  I should be able to work on the transaction conversion of RFM69 today.

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #20 on: January 21, 2015, 11:39:54 PM »
Hi Tom, Have you made any progress ?

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #21 on: January 22, 2015, 08:02:37 AM »
@Kiwi, sorry, no I haven't.  I've been travelling this week.  Hopefully I can get to it on my Sunday...

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #22 on: January 25, 2015, 08:19:27 AM »

@Kiwi,
I looked over the code and everything looks good EXCEPT the changes in receiveDone(), which I'll get to in a moment.   

The #ifdef approach works well without a lot of messiness.  Good job and good approach in select().

Re receiveDone, the problem I see is that the 'transaction' is now more than just a SPI sort of thing.  receiveDone() disables interrupts so that it can perform an atomic test and execute on the mode and payloadlen, but then relies on this to be 'fixed' at the end of the unselect() on either the setMode() or receiveBegin() calls.  This MIGHT be ok, if the logic in the begin/endtransaction isn't state dependent, ie, that interrupts are already disabled.  Like your counting approach, this could be a problem if the transaction logic simply restores the 'previous' state.  I'm not sure the current version does, probably due to the simplicity of the processor interrupt logic, it just seems 'unbalanced' to me. 

If we accept that the endtransaction will re-enable interrupts, then the comments in the code indicate that receiveBegin() will 'unselect' (and therefore re-enable interrupts), hence your addition here is not necessary.

What are your thoughts?
Tom
My belief is the receive done method needs to be changed. Either the interrupts() removed, or balanced as I have done in GitHub

The reason it has to change is that the endtransaction() method in SpI library do not reenable  interrupts. you can see more clearly what is happening in the begintransaction() spi method. This method is design to mask interrupts for the interrupt pins that have been registered via usinginterrupts(), but not disable interrupts entirely. This allows timer0 millis() to continue to function.

Thus if we rely on end transaction to reenable interrupts then this won't happen.

The approach that I have taken, assumes that the blocking of interrupts is necessary for the atomic locking to occur, if not it should be removed.

 Since the disabling of interrupts and masking of interrupts i think are  done on different registers there shouldn't be an issue. Also so long as the two mechanisms happen in matching pairs, don't overlap instead one surrounds the other we should be ok,

 I.e.  Spi end transaction is called and restores the interrupt state when begintransaction was called, then the receive done method enables the interrupts

Hope the makes sense.

Ps I am away from home for a couple of days, so can't check Ethernet board
@Kiwi, I have to tell you that I scratched my head long and hard on this and, in the end, have come full circle.   I think you're completely right about using noInterrupts/interrupts() in receiveDone().   

I really struggled with this because strictly speaking, receiveDone() should only need to be atomic with respect to its own interrupt, which, in this case, is the same as the SPI interrupt.  Unfortunately there are two problems with this 'purist' view, the first being that a 'universal' receiveDone() would have to do the same work as SPI.usingInterrupt() to generate the appropriate mask and a quick look at the code needed to parse SPI.usingInterrupt() for all possible processors makes your head spin!

The second aspect is more a 'conservative' concern that it may not be JUST SPI interrupts we need to block in this case.  It may be that ANY interrupts used by the Moteino application may need to be blocked at this point and noInterrupts() does just that.  And, as you already concluded, since the setMode() and receiveBegin() don't restore global interrupt (if using SPI transactions) then the extra interrupts() calls are necessary in receiveDone().  However, since these are ONLY needed in the SPI transaction case, I think we should use a conditionally defined INTERRUPTS() (or conditionally execute interrupts()) in these two places.

Do you agree?

Once this is resolved, I think what you have is great and should be submitted to the 'committee' (AKA Felix) via pull request.

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #23 on: January 26, 2015, 06:59:13 AM »
...

I really struggled with this because strictly speaking, receiveDone() should only need to be atomic with respect to its own interrupt, which, in this case, is the same as the SPI interrupt.  Unfortunately there are two problems with this 'purist' view, the first being that a 'universal' receiveDone() would have to do the same work as SPI.usingInterrupt() to generate the appropriate mask and a quick look at the code needed to parse SPI.usingInterrupt() for all possible processors makes your head spin!

The second aspect is more a 'conservative' concern that it may not be JUST SPI interrupts we need to block in this case.  It may be that ANY interrupts used by the Moteino application may need to be blocked at this point and noInterrupts() does just that.  And, as you already concluded, since the setMode() and receiveBegin() don't restore global interrupt (if using SPI transactions) then the extra interrupts() calls are necessary in receiveDone().  However, since these are ONLY needed in the SPI transaction case, I think we should use a conditionally defined INTERRUPTS() (or conditionally execute interrupts()) in these two places.

Do you agree?

Once this is resolved, I think what you have is great and should be submitted to the 'committee' (AKA Felix) via pull request.

Tom
I have made the changes as you suggested, and created a pull request.

I did this because a non 1.5.8 user won't see any changes at compile time, It is the simplest step to get adoption of the change, i.e. minimal impact to existing users, is proven to work, and calls interrupts() once when completing receiveDone(). An I do appreciate the pragmatism of this approach.

One of my concerns is readability and future maintainability of the code. If you look at it now it may not be obvious why some times interrupts() is called and sometimes it is not, and without understanding how select() and unselect() work differently with and without 1.5.8 SPI this may not be obvious, and lead to mistakes.

The code as it stands creates a subtle dependancy between unselect() and receiveDone(). Always calling interrupts() in receiveDone() breaks this dependancy, and make the code easier to read and more reliable.

I question the motivation for excluding the extra line of code, All this to save a few extra bytes in flash, and clock cycles at runtime, I know this is a constrained platform, but really...

I come from a professional Java coding background, in a large scale system this sort of thing wouldn't be accepted because across many 10's or 100's of thousands of line it is impossible to understand manage.

Kiwi.



Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support
« Reply #24 on: January 26, 2015, 08:47:22 AM »
Got the pull request, thanks.
These are high risk changes and they will need to be well tested before merging.

damadmai

  • NewMember
  • *
  • Posts: 2
    • GitHub
Re: Moteino & W5100 ethernet SPI support
« Reply #25 on: January 26, 2015, 01:17:51 PM »
Hi kiwisincebirth!

As it is not done in the implementation of beginTransaction() and endTransaction() I would suggest placing the lines which save and restore the current SPI settings in front of the #ifdefs to not interfere with other code that accesses SPI and relies on a previous configuration.

You have a typo - "doest" but i don't know if you mean does or doesn't as beginTransaction() saves and endTransaction() restores the SREG and therefore the interrupt bit in SREG is the same as before an SPI access.
In the comments it says that "New SPI Library doesn't disable interrupts" but they are enabled here and here?

And just delete that unnecessary unselect entirely.

Daniel

scott216

  • NewMember
  • *
  • Posts: 41
Re: Moteino & W5100 ethernet SPI support
« Reply #26 on: January 26, 2015, 04:15:14 PM »
How are you guys dealing with the issue that the Moteino uses pin D10 for the radio SS and so does the stock Arduino Ethernet library?  I have a modified Ethernet.h/cpp and w5100.h/cpp files to handle this, but I didn't see any mention of it in the conversation and was curious how you handle it.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support
« Reply #27 on: January 26, 2015, 04:27:07 PM »
This is how:

void RFM69::setCS(uint8_t newSPISlaveSelect)

scott216

  • NewMember
  • *
  • Posts: 41
Re: Moteino & W5100 ethernet SPI support
« Reply #28 on: January 26, 2015, 04:31:56 PM »
This is how:
void RFM69::setCS(uint8_t newSPISlaveSelect)

Nice.  I didn't know about that function.  But wouldn't Moteino's D10 pin be hard-wired to the CS pin on the RFM69 module.
« Last Edit: January 26, 2015, 04:38:02 PM by Felix »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support
« Reply #29 on: January 26, 2015, 04:38:48 PM »
You are correct sir. You move one of the pins to something else :)

scott216

  • NewMember
  • *
  • Posts: 41
Re: Moteino & W5100 ethernet SPI support
« Reply #30 on: January 26, 2015, 05:19:26 PM »
You are correct sir. You move one of the pins to something else :)
I'm confused.  The wiring from pin to the RFM module would be a copper trace on the Moteino PCB.  I don't see how you would change anything.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support
« Reply #31 on: January 26, 2015, 07:38:44 PM »
Cut, resolder to another pin using thin hookup wire, add 1 line of code, done.

scott216

  • NewMember
  • *
  • Posts: 41
Re: Moteino & W5100 ethernet SPI support
« Reply #32 on: January 26, 2015, 08:19:07 PM »
Cut, resolder to another pin using thin hookup wire, add 1 line of code, done.
ok, I see.  I was thinking there might be a less invasive option.

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #33 on: January 26, 2015, 08:42:57 PM »
ok, I see.  I was thinking there might be a less invasive option.
I have followed your approach and moved the Ethernet CS Pin to a different location, and downloaded the updated libraries you referenced.

Kiwi

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #34 on: January 28, 2015, 10:12:44 AM »
<...snip>
I question the motivation for excluding the extra line of code, All this to save a few extra bytes in flash, and clock cycles at runtime, I know this is a constrained platform, but really...

I come from a professional Java coding background, in a large scale system this sort of thing wouldn't be accepted because across many 10's or 100's of thousands of line it is impossible to understand manage.

Kiwi.
The motivation wasn't saving code, but an effort to try to keep the calls to noInterrupts()/interrupts() balanced.  If these ever permit nested hierarchical calls, then an unbalance isn't a good thing.  I'm with you on struggling with the dependency, but, as you say, one step at a time...

Thanks for your work.  Hopefully I'll be able to join in the testing soon, right now I'm butt deep in my gateway code...

Thanks for the W5100 info.  I've ordered some of the 'Mini Shields' (for my gateway) and will be able to test once the 'slow boat' arrives...

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #35 on: January 29, 2015, 07:32:50 AM »
Hi kiwisincebirth!

As it is not done in the implementation of beginTransaction() and endTransaction() I would suggest placing the lines which save and restore the current SPI settings in front of the #ifdefs to not interfere with other code that accesses SPI and relies on a previous configuration.
I have made this change. I am not sure why the the new SPI library doesn't do this in the begin/end transaction, I am guessing the assumption is that SPI will be configured before each access to SPI

You have a typo - "doest" but i don't know if you mean does or doesn't as beginTransaction() saves and endTransaction() restores the SREG and therefore the interrupt bit in SREG is the same as before an SPI access.
In the comments it says that "New SPI Library doesn't disable interrupts" but they are enabled here and here?
I have updated the code to more correctly document the change in the receiveDone() method. However it is important to note that the interrupts are disabled in this method to gain an atomic lock in the code, not specifically about locking SPI access. It just so happened that the completion of SPI calls interrupts are re-enabled by unselect(), thus nointerrupts() didn't need to be called. But with the new SPI library this is not guaranteed to be true, hence noInterrupts() needs to be explicitly called.

RE SPI beginTransaction(). The first couple of lines of code save SREG (to local variable) and disable interrupts. But you should also note that the SREG is restored (a few lines latter) if EIMSK can be used. Thus interrupts are not disabled for the duration of the SPI transaction. endTranaction() is similar in function creating a atomic lock, then restoring SREG.

And just delete that unnecessary unselect entirely.
Done.

The motivation wasn't saving code, but an effort to try to keep the calls to noInterrupts()/interrupts() balanced.  If these ever permit nested hierarchical calls, then an unbalance isn't a good thing.  I'm with you on struggling with the dependency, but, as you say, one step at a time...
To that end I have removed the #ifdefs out of my receiveDone(), and always call interrupts() to balance the noInterrupts() at the the top of this method. This archives matching calls, and removes the dependancy on the select() and unselect() entirely.

Note: Previously it wasn't balanced i.e. recieveDone() calls noInterupts(); select() calls noInterrupts(); unselect calls interrupts(); so 2 x Off and 1 x On.

ALSO. I think the best improvement would be simply to save and restore SREG, where interrupts are enabled and disabled in the code. e.g. select() and unselect()

This would solve a potential problem in interruptHandler(). When interruptHandler() calls a method that requires SPI, that method calls select() does it work then calls unselect(), unselect() then calls interrupts(). Which I assume means for the remainder of the interruptHandler() interrupts can occur.

I am not sure if this is a bug, and easily fixed by saving and restoring SREG in select() unselect(), OR it could be a FEATURE, meaning that other interrupts can occur (e.g. Timer0) during the rest of the interrupt, I don't know how long interruptHandler() takes to execute.

Thanks for your work.  Hopefully I'll be able to join in the testing soon, right now I'm butt deep in my gateway code...

Thanks for the W5100 info.  I've ordered some of the 'Mini Shields' (for my gateway) and will be able to test once the 'slow boat' arrives...

Tom

I have committed my small changes back to my GitHub Fork, not sure if I need to do anything else to make them visible in the Pull request.

This is quite a long post, and I hope it makes sense. Tom Good luck with your gateway

Regards
Kiwi

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #36 on: January 29, 2015, 08:23:48 AM »
<...snip>

The motivation wasn't saving code, but an effort to try to keep the calls to noInterrupts()/interrupts() balanced.  If these ever permit nested hierarchical calls, then an unbalance isn't a good thing.  I'm with you on struggling with the dependency, but, as you say, one step at a time...
To that end I have removed the #ifdefs out of my receiveDone(), and always call interrupts() to balance the noInterrupts() at the the top of this method. This archives matching calls, and removes the dependancy on the select() and unselect() entirely.

Note: Previously it wasn't balanced i.e. recieveDone() calls noInterupts(); select() calls noInterrupts(); unselect calls interrupts(); so 2 x Off and 1 x On.

ALSO. I think the best improvement would be simply to save and restore SREG, where interrupts are enabled and disabled in the code. e.g. select() and unselect()

This would solve a potential problem in interruptHandler(). When interruptHandler() calls a method that requires SPI, that method calls select() does it work then calls unselect(), unselect() then calls interrupts(). Which I assume means for the remainder of the interruptHandler() interrupts can occur.

I am not sure if this is a bug, and easily fixed by saving and restoring SREG in select() unselect(), OR it could be a FEATURE, meaning that other interrupts can occur (e.g. Timer0) during the rest of the interrupt, I don't know how long interruptHandler() takes to execute.

<snip...>

Your comments make sense with respect to the already unbalanced nature of the noInterrupts()/interrupts() calls and I agree with the change.  I can't look at the code right now so can't comment on the SREG discussion although I will say I'm concerned about the possible re-entrance of interruptHandler().  I'll try to get to it later today. 

Tom

damadmai

  • NewMember
  • *
  • Posts: 2
    • GitHub
Re: Moteino & W5100 ethernet SPI support
« Reply #37 on: February 27, 2015, 09:36:34 AM »
Hi kiwisincebirth!

Your new commits are visible in the Pull Request.
Thank you for implementing my suggestions.

I have another suggestion regarding the current state.

https://github.com/damadmai/RFM69/commit/69620f280b5ba8eca991c107097f36a3d9d50d6b

As it might be possible that an interrupt occurs after saving the SPCR and SPSR I think it would be better if the call to noInterrupts() stays where it was like in select().
(and SREG needs only be saved in _SREG if we don't have SPI_HAS_TRANSACTION ;))

And as endTransaction doesn't change SPCR or SPSR unselect() could be written for the same reason as in my commit.

In the Header file it might be necessary to do some #ifdef

In this line with your changes the comment "enables interrupts" would not be true any more because unselect does not re-enable interrupts even if they were not enabled before!
https://github.com/LowPowerLab/RFM69/pull/25/files#diff-2d1040d890d26d4ac6877f9269b3e32fR367
So just please remove this comment.

Thats a comlex change. I just thought two hours about it...

Does anyone know if there is a better way on GitHub to suggest changes to an Pull Request like my manual approach? :)

Daniel

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #38 on: February 27, 2015, 09:49:57 AM »
Daniel, I've added a comment to your commit.  Net: I agree with your change and also added that I think a SPIsettings variable, _settings, should be conditionally added and initialized once, rather than calculate the value on each beginTransactions() call.

Tom

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #39 on: February 27, 2015, 12:47:07 PM »
I've updated the SPIFlash library to include the SPI Transaction support and submitted a pull request.

I've tested this on V1.5.8 and V1.6.0 and don't think I did anything bone headed like the last pull request  :-[

My tests included the updated RFM69 library from kiwi... (with my own transmit power control mods added) as well as simultaneous use with the V1.6.0 SD library which also includes SPI Transaction support.   I've not seen a single hiccup after a lot of traffic, including multiple over the air program updates.  With today's updates to the RFM69 library, I think its good to go.

Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support
« Reply #40 on: February 27, 2015, 01:06:46 PM »
This is an ultra major potentially breaking change and it's very labor intensive to test it properly.
I'm not sure when I will get to this.
Also I am not sure package deal SPI transactions are the best thing either, as we've seen with other things bundled with Arduino. SPI "transactions" were already implemented in the library in a raw way.

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #41 on: March 01, 2015, 09:21:03 PM »
Hi kiwisincebirth!

Your new commits are visible in the Pull Request.
Thank you for implementing my suggestions.

I have another suggestion regarding the current state.

https://github.com/damadmai/RFM69/commit/69620f280b5ba8eca991c107097f36a3d9d50d6b

As it might be possible that an interrupt occurs after saving the SPCR and SPSR I think it would be better if the call to noInterrupts() stays where it was like in select().
(and SREG needs only be saved in _SREG if we don't have SPI_HAS_TRANSACTION ;))

And as endTransaction doesn't change SPCR or SPSR unselect() could be written for the same reason as in my commit.

In the Header file it might be necessary to do some #ifdef

In this line with your changes the comment "enables interrupts" would not be true any more because unselect does not re-enable interrupts even if they were not enabled before!
https://github.com/LowPowerLab/RFM69/pull/25/files#diff-2d1040d890d26d4ac6877f9269b3e32fR367
So just please remove this comment.

Thats a comlex change. I just thought two hours about it...

Does anyone know if there is a better way on GitHub to suggest changes to an Pull Request like my manual approach? :)

Daniel
I have corrected my branch, assume you can see this. Note: I simplified the code with a single #if compiler directive in each of the select() and unselect() methods. IMHO this make it more readable, since you can now clearly identify the two distinct blocks of code. The original code is now back in its unmodified (except fro SREG) state.


kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #42 on: March 01, 2015, 09:25:44 PM »
Daniel, I've added a comment to your commit.  Net: I agree with your change and also added that I think a SPIsettings variable, _settings, should be conditionally added and initialized once, rather than calculate the value on each beginTransactions() call.

Tom

Hi Tom, From the Article

http://dorkbotpdx.org/blog/paul/spi_transactions_in_arduino

Quote
The new SPISettings is a special data type, just for describing SPI clock, data order and format.  For fixed settings, you can use beginTransaction(SPISettings(clock, order, format)), and the compiler will automatically inline your fixed settings with the most optimal code.  For user controlled settings, you can create a variable of SPISetting type and assign it based on user choice, which you don't know in advance.  This allows a very efficient beginTransaction(), because the non-const settings are converted to an efficient form ahead of time.

This statement in the article was the reason I put the SPISettings inside the call to beginTransaction()

Kiwi

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #43 on: March 01, 2015, 09:47:02 PM »
This is an ultra major potentially breaking change and it's very labor intensive to test it properly.
I'm not sure when I will get to this.
Also I am not sure package deal SPI transactions are the best thing either, as we've seen with other things bundled with Arduino. SPI "transactions" were already implemented in the library in a raw way.
I can understand your caution.

FYI I have been running my Gateway Node (Motino and Ethernet Shield) for the past 2-3 weeks. In that time I can say that the gateway hasn't crashed, but I can't confirm I havent lost a message. I have of course been re-flashing it with the latest libraries as changes are made, and with Arduino 1.6.0 when it came out.  The gateway doesn't transmit (it only receives) over RFM radio, and relays to MQTT via the ethernet hardware.

So from my perspective I am good I am fully working (have retired my RaspPi), hopefully in time will post a more complete description of my project to the forum.

I will leave it with you when and if you want to merge it back in, and keep it updated with other changes in you main branch, and suggestions from the community.

Stay tuned, a much more usable and more automatic interface for Moteino based stuff is coming from Low Power Lab. It will only require a few files.

Cant wait.

Kiwi.


TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #44 on: March 01, 2015, 11:42:45 PM »
Daniel, I've added a comment to your commit.  Net: I agree with your change and also added that I think a SPIsettings variable, _settings, should be conditionally added and initialized once, rather than calculate the value on each beginTransactions() call.

Tom

Hi Tom, From the Article

http://dorkbotpdx.org/blog/paul/spi_transactions_in_arduino

Quote
The new SPISettings is a special data type, just for describing SPI clock, data order and format.  For fixed settings, you can use beginTransaction(SPISettings(clock, order, format)), and the compiler will automatically inline your fixed settings with the most optimal code.  For user controlled settings, you can create a variable of SPISetting type and assign it based on user choice, which you don't know in advance.  This allows a very efficient beginTransaction(), because the non-const settings are converted to an efficient form ahead of time.

This statement in the article was the reason I put the SPISettings inside the call to beginTransaction()

Kiwi
Ah, very good.  Thank you very much for pointing this out, I had not realized that - very clever indeed!  I used a variable in the SPIFlash update, perhaps I should change it?  On the other hand, I noticed that a variable was used in the IDE 1.6.0 SD library - maybe they don't trust the compiler as much as the writers of that comment?

Maybe some others should chime in on this.  I'll try to run some experiments to see I can look at the code produced to verify that they do, indeed, use constants as opposed to re-calculating the settings each time.

Regardless, I now understand your reasoning and withdraw my suggestion.  Thanks!

Tom

bborncr

  • NewMember
  • *
  • Posts: 13
  • Country: cr
Re: Moteino & W5100 ethernet SPI support
« Reply #45 on: March 10, 2015, 12:34:32 PM »
Hello everyone, I'm interested in creating a W5100 + Moteino gateway. I've been reading through this post and am confused regarding the exact status.  Which is the repository I should be using to try this out?

Regards,

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #46 on: March 11, 2015, 08:40:39 AM »
Hello everyone, I'm interested in creating a W5100 + Moteino gateway. I've been reading through this post and am confused regarding the exact status.  Which is the repository I should be using to try this out?

Regards,
Kiwi will have to advise you on the specifics on using the W5100 as I'm pretty sure he's using it in his Moteino Gateway.

Re: SPI transaction updates to the RFM69 library, the latest code is on Kiwi's github (referenced in an earlier post) and I am going to create a new extension to my 'virtualized' update to RFM69, which will add Kiwi's SPI Transaction updates in a derived class.  I'm hoping to have that posted on my github later this week (however it is 'March Madness'..., so any predictions at this point are entirely unreliable  ;)

I suspect that Felix is not ready to incorporate the SPI transaction change into the base class simply due to the amount of regression testing he would need to do, but I'll let Felix comment on that.  Also, the urgency is diminished if I'm able to get the SPI Transaction extension completed in a timely manner.

From your perspective, you can use Kiwi's change now (it works well and plays nice with W5100 and SD card libraries), or, when I finish the SPI Transaction extension, use that coupled with my virtualization update to RFM69.  AND, if you're not using Arduino IDE 1.6.0 (or 1.5.8  ) - you don't need any of this!!!

Tom

bborncr

  • NewMember
  • *
  • Posts: 13
  • Country: cr
Re: Moteino & W5100 ethernet SPI support
« Reply #47 on: March 11, 2015, 05:52:42 PM »
What I understood is stopping the RF69 and Ethernet libraries from working together happily is that they are both using pin 10 as SS.  The fix would be to physically move the RF69 SS pin to another (9). And then change the SS using the line that I believe Felix posted previously. I would use 1.0.6 if 1.6.0 is causing problems.

Am I understanding this correctly or missing something vital? I have searched the forum but haven't found mention of an Ethernet/Moteino Gateway apart from this thread.

Regards,

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #48 on: March 11, 2015, 08:38:49 PM »
What I understood is stopping the RF69 and Ethernet libraries from working together happily is that they are both using pin 10 as SS.  The fix would be to physically move the RF69 SS pin to another (9). And then change the SS using the line that I believe Felix posted previously. I would use 1.0.6 if 1.6.0 is causing problems.

Am I understanding this correctly or missing something vital? I have searched the forum but haven't found mention of an Ethernet/Moteino Gateway apart from this thread.

Regards,
I believe that the SS pin for the W5100 can be moved to virtually any pin.  Where it can't be moved is on an Arduino shield THAT IS plugged directly into an Arduino, but that's not an issue with Moteino - the Arduino shield will not plug directly into a Moteino board.  Consequently, whether you use the shield or a W5100 breakout board or design your own PCB, you can connect a different pin from the Moteino to the W5100 - this is a HARDWARE statement. 

Unfortunately the library is another story.  As far as I've seen, it's pretty unfriendly about operating with flexible parameters  AND I just did a deeper look into the library and see that it's even more obnoxious than I realized.  They hard code the SS bit into inline code - incredibly stupid - unless you want it to ONLY work with that limited configuration.  So, Net:  I need to get with my buddy Kiwi and see what he did.
Tom
« Last Edit: March 11, 2015, 08:58:59 PM by TomWS »

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #49 on: March 12, 2015, 09:03:57 AM »
Hi there, in summary, since I lost my more detailed posting.

1. Use arduino 1.6.0, it contains the SpI transaction support to allow the two devices to play nice together.

2. Use the enhanced rfm69 library on my GitHub account, this adds the spi transaction support to the library.

3. I choose to change the Ethernet SS Pin, this requires a change to the Ethernet library, I published the change here. https://github.com/kiwisincebirth/Arduino/tree/master/Ethernet

Lastly, the Ethernet shield is 3.3v compatable, but does require 5v input power. In my setup I have a moteino mounted to a prototype shied which then has an Ethernet shield mounted to it. This means I am free to route any pin I want to pin 10 on the connector, to drive the Ethernet shield

I have been running my gateway without issue for well over a month now, the good thing is that I don't have worry about shutting it down correctly (like rasp pi) there is no OS or sd card to cause an issue.

Kiwi

bborncr

  • NewMember
  • *
  • Posts: 13
  • Country: cr
Re: Moteino & W5100 ethernet SPI support
« Reply #50 on: March 12, 2015, 10:17:16 AM »
Thanks for the info.  I'll give those try.  I have a W5100 module that supposedly works at 3.3V for Vcc and logic. I also want a clean simple gateway that posts to my EMON server in the cloud.

Regards,

bborncr

  • NewMember
  • *
  • Posts: 13
  • Country: cr
Re: Moteino & W5100 ethernet SPI support
« Reply #51 on: March 12, 2015, 04:52:52 PM »
I installed the KiwiSinceBirth RFM69 library and the w5100 files in "arduino-1.6.0/libraries/Ethernet/src/utility/". It turns out the module requires 5V Vcc so I took care of that. The PWR, LNK, SPD, FDS leds all come on and the TX/RX flashes as it sees network traffic. SS is pin 8. The code being used is the DHCP example code (also tried static but no change). Eventually, it times out and the Failed to Configure Ethernet message appears.  Below is the exact code (ethernet only to rules out any conflicts).  Any thoughts?

Connections Module --> Moteino

NSS --> 8
SCK --> 13
MI -->  11(MO)
MO --> 12 (MI)
RST --> not connected

Code: [Select]
/*
  DHCP-based IP printer

 This sketch uses the DHCP extensions to the Ethernet library
 to get an IP address via DHCP and print the address obtained.
 using an Arduino Wiznet Ethernet shield.

 Circuit:
 * Ethernet shield attached to pins 10, 11, 12, 13

 created 12 April 2011
 modified 9 Apr 2012
 by Tom Igoe

 */

#include <SPI.h>
#include <Ethernet.h>
#include <utility/w5100.h>
// Enter a MAC address for your controller below.
// Newer Ethernet shields have a MAC address printed on a sticker on the shield
byte mac[] = {
  0x00, 0xAA, 0xBB, 0xCC, 0xDE, 0x33
};

// Initialize the Ethernet client library
// with the IP address and port of the server
// that you want to connect to (port 80 is default for HTTP):
EthernetClient client;

void setup() {
  W5100.select(8);
  // Open serial communications and wait for port to open:
  Serial.begin(9600);
  // this check is only needed on the Leonardo:
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }
Serial.println("Ready....");
  // start the Ethernet connection:
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Failed to configure Ethernet using DHCP");
    // no point in carrying on, so do nothing forevermore:
    for (;;)
      ;
  }
  // print your local IP address:
  Serial.print("My IP address: ");
  for (byte thisByte = 0; thisByte < 4; thisByte++) {
    // print the value of each byte of the IP address:
    Serial.print(Ethernet.localIP()[thisByte], DEC);
    Serial.print(".");
  }
  Serial.println();
}

void loop() {

}



TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #52 on: March 12, 2015, 07:02:50 PM »
I think you will find that the flash memory chip uses pin 8 as its CS...  If you don't have flash installed then there might not be a conflict unless the pin is getting inadvertently configured (via flash.initialize or something like that).

Check out the great image of the Moteino and its pinouts at: https://lowpowerlab.com/moteino/#pinout  Note the pins with asterisks.

I've downloaded this image and have it on my Desktop, referencing it quite often.  I think Felix should make this into a product, high quality image double laminated in plastic!

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #53 on: March 13, 2015, 05:30:09 AM »
You also need to add a couple of lines of code to set pin 10 as output, and set the output to low, otherwise the pin is a floating input pin, which could cause the rfm radio to interfere on the spi bus.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #54 on: March 13, 2015, 08:45:13 AM »
You also need to add a couple of lines of code to set pin 10 as output, and set the output to low, otherwise the pin is a floating input pin, which could cause the rfm radio to interfere on the spi bus.
Good catch, Kiwi, I failed to see that, with the radio not use, pin 10 won't be declared as an output and SPI won't work, however, to disable the RFM69 CS, pin 10 should be HIGH, not LOW - easy typo.

Tom

bborncr

  • NewMember
  • *
  • Posts: 13
  • Country: cr
Re: Moteino & W5100 ethernet SPI support
« Reply #55 on: March 13, 2015, 03:59:59 PM »
Thanks KiwiSinceBirth and TomWS!  It's all working.  The gateway is receiving sensor values and forwarding them via ethernet. The SS is on pin 7.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #56 on: March 13, 2015, 05:34:35 PM »
Thanks KiwiSinceBirth and TomWS!  It's all working.  The gateway is receiving sensor values and forwarding them via ethernet. The SS is on pin 7.
GREAT! Thanks for sticking with it!  Glad its working for you!

Tom

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #57 on: March 14, 2015, 12:46:25 AM »
Good catch, Kiwi, I failed to see that, with the radio not use, pin 10 won't be declared as an output and SPI won't work, however, to disable the RFM69 CS, pin 10 should be HIGH, not LOW - easy typo.

Tom
Yes when I wrote that (on train) I wasn't quite sure. bborncr, Glad it is working

bborncr

  • NewMember
  • *
  • Posts: 13
  • Country: cr
Re: Moteino & W5100 ethernet SPI support
« Reply #58 on: March 17, 2015, 01:27:11 PM »
I have been having trouble with the Ethernet module not connecting.  Sometimes it worked and sometimes it didn't. After several days of frustration I think I found the problem and a solution.  According to many users the WIZNET module can have troubles after a cold start.  The fix has been to place a 220nF cap between RESET and GND.  I just performed a dozen resets without issue.  The suggested value for the cap is 100nF but I had the 220nF so I used it instead.

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #59 on: March 17, 2015, 01:30:13 PM »
I have been having trouble with the Ethernet module not connecting.  Sometimes it worked and sometimes it didn't. After several days of frustration I think I found the problem and a solution.  According to many users the WIZNET module can have troubles after a cold start.  The fix has been to place a 220nF cap between RESET and GND.  I just performed a dozen resets without issue.  The suggested value for the cap is 100nF but I had the 220nF so I used it instead.
Good to know!  Thanks for the tip!

Tom

Fernando Garcia

  • NewMember
  • *
  • Posts: 6
Re: Moteino & W5100 ethernet SPI support
« Reply #60 on: March 25, 2015, 06:36:12 PM »
Hello guys!

Kiwi, any chance to make this changes to RFM12B library?

I would like to make by myself but I'm not able to work with library core.

I'm using a  custom board with SD card, W5100 and RFM12B.

I can send datas via RF with this boards but I can't receive.

To send datas I had to change this line at CanSend() in .cpp

Code: [Select]
if (rxstate == TXRECV && rxfill == 0 /*&& (Byte(0x00) & (RF_RSSI_BIT >> 8)) == 0*/)

The SD card and W5100 are working fine apparently.

Here two videos showing the RF working



Thanks in advance!

Best regards.




 

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support
« Reply #61 on: March 25, 2015, 07:00:35 PM »
My library and my examples on other hardware, nice. I am famous.

Fernando Garcia

  • NewMember
  • *
  • Posts: 6
Re: Moteino & W5100 ethernet SPI support
« Reply #62 on: March 26, 2015, 10:01:44 AM »
Hi Felix!

I tried buy a Moteino in your store to use in my tests but the RFM12B is out of stock.

If you want know more details about what I'm doing look this topic.

Best regards.

Fernando Garcia

  • NewMember
  • *
  • Posts: 6
Re: Moteino & W5100 ethernet SPI support
« Reply #63 on: March 27, 2015, 10:58:02 AM »

3. I choose to change the Ethernet SS Pin, this requires a change to the Ethernet library, I published the change here. https://github.com/kiwisincebirth/Arduino/tree/master/Ethernet

Kiwi

Hi!

I would like to give a suggestion.

I'm using this method to change the SS pin. Is more complicated to edit library but you can work directly with EthernetClass.

Best regards.

 

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support
« Reply #64 on: March 27, 2015, 06:15:44 PM »
Hi Felix!
I tried buy a Moteino in your store to use in my tests but the RFM12B is out of stock.
If you want know more details about what I'm doing look this topic.
Best regards.
Yeah I had to discontinue RFM12B since there's really low interest in that module and also much lower performance than the RFM69. Nice project by the way.

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #65 on: March 29, 2015, 12:12:48 PM »
Hello guys!

Kiwi, any chance to make this changes to RFM12B library ?

Thanks in advance!

Best regards.
Unfortunately no, the problem is that it isn't a simple change. Felix's RFM12b library doesn't actually use the SPI library, I believe it talks natively to the underlying HW. Thus a complete rewrite of the RFM12b library would be required.

Kiwi

Fernando Garcia

  • NewMember
  • *
  • Posts: 6
Re: Moteino & W5100 ethernet SPI support
« Reply #66 on: April 19, 2015, 01:42:27 PM »
Hi!

Kiwi, thanks for your answer.

Best regards.

RobW

  • NewMember
  • *
  • Posts: 1
Re: Moteino & W5100 ethernet SPI support
« Reply #67 on: July 03, 2015, 02:05:59 PM »
Hi there, in summary, since I lost my more detailed posting.

1. Use arduino 1.6.0, it contains the SpI transaction support to allow the two devices to play nice together.

2. Use the enhanced rfm69 library on my GitHub account, this adds the spi transaction support to the library.

3. I choose to change the Ethernet SS Pin, this requires a change to the Ethernet library, I published the change here. https://github.com/kiwisincebirth/Arduino/tree/master/Ethernet

Lastly, the Ethernet shield is 3.3v compatable, but does require 5v input power. In my setup I have a moteino mounted to a prototype shied which then has an Ethernet shield mounted to it. This means I am free to route any pin I want to pin 10 on the connector, to drive the Ethernet shield

I have been running my gateway without issue for well over a month now, the good thing is that I don't have worry about shutting it down correctly (like rasp pi) there is no OS or sd card to cause an issue.

Kiwi

Hello,

I'm building a RFM69 gateway connected to a W5200 DRDuino Ethernet shield mounted on a Uno R3 board.  I've found this thread enormously helpful in working out what to do.  However I still have a few questions that I'm hoping someone can help with:

1) compatibility with w5200.  I'm using a modified Ethernet library https://github.com/Wiznet/WIZ_Ethernet_Library

2) chip select for SPI bus.  As I understand it, both RFM69 and Ethernet libraries are programmed to use pin 10, causing a bus clash.  The fix is to change one of them.  Which is easiest to alter?

3) as I understand it the enhanced rfm69 library prevents the radio Rx/Tx creating an interrupt when another device is using the SPI bus.  Does the enhanced library function correctly with Arduino IDE 1.6.4?

4) is the converse an issue?  Could the W5200 create an interrupt when the radio Rx/Tx is using the SPI bus?  If so what code could I use to avoid this?

Many thanks for any advice

Rob


kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #68 on: July 26, 2015, 05:46:43 AM »
Hello,

I'm building a RFM69 gateway connected to a W5200 DRDuino Ethernet shield mounted on a Uno R3 board.  I've found this thread enormously helpful in working out what to do.  However I still have a few questions that I'm hoping someone can help with:

Many thanks for any advice

Rob
Hi Rob, sorry for late reply I am not very active on this forum.

1) compatibility with w5200 : I had a quick look at the library, and it doesn't appear to have been updated for the SPI (transactional) changes introduced in 1.6.x Basically it means that while an ethernet library is using the SPI bus there is nothing to stop an interrupt from the RFM69 radio from taking control and using SPI.

2) chip select for SPI bus : I would first look at hardware, is there anything limiting which pin you can move? Software. The RFM libraries support it OOTB, The Arduino W5100 libraries don't support the change without changing the libraries source code.

3) Does the enhanced library function correctly with Arduino IDE 1.6.4? ; The enhanced library was designed to support 1.6.x and above, it is its primary purpose. It is backwards compatible with < 1.6.x with the older SPI libraries.

4) is the converse an issue?  Could the W5200 create an interrupt when the radio Rx/Tx is using the SPI bus?  If so what code could I use to avoid this? ; The W5100 does not implement interrupts ( event though HW supports it ), not sure about W5200. However if it DID, and the W5200 libraries were upgraded to the new 1.6.x SPI libraries, then just a single line of code is required " SPI.usingInterrupt(...);" which registers the interrupt usage, which means that when and SPI usage occurs the interrupt can be disabled.

Hope this helps.

Kiwi

kiwisincebirth

  • Jr. Member
  • **
  • Posts: 69
Re: Moteino & W5100 ethernet SPI support
« Reply #69 on: July 26, 2015, 05:56:49 AM »
Update: While this thread has been dead for many months, my gateway is NOT. Has been running without an issue or any reboot required whatsoever. The good thing is that I can disconnect power without any issue whatsoever, unlike the RPi which it replaced. Very happy indeed.

In summary here is my overall setup.
Remote: Sensor-(Moteino/RFM69) ==>> Gateway: (RFM69/Moteino)-EthernetShield ==>> Server: MQTT -> NodeRed -> Other Applications

Kiwi

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #70 on: July 26, 2015, 06:51:50 AM »
Update: While this thread has been dead for many months, my gateway is NOT. Has been running without an issue or any reboot required whatsoever. The good thing is that I can disconnect power without any issue whatsoever, unlike the RPi which it replaced. Very happy indeed.

In summary here is my overall setup.
Remote: Sensor-(Moteino/RFM69) ==>> Gateway: (RFM69/Moteino)-EthernetShield ==>> Server: MQTT -> NodeRed -> Other Applications

Kiwi
Glad to hear it, Kiwi, and glad to have you back!  I've recently added a gateway with Ethernet using your library and, I, too, am pleased at how well it's working.  No issues at all! 

It would be nice if I could check the link state through the W5100 interface, but that's a W5100 HW issue, outside of any SW capability.

Thanks for your hard work on this.
Tom

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support
« Reply #71 on: October 17, 2015, 04:12:59 AM »
Hi,
Just to mention  an issue, when using Arduino Ethernet Shield and RFM transceivers.

There is a SPI Slave Select issue between the W5100 of the Ethernet Shield and the RFM interrupts.
(see  http://harizanov.com/2012/04/rfm12b-and-arduino-ethernet-with-wiznet5100-chip/).

Even I believe this has nothing to do with the Slave Select  shmitt trigger chip; the solution is very efficient, and consist in disabling the arduino interrupts  at W5100 at SS activation.

In my case using an ATMEGA2560 changing the W5100.h library from:

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  inline static void initSS()    { DDRB  |=  _BV(4); };
  inline static void setSS()     { PORTB &= ~_BV(4); };
  inline static void resetSS()   { PORTB |=  _BV(4); };
To

#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)
  inline static void initSS()    { DDRB  |=  _BV(4); };
  inline static void setSS()     { cli ();PORTB &= ~_BV(4); };
  inline static void resetSS()   { PORTB |=  _BV(4); sei();};

This issue is particularly true when using a asynchronous RF and Ethernet messages (typically, with a  RFM transceiver, an Ethernet Shield and a MQTT broker (PubSubScribe library, 'loop' keep alive function) )

If this looks to be a very old issue (2012) it is not corrected in the Ethernet library of the Arduino IDE package (I have posted a note on the Arduino forum as well).

If we are forced to use unsupported library, may I suggest to add this modification to the new W5100.h library of Kiwi, in order to combine the flexibility of changing the Slave Select pin and the interrupt conflict issue.

Robert



TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #72 on: October 17, 2015, 09:10:13 AM »
@Robert, the library posted on github by kiwi (referenced earlier in this thread) works well with RFM69 library.  I use this on a Moteino/Ethernet gateway running in my vacation home without any issues.

Let me know if you need specifics.

Tom

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support
« Reply #73 on: October 17, 2015, 11:11:40 AM »
Tom,
This is currently the only issue I can describe.
The MQTT "PubSubClient.loop", polls at regular interval the MQTT Broker (via Ethernet). When this happens simultaneous with a RFM radio message reception, the Arduino activity is stopped.

Disabling the interrupt during the Ethernet Slave selection solves definitively the problem (my gateway is running for days now, while before it was hanging after few minutes). I suppose that this issue only happens with two asynchronous functions (Ethernet transfer and RFM interrupts).
If radio reception is synchronised (or chained) with an Ethernet one (or vice versa). The problem should not occur.

So I don't have special needs, the problem is solved for me, but it is a little bit cumbersome to manage different versions of the libraries.

Robert

 

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #74 on: October 17, 2015, 12:05:08 PM »
Disabling the interrupt during the Ethernet Slave selection solves definitively the problem (my gateway is running for days now, while before it was hanging after few minutes). I suppose that this issue only happens with two asynchronous functions (Ethernet transfer and RFM interrupts).
If radio reception is synchronised (or chained) with an Ethernet one (or vice versa). The problem should not occur.
The SPI transaction support is supposed to be doing this (disabling interrupt) automatically.  You shouldn't need to do it explicitly in the ethernet code.

Tom

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support
« Reply #75 on: October 17, 2015, 12:20:45 PM »
Tom,

As a matter of fact I have to do it, and I am using a brand new copy of the Arduino IDE 1.6.5-r5.
I also did try the W5100.h Kiwi version with the SPI version of Paul Stoffregen (see https://github.com/PaulStoffregen/SPI), without success.

But I don't want to continue to argue, this work fine for me.

Robert





TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #76 on: October 17, 2015, 04:16:27 PM »
Tom,

As a matter of fact I have to do it, and I am using a brand new copy of the Arduino IDE 1.6.5-r5.
I also did try the W5100.h Kiwi version with the SPI version of Paul Stoffregen (see https://github.com/PaulStoffregen/SPI), without success.
Yes, of course you do.  I forgot that the RFM69 library hasn't implemented SPI transactions!  I have this implemented in my RFM69_ATC wrapper, which is why I don't have the problem.  Kiwi's change to W5100 was to make the SS pin variable, but he also implemented SPI transactions in his version of the RFM69 library to get it to work.
Quote
But I don't want to continue to argue, this work fine for me.
No argument, just trying to understand what the problem was and you are exactly right, disabling the RFM69 interrupt during Ethernet SPI access (or any other SPI access for that matter) is necessary.

Tom

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support
« Reply #77 on: October 18, 2015, 03:52:17 AM »
Tom,

It is becoming very difficult to follow the RFM69 library variants.
I had a look at the RFM library of Kiwi
   https://github.com/kiwisincebirth/RFM69/blob/master/RFM69.cpp
which looks to integrate the change request :
  https://github.com/LowPowerLab/RFM69/pull/25/files#diff-2d1040d890d26d4ac6877f9269b3e32fR36
This is probably a fix for my issue (didn't try it yet)

However looking at the new releases of the RFM library of Felix, I don't see these changes, however your 'vitalisation' is now included.

Any ideas why the  change above was not implemented, it would greatly improve the management of all the RFM versions and not to patch standard code.

Robert

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #78 on: October 18, 2015, 09:27:57 AM »
Tom,

It is becoming very difficult to follow the RFM69 library variants.
I had a look at the RFM library of Kiwi
   https://github.com/kiwisincebirth/RFM69/blob/master/RFM69.cpp
which looks to integrate the change request :
  https://github.com/LowPowerLab/RFM69/pull/25/files#diff-2d1040d890d26d4ac6877f9269b3e32fR36
This is probably a fix for my issue (didn't try it yet)
Unfortunately, Kiwi's changed RFM69 might be too dated at this point to include directly.
Quote
However looking at the new releases of the RFM library of Felix, I don't see these changes, however your 'vitalisation' is now included.

Any ideas why the  change above was not implemented, it would greatly improve the management of all the RFM versions and not to patch standard code.
At the time these changes were made, I think Felix thought they weren't sufficiently tested enough and required a new (at the time) version of Arduino IDE (1.6.0).  Also, I was trying to incorporate my ATC changes into the base library.   There were also proposals being made to add enhanced security features to RFM69 and the sense was that there wasn't a single combination of these requested changes that everyone wanted.

To deal with this dilemma I proposed virtualizing the RFM69 methods so that derived classes could add features without requiring a change to the base class.  This is how the RFM69_ATC library was born. 

As you point out, the virtualization change has been made to the base class, and I'm working with Felix to resolve the ATC changes.  Frankly I had forgotten about the SPI transaction changes until you mentioned your difficulty.  I do think these changes SHOULD go into the base library and I'll work with Felix to incorporate them into the base library.  I can make the changes to a fork of the RFM69 library and post them on Github if you'd be willing to test it.  I'm sure Felix would appreciate extra help with the testing.

Tom

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support
« Reply #79 on: October 18, 2015, 10:57:59 AM »
Tom,

Ok thanks to your reply, looking forward to see a new RFM69 version including all these changes, for the time being I can live with my W5100 patch.

I didn't mentioned that I am not actually using the  RFM69 library but the RFM69_SessionKey one, which also uses your visualisation, it would be nice to have a smooth way to included it the RFM69 library.

Also I have no problem and time   :) to test  any new RFM version within my limited test environment.

Notes:
Even if the RFM69_SessionKey is generating a little overhead, security (anti-replay) is for me of the utmost importance, so I see it as a nice feature of the standard RFM69 library .
(I have some comments about the RFM69_SessionKey, that I will keep for a future discussion).

Br
Robert

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support
« Reply #80 on: October 23, 2015, 02:01:56 PM »
Tom,
I have modified the standard and current library with the kiwi patches (covering the Ethernet / RFM interrupts issue).
Because I am using  the RFM69_SessionKey Library I had also to modify:
1. the RFM69.h - CtlByte definition with the one used by the SessionKey library.
2. the RFM69_SessionKey.cpp library to take into account the the interrupt issue on the "receiveDone ()" function
Details can be found on: https://github.com/rrobinet/RFM69_Libary.
Modifications are surrounded by excavation points (!!!)
Hoping this may help others.
Robert

FYI
This library was tested  with an Ethernet Shield plugged on an ATMEG2560 (a gateway) together with a RFM69WH and  transmitting in RF  to a Moteino R4 Node (RFM69W)
 - The gateway connects via Ethernet to a Raspberry  server (OpenHab + MQTT broker) to publish and subscribe  Node data
 - In data mode, I use modified version of the RFM69_SessionKey (Challenge extended from a random Byte to  the system time (long integer))
 - In upgrade mode, the  Raspberry server talks to the gateway with a variant of the wirelessProgarmming (Serial connection is replaced by a TCP/IP one)  to upgrade the remote node software.

With the current library I was able to:
- run the normal data mode between Server (MQTT Broker + OpenHab Interface) - RFM gateway - RFM Mote,  without problem during several days.
- start OTA upgrade from the Server across the gateway to the remote node without problem.
 




TD22057

  • NewMember
  • *
  • Posts: 26
  • Country: us
Re: Moteino & W5100 ethernet SPI support
« Reply #81 on: February 11, 2016, 10:57:36 PM »
Hey Robert (or Kiwi),
I was wondering if you could help me understand some of the code in your transaction based RFM69 class. 

In select() (lines 461-462), it's saving SPCR and SPSR (SPI status register) and then restoring them in unselect() (lines 489-490) but I thought that the point of the SPI transaction system was that beginTransaction()/endTransaction() takes care of this.   Is this in case some other library isn't using transactions or am I confused (which I assume is the answer)?

The biggest thing I don't understand is the interrupt handling in receiveDone() (lines 380-407).  The comment by noInterrupts() (line 384) says that the interrupts will get re-enabled in unselect() but the call to interrupts() in unselect() is commented out in the transaction based code.  The original line in Kiwi's code has a comment about why SREG is manipulated but I didn't really understand it at all.  So I was wondering if you (or anyone) could explain why receiveDone() is saving/restoring SREG which wasn't necessary before and why it calls noInterrupts() but never calls interrupts()?  Every other call to interrupts()/noInterrupts() is no longer needed w/ the transaction code so it was a little confusing to me to see noInterrupts() still there on line 384.

Thanks,
TD


TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #82 on: February 12, 2016, 07:54:26 AM »
Hey Robert (or Kiwi),
I was wondering if you could help me understand some of the code in your transaction based RFM69 class. 

In select() (lines 461-462), it's saving SPCR and SPSR (SPI status register) and then restoring them in unselect() (lines 489-490) but I thought that the point of the SPI transaction system was that beginTransaction()/endTransaction() takes care of this.   Is this in case some other library isn't using transactions or am I confused (which I assume is the answer)?

The biggest thing I don't understand is the interrupt handling in receiveDone() (lines 380-407).  The comment by noInterrupts() (line 384) says that the interrupts will get re-enabled in unselect() but the call to interrupts() in unselect() is commented out in the transaction based code.  The original line in Kiwi's code has a comment about why SREG is manipulated but I didn't really understand it at all.  So I was wondering if you (or anyone) could explain why receiveDone() is saving/restoring SREG which wasn't necessary before and why it calls noInterrupts() but never calls interrupts()?  Every other call to interrupts()/noInterrupts() is no longer needed w/ the transaction code so it was a little confusing to me to see noInterrupts() still there on line 384.

Thanks,
TD
TD, your confusion is justified.  There were several iterations of changes to RFM69/W5100 code during the SPI Transaction conversion.  Without going into detail (I probably have forgotten most of it anyway), the RFM69 library from LowPowerLab did not implement the SPI transaction code.   I ended up putting  SPI Transaction support in the RFM69_ATC library as an extension to the base RFM69 library as overrides to the base code.

Here is a snippet from the RFM69_ATC library:
Code: [Select]
//=============================================================================
// select() - replaces base class with one supporting spiTransactions
//=============================================================================
// select the transceiver
void RFM69_ATC::select() {
  // save current SPI settings
  _SPCR = SPCR;
  _SPSR = SPSR;
  _SREG = SREG;
#ifdef SPI_HAS_TRANSACTION
  SPI.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE0));
#else
  noInterrupts();
  // set RFM69 SPI settings
  SPI.setDataMode(SPI_MODE0);
  SPI.setBitOrder(MSBFIRST);
  SPI.setClockDivider(SPI_CLOCK_DIV4); // decided to slow down from DIV2 after SPI stalling in some instances, especially visible on mega1284p when RFM69 and FLASH chip both present
#endif
  digitalWrite(_slaveSelectPin, LOW);
}


//=============================================================================
// unselect() - replaces base class with one supporting spiTransactions
//=============================================================================
// UNselect the transceiver chip
void RFM69_ATC::unselect() {
  digitalWrite(_slaveSelectPin, HIGH);
#ifdef SPI_HAS_TRANSACTION
  SPI.endTransaction();
#else 
  SREG = _SREG;
#endif
  // restore SPI settings to what they were before talking to RFM69
  SPCR = _SPCR;
  SPSR = _SPSR;
}

Tom
« Last Edit: February 29, 2016, 05:28:53 PM by Felix »

TD22057

  • NewMember
  • *
  • Posts: 26
  • Country: us
Re: Moteino & W5100 ethernet SPI support
« Reply #83 on: February 12, 2016, 10:26:14 AM »
TomWS,
Thanks for the reply.  But - the ATC library at LowPowerLab and in your own github repository doesn't contain any transaction code.  Can you update your github repository with the latest version?

And - in your example, could you comment on why the transaction code needs to save and restore SPCR, SPSR, and SREG?  My understanding (probably wrong) is that if all the SPI devices are using transactions, saving and restoring these registers shouldn't be necessary.

Thanks,
TD

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support
« Reply #84 on: February 12, 2016, 12:16:31 PM »
TomWS,
Thanks for the reply.  But - the ATC library at LowPowerLab and in your own github repository doesn't contain any transaction code.  Can you update your github repository with the latest version?

And - in your example, could you comment on why the transaction code needs to save and restore SPCR, SPSR, and SREG?  My understanding (probably wrong) is that if all the SPI devices are using transactions, saving and restoring these registers shouldn't be necessary.

Thanks,
TD
Curious... My own version of the ATC library has the code I posted a little while ago.  I'll have to take a look at the various versions, but I can't do it today.  Maybe this weekend.

Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #85 on: February 29, 2016, 08:53:01 PM »
I would like to jumpstart this thread back to life in an effort to try to consolidate the SPI transaction support into the master RFM69 library.
To try to clarify some confusion - when I added Tom's ATC changes, it was an entirely manual change by myself, without a proper merge. I had to do that since Tom's pull included other things I was not ready to integrate at that time, including any SPI transaction support.

Now ... at this point in time I would like to add SPI transaction support, based on kiwisincebirth's pull request and also select changes from Tom's SPI transaction branch. Sorry guys, I know it's been 1 year since this stuff was pushed but I am just that slow these days.

Since these pulls and branch are too different than the current master, I had to do a manual merge of these into a new branch of my own: https://github.com/LowPowerLab/RFM69/tree/SPI_TRANSACTION-attempt
Consider this a SPI transactions branch only.
I would like to ask TomWS and kiwisincebirth (and others that wish to review/test) to please take a look at this new branch. Please let me know what you think and if I am missing something. I will try to test this but first I'd like to get a first pass of your review. One thing I still don't fully understand, and it was asked by TD22057 also, is why there's still a need to save/restore SPCR and SPSR in addition to the SPI transaction calls.

geco82

  • NewMember
  • *
  • Posts: 1
  • Country: it
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #86 on: August 17, 2016, 04:32:10 AM »
Hi Felix,
did you managed to test the SPI support?

I'm new to moteino and I have also experienced some silly errors so I wouldn't like to break my settings...

Thanks

Giacomo

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #87 on: August 17, 2016, 08:00:39 AM »
Hi Felix,
did you managed to test the SPI support?
Hi Giacomo,
Unfortunately not. There has been no activity on this SPI-transaction-attempt branch linked above and I don't really use any other SPI devices on the Moteinos (like the W5100) so I don't see these issues. The master branch has since been updated with various patches so this is now behind but can probably merge the master commits.

vysocan

  • NewMember
  • *
  • Posts: 1
  • Country: cz
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #88 on: September 20, 2016, 01:42:52 PM »
Hello Felix,

I will be happy to test SPI transaction with W5500, which I heavily use. In fact I'm using your SPI transaction attempt already, but it hangs after while. I did not give it more thoughts, as I had some hardware problem with W5500, but now I can come back to it. Using cli(); sei(); keep my code running, but I'm loosing interrupts.

For W5*00 I use official WizNet library which I think is fully equipped with SPI transaction support.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #89 on: September 20, 2016, 02:53:31 PM »
@vysocan,
Thanks for the offer, I am not familiar with the new W5500, only a little with the older W5100, and I don't have any of the hardware available. Either way the story is similar to any SPI device. If you find the branch can be improved you can submit pull requests with your patches, and I will try my best to assist and test.
Thanks again.

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #90 on: September 30, 2016, 11:09:39 AM »
Hello Felix
I have tested the RFM_SPI_TRANSACTION_attemp library which is actually not working (RFM is hanging with an Ethernet controller).
It is quite similar to the Kiwi version, however  one piece is missing (see modification 3.)
Modification 1 and 2 are related to compilation errors.
 
Modification: RFM69.h
1. Suppress “SPISettings _settings;”  which cause a compilation error for incorrect type

#ifndef SPI_HAS_TRANSACTION
    uint8_t _SREG; // Saves the Interrupt state before disabling
// !!!! ROB    SPISettings _settings;
#endif

Modifications in RFM69.cpp
1. Suppress after the association of SPISettings to _setting after SPI.begin ();
  SPI.begin();
/* !!!!!!! ROB
#ifdef SPI_HAS_TRANSACTION
  _settings = SPISettings(4000000, MSBFIRST, SPI_MODE0);
#endif
*/


2. replace _settings by its actual function in RFM69::select ();
void RFM69::select() {
#ifdef SPI_HAS_TRANSACTION
  #if defined (SPCR) && defined (SPSR)
    _SPCR = SPCR;
    _SPSR = SPSR;
  #endif
// !!!!! ROB  SPI.beginTransaction(_settings); // Replaced by …
  SPI.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE0));// !!!!! ROB

#else
…..

3. Most Important add SPI.usingInterrupt(_interruptNum) in the bool RFM69::initialize(uint8_t freqBand, uint8_t nodeID, uint8_t networkID)
……..
  while (((readReg(REG_IRQFLAGS1) & RF_IRQFLAGS1_MODEREADY) == 0x00) && millis()-start < timeout); // wait for ModeReady
  if (millis()-start >= timeout)
    return false;
//!!!! ROB
#ifdef SPI_HAS_TRANSACTION
  SPI.usingInterrupt(_interruptNum);
#endif
//!!!!! 
 
  attachInterrupt(_interruptNum, RFM69::isr0, RISING);

  selfPointer = this;
  _address = nodeID;
  return true;
}

TomWS

  • Hero Member
  • *****
  • Posts: 1930
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #91 on: September 30, 2016, 04:32:46 PM »
3. Most Important add SPI.usingInterrupt(_interruptNum) in the bool RFM69::initialize(uint8_t freqBand, uint8_t nodeID, uint8_t networkID)
……..
  while (((readReg(REG_IRQFLAGS1) & RF_IRQFLAGS1_MODEREADY) == 0x00) && millis()-start < timeout); // wait for ModeReady
  if (millis()-start >= timeout)
    return false;
//!!!! ROB
#ifdef SPI_HAS_TRANSACTION
  SPI.usingInterrupt(_interruptNum);
#endif
//!!!!! 
 
  attachInterrupt(_interruptNum, RFM69::isr0, RISING);

  selfPointer = this;
  _address = nodeID;
  return true;
}
THAT is sort of key to the whole thing working, isn't it!!!   ;)

Good job.
Tom

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #92 on: September 30, 2016, 04:59:34 PM »
Thanks Robert, this is great, I will have to try to test and merge these changes when I get a chance.
So did you start off with the RFM69-SPITransaction-attempt branch and just added the changes you mentioned?

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #93 on: October 01, 2016, 03:33:56 AM »
Felix,

Yes I just did those changes to the RFM69-SPITransaction-attempt branch, and I am running my Arduino Ethernet gateway with this version.

Now I have two remarks.
1. The RFM69-SPITransaction-attempt library is slightly different that the "last official" RFM69 one (so I will check the patch with the last version, and give you a feedback).
    Note that I don't use the ATC option, but I will also try it with the updated version
2. The interrupt patch uses direct access to AVR SPI registers, which is an issue while using this with ESP8266 modules.

As far I have test it the current RFM69 library is compatible with the ESP8266 SPI library and the interrupt issue of the Arduino Ethernet shield does't occur with the WiFi interface, so the patch is not necessary for ESP8266.
Introducing direct access to AVR registers or SPI functions that are not defined in the ESP8266 SPI library makes the RFM69 library incompatible with the ESP8266 which is annoying because two different versions have to be maintained.

This requires more work to find if compatible solution may be found, but I will give a try !

Robert

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #94 on: October 04, 2016, 10:57:42 AM »
Voil 
After spending some time to read all the comments regarding the SPI library interrupt issue and improvement, let me summarise my findings expecting to clarify this topic.

Motivations:
ESP micro-controllers allow concurrent usage of Ethernet Wireless and RFM69 Wireless modules and is a cheap alternative to Arduino WiFi Shield to build Ethernet/RFM Gateways.
The RFM69 library is compatible with the ESP8266 devices such as WeMos, NodeMCU, HUZZA, etc… more precisely the ESP8266 SPI library (currently 2.3.0).
See https://lowpowerlab.com/forum/projects/(update)-rfm69-library-for-esp8266-moteino-compatible!/75/
(Beside possible SPI clock speed adjustment; see https://bitbucket.org/xoseperez/rfm69gw), and below: SPI depreciated functions).

For Ethernet wired configuration, using RFM69 transceivers and Arduino Ethernet board based on WizNet5100 (Arduino Ethernet or Arduino Ethernet Shield) there are SPI interrupt conflicts that are hanging sketches; this issue is solved by a new version of the SPI library and RFM69 library patch (currently not implemented).

Goal:
To have a RFM69 library operable in both Arduino Ethernet and ESP8266 environments.

Current issues:
Arduino AVR environment.
When using SPI interrupts (case of W5100 and RFM69), interrupts conflicts may occurs.
This problem is described by http://dorkbotpdx.org/blog/paul/spi_transactions_in_arduino
The workaround is a new SPI library (since Arduino IDE 1.5.8 )
This new library implements 3 new functions while accessing (select / unselect SPI):
 From synchronous access:
  SPI.beginTransaction(SPISettings);
  SPI.endTransaction();

 For asynchronous access:
  SPI.usingInterrupt(number);
Which are well documented, see http://www.pjrc.com/teensy/td_libs_SPI.html

To activate conditionally these new functions, for compatibility with older IDE compilers, a statement SPI_HAS_TRANSACTION is defined in the new SPI library.

A patch using these functions for the RFM69 library was submitted by kiwisincebirth (see https://github.com/kiwisincebirth/RFM69) but was never actually implemented.

So the first fix is to ensure that this patch is working in an environment where an RFM transceiver is activated together with an Ethernet shield.

ESP environment
If the SPI_HAS_TRANSACTION i.e: SPI.beginTransaction(SPISettings) and SPI.endTransaction() is implemented in the ESP8266 SPI library (2.3.0), the (SPI.usingInterrupt(number) is not, which is a first issue.
Also, the kiwisincebirth  patch makes access to an AVR register: SREG (Status Register) this register doesn’t exit as such in the ESP8266 which is a second issue.
Moreover the kiwi patch which is working for Arduino AVR, was removed for an obscure reason to fit the ESP environment see https://github.com/esp8266/Arduino/issues/1943 and https://github.com/LowPowerLab/RFM69/commit/ec90680e008c366dc7340ec1aada3942f8592707

So the second fix is to ensure that the patched RFM69 library is still working with the ESP8266 SPI library.

Note:
The RFM69 library uses references to other registers such as SPCR (SPI Control register) and SPSR (SPI Status Register). However conditional access to  these registers is made (typically  via : if defined (SPCR) && defined (SPSR)). Because SPCR and SPSR are not defined in the ESP8266 library, this is not causing a problem.

Current approach
With this approach the new SPI functions will be activated according to the SPI library version using “#ifdef SPI_HAS_TRANSACTION”
Saving and restoring the SREG is more likely unnecessary (was verified during tests), but for backward compatibility, reference to this register is made conditional for AVR environment.

Now, to avoid activating the function SPI.usingInterrupt(number), an extra test is done to one the processor type (typically ESP8266) using “#if defined (SPI_HAS_TRANSACTION) && !defined (ESP8266)" before activating this function.

Depreciated SPI functions in RFM69 Library
Small library improvements may be applied.
1. Explicit reference to Interrupt Number, which could be replaced by: digitalPinToInterrupt(interrupt_pin)
2. SPI functions such as:
        SPI.setDataMode();
        SPI.setBitOrder();
        SPI.setClockDivider();
   Are replaced by SPISettings(speed, bit_order, mode) see https://www.arduino.cc/en/Reference/SPISettings (which by the way is also implemented in the ESP library).
 This feature allows to use the appropriate speed for a SPI device independent of the processor clock :D

Conclusions:
The RFM69 library issues described above are not related to a MOTEINO environment but related to the usage of this library with SPI Ethernet controller or ESP controllers.

One has to decide if this library update is to be implemented or not in the frame of MOTEINO.

My point of view is that it should be implemented to make usage of the new Arduino SPI library functions (MOTEINO uses AVR processors), despite the fact that the ESP SPI library is not implementing the SPI.usingInterrupt(number) function (or a similar dummy function) see http://www.esp8266.com/viewtopic.php?f=28&t=11998&sid=59d9547d624a26a1de38a1e6ebbf3932#p56001f=28&t=11998&sid=59d9547d624a26a1de38a1e6ebbf3932

In this case the only solution for people wanting to use the RFM69 library for ESP micro-controller is to adapt the library avoiding to activate SPI.usingInterrupt(number) controlling the environment using “if defined (ESP8266) statement”. 
Tests
I did tests with an Arduino ATMEGA2560, Arduino Ethernet Shield and  RFM69HW transceiver as network coordinator (sending converted RFM messages via  Ethernet MQTT to a Raspberry OpenHab broker) for my Home automation MOTEINO RFM69 nodes . This version is currently running in my operational environment, without problems.

I have also loaded  an  ESP-12 with a similar gateway sketch, I use the Struct_send.ino sketch from the RFM69 library to send RFM data that are forwarded via Wifi to my Raspberry Broker without problems.

I plan to replace my coordinator by WeMOs module on a Charles-Henry Hallard WeMos-RFM gateway, I will keep you inform if I encounter new problems.


For the record I have posted a RFM69.cpp and RFM69.h updated library on https://github.com/rrobinet/RFM69_Libary where my modifications are clearly indicated (!!! ROB)

NB: RFM_ATC library was not tested because of compilation errors, but this is another story (I must admit that I did not spend too much time to debug that one)
 

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #95 on: October 26, 2016, 03:05:35 AM »
For information the RFM69 library on WeMos is also working
Robert

JP

  • NewMember
  • *
  • Posts: 2
  • Country: es
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #96 on: November 07, 2016, 01:17:13 PM »
Hello,

We are trying to develop a RFM69HW gateway with a W5100 chip. After reading all the posts of the topic...

I have downloaded the new version of the RFM69HW of Robert

And I am not sure if it is necessary, or finally not, to install the modified Ethernet Library with the CSPIN argument.

I am also confused if it is, finally, necessary or not to add the cli() and sei() lines into the w5100 library.

Thanks for your work, it is really awesome.

Congratulations!!!
« Last Edit: November 07, 2016, 02:58:03 PM by JP »

Robert

  • Jr. Member
  • **
  • Posts: 66
  • Country: be
Re: Moteino & W5100 ethernet SPI support / SPI_HAS_TRANSACTION
« Reply #97 on: November 19, 2016, 01:08:08 PM »
Hi JP,

I do not use the W5100 directly, what I did use is the Arduino Ethernet Shield with an ATMEGA2560 and the Ethernet Library, (which is using the W5100 one) together with an home made RFM69HW shield.
As I wrote previously, the issue is while multiple SPI slaves are used (RFM69 and W5100 for instance)

This issue is solved by the new (current) SPI library, that introduces a way to control / co-ordinate SPI transactions. The SPI.beginTransaction() at the time a specific SPI device is selected and the SPI.endTransaction() at the end of the selection. These SPI library functions are taking care of the interrupts.
Now the W5100 library is probably not updated with these new functions, however using these ones with the RFM69 library looks to be sufficient.
So when using an RFM69 and a W5100, you should use my patched RFM69 library, and you should NOT enable and disable interrupts with cli() and sei() in a modified Ethernet library such as the one described by http://harizanov.com/2012/04/rfm12b-and-arduino-ethernet-with-wiznet5100-chip/
You may perhaps modify the W5100 library with the SPI transaction functions, but this is another story :)

However while connecting a RFM69 transceiver on an Arduino, you should take care of a correct configuration of the SPI signals (I/O pins) and use an appropriate Slave Select pin.

Note: If you don’t need several I/Os, I strongly recommend you to have a look at the WeMos module and at the WeMos gateway of Charles-Henry Hallard (ESP8266 WeMos Shield for HopeRF RFM69 and RFM12 Module see https://github.com/hallard/WeMos-RFM69). Which with a little effort .... will allow you to build a powerful and cheap Ethernet (WiFi) (WEB) gateway.

Robert