Why Arduino users so agressive?

[Simon]

Put it this way, I could take the mega schematic and the can shield schematic (the shield that they don't seem to do any more) and I could create the hardware required to be an ECU for work. This would mean that for prototyping I could program it in Arduino and for production our sub contractor that codes AVR could bare bones it. But I am very reluctant to put any faith in the Arduino.....

The other worry i have is that I have no idea what the overhead in Arduino is as I have no idea what is going on under the hood.

[bd139]

Yeah the overhead is terrible in some cases. Also where the abstraction is fragile like around interrupts and timers. Ugh.

[mikerj]

The other worry i have is that I have no idea what the overhead in Arduino is as I have no idea what is going on under the hood.

It's trivial to find out what's happening though, all the library source code is available.

[bd139]

Another thing that’s a ball ache is managing all the licenses. Forgot to mention that earlier.

[Simon]

The other worry i have is that I have no idea what the overhead in Arduino is as I have no idea what is going on under the hood.

It's trivial to find out what's happening though, all the library source code is available.

At which point I bare metal. This is the thing that really pisses me off about all open source projects! The standard retort to many questions is either "oh well if you don't like it you can always modify the code" or as you say "just read the source code". The reason I would use someone else's code is for the simplicity, if I have to reverse engineer what someone else wrote and have that much in depth knowledge of the chip to do that not to mention skills in one or more programming languages myself I may as well just do it myself.

[eugene]

To be fair, you can get as low level as you like with any Arduino implementation. You can setup timers manually by setting registers, etc. You can even setup the interrupt tables manually if you want. The people that created the Arduino made it so that you don't have to do those things, but neither do they discourage it.

Many of the people here saying Arduino sux are really saying it's not what they need to solve any problems in their professional life. The ones complaining that Arduino users are idiots are really saying that they're not like you. Well that's a good thing! If Arduino users had to be like you to make the things work then the Arduino project would be a massive failure!

Seriously, nobody ever promised that they would be the right tool for you. If you need a big motorcycle for touring the countryside, don't complain that e-bikes are underpowered and dangerous at highway speeds. If you need to get around the city quickly, don't complain that big motorcycles a inefficient and dangerous in traffic. If you do, the problem lies entirely with you.

[rstofer]

Completely off of the Arduino topic...

NXP makes the LPC2148 (ARM7-TDMI), an older technology but it has a lot of gadgets and is a pretty fun chip to use.  At http://www.jcwren.com/arm/ there is a library for every single peripheral written at the lowest C level possible.  This code has been around for years and is a great example of bare metal programming.  It is not all things for all people but it's a pretty good start.

In the context of the ATmega328P, it wouldn't take much effort to duplicate JC's code ideas and write a driver for each peripheral.  There just aren't that many.  If a project didn't need a particular peripheral, don't write a driver.

This would get rid of licensing issues above the C library level and I don't pretend to know how that works for commercial projects.  One option would be to use one of the 'for pay' tools like Rowley CrossWorks and let them deal with the licensing issues.  Tell them you plan to distribute a binary as closed source and see what they say.  They have tools for ARM, AVR and several other families.  It's a pretty terrific tool and their CrossConnect works really well on the LPC2148 and LPC2106.  I haven't used it on other families because just about everything is coming with a programmer.  CrossConnect is actually a debugging tool, not just a programmer.

[Simon]

Many of the people here saying Arduino sux are really saying it's not what they need to solve any problems in their professional life. The ones complaining that Arduino users are idiots are really saying that they're not like you. Well that's a good thing! If Arduino users had to be like you to make the things work then the Arduino project would be a massive failure!

You are missing the point. If a thing is defective it is defective. I found the LCD library documentation hard work and pointed it out on their forum where several users agreed with me. I got the usual "well if you don't like it fix it" crap which i could not because I did not have the permissions on the site to just go around editing their pages. I was then banned! because I pointed out an issue and the documentation was updated. So i am sorry but at the very least the moderators are a stuck up bunch of assholse that do not wish to take on board suggestions and as time is going on they are introducing bugs!

This has nothing to do with right tools and right people. i do indeed use it from time to time as a last minute hack but never ever would I resy on it for production for the same reasons others are advising me not to rely on any chip vendors software frameworks. By their very nature of trying to be all things to all people they end up bloated, unpredictable and downright buggy!

[rstofer]

At which point I bare metal. This is the thing that really pisses me off about all open source projects! The standard retort to many questions is either "oh well if you don't like it you can always modify the code" or as you say "just read the source code". The reason I would use someone else's code is for the simplicity, if I have to reverse engineer what someone else wrote and have that much in depth knowledge of the chip to do that not to mention skills in one or more programming languages myself I may as well just do it myself.

From previous posts, I'm guessing your adventures with C are still in the early stages.  There's nothing like writing to bare metal to up your game!

The thing about embedded programming (as opposed to, say, Windows Application programming) is the amount of interaction with the hardware and that can only happen after working with a 1000 page User Manual.

My general approach:

• Get the UART running
• Copy the number conversion routines from "The C Programming Languge" Kernighan & Ritchie
• While you're at it, copy the string functions.  These won't require you to use a heap
• Get a timer interrupt working - even a blinking LED is proof of concept
• Add interrupts to the UART and perhaps a circular buffer on input and output
• If USB Mass Storage is required, look at www.jcwren.com/arm and see how to convert his code.  Pay attention to the tables because they are critical to making a connection.  Read "Complete USB".  Find factory code!
• If I have the pins, I might want to add a display for diagnostic messages.  This might be more useful than console output.  Or not...
• And then it's off to the races!

There are probably a lot of ways to get to this point but I like to work on small nibbles and write my code from the bottom up.

[bd139]

Have you looked at the windows API recently? 

[rstofer]

Have you looked at the windows API recently? 

It's massive!  If I had to develop a GUI application for Windows, I would be tempted to use Visual Basic.  Building the forms is pretty easy and writing event code isn't overly difficult.

Part of the problem with the API is backward compatibility.  There are probably Windows 3 apps still running somewhere in the world!

ETA:  In terms of volume of documentation, the Windows API wins.  I don't get the feeling that any particular function is anywhere near as complex as, say, a UART interrupt handler with queue.  As I recall, an API call passes a handle to an object and the function performs some operation on or with the object.   I always thought of them as less challenging.  When embedded gets into multiple cores, RTOS with priority queues, interrupt driven hardware and DMA channels, I think embedded is more challenging.  I'm probably wrong...

[Simon]

From previous posts, I'm guessing your adventures with C are still in the early stages.  There's nothing like writing to bare metal to up your game!

The thing about embedded programming (as opposed to, say, Windows Application programming) is the amount of interaction with the hardware and that can only happen after working with a 1000 page User Manual.

My general approach:

• Get the UART running
• Copy the number conversion routines from "The C Programming Languge" Kernighan & Ritchie
• While you're at it, copy the string functions.  These won't require you to use a heap
• Get a timer interrupt working - even a blinking LED is proof of concept
• Add interrupts to the UART and perhaps a circular buffer on input and output
• If USB Mass Storage is required, look at www.jcwren.com/arm and see how to convert his code.  Pay attention to the tables because they are critical to making a connection.  Read "Complete USB".  Find factory code!
• If I have the pins, I might want to add a display for diagnostic messages.  This might be more useful than console output.  Or not...
• And then it's off to the races!

There are probably a lot of ways to get to this point but I like to work on small nibbles and write my code from the bottom up.

Indeed. i usually start with ports and then PWM and then ADC. I've not done any coms stuff yet but i need to get into CAN bus and indeed serial is the universal of sending data to a PC without getting stuck in USB.

i am currently trudging through the 1300 page manual of the SAMC21

[GeorgeOfTheJungle]

If all you need is to drive an oled or read the temp off a DHT22 you probably don't need any library, but to drive the radio of an esp32 and connect to a WiFi you'd better use the TCP stack and WiFi drivers provided by Espressif, with or without the glue to make them look Arduino-ish. Any library that works saves you time and effort.

[bd139]

Have you looked at the windows API recently? 

It's massive!  If I had to develop a GUI application for Windows, I would be tempted to use Visual Basic.  Building the forms is pretty easy and writing event code isn't overly difficult.

Part of the problem with the API is backward compatibility.  There are probably Windows 3 apps still running somewhere in the world!

Yeah I've got a book called "the MSDOS encyclopedia" somewhere (rationally I'm keeping it because Gates signed it so I'm waiting for him to drop dead to cash in  ).  In the back is a chapter on windows API and it looks just like win32 does today. The book is over 30 years old.

Windows GUI apps, I use C#. Max lazy.

[rstofer]

Indeed. i usually start with ports and then PWM and then ADC. I've not done any coms stuff yet but i need to get into CAN bus and indeed serial is the universal of sending data to a PC without getting stuck in USB.

i am currently trudging through the 1300 page manual of the SAMC21

The reason I get the UART, numeric conversion and string functions settled first is that I know I am going to use the UART for debugging.  I try to avoid printf() because it inevitably uses the string library which uses the heap and I don't want to do that.  As a result, nicely formatted output is perhaps out of the question but I can print nibbles, bytes, shorts, ints with or without the leading 0x along with a legend and whatever text seems appropriate.  That's a good start.

I don't usually do it but I could #ifdef DEBUG the blocks of debug code.

[Yansi]

That is why you do NOT use a printf, but snprintf or vsnprintf respectively.

Printf is also extremely uneffective to redirect to any comms peripherals as far as I can tell, as putchar-ing a single character at a time is downright dumb, if you can do a whole buffer with DMA.

[SiliconWizard]

That is why you do NOT use a printf, but snprintf or vsnprintf respectively.

That's what I do as well.

[fourfathom]

Some advice please?  I'm a hardware engineer (retired) who has some mixed software / firmware experience.  I've coded in assembler for early uCs, coded in basic, pascal, and c for pre-Windows PCs, coded in vbasic and c# on modern PCs, done a little c work on RPis and arduinos and Pics, and played with python.  I really like the small / cheap arduino-style boards from Adafruit (etc), and most of my little projects can easily run on  one of these or a RPi.

So my question is, what toolchain would you recommend for my hobby projects?  Preferably c-based, but I'm not adverse to learning something else.  I would like to be methodical about this.  I do like to do some real-time stuff, so good ISR support would be nice.

Thanks!

[Simon]

bare metal in your language of choice? nothing stopping you doing that on an Arduino board. If you want something easy and if there are no bugs by all means use Arduino that is C or C++

[rstofer]

That is why you do NOT use a printf, but snprintf or vsnprintf respectively.

Workable on chips with more memory but a little over-the-top for me.  I don't need all that capability.

Printf is also extremely uneffective to redirect to any comms peripherals as far as I can tell, as putchar-ing a single character at a time is downright dumb, if you can do a whole buffer with DMA.

Assuiming I could get DMA working without already needed debug messages.  Clearly, DMA comes along a little later (if the chip supports it) but out of the gate I like minimalist code.  Just the lowest possible generated code and the easiest to bring up.

Fancy comes later...

[Yansi]

On chips that do not have features such as DMA, things like formatted printing should not be used there in the first place. 

Printf (or any variation on) is very slow on simple (8bit) MCUs. (And takes kilobytes of what is generally not that abundant there too)

Although I understand, this is an arduino topic and nobody gives shit when printf is used in between blinkenlights.

[bd139]

Some advice please?  I'm a hardware engineer (retired) who has some mixed software / firmware experience.  I've coded in assembler for early uCs, coded in basic, pascal, and c for pre-Windows PCs, coded in vbasic and c# on modern PCs, done a little c work on RPis and arduinos and Pics, and played with python.  I really like the small / cheap arduino-style boards from Adafruit (etc), and most of my little projects can easily run on  one of these or a RPi.

So my question is, what toolchain would you recommend for my hobby projects?  Preferably c-based, but I'm not adverse to learning something else.  I would like to be methodical about this.  I do like to do some real-time stuff, so good ISR support would be nice.

Thanks!

https://www.nongnu.org/avr-libc/

Toolchain is gcc + make + avrdude. You can get a prebuilt toolchain by installing the arduino IDE and stealing the files out of the target 

[rstofer]

So my question is, what toolchain would you recommend for my hobby projects?  Preferably c-based, but I'm not adverse to learning something else.  I would like to be methodical about this.  I do like to do some real-time stuff, so good ISR support would be nice.

I would use the Arduino toolchain as it comes.  The library code is written in C++ but almost all of the user code can be written in C.  The toolchain works well and the library is very well documented.

Then, when you need horsepower, look into one of the Teensy boards.  The latest, Teensy 4 (seems to be missing off the web site, probably having demand vs supply problems) runs at a very fast 600 MHz.  It uses exactly the same IDE and implements nearly all of the Arduino library even though it is a 32 bit ARM processor and the normal Arduino is an 8 bit AVR.

Yes, the IDE is a sub-optimal POS but it works and a lot of tools are targeted for it.  I find it easier to go with the flow.  Download and install the dark theme from the Internet and get rid of the foolish coloring.  It's not perfect but it a lot less juvenile.

I used to use the avr-gcc compiler with makefiles and avrdude as a programmer on a Linux box when I was playing with the ATmega128.  Note that this is the very same toolchain that is installed by Arduino.  They just wrapped an IDE around it.

Look what happens to the Arduino root directory after you install TeensyDuino.  It just adds more compilers and such.

[Yansi]

awww yeah, 600MHz arduino, for blinkenlights using a delay()...   


PS: I'll always try to make very sure, my code and stuff is never compatible with arduino, even that stuff I (although seldom) publish.

[GeorgeOfTheJungle]

Some advice please?  I'm a hardware engineer (retired) who has some mixed software / firmware experience.  I've coded in assembler for early uCs, coded in basic, pascal, and c for pre-Windows PCs, coded in vbasic and c# on modern PCs, done a little c work on RPis and arduinos and Pics, and played with python.  I really like the small / cheap arduino-style boards from Adafruit (etc), and most of my little projects can easily run on  one of these or a RPi.

So my question is, what toolchain would you recommend for my hobby projects?  Preferably c-based, but I'm not adverse to learning something else.  I would like to be methodical about this.  I do like to do some real-time stuff, so good ISR support would be nice.

Thanks!

https://platformio.org/ + Atom

Supports almost everything out there, from the bare metal up, thousands of platforms, boards, libraries and frameworks, Arduino too.