by-passing the arduino-e-ness?

zmemw16 wrote:is it or will it be possible for users to access the HAL layer interface directly?

could we have a flag __HAL_CODE__ ?

it is perhaps not a good idea for libraries:–)

stephen

given the i2s thread currently active, some of their code is at least fairly esoteric and
‘below’ the arduino code; even though it’ll probably be going into a library.

stephen

Maybe right, but fact is that that arduino.cc totally neglected the potential of the Arduino Due (like I2S, SPI, DMA…) over years and only converted the standard AVR things into it. This was the point leaflabs started with own libraries.

I don’t see a problem access the HAL layer interface, we have also totally access to the libmaple layer or I missed something?
I always use 80% “Arduino code” and about 20% low level things… I would say this is the real power of STM32duino -> the world of both!

madias wrote:
<…>
I don’t see a problem access the HAL layer interface, we have also totally access to the libmaple layer or I missed something?
I always use 80% “Arduino code” and about 20% low level things… I would say this is the real power of STM32duino -> the world of both!

I’m new to MCU’s programming and I can’t decide what API is better to begin and grow…
I’m slightly familiar with Wiring and Arduino IDE (which is total crap and useless painful thing in my opinion, because of lacking of code navigation, code completion, refactoring helpers, convinient project management, and other tools long ago available in popular and mature IDE’s such as Eclipse and CodeBlocks, which are could be used instead). Wiring seems popular framework with big community and a lot of ready stuff based on it. But how do we use modern STM32 features like USB support?

i’m not sure what prompted the technique, but you write a very short fred.ino file having a #include /,Arduino.h> line
and a second #including “./fred.cpp; it’s then more like a cpp source.

arduino wise you store it in the sketchbook folder in a folder fred containing fred.ino and fred.cpp

if you copied the Arduino.h include line into fred.cpp, i suspect you’d be able to apply the tools you’re used to using
to it as the main file? you’ll need the various binary, include, search and libraries paths from a verbose compilation to even create a Makefile.
that’s a completely different world in Arduino(Arduino-mk) and a slowly greying black hole in Arduino_STM32; at least for me it is.
i was looking at Arduino-mk on hackaday yesterday and there’s teensy support now available.
oh look the tab’s still there
http://hackaday.com/2015/10/01/arduino- … -for-that/
:shock:
stephen

ps.you may want to look at Cube-MX and HAL as well, as the worlds seem to be on a slow collision course.

zmemw16 wrote:i’m not sure what prompted the technique, but you write a very short fred.ino file having a #include /,Arduino.h> line
and a second #including “./fred.cpp; it’s then more like a cpp source.

arduino wise you store it in the sketchbook folder in a folder fred containing fred.ino and fred.cpp

if you copied the Arduino.h include line into fred.cpp, i suspect you’d be able to apply the tools you’re used to using
to it as the main file? you’ll need the various binary, include, search and libraries paths from a verbose compilation to even create a Makefile.
that’s a completely different world in Arduino(Arduino-mk) and a slowly greying black hole in Arduino_STM32; at least for me it is.
i was looking at Arduino-mk on hackaday yesterday and there’s teensy support now available.
oh look the tab’s still there
http://hackaday.com/2015/10/01/arduino- … -for-that/
:shock:
stephen

ps.you may want to look at Cube-MX and HAL as well, as the worlds seem to be on a slow collision course.

@Ray
apologies for riling you.
my forum style can be a little (jovial, cynical, sarcastic, understated), i have a thought leapfrog issue and can be overly succinct.
actually i’m quite seriously dialled back in my postings as i once upset a Mexican and that really was quite interesting for a little bit. see above brackets

i’m aware to the topic and that i started it and your position in its regard, but whilst i appreciate it and do like its ease of use, the ability to drop down the abstraction level is to my mind not such a bad thing.
to me it is simply that for what i want to do it is possibly the best way. i also like perl, c and c++ programming, as you can probably tell i didn’t take to Ada at all well, regardless of 3 off 5 day courses.
(the last course was 20mls each way and i did it on my first 700c hand built wheels, trued them twice in that week and not needed to since.)
i started with 6502 and it took me six months to write my first program in hex, actually it took me 5.95 months to grasp the concept of byte, shift and rotate, assembler and hex etc, then it became a so simple it’s difficult to explain it thing.

understanding the aspects of hal and cubemx and how to potentially exploit them to a future ‘abstraction layer’ for arduino_stm32 is also to me of some interest.

i was merely pointing out that as he is aware of other tool chains, he might look at a couple of possibilities that might/could allow him to perhaps better use his knowledge of their capabilities.

hackaday was one i’m still looking at as i’ve tried it before in pure Arduino land and was curious about the teensy aspect with a view to stm32 use.

i pulled the items, followed upto their github repositories, even gone to read documentation about it.
i have been trying to use it as well, pointing out that i had fun with the various paths etc just seemed polite as well as it being a potential problem.

the reference to cubemx/hal was an immediate after-thought and edit, no idea why its bolded.

stephen

mrburnette wrote:There is a reason that all commercial Pilots and Air Traffic Control all use English as the common denominator for communications… optimum word is common. The compilation in the ArduinoIDE of error free code is a common way to communicate with other makers and owners of compatible hardware. One does not have to “like” the environment, but the IDE does force some rules that help we forum members to assist and share.

alextrezvy wrote:mrburnette wrote:There is a reason that all commercial Pilots and Air Traffic Control all use English as the common denominator for communications… optimum word is common. The compilation in the ArduinoIDE of error free code is a common way to communicate with other makers and owners of compatible hardware. One does not have to “like” the environment, but the IDE does force some rules that help we forum members to assist and share.

zmemw16 wrote:@Ray
apologies for riling you.
my forum style can be a little (jovial, cynical, sarcastic, understated), i have a thought leapfrog issue and can be overly succinct.
actually i’m quite seriously dialled back in my postings as i once upset a Mexican and that really was quite interesting for a little bit. see above brackets

i’m aware to the topic and that i started it and your position in its regard, but whilst i appreciate it and do like its ease of use, the ability to drop down the abstraction level is to my mind not such a bad thing.
<…>

@ray
i like things being easy, overly so maybe.
to me arduino is about it being easy to use the hardware.

ok, maybe a thread title change, summarise :-
the visible abstraction layer is arduino [orientated/extendable?] it’s likely to have another layer of hardware abstraction – tdb,
but we’d like to tinker as well’
ultimately a stm32fx.

we’re ‘arduino on stm32fx, optional extras’?

however you can only blink so many leds, clatter relays, … … at some point a decision to do something more with it will occur or not, not is a loss.
i was reading/watching you-tube on esp-8266 with arduino and using AT commands, my thought was could i use a lua variant and what would it involve/what gains? probably not, but i looked just in case.

not hiding the hardware is also important, it makes it fun. at sometime people will have issues with it. if they don’t see the hardware functionality and the connections, that’ll lead to many more ‘newbie’ questions. encouraging people to take that extra look and google as you do, then ask slightly deeper questions will ultimately be more beneficial.

the stm32 aspect is that i like the go faster stripe, i don’t want it to be my purchasing reason, but i want to get it at the right price, just below the knee of the performance and resources against cost graph, where it’s still linear and not asymptotic.
my eyes only go so fast, my brain somewhat slower.

your projects are building blocks to me, i do the same, i tend to do it in software, i break the ultimate destination into little programs with just one aspect, debug those and assemble (shave , glue ) them into my picture frame.
if i can see a possible (future or multiple use) benefit to moving a chunk of my blocks to a sub-system, whether it’s to an attiny85, atmega1284 or a stm32 chip. it’s just a block.

i once had 2yrs commissioning an ate system, freedom to go anywhere from a command language, interpreter written in macro-11 through any of the sub-systems(8031/2,8051/52), adc, dac, controlled power supplies, relay card types and STT’s, interfaces to ieee equipment to the inside of the target uut.
object find the reason it don’t and where, suggest how to fix it. i got there really early and left really late. all immensely enjoyable.

stephen
currently massively distracted, frontier series, ryk brown, 11 down, 4 to go, – very tom clany’ish style, kindle unlimited

Am I missing something here.. But wouldn’t the HAL functions be akin to a library ?

Albeit the library is not for external hardware, but its not uncommon to have a library e.g AVR TimerOne , which purely provides access to hardware functions that the core Arduino API doesnt.
(EEPROM library is the same)

But… I think in reality it would be impractical to write such a library to be compatible with Libmaole, as it would proably cause massive code bloat, and potentially cause the core to stop working when various HAL functions were run.
It would also duplicate a lot of functions in the Arduino API and the libmaple API.

I suspect the only practical way to do this is using @sheepdoll’s HAL based core, rather than libmaple.

In terms of Arduino-ness.

I presume if a system has all the Arduino 1.0 API functions, and uses setup() and loop(), and handles libraries in an Arduino way … and compiles in the Arduino IDE

Then it probably passes the test.

( cases in point, include the Teensy and ESP8266-Arduino)

my muddled thinking. i was thinking the core was an abstraction layer.

would you have seen an outline structure/diagram of it anywhere? at this point even a terrible one
doxygen????

stephen

RogerClark wrote:
<…>
In terms of Arduino-ness.

I presume if a system has all the Arduino 1.0 API functions, and uses setup() and loop(), and handles libraries in an Arduino way … and compiles in the Arduino IDE

Then it probably passes the test.

( cases in point, include the Teensy and ESP8266-Arduino)

ditto

stephen

zmemw16 wrote:my muddled thinking. i was thinking the core was an abstraction layer.

would you have seen an outline structure/diagram of it anywhere? at this point even a terrible one
doxygen????

stephen

In terms of libraries, I find it quite interesting what the ESP8266 team (guy) has done in making lots of the things that appear to be intrinsic to the ESP8266 (e.g. its WiFi’ness) into libraries

https://github.com/esp8266/Arduino/tree … /libraries

I’m not sure if there is anything we could take from this approach, possibly not, but I still think its a well structured “Core”

RogerClark wrote:In terms of libraries, I find it quite interesting what the ESP8266 team (guy) has done in making lots of the things that appear to be intrinsic to the ESP8266 (e.g. its WiFi’ness) into libraries
<…>

mrburnette wrote:
……
The very cheap price of the ESP8266 is now driving me to investigate the device much more – with the RF section disabled!
Ray