RFM69HW demo application for blue pill?

Post here first, or if you can't find a relevant section!
User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: RFM69HW demo application for blue pill?

Post by mrburnette » Wed Dec 20, 2017 1:13 am

turboscrew wrote:
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 wrote:
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 195 times
If you look at the graphic, you will see that this "BMP180_Datalogger.ino" project has two (2) .ino files, one with the same name as the folder and thus it is the main tab and another .ino file which is shown in the graphic as "ScrnFuncts" which is really ScrnFuncts.ino so the IDE drops the .ino file extension.

When using more than one .ino in a project, all .ino files are combined (concatenated) first by the preprocessor. The .h + the associated .cpp are compiled separately (if I remember correctly) and then linked into the main program. The takeaway here is that just giving a Tab a name with no extension in the IDE automatically creates a separate .ino and this file will automatically be combined with the main .ino ... by design.

Here is what the ScrnFunct.ino file looks like:

Code: Select all

// Nokia 5110 LCD support functions and font mapping
static const byte ASCII[][5] =
{{0x00, 0x00, 0x00, 0x00, 0x00} // 20  
,{0x00, 0x00, 0x5f, 0x00, 0x00} // 21 !
,{0x00, 0x07, 0x00, 0x07, 0x00} // 22 "
,{0x14, 0x7f, 0x14, 0x7f, 0x14} // 23 #
,{0x24, 0x2a, 0x7f, 0x2a, 0x12} // 24 $
,{0x23, 0x13, 0x08, 0x64, 0x62} // 25 %
,{0x36, 0x49, 0x55, 0x22, 0x50} // 26 &
,{0x00, 0x05, 0x03, 0x00, 0x00} // 27 '
,{0x00, 0x1c, 0x22, 0x41, 0x00} // 28 (
,{0x00, 0x41, 0x22, 0x1c, 0x00} // 29 )
,{0x14, 0x08, 0x3e, 0x08, 0x14} // 2a *
,{0x08, 0x08, 0x3e, 0x08, 0x08} // 2b +
,{0x00, 0x50, 0x30, 0x00, 0x00} // 2c ,
,{0x08, 0x08, 0x08, 0x08, 0x08} // 2d -
,{0x00, 0x60, 0x60, 0x00, 0x00} // 2e .
,{0x20, 0x10, 0x08, 0x04, 0x02} // 2f /
,{0x3e, 0x51, 0x49, 0x45, 0x3e} // 30 0
,{0x00, 0x42, 0x7f, 0x40, 0x00} // 31 1
,{0x42, 0x61, 0x51, 0x49, 0x46} // 32 2
,{0x21, 0x41, 0x45, 0x4b, 0x31} // 33 3
,{0x18, 0x14, 0x12, 0x7f, 0x10} // 34 4
,{0x27, 0x45, 0x45, 0x45, 0x39} // 35 5
,{0x3c, 0x4a, 0x49, 0x49, 0x30} // 36 6
,{0x01, 0x71, 0x09, 0x05, 0x03} // 37 7
,{0x36, 0x49, 0x49, 0x49, 0x36} // 38 8
,{0x06, 0x49, 0x49, 0x29, 0x1e} // 39 9
,{0x00, 0x36, 0x36, 0x00, 0x00} // 3a :
,{0x00, 0x56, 0x36, 0x00, 0x00} // 3b ;
,{0x08, 0x14, 0x22, 0x41, 0x00} // 3c <
,{0x14, 0x14, 0x14, 0x14, 0x14} // 3d =
,{0x00, 0x41, 0x22, 0x14, 0x08} // 3e >
,{0x02, 0x01, 0x51, 0x09, 0x06} // 3f ?
,{0x32, 0x49, 0x79, 0x41, 0x3e} // 40 @
,{0x7e, 0x11, 0x11, 0x11, 0x7e} // 41 A
,{0x7f, 0x49, 0x49, 0x49, 0x36} // 42 B
,{0x3e, 0x41, 0x41, 0x41, 0x22} // 43 C
,{0x7f, 0x41, 0x41, 0x22, 0x1c} // 44 D
,{0x7f, 0x49, 0x49, 0x49, 0x41} // 45 E
,{0x7f, 0x09, 0x09, 0x09, 0x01} // 46 F
,{0x3e, 0x41, 0x49, 0x49, 0x7a} // 47 G
,{0x7f, 0x08, 0x08, 0x08, 0x7f} // 48 H
,{0x00, 0x41, 0x7f, 0x41, 0x00} // 49 I
,{0x20, 0x40, 0x41, 0x3f, 0x01} // 4a J
,{0x7f, 0x08, 0x14, 0x22, 0x41} // 4b K
,{0x7f, 0x40, 0x40, 0x40, 0x40} // 4c L
,{0x7f, 0x02, 0x0c, 0x02, 0x7f} // 4d M
,{0x7f, 0x04, 0x08, 0x10, 0x7f} // 4e N
,{0x3e, 0x41, 0x41, 0x41, 0x3e} // 4f O
,{0x7f, 0x09, 0x09, 0x09, 0x06} // 50 P
,{0x3e, 0x41, 0x51, 0x21, 0x5e} // 51 Q
,{0x7f, 0x09, 0x19, 0x29, 0x46} // 52 R
,{0x46, 0x49, 0x49, 0x49, 0x31} // 53 S
,{0x01, 0x01, 0x7f, 0x01, 0x01} // 54 T
,{0x3f, 0x40, 0x40, 0x40, 0x3f} // 55 U
,{0x1f, 0x20, 0x40, 0x20, 0x1f} // 56 V
,{0x3f, 0x40, 0x38, 0x40, 0x3f} // 57 W
,{0x63, 0x14, 0x08, 0x14, 0x63} // 58 X
,{0x07, 0x08, 0x70, 0x08, 0x07} // 59 Y
,{0x61, 0x51, 0x49, 0x45, 0x43} // 5a Z
,{0x00, 0x7f, 0x41, 0x41, 0x00} // 5b [
,{0x02, 0x04, 0x08, 0x10, 0x20} // 5c £¤
,{0x00, 0x41, 0x41, 0x7f, 0x00} // 5d ]
,{0x04, 0x02, 0x01, 0x02, 0x04} // 5e ^
,{0x40, 0x40, 0x40, 0x40, 0x40} // 5f _
,{0x00, 0x01, 0x02, 0x04, 0x00} // 60 `
,{0x20, 0x54, 0x54, 0x54, 0x78} // 61 a
,{0x7f, 0x48, 0x44, 0x44, 0x38} // 62 b
,{0x38, 0x44, 0x44, 0x44, 0x20} // 63 c
,{0x38, 0x44, 0x44, 0x48, 0x7f} // 64 d
,{0x38, 0x54, 0x54, 0x54, 0x18} // 65 e
,{0x08, 0x7e, 0x09, 0x01, 0x02} // 66 f
,{0x0c, 0x52, 0x52, 0x52, 0x3e} // 67 g
,{0x7f, 0x08, 0x04, 0x04, 0x78} // 68 h
,{0x00, 0x44, 0x7d, 0x40, 0x00} // 69 i
,{0x20, 0x40, 0x44, 0x3d, 0x00} // 6a j 
,{0x7f, 0x10, 0x28, 0x44, 0x00} // 6b k
,{0x00, 0x41, 0x7f, 0x40, 0x00} // 6c l
,{0x7c, 0x04, 0x18, 0x04, 0x78} // 6d m
,{0x7c, 0x08, 0x04, 0x04, 0x78} // 6e n
,{0x38, 0x44, 0x44, 0x44, 0x38} // 6f o
,{0x7c, 0x14, 0x14, 0x14, 0x08} // 70 p
,{0x08, 0x14, 0x14, 0x18, 0x7c} // 71 q
,{0x7c, 0x08, 0x04, 0x04, 0x08} // 72 r
,{0x48, 0x54, 0x54, 0x54, 0x20} // 73 s
,{0x04, 0x3f, 0x44, 0x40, 0x20} // 74 t
,{0x3c, 0x40, 0x40, 0x20, 0x7c} // 75 u
,{0x1c, 0x20, 0x40, 0x20, 0x1c} // 76 v
,{0x3c, 0x40, 0x30, 0x40, 0x3c} // 77 w
,{0x44, 0x28, 0x10, 0x28, 0x44} // 78 x
,{0x0c, 0x50, 0x50, 0x50, 0x3c} // 79 y
,{0x44, 0x64, 0x54, 0x4c, 0x44} // 7a z
,{0x00, 0x08, 0x36, 0x41, 0x00} // 7b {
,{0x00, 0x00, 0x7f, 0x00, 0x00} // 7c |
,{0x00, 0x41, 0x36, 0x08, 0x00} // 7d }
,{0x10, 0x08, 0x08, 0x10, 0x08} // 7e ¡û
,{0x78, 0x46, 0x41, 0x46, 0x78} // 7f ¡ú
};

char disp_tab[]={'0','1','2','3','4','5','6','7','8','9'};


void LcdInitialise(void)
{ 
    pinMode(PIN_SCE,    OUTPUT);
    pinMode(PIN_RESET,  OUTPUT);
    pinMode(PIN_DC,     OUTPUT);
    pinMode(PIN_SDIN,   OUTPUT);
    pinMode(PIN_SCLK,   OUTPUT);
    digitalWrite(PIN_RESET, LOW);
    digitalWrite(PIN_RESET, HIGH);
    LcdWrite(LCD_C, 0x21 );  // LCD Extended Commands.
    LcdWrite(LCD_C, NOKIAcontrast );
    LcdWrite(LCD_C, 0x04 );  // Set Temp coefficent. //0x04
    LcdWrite(LCD_C, 0x14 );  // LCD bias mode 1:48. //0x13
    LcdWrite(LCD_C, 0x0C );  // LCD in normal mode.
    LcdWrite(LCD_C, 0x20 );
    LcdWrite(LCD_C, 0x0C );
}


void LcdCharacter(char character)
{
    LcdWrite(LCD_D, 0x00);
     for (int index = 0; index < 5; index++)  {
      LcdWrite(LCD_D, ASCII[character - 0x20][index]);  }
  LcdWrite(LCD_D, 0x00);
}


void LcdClear(void)  //20130504 Added nColumn/nRow reset and goto(0, 0)
{
  for (int index = 0; index < LCD_X * LCD_Y / 8; index++)
    {
      LcdWrite(LCD_D, 0x00);
    }
    nColumn = 0; nRow = 0;
    gotoXY(0, 0);
}


void LcdString(char *characters)
{ 
    while (*characters)
    {LcdCharacter(*characters++); }
}


void LcdWrite(byte dc, byte data)                  // Software SPI for Nokia
{
    digitalWrite(PIN_DC, dc);
    digitalWrite(PIN_SCE, LOW);
    shiftOut(PIN_SDIN, PIN_SCLK, MSBFIRST, data);
    digitalWrite(PIN_SCE, HIGH);
}


void gotoXY(int x, int y)
{
    LcdWrite( 0, 0x80 | x);  // Column.
    LcdWrite( 0, 0x40 | y);
} // Row.  


void dispcountt(int8_t count)  // decimal point(s)
{
  //LcdCharacter(disp_tab[count/10000]);
  //LcdCharacter(disp_tab[count/1000%10]);
  //LcdCharacter(disp_tab[count/100%10]);
  LcdCharacter(disp_tab[count%100/10]);
  //LcdString(".");
  LcdCharacter(disp_tab[count%10]);
}

// Routine to create a black current line to overtype
void LcdCurrentLine(int line)
{
  unsigned char  j;  
  for(j=0; j<84; j++) //Bottom
    {
      gotoXY (j, line);
      LcdWrite (1,0x70);
    }
}
  
Moving this kind of thing outside the main .ino file really helps to organize the project.

Ray

turboscrew
Posts: 78
Joined: Fri Mar 10, 2017 7:36 pm

Re: RFM69HW demo application for blue pill?

Post by 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

User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: RFM69HW demo application for blue pill?

Post by mrburnette » Wed Dec 20, 2017 1:00 pm

turboscrew wrote:
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
Posts: 78
Joined: Fri Mar 10, 2017 7:36 pm

Re: RFM69HW demo application for blue pill?

Post by turboscrew » Thu Dec 21, 2017 12:37 pm

mrburnette wrote:
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!

User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: RFM69HW demo application for blue pill?

Post by mrburnette » Thu Dec 21, 2017 1:34 pm

turboscrew wrote:
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
Posts: 78
Joined: Fri Mar 10, 2017 7:36 pm

Re: RFM69HW demo application for blue pill?

Post by 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):

Code: Select all

  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);
}
prints:
Sending[0]:
and hangs.
If I use "radio.send()" instead, it prints
S
and hangs.
In both cases it prints
Transmitting at 433 Mhz...
at the beginning, though.
Something seems to be very wrong, and it's not HW, because with my own code it prints stuff out on a terminal just fine and manages to receive something (somewhat corrupted messages) from another board that uses CC1101-module,
As if the core was faulty, or the library messed up with the core.

Any idea what/where should I look?

[edit]
I wonder if it's the NSS-pin mapping to GPIO? There seems to be some "juggling" with that, and I have no idea how that's supposed to end up to the (I guess) SPI-module of the Arduino-STM32 core.

turboscrew
Posts: 78
Joined: Fri Mar 10, 2017 7:36 pm

Re: RFM69HW demo application for blue pill?

Post by 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.

User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: RFM69HW demo application for blue pill?

Post by mrburnette » Wed Dec 27, 2017 4:27 pm

turboscrew wrote:
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?

Code: Select all

RFM69HW  site:STM32duino.com
https://www.google.com/search?ei=MtNDWp ... 2duino.com

However, I want to introduce you to the Streaming lib (actually, it is a macro) ... no memory is used to implement the functionality:
http://arduiniana.org/libraries/streaming/

This code:

Code: Select all

    Serial.print("Sending[");
    Serial.print(sendSize);
    Serial.print("]: ");
Converts to:

Code: Select all

Serial << "Sending{" << sendSize << "]: " ;

Ray

turboscrew
Posts: 78
Joined: Fri Mar 10, 2017 7:36 pm

Re: RFM69HW demo application for blue pill?

Post by 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.

User avatar
mrburnette
Posts: 2232
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: RFM69HW demo application for blue pill?

Post by 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/

Post Reply