RFM69HW demo application for blue pill?

turboscrew
Sun Dec 17, 2017 1:22 am
Does anyone know a demo application for blue pill that at least sends some data using RFM69HW-module?
I can receive data that I send from another blue pill using CC1101-module, but it looks like I haven’t got the RFM-module to send anything.
(Well, from CC1101 to another CC1101 the data transfer is fine, but the receiving RFM seems to loose the bit sync.)

It looks like as if the RFM sends the messages (frame sent interrupt), but a receiving CC1101 doesn’t even see any change in the RSSI.

I’d just like to see that the RFM-module is able to send something, and maybe even discover what I’ve been doing wrong.


mrburnette
Sun Dec 17, 2017 1:47 am
Start here, from a year back in time:

viewtopic.php?t=1582

Ray


turboscrew
Sun Dec 17, 2017 10:54 am
I checked those, but there seems to be quite some porting to do, and they are libraries.
For those I’d have to start a new project in the middle of my current project.
My current project is done in plain C (and a bit of assembly) and without any libraries. (Well, I use stdint.h, but everything else is my own writing.)

But if I have to port a library, so be it. In that case, which one would be smaller job?
I already installed Arduino and Arduino_STM32 just to be ready.
I really wouldn’t like to use HAL-libraries.


mrburnette
Sun Dec 17, 2017 10:51 pm
I did a Google search against github.com

rfm69 stm32f103 site:github.com


turboscrew
Tue Dec 19, 2017 1:36 pm
I tried to replay earlier, but the site seemed to have some problems…

Yes, the RFM69-STM seems to be a “subset” of the LowPowerLab-library. Made me think, maybe that’d be less porting…
What’s “a multi-tab Arduino project”? I’m very new to Arduino.
I’ve mostly written my own programs without any libraries, and using C/assembly.
(I’ve been interested in learning about HW interfaces, not about learning the interfaces of some – often huge – libraries.)


mrburnette
Tue Dec 19, 2017 2:23 pm
[turboscrew – Tue Dec 19, 2017 1:36 pm] –
<…>
What’s “a multi-tab Arduino project”? I’m very new to Arduino.
I’ve mostly written my own programs without any libraries, and using C/assembly.
<…>

Let look at a new project:

SingleTab.png
SingleTab.png (9.66 KiB) Viewed 399 times

turboscrew
Tue Dec 19, 2017 2:26 pm
Loads of thanks!
You, mrburnette, seem to have a quite nice collection of projects. :-)

Now that I’ve looked further into the codes of the libraries, it looks like LowPowerLab-library and it’s derivatives are much easier to port for blue pill. At least it looks like it uses Arduino libraries, that are already installed when I installed the Arduino and STM32-core. Porting HAL-based stuff seem much more laborous.


mrburnette
Tue Dec 19, 2017 2:43 pm
To dramatically show the difference, last year I took an ESP8266 Arduino project and ported it over to a multi-tab project – essentially not adding any functionality … or value!

The Sniffing2 is my first working rendition of code as the original author’s version which did not compile successfully.
Sinffing6 is the same code in an organized Arduino multi-tab project.

Ray


turboscrew
Tue Dec 19, 2017 9:11 pm
Is that a way around “single file application”?
It looks like the application is supposed to be contained in a single .ino file, and anything bigger should be broken into libraries.
At least it seems hard to open other kind of files.
And a bit bigger chunk in a single file is really a P.I.T.A.

(Like I mentioned, I’m _very_ new to Arduino, even if I have about 20 years of experience as an embedded SW programmer.)


fredbox
Tue Dec 19, 2017 9:47 pm
Each folder will have only one .ino file that is your main application. Additional tabs will be .cpp and .h files.

You can choose to create custom libraries if you want, but for many projects they add unnecessary complexity. If you do use 3rd party libraries, it is suggested that you copy the libraries into the folder with your sketch. I’ve had projects where the library folder was updated and it broke something. I have one project that is 20+ tabs and the only library used is Streaming. Everything else is standard C code in a .cpp file with a .h header.

I typically only have setup() and loop() in my .ino file with everything else in external cpp and h files.


mrburnette
Wed Dec 20, 2017 1:13 am
[turboscrew – Tue Dec 19, 2017 9:11 pm] –
Is that a way around “single file application”?
It looks like the application is supposed to be contained in a single .ino file, and anything bigger should be broken into libraries.
<…>


Absolutely!

[fredbox – Tue Dec 19, 2017 9:47 pm] –
…each folder will have only one .ino file that is your main application. Additional tabs will be .cpp and .h files.

Not necessarily.

MultiTab.png
MultiTab.png (14.18 KiB) Viewed 355 times

turboscrew
Wed Dec 20, 2017 9:37 am
Thanks.
I think it’s beginning to dawn to me. Still takes some brewing in my mind… :D

mrburnette
Wed Dec 20, 2017 1:00 pm
[turboscrew – Wed Dec 20, 2017 9:37 am] –
Thanks.
I think it’s beginning to dawn to me. Still takes some brewing in my mind… :D

Brewing is best left for coffee … which, has just completed according to the beeping on my coffee maker.
Coffee, making the world a better place one cup at a time :D

As far as the ArduinoIDE is concerned, just approach this tool as that, “a tool.” You can use it simply or you can use it in a more complex manner, the choice is yours. As you do traditional C and assembler, you may find this article very interesting:
https://hackaday.com/2015/10/01/arduino … -for-that/

The official page on using makefiles:
https://playground.arduino.cc/Learning/CommandLine

Ray


turboscrew
Thu Dec 21, 2017 12:37 pm
[mrburnette – Wed Dec 20, 2017 1:00 pm] –
Brewing is best left for coffee …

Or beer?

I meant that I need to let things to find their place in my mind, when it comes to the structure of Arduino code.
Especially the kind that’s supposed to play nice with Arduino IDE. :lol:

The article about make was interesting. Thanks!


mrburnette
Thu Dec 21, 2017 1:34 pm
[turboscrew – Thu Dec 21, 2017 12:37 pm] –
<…>
I meant that I need to let things to find their place in my mind, when it comes to the structure of Arduino code.
Especially the kind that’s supposed to play nice with Arduino IDE. :lol:
<…>

I understood and agree. Even old-time Arduino users such as myself (I got started long before the 1.0 release) need to think about what we are doing in the IDE. For example, the IDE typically avoids (the need for) forward declarations, but not always.

Ray

PS: Coffee can sustain life… Beer can create life… and often does :D


turboscrew
Tue Dec 26, 2017 2:29 pm
Hmm, this doesn’t seem to work: https://github.com/brainelectronics/RFM69-STM32
It hangs at the first sending. I don’t think I’m willing to debug that code, especially when that means adding another full development environment to this machine (StinkBad T400 / Linux Mint). I already have another machine (StinkBad T42 / Slackware) with a different development environment (Eclipse + OpenOCD) that I use for most on my STM32-SW development, and I don’t think it’s that simple to put Arduino in a Slackware machine.

This (from the .ino-file):
if (currPeriod != lastPeriod)
{
lastPeriod=currPeriod;

Serial.print("Sending[");
Serial.print(sendSize);
Serial.print("]: ");
for(byte i = 0; i < sendSize; i++)
Serial.print((char)payload[i]);

if (radio.sendWithRetry(GATEWAYID, payload, sendSize))
Serial.print(" ok!");
else Serial.print(" nothing...");

sendSize = (sendSize + 1) % 31;
Serial.println();
Blink(LED,3);
}


turboscrew
Wed Dec 27, 2017 2:15 pm
Is the NSS handled by SW? (I couldn’t find it in the core code.)
In my blue pill chips the HW NSS doesn’t seem to work, and I’ve seen problems like that reported elsewhere too.

mrburnette
Wed Dec 27, 2017 4:27 pm
[turboscrew – Wed Dec 27, 2017 2:15 pm] –
Is the NSS handled by SW? (I couldn’t find it in the core code.)
In my blue pill chips the HW NSS doesn’t seem to work, and I’ve seen problems like that reported elsewhere too.

I thought the NSS stuff was fixed a long time ago:
viewtopic.php?t=285
but, maybe just for the NRF24L01 although the same fix may be applicable, in theory.

But, I have never tried the RFM69HW with the Maple Mini… so, I am no help here. Perhaps another member?
RFM69HW site:STM32duino.com


turboscrew
Wed Dec 27, 2017 5:08 pm
I don’t think new SW repo can fix HW-bugs. I know that STM32-SPI NSS should work such that when the first byte is written to data register, the clock starts ticking and the NSS goes low. So far so good. When the last bit is clocked out and new data in not written in, the clock stops, but the NSS stays low. The NSS is supposed to go high when you turn OFF the SPI (spie-bit). That according to the specs, but with several chips that doesn’t seem to work. In some chips, the NSS doesn’t go low at all, and in some chips – like mine, the NSS doesn’t go high when the SPI is disabled. It goes up eventually, but at least in my case (checked with logic analyzer) 5 ms was not long enough, after disabling the SPI, to see NSS getting HIGH.

I then tried to use the same pin (PA4) as a GPIO and controlled it by SW, but the darn SPI still read that pin and when it saw the pin getting low and it didn’t drive that, it generated mode error and dropped to slave mode. So I had to leave PA4 unconnected and use another GPIO (PA3 was nicely free) for SW NSS.

And I don’t have any Maples either. Just blue pills.

To my understanding, this NSS-bug is almost as famous as the wrong kind of RTC crystal (LSE doesn’t start), but in this case, the bug is in the chip.


mrburnette
Wed Dec 27, 2017 5:17 pm
Ummm…

Reworking the query:
NSS RFM69HW STM32F103

gives this:
https://www.google.com/search?ei=39RDWo … +STM32F103

and points to what looks like a working solution:
https://jeelabs.org/article/1613c/


mrburnette
Wed Dec 27, 2017 5:18 pm
the bug is in the chip.

Oh, my :shock:

One man’s bug is another’s feature.

Ray


turboscrew
Wed Dec 27, 2017 5:42 pm
OK. That’s probably the fix to situations where the HW NSS doesn’t seem to do anything, but in my chips the NSS seems to go low just as expected, but it doesn’t go high – at least in any reasonable time.

I just checked. I had left a comment to myself in my code that turning SSOE to zero didn’t help… ;-)

And my Arduino-STM32 core was downloaded Dec 17. Is that new enough?


mrburnette
Wed Dec 27, 2017 5:46 pm
[turboscrew – Wed Dec 27, 2017 5:42 pm] –
OK. That’s probably the fix to situations where the HW NSS doesn’t seem to do anything, but in my chips the NSS seems to go low just as expected, but it doesn’t go high – at least in any reasonable time.

Do you need a 10K pullup?


turboscrew
Wed Dec 27, 2017 7:17 pm
Well, in my own projects I’ve been using SW NSS and some other GPIO and I haven’t had any problems. And with SW NSS I can put more than one chip on the same SPI “bus”. Just separate NSS-pin for each… :)

Maybe that NSS-changing hasn’t worked. I think I’ll remove the NSS-pin mappings and try with the default (PA4) next.

I don’t think any additional pull-ups should be needed? I don’t think the HW NSS-pin is open drain – at least open drain without internal pull-up?


turboscrew
Thu Dec 28, 2017 7:24 am
Mrburnette, you were referring to this?
viewtopic.php?f=14&t=300
So the NSS is PA4 and it now should be controlled by SW?

turboscrew
Thu Dec 28, 2017 9:15 am
Reverting all NSS-changes and using PA4 as NSS I got it to run once a couple of rounds before it got stuck.
The other times I tried, it didn’t seem to work at all.
[edit] It did start to run all the way all of a sudden. Doesn’t seem to be very stable program…
But the SPI didn’t seem to work. Register dump was all 0xFFs.

Looks like the RFM69-code is too old. It tries to handle NSS by itself, and it probably conflicts with the core…
I tried to make it use PA3 as NSS again, but then the SW froze almost immediately…


mrburnette
Thu Dec 28, 2017 1:22 pm
[turboscrew – Thu Dec 28, 2017 9:15 am] –
Reverting all NSS-changes and using PA4 as NSS I got it to run once a couple of rounds before it got stuck.
The other times I tried, it didn’t seem to work at all.

[edit] It did start to run all the way all of a sudden. Doesn’t seem to be very stable program…
But the SPI didn’t seem to work. Register dump was all 0xFFs.

Looks like the RFM69-code is too old. It tries to handle NSS by itself, and it probably conflicts with the core…
I tried to make it use PA3 as NSS again, but then the SW froze almost immediately…

Generally, one does not see “random issues” with software issues; that is, software typically runs until something bad happens then things “break.” Reset and repeating tends to give the same results. Now, we do see crazy things happens with buffer overflows and such which is often difficult to isolate.

Just asking, but are you sure all of the wiring connections are as short as possible and are properly fastened? Is the 5V power supply rock solid? Look to other potential wiring concerns like an inexpensive solderless breadboard, etc.

Ray


turboscrew
Thu Dec 28, 2017 6:08 pm
I’m using two 1.5V batteries (AA) – this is blue pill. And yes, both blue pill and the RFM-module should run fine (I recall 3.6V – 2.8V).
Regardless of the one run with a couple of rounds, it usually starts or not. Either it jams at about the first “sending” or it’ll keep going.
It just looks like the SPI is not working.
The cables are not as short as possible, but 20 cm DuPonts. My breadboard is still in mail, so the DuPonts go directly from pin to pin.
(It was pretty hard to find 2mm-to-0.1″ DuPonts for the RFM-module.)

Oh, and with my own code and the same DuPonts, my CC1101-modules work fine. And I can also receive with the RFMs, but I haven’t managed to make them send anything. That’s why I wanted to try with some code that’s known to work.


mrburnette
Fri Dec 29, 2017 2:37 am
That’s why I wanted to try with some code that’s known to work.

I understand. But I have not seen any of the forum members post to this thread with a clean lib for the RFM69HW device.
Unless someone points us to a tested library, it appears that you will either need to port your own or select a different uC architecture.

SPI/I2C is where a logic analyzer really shines.

I am still suspicious of the stability of the wiring. When you have your breadboard, retest using the shortest length of wire.

I would strongly suggest you select LiFePO4 cell for your battery instead of 2x 1.5V cells. uC prefer DC supply with low impedance.

Ray


turboscrew
Fri Dec 29, 2017 8:30 am
[mrburnette – Fri Dec 29, 2017 2:37 am] –
I understand. But I have not seen any of the forum members post to this thread with a clean lib for the RFM69HW device.
Unless someone points us to a tested library, it appears that you will either need to port your own or select a different uC architecture.

Yes. I’ve been thinking about the two other options: the LowPowerLab’s and Hessling’s. Both just seem to require quite a lot of work.


mrburnette
Fri Dec 29, 2017 2:38 pm
[turboscrew – Fri Dec 29, 2017 8:30 am] –
Yes. I’ve been thinking about the two other options: the LowPowerLab’s and Hessling’s. Both just seem to require quite a lot of work.

Take a look at this link: http://stm32duino.com/viewtopic.php?f=15&t=938#p10875

The RadioHead library may be a better option for you.
stevech indicates he has had success. PM him if you wish, but ask him to post to this thread so we do not loose his input.

Ray

Also, Adafruit has a version of the RadioHead lib up on github: https://github.com/adafruit/RadioHead with example code which may get you started easier.
// Example sketch showing how to create a simple addressed, reliable messaging client
// with the RHReliableDatagram class, using the RH_ASK driver to control a ASK radio.
// It is designed to work with the other example ask_reliable_datagram_server
// Tested on Arduino Mega, Duemilanova, Uno, Due, Teensy


turboscrew
Fri Dec 29, 2017 3:36 pm
Thanks!
It seems that RadioHead is no more just a virtual wire it (mostly) used to be!
Have to take a better look…

Leave a Reply

Your email address will not be published. Required fields are marked *