ARM port?

[bevangg]

Hi Robert
I have been using your brilliant library for lightwave rf home automation for some time now. I am hoping to get it working on the ARM platform with a view to using Spark Cores / Dues as the main control units and web interface and very cheap arduinos controlling relays, pirs etc through lightwaverf. Peekay on the spark core forums has been helping and has already done a lot of the ground-work, having created a timer library for the due / spark core. Unfortunately we have not been able to get it working properly, it does actually transmit and receive but does not behave consistently. Your library just works perfectly with the arduino atmel but will not compile for the due / spark.
Here is a link to the thread:
https://community.spark.io/t/lightwaverf-library-port-for-spark/4179/39
There are links to Peekay's spark mods and interval timer library in there.
I have no idea as to whether you could help to port the library but if you could I would gladly send you a brand new unused spark core to test and enjoy. I am going to send one to Peekay to thank him for all his help.
Regards
Bevan

[roberttidey]

This sounds interesting. I have been through the thread and it sounds like you / Peekay have had some success but ups and downs as well with the recent issues being mainly around TX.

I do have dev environments for the chip used in the Spark as it is the same as the one used in my digital scope (SeeedStudio DSO203) which I do a bit of firmware development on. It is also similar to the Due processor used in my 3D reprap printer and I compile for that as well.

Let me start by looking at what has been done by Peekay so far which I'll do over the next few days.

In principle the library is quite simple but it does rely on interrupts. I did it this way as it allows the rx and tx to be fairly independent of any applications running in the foreground and it also allowed very accurate control of the timing on the mega chip. The rx uses pin change interrupts and then uses internal clocks to effectively measure the timing of each pulse. The tx side uses a fixed timer interrupt which is set to allow generating the pulse widths required. Both the rx and tx interrupt routines are effectively state machines to keep the logic straightforward and minimise the time spent in the interrupt service routines.

The main challenge is probably caused by making it work within the Spark software environment as opposed to the bare chip environment of the mega chip where everything is under one's own control.

I'll get back to you when I have had a chance to check this out further.

[roberttidey]

Couple of observations. On the RX side changes seem to be primarily changing int to uint16, disabling EEPROM, and allowing any pin as the trigger. That should be OK and I understand rx is largely working.

On the TX side the changes are again, disabling EEPROM, into to uint16, but now the interrupt set up is changed from the mega register specific approach to using built in interrupt handlers and the SparkIntervaltimer. The set up looks a bit strange to me around line 242. The ifndef logic doesn't look right to me as it looks like it is using the old clock count calculation for SPARK and the new one for Mega. If so then the clock measurements will be all wrong. If this don't correct it then I would start checking what overheads are in the general interrupt handler before it gets to the handler in the library. I chose to use the direct interrupt set up in the mega to avoid arduino overheads which can be quite large. It may be OK for the SPARK as the CPU is much faster.

[bevangg]

Thanks for the suggestions. I will have a look over the weekend.
Regards

[bevangg]

Hi Robert
Peekay and I are both looking into it. I hope that you will follow and comment on the thread on the spark forum:
https://community.spark.io/t/lightwaverf-library-port-for-spark/4179/43
It would be great to get this working, it would work on most arm avrs with minimal modification.
Regards

[bevangg]

Hi Robert
It seems that you were absolutely spot on with that. Peekay has changed the library and it now seems to be working.
Please follow the link from my last post to see peekay's update.
His modification of your library can be found here:
https://github.com/pkourany/LightWaveRF_Tidey_Library
I am testing it for a day for stability before saying for sure but so far it is looking really good and needless to say it is very fast and responsive.
Thankyou so much for your input, I can't believe that something that has taken weeks of my time fumbling for answers has been resolved so quickly.
Do you want a spark core, I have got one with your name on it.
Best Regards

[roberttidey]

Hi bevangg,

Good to hear that it has sprung into life. I hope it continues to work
out OK. Peekay deserves all the credit for for the porting work. I can
see from the thread that early on the port was thought to be a daunting
task but the way library works is fairly straightforward if one can find
a way to tie it into the interrupt system. He has done a nice job on
making it work in this different environment. Sometimes it just needs a
different pair of eyes to see what is getting in the way.

I'll continue to watch that thread as I'm indeed interested to see this
sort of activity on a different processor and the Spark is a neat
platform for automation of this sort. The mega also remains a nice
economical way of making simple dedicated end points which is how I
started on the library work.

If you need any further help just let me know. Thanks also for the kind
offer of the spark core. I am very interested in this technology but I
haven't really done that much to help out here.

regards

On 30/05/2014 22:07, bevangg wrote:

Hi Robert
It seems that you were absolutely spot on with that. Peekay has changed the library and it now seems to be working.
Please follow the link from my last post to see peekay's update.
His modification of your library can be found here:
https://github.com/pkourany/LightWaveRF_Tidey_Library
I am testing it for a day for stability before saying for sure but so far it is looking really good and needless to say it is very fast and responsive.
Thankyou so much for your input, I can't believe that something that has taken weeks of my time fumbling for answers has been resolved so quickly.
Do you want a spark core, I have got one with your name on it.
Best Regards

---

Reply to this email directly or view it on GitHub:
#1 (comment)

[pkourany]

Robert, I just wanted to add my thanks. Like you said, sometimes a different pair of eyes is all that's needed :)

Paul