B.A.S.I.C. for Arduino

https://www.b4x.com/store.html
Applications developed with B4A, B4i or B4J are royalty free.
Licenses are per developer. Each developer requires a single license.
Payments are done over a secured server.
After purchasing you will receive an email with a link to the full version and the license file. Email should arrive 10-15 minutes after you purchase.
Choose the FastSpring option to purchase with coupon codes. Enter the code in the second order page.

You may wish to look into:
https://github.com/esp8266/Basic

I know all the purists out there will say you should be using a real language for this type of job blah blah blah.

I do not have a “problem” with BASIC as a language … after all, Arduino is a pseudo-language in one sense – but the data types and syntax are more closely aligned to C/C++, IMO.

It looks like it may work with stm32 with a little alterations…
Unlikely since the AVR is 8-bit. But, I am often wrong.

My biggest poopoo about this product is that Microsoft’s .Net must be installed. It will be a cold day in Hades before I muck up my Linux installation with .Net.

Ray

mrburnette wrote:
You may wish to look into:
https://github.com/esp8266/Basic

I managed to get an hour to try B4R. I took the opportunity to upgrade to 1.69 and then tried the following Blinky example.

On the Uno it compiled and run straight away

#Region Project Attributes
#AutoFlushLogs: True
#CheckArrayBounds: True
#StackBufferSize: 300
#End Region

Sub Process_Globals
Public Serial1 As Serial
Private Timer1 As Timer
Private pin13 As Pin
End Sub

Private Sub AppStart
Serial1.Initialize(115200)
Log("AppStart")
pin13.Initialize(13, pin13.MODE_OUTPUT)
Timer1.Initialize("Timer1_Tick", 1000) '1000ms = 1 second
Timer1.Enabled = True
End Sub

Private Sub Timer1_Tick
Dim currentState As Boolean = pin13.DigitalRead
Log("CurrentState: ", currentState)
Dim NewState As Boolean = Not(currentState)
Log("NewState: ", NewState)
pin13.DigitalWrite(NewState)
End Sub

@simonf

Some of the errors are being caused because libmaple uses a special variable type/enum of WiringPinMode instead of a byte for the pinMode

I think the libmaple implementation is technically better that using byte, but it does cause incompatibilities sometimes, and I recall changing other things to resolve the same issue.

I’m not sure why there are issues with the definition of false

Its done the same way as the Arduino SAM core does it

Its probably best to try to compile the basic for the Arduino Due and see if it had the same issues, (and also compile for the Uno – or any AVR core)

RogerClark wrote:@simonf

Some of the errors are being caused because libmaple uses a special variable type/enum of WiringPinMode instead of a byte for the pinMode

I think the libmaple implementation is technically better that using byte, but it does cause incompatibilities sometimes, and I recall changing other things to resolve the same issue.

On board pin #

I note that Raspberry Pi named all the GPIO as GPIO-1, -2, etc. Unrelated to pin number on header connector. Everyone seems to easily adapt to that; e.g., the GPIO library class instances just use the GPIO number, and people have little color crib sheets to show what GPIO # is where on the header. Even though the header layout is the same for all boards expect one, and including the smaller Zero board.

I wonder if it was worth the hassle, in hindsight, for Arduino to fixate on port pin vs. board pin such that port pin is hidden from the coder.

stevech wrote:

I wonder if it was worth the hassle, in hindsight, for Arduino to fixate on port pin vs. board pin such that port pin is hidden from the coder.

[quote=”simonf”
It’s not the actual pin number vs port number that is the problem it the way the pinmode is stored, in this case passed.
The problem is the variable type used to describe the pin mode in arduino is byte whereas maple/stm32duino uses an ENUM.
I had a quick look on the net and I remembered from my C# days that you could do something like this

enum MyEnum : unsigned char
{
i ,j, k, w
};


I have got B4R to compile successfully for the STM32Nucleo F103

I needed to make several changes.
Inside the B4R files and also inside the Arduino_Stm32 library files.

It does compile and run. ie. B4R Blink example.

But, I am getting an additional 64K added to the size of the output BIN file.
Even when I compile an empty project.

I think I have tracked it down to the B4Rscheduler.cpp file
I think it is in the class PollerNode and could be caused by the declare
void* tag;

I am wondering if this declare is likely to make a referance to 00000
in the ELF file and altermately causing the BIN to increae in size by 64K?
I believe for stm32 code starts at the first 64K boundary.

Even though the file is 66K it still loads ok on the Nucleo F1 (128K flash) but for a STM32F103C8 board (64K flash) the resultant minimum size is 66K. The loader won’t pass it to the board.

I would appreciate any insight from anyone.
I can post my B4R mods if anyone is interested.

I’m not sure if my last (very first) post was successful as I can’t find any reference to it.

I have got B4R compiling and running for the stm32NucleoF1 board.

Several changes were required to overcome incompatibility between the stm32 libraries and the arduino avr libraries and B4R underlying C source files.

Below are my changes.

Mods for STM32F1
==============

This file details the changes made in implementing the Arduino_STM32
libraries and B4R libraries so that B4R can successfully compile to
target a STM32F103RB Nucleo Dev board.

Other changes may still need to be made as further libraries and
hardware support are confirmed.

I have only made changes to support the STM32F1 series.
The Arduino_STM32 libraries appear to support the other
microcontrollers in the ST family.

Last Revised: 10th June 2016

-------------------------------------------------------------------------
Added the following to lines to the STM32 file:
..//Arduino_STM32/STM32/STM32F1/cores/maple/print.h

size_t print(const Printable&);
size_t println(const Printable&);

Also added:
#include "printable.h"
This file was already in the maple folder just not included.

---------------------------------------------------------------------------
Seems that the STM32 libraries use an enumerated type (WiringPinMode)
for the pin mode value. STM32 supports many more pin modes.
In Arduino the pin mode is a numeric value only
defined as INPUT, OUTPUT and INPUT_PULLUP.
A type mismatch error occurs at compilation.
To translate the types, I edited the SetMode function in
the B4R file.
..//B4R/Libraries/rCore/B4RArduino.cpp

void Pin::setMode(Byte arduino_Mode) {

#ifdef USING_STM32
WiringPinMode stm32_Mode;
switch (arduino_Mode) {

case INPUT:

stm32_Mode = INPUT;

break;

case OUTPUT:

stm32_Mode = OUTPUT;
break;
case INPUT_PULLUP:

stm32_Mode = INPUT_PULLUP;
break;
}

pinMode(PinNumber, stm32_Mode);

#else
pinMode(PinNumber, arduino_Mode);
#endif
if (arduino_Mode == INPUT_PULLUP)

CurrentValue = true;

}

You need to define a compiler symbol "USING_STM32"to
..//B4R/Defines-Template.h

#define USING_STM32

Remove this define to compile B4R code for microcontrollers other
than stm32.

-------------------------------------------------------------------
Also need to extend the process timeout in B4R so that the
compilation results get displayed.
Menu: Tools/IDE-Options/Configure-Process-Timeout
Set it to 45 seconds.

------------------------------------------------------------------

Further to my last post, the void* tag; declaration is not the cause of the extra memory allocation in the BIN.

I have tracked the problem down to the instantiation of a class to a pointer type.
Even when the class itself is empty, it doesn’t matter.

This is a simple Arduino code snippet to replicate the problem.
class MyClass {
};

MyClass* fred;

void setup() {
fred = new MyClass();
}

The reason the bin file is large, is that the “new” operator reads in a load of libraries.

This has been noted in other postings.

Normally with embedded programming, these objects would have static instantiations, but I presume its not possible in this case.

BTW.
Most STM32F103c8 devices actually have 128k flash even though they are specc’ed at 64k.

Just that if compiling to Arduino UNO the difference is only 600 bytes not 64K.
I assumed there was something wrong with the handling of NEW for stm32.

Thanks.

BTW.
Most STM32F103c8 devices actually have 128k flash even though they are specc’ed at 64k.
Roger, how did you find out this?
How to check/reproduce?

stevestrong wrote:BTW.
Most STM32F103c8 devices actually have 128k flash even though they are specc’ed at 64k.
Roger, how did you find out this?
How to check/reproduce?

Thanks Ray, good to know if one of my applications is missing only couple of bytes above the 64k limit

stevestrong wrote:Thanks Ray, good to know if one of my applications is missing only couple of bytes above the 64k limit

Offtopic… but just a note, that the GD32F103C8 only has 64k not 128k as its internal architecture is quite different.

RogerClark wrote:Offtopic… but just a note, that the GD32F103C8 only has 64k not 128k as its internal architecture is quite different.

Ray
Agreed. SPI doesn’t seem to work the same either.