EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: 001 on August 21, 2019, 10:27:13 am
-
Hi
I`m old tech from 70th without any programming background
But interested in AVR too just for fun
It is so funny and EASY to solder and program AVR now :-+
But every time I google for AVR projects I`m furious about agressive Arduino users :rant:
Is Arduino a sect? :-//
-
Hi
I`m old tech from 70th without any programming background
But interested in AVR too just for fun
It is so funny and EASY to solder and program AVR now :-+
But every time I google for AVR projects I`m furious about agressive Arduino users :rant:
Is Arduino a sect? :-//
I think most people have no idea what you're talking about so being more specific may help. :)
-
Arduino has break the huge barrier
between ordinary people and electronic so the
thin line that separates courage from stupidity
has been broken also.
-
I've seen plenty of stupid, but not so much aggressive...
-
There is a line between arduino and raw AVR, most don't want to leave the comfort zone, so they reinforce themselves with reasons to not leave it
If all you have is a hammer, a lot of problems start looking like nails, but when you have been solving problems by hitting them with a hammer for too long, your not going to handle things too well when someone hands you a saw to cut down a tree in an hour when you have spent the last 2 weeks denting it.
The arduino community you can treat like youtube comments, raw unfiltered human minds, the general bias to a younger audience means things will have less tact, but there will still be some knowledge shared, equally if you keep answering the same beginners questions on a forum over and over again, I myself have in the past devolved into starting to mix one previous user into how I perceive the current one, and that just leads to the feeling your talking to someone who is forgetful, when in fact its not the same person. just to give the view point of the other side.
-
Speaking as someone who played with AVRs using assembler before Arduino was a "thing"... I wouldn't go back to that except for very specific reasons.
Every time I google for info on Arduino I find tons of helpful people sharing all kinds of information, at every level of sophistication.
The big community is one of the best things about Arduino as a hobbyist's / experimenter's platform....
-
"BMKs"(1) *seems* to be the real problem with Arduino.
There are too many around with zero skills, they are complete unskilled on anything regarding computer science because they do not even try to learn something, they go around the internet looking for a quick solution for their crazy projects or for someone who makes their homework, and the problem with forums is that there are awful mods who randomly flush away users because they are tired to handle BMK ones.
So, it's my personal opinion that "probably" aggressive users are just trying to defend their living space on the internet from BMKs.
edit:
(1) BMK is the most polite internet neologism to describe the kind without being rude. They can be adults or kids, who behave in a silly way regarding internet resources.
-
There is always someone coming along saying you have to use this new and better chip or language. 99.9% of the applications for a micro are quite mundane with no need for speed or hardware advantage. In a way I miss the old days of assembly language where you had to fit everything into 1K of memory. But the packages are all black and you can't see the code inside. Who cares what the program looks like. I think it is those other people that complain about Arduino that have a stick up their butt.
-
"BMKs" is the real problem with Arduino.
There are too many around with zero skills, they are complete unskilled on anything regarding computer science because they do not even try to learn something, they lazy around the internet on their daddy;s or mammy's laptop looking for a quick solution for their crazy projects(1) or for someone who makes their homework, and the problem with forums is that there are awful mods who randomly flush away users because they are tired to handle BMK ones.
So, it's my personal opinion that "probably" aggressive users are just trying to defend their living space on the internet from BMKs.
BMK?
-
"BMKs" is the real problem with Arduino.
There are too many around with zero skills, they are complete unskilled on anything regarding computer science because they do not even try to learn something, they lazy around the internet on their daddy;s or mammy's laptop looking for a quick solution for their crazy projects(1) or for someone who makes their homework, and the problem with forums is that there are awful mods who randomly flush away users because they are tired to handle BMK ones.
So, it's my personal opinion that "probably" aggressive users are just trying to defend their living space on the internet from BMKs.
BMK?
Same question here. Unlikely it is "Baby Mouse Kidney" :-DD
https://www.acronymfinder.com/BMK.html (https://www.acronymfinder.com/BMK.html)
-
Is Arduino a sect? :-//
Although I found your post quite funny, I must admit we have to wonder sometimes whether it is indeed a sect. :-DD
-
BMK?
Sounds like a variant of PEBCAK - Problem Exists Between Chair And Keyboard
-
Has anyone seen an agressive Arduino user? Usually I notice the bare-metal zealots dribbling. My prediction is the anti-Arduino crowd will gather here. Which might have been the intention of the invitation.
-
I guess I have missed the purported bad attitudes of the Arduino users. More likely, I suspect, is the negative attitude of the high priests who proclaim the Arduino a sacrilege. This comes, of course, from the simplicity of using the Arduino and the fact that everything that can be done with an Arduino has been done and it's all out on the Internet. And high priests just aren't in demand at the entry level.
If the Arduino is big enough and fast enough to solve the problem, I'll darn sure use it.
If Arduino users do have an attitude problem, who can blame them? They are continually ridiculed for using a platform without having spent the time to understand the internals. Heck, they probably don't even have the Datasheet much less having taken the time to read it! They are told, over and over, how the Arduino will lead to world hunger and massive societal disruption and all because the users haven't bothered to learn how to write their own interrupt handlers in assembly language. I mean, seriously, what kind of user doesn't understand interrupts at the machine code level?
So while the high priests bitch and moan about the Arduino users, the users themselves are having a great time. There is a universal platform with canned examples of just about everything that could possibly be done; just copy and paste! No priesthood required!
In my view, it's the high priests who have the attitude problem.
-
I heard on the Internet that Arduino crowd is asking the same thing about you ... ^-^
-
Based on what I see on the Arduino forum at https://forum.arduino.cc/index.php#c2
only a minority of Arduino users are doing it as a hobby.
As of today I think the breakdown is roughly as follows:
90% of the posts are from students who have been given a project that they need to get done ASAP so they can pass their course. They just want an answer on a plate, preferably source code they can copy and past into their project. Having to understand things is a low priority. For this audience spending 10 minutes doing a Google search is too much effort.
5% are entrepeneurs who see the Arduino as a way of replacing some expensive piece of industrial equipment with something at 1/10 the price. They don't want to be told that fast, cheap and accurate are conflicting requirements or that WiFi doesn't work well underground.
2% are hobbyests who peppered their code with the "delay()" function because that is in so many of the official example projects. Once they discover that this is the worst way of doing things they feel like they have been lied to. It takes years for the bitterness to subside (don't ask me how I know this).
1% are hobbyests wresting with the default awful blocking libraries that paralyse their code making it impossible to do multitasking, until some kind soul points them to the non-blocking versions and then they too feel like they've been lied to. Again bitterness is the outcome.
The remaining 2% are hobbyests who have got over the bitterness of the delay() and blocking function experience and are now actually trying to use the Arduino do something useful, but have just discovered something called a 'silicon bug'. You try explaining to someone that the hardware they paid for doesn't actually do what is says in the datasheet and the manufacturer has no intention of fixing it.... and there is no workaround.
-
I haven't really noticed a lot of aggression. The thing that annoys me is the prevalence of all those awful Fritzing diagrams in lieu of proper schematics. I really wish Fritzing would just die already, it makes my head hurt trying to decipher a jumble of wires and color coded resistors on a picture of a breadboard when a schematic would be crystal clear. Fritzing is a crutch that enables people to bypass learning to read a schematic, saving them an hour early on while costing countless hours later for themselves and everyone else.
-
If the Arduino is big enough and fast enough to solve the problem, I'll darn sure use it.
Exactly. I happily use Visual Basic for some projects for the same reason. Despite occasional derision from my colleagues, it is usually hard to beat a good combination of "simple", "works", and "quickly"!
-
Exactly. I happily use Visual Basic for some projects for the same reason. Despite occasional derision from my colleagues, it is usually hard to beat a good combination of "simple", "works", and "quickly"!
Not to mention VBA is still fairly common. It's helpful to know your way around it.
-
Exactly. I happily use Visual Basic for some projects for the same reason. Despite occasional derision from my colleagues, it is usually hard to beat a good combination of "simple", "works", and "quickly"!
Not to mention VBA is still fairly common. It's helpful to know your way around it.
Yes, and it is usually the only general purpose programming environment readily available on site in large corporations without having to first go through long and complicated approval processes with their IT, networking, and various other productivity prevention departments...
-
I'm going to bite here because I have worked with a couple of programmers that jumped into Arduino.
Usual steps for arduino users are:
1. Got Arduino hype
2. Buy arduino kit off amazon or ebay
3. Flash LED. Marvellous.
4. Try and build a fucking warp capable space ship because you know, you can flash an LED.
5. Buy all the sensor kits on ebay
6. Smoke thirty packs of cigarettes getting nowhere because flashing LED was a gigantic lie.
7. Go watch netflix.
8. Find another fad.
9. Sell the lot on ebay as an "arduino lot" along with golf clubs, tennis rackets and all the other incomplete fads.
Edit: here's one just searched for :-DD https://www.ebay.co.uk/itm/223626508024 (https://www.ebay.co.uk/itm/223626508024) (complete with bollocks excuse for "it wasnt what i though it was")
-
;D
-
Arduino is awesome for everyone!
Much more people got into electronics, manufacturers made modules for everything, Chinese copy them and I can buy them for near the cost of parts (in their reel price)
I can buy a bluepill for 1.5$ inc shipping!!!! There was a time when cars were cheaper than a debugger... :palm:
"Arduino programmers" are not embedded engineers.
"Arduino" is a C++ HAL library, what's wrong with that? Most of the time it's the worst solution to a problem, some times it's the best (ex. Marlin which supports every PCB/MCU for 3D printers....)
Also I like when other people give me free code because I don't like to pay, they are doing great jobs on libraries, most of them are crap in performance and memory but they work and I don't have to copy paste registers from datasheet :phew: Reworking a drivers is much faster than making it from scratch and debug it :-//
Now they want to do pcbs! Result -> pcbs costs 2$.
They don't like to read datasheet! Result -> I can find a Job easier because they don't know how to make something cost efficient.
"But the internet if full of shit now..." Learn asm for 1 mcu family as a real embedded engineer and you will be able to detect crappy code for any mcu...
Any good engineer should know as many tools as possible in his field to be able to judge and choose the best for each task, especially the free ones...
Although it's funny when arduino makers ask how to make a homing missle with arduino :-/O
My eyes hurt on their schematics, I am a bad person and I don't try to read it >:D But being a dickhead rather than helpful is worse....
In my case my 1st software was Fritzing! I am not proud of using it for ~2 weeks but it helped me to learn the basics (I was googled PCB as green electronic tablet :-DD), then moved to eagle and now to Altium. Every crap helped someone some time become better...
-
Best part about Arduino is
(https://imgur.com/meIHp64.gif)
-
High priests of assembly, lol. When someone starts preaching about assembly, today, there's a 90% chance he did some assembly 20 years ago and is now talking out of his ass. Beware the preacher.
The guys who really know their stuff (not me), tend to help when asked. And their answers are infuriatingly like they came out of a datasheet. If I could understand the manual, I wouldn't be asking! :) The reason for this is they understand the stuff so well, they give answers that are carefully crafted to be unequivocally correct. And this is how technical documents are written.
First several months on the Microchip forums, I got the impression some guys were just copypasta'ing crap to answer questions. Over time, I figure out, no. They just understand to a higher level. The guys that know their stuff aren't out there preaching; they're tired of dealing with dummies. It's the lower level disciples that go out and do the preaching.
-
The guys that know their stuff aren't out there preaching; they're tired of dealing with dummies. It's the lower level disciples that go out and do the preaching.
Isn't that how that also works in sects? ;D
-
I don't think they are more aggressive than EEVBLOG members, or the whole internet as a matter of fact
-
The guys who really know their stuff (not me), tend to help when asked. And their answers are infuriatingly like they came out of a datasheet. If I could understand the manual, I wouldn't be asking! :) The reason for this is they understand the stuff so well, they give answers that are carefully crafted to be unequivocally correct. And this is how technical documents are written.
And the alternative is an answer that is sloppy, easy to understand and wrong under multiple conditions. This stuff isn't easy to learn and to know it to any depth takes a lot of time and a whole lot of mistakes. How many hours does it take to learn that you have to apply power to a certain peripheral in the PCON register? Unless you read the datasheet, and read it very carefully, you can be stuck on this for days.
Who has time to digest a multi-thousand page User Manual just to blink an LED? Think about the difference between blinking an LED on an Arduino and doing it from bare metal (no HAL) on an ARM. There's a HUGE difference and it is nearly insurmountable without a good deal of experience. If the only thing you have is the User Manual for the ARM, it's going to be weeks before you get it to run. This is especially true if you need to understand crt0.S (from ARM7TDMI like the LPC2106 or LPC2148) and then the ever popular linker script. Try creating that from scratch. Heck, just try to create a realistic Makefile that includes a target for device programming.
Nope! The Arduino, within its capability, wins hands down!
-
Has anyone seen an agressive Arduino user? Usually I notice the bare-metal zealots dribbling. My prediction is the anti-Arduino crowd will gather here. Which might have been the intention of the invitation.
I scoffed at Arduino for quite a while when it first started picking up. While I don't consider myself a "bare-metal zealot" I do do this professionally and I think that's what was causing my disdain: it was all hacked together kludge upon kludge to do things that could have been done so much better and with less. Then I started to realize that Arduino really brought a lot of people to electronics and computer programming, and in good ways, too. They were learning embedded, not just programming or electronics. Kids were building things. Adults were building things. Old mechanical guys who were afraid of electronics/programming were building things. Arduino took a lot of the initial pain away and for a lot of applications you don't really need more than an Arduino and some kind of shield to get the I/O where you need it. This isn't a bad thing at all; it is in fact a great way to solve a lot of problems. Those who want to take things to the next level can now do so, where before they'd be stuck behind the start line, unsure or overwhelmed with how to begin.
I really do appreciate what Arduino has done for my industry. I do still roll my eyes a bit at the "I used an Arduino to blink an LED" type projects when that's all the goal of the project was, but I tend to do it only when I'm alone. :-)
-
4. Try and build a fucking warp capable space ship because you know, you can flash an LED.
So much this. Flashing the LED isn't the hard part, it's learning how to manage your own expectations and not get discouraged that turns someone into a budding engineer.
-
Based on what I see on the Arduino forum at https://forum.arduino.cc/index.php#c2
only a minority of Arduino users are doing it as a hobby.
As of today I think the breakdown is roughly as follows:
90% of the posts are from students who have been given a project that they need to get done ASAP so they can pass their course. They just want an answer on a plate, preferably source code they can copy and past into their project. Having to understand things is a low priority. For this audience spending 10 minutes doing a Google search is too much effort.
I think you give them too much credit assuming they know how to use google or that answer on a plate isn't too complicated
-
Best part about Arduino is
(https://imgur.com/meIHp64.gif)
That’s right for pretty much the entire user base. And I don’t mean that in a derogatory way, I do exactly that when I want a quick and dirty simple automation one-off Arduino solution for my own use. I can’t imagine me using one in a commercial product though, although I know many have.
-
I also scoffed at Arduino for a long time, but then it got to where there are SO many ready to use libraries that I had to admit it has value. I can get any number of random widgets from China and more often than not I can find a library, wire it up and have it doing something in minutes.
My main complaint about these libraries is that they are often poorly documented. I can try to decipher the example programs but they are often poorly commented and may only use a few of the capabilities of the library.
-
Rstopher, I know, right? Assembly (and more specifically, the device-specific trappings) are so complicated that spitting out near verbatim datasheet answers becomes natural, efficient, correct. I'm not criticizing. It's like at that level, you aren't even speaking in a language that normal human beings can recognize. Your saying exactly what you're thinking, the way you understand it.
Weeks? Yep. Took me months to blink a LED on a PIC. That's an obvious drawback. The only good thing about it is I know (or I knew) a process to do things on the lowest level if/when it mattered. For latency or power consumption or w/e. The problem is this knowledge is very device specific, and the devices change. Even the dev tools change. Heck, even the datasheets change. (Microchip stopped putting an index in their datasheets; and this was a big part of how I managed information). So it becomes almost the same challenge all over again to repeat the feat.
So to this day, some of the technically awesomest projects I have done? Super low power consumption, super low latency multitasking to get everything working on a single chip, automatic battery cutout, deep sleep, working like a peach? It's too much trouble to incorporate these features fully, all the time. It has to be very important and/or a very huge project (in production numbers) to bother. So for many projects I agree that Arduino can be awesome. I don't take a side on this. Nothing wrong with Arduino. But I'm sure it comes with its own problems, as many have noted.
-
... I do exactly that when I want a quick and dirty simple automation one-off Arduino solution for my own use. I can’t imagine me using one in a commercial product though, although I know many have.
I do this all the time too. Except I copy from my past projects. And I never use Arduino. Works better that way ;)
-
I also scoffed at Arduino for a long time, but then it got to where there are SO many ready to use libraries that I had to admit it has value. I can get any number of random widgets from China and more often than not I can find a library, wire it up and have it doing something in minutes.
My main complaint about these libraries is that they are often poorly documented. I can try to decipher the example programs but they are often poorly commented and may only use a few of the capabilities of the library.
Yes and no. Last two times I used Arduino libraries I got so pissed off with the utterly awful fucking bugs and bloated code output I rewrote my own in AVR-libc. I've written libraries for Si5351 and HD44780. Also it's a million times easier to throw together event and interrupt driven code without being punched in the balls over and over again. Debouncing when handling other interrupts is an example of kicking you in the danglies.
The hardware and toolchain underneath it is pretty good. I use avr-gcc toolchain and avrdude. Rest of it is like attempting to date a hungry crocodile.
-
One thing that made me go "hmmm" about arduino is the boards. Yes, you can remove some unused pins from the header, arrange them in a consistent order, and with a nice silkscreen. But seems like a DIP chip would be almost the same thing. And more versatile.
I once worked with a project on which a test gear was done by an Arduino-based tool. The PSU died on it, and my client came to me to get production back up and running. I rigged up a USB supply with integral li ion battery and DC boost to 5V, cuz why not?
Well, one day, I run into the guy that developed this gear. He had seen it, and he asks me about the nifty solution I came up with. I'm explaining what I did, and he says, "How does it run on 5V? It needs 7, doesn't it?" That's when I see, for a "software guy," Arduino board just handles things, and they don't have to think about it. But... where's the line between making things easier and adding layers of obfuscation?
-
It seems OP hasn't bothered to specify what he means when he takes about agressive Arduino users. He hasn't bothered replying at all in fact.
-
Who has time to digest a multi-thousand page User Manual just to blink an LED?
I start every project from blinking LED. However, the blinking LED is never the end goal. The more you want to accomplish, the harder it gets. In most cases the cookie-cutter solutions don't work for me.
If I want to hang a huge painting above my bed, I don't care how to do it easily - say without drilling, or without any tools, or with fewer wacks of a hummer. What I care about is that the painting is straight, solid, and will never fall on my head while I'm sleeping. And I'm prepared to do whatever is necessary to accomplish my goal.
I have similar approach to programming. I have requirements which must accomplish certain goals. So, I work on that. If I need something from the datasheet, I have no problem finding it there. If I need to use assembler, I'll do it. If I need to do a research to find a better MCU, I'll do it. Whatever it takes to meet the requirements. Would I save time if I used Arduino? I don't see how.
-
One thing that made me go "hmmm" about arduino is the boards. Yes, you can remove some unused pins from the header, arrange them in a consistent order, and with a nice silkscreen. But seems like a DIP chip would be almost the same thing. And more versatile.
The Arduino Nano comes in a 'stamp' format with headers more suited to installation on daughter cards:
https://www.amazon.com/ELEGOO-Arduino-ATmega328P-Without-Compatible/dp/B0713XK923 (https://www.amazon.com/ELEGOO-Arduino-ATmega328P-Without-Compatible/dp/B0713XK923)
I especially like the mbed LPC1768 for this kind of thing. All I have to do is design the daughter card with project specific components and plug in the MCU
https://os.mbed.com/platforms/mbed-LPC1768/ (https://os.mbed.com/platforms/mbed-LPC1768/)
In fact, all I need to add is a MagJack and ethernet is up and running. The mbed project furnishes the lwIP stack.
-
It seems OP hasn't bothered to specify what he means when he takes about agressive Arduino users. He hasn't bothered replying at all in fact.
Nearly all of his posts are provocative. He gets scolded from time to time.
-
Rstopher, I don't get it, though. If you're gonna do that, why not do away with the Arduino board, entirely, and put the nekkid chip on your board? And add the few external components (the ones that you need).
If you are repeatedly designing stuff within Arduino, and you want to recycle that footprint, you could even make the entire thing a library component, perhaps? (I guess it depends on your PCB software). So you plop that into your schematic and and then drag and drop it onto your board.
Humm.. maybe Arduino boards are so cheap it saves on assembly time/cost to buy and install the entire boards? :-// >:D
-
I have similar approach to programming. I have requirements which must accomplish certain goals. So, I work on that. If I need something from the datasheet, I have no problem finding it there. If I need to use assembler, I'll do it. If I need to do a research to find a better MCU, I'll do it. Whatever it takes to meet the requirements. Would I save time if I used Arduino? I don't see how.
I think it could save time on your next project... as long as Arduino can meet the requirements. Learning Arduino, that knowledge is somewhat consistent going into the future. Knowing how to program a chip to the bare metal is useful when it's useful. But unless you want to use Z80 forever, that knowledge is not quite as portable. You slog through it to meet the requirements of a given project. On the next project, you slog through it all over again. As AVR continue to evolve, someone over at Arduino Co will incorporate newer, faster, cheaper micro into more or less stable platform, I think. So as the user, you will mostly find the switches to be in the same position, with the same names, and the same functions. With only a few new ones.
My POV is obviously super biased towards my own narrow experience.
-
Best part about Arduino is
(https://imgur.com/meIHp64.gif)
When you write
#include <stdio.h>
Aren't you doing the same thing?
-
Rstopher, I don't get it, though. If you're gonna do that, why not do away with the Arduino board, entirely, and put the nekkid chip on your board? And add the few external components (the ones that you need).
If you are repeatedly designing stuff within Arduino, and you want to recycle that footprint, you could even make the entire thing a library component, perhaps? (I guess it depends on your PCB software). So you plop that into your schematic and and then drag and drop it onto your board.
Humm.. maybe Arduino boards are so cheap it saves on assembly time/cost to buy and install the entire boards? :-// >:D
There are complications when dealing with high speed signals (LPC1768 not Arduino) and, in the case of the LPC1768, there are components on both sides of the board. How do I reflow that? I'm a hobbyist, not a manufacturer.
Shorter answer: I don't want to design the MCU part of the project. I'll leave it to others. Another short answer: I consider my time to be worth $100/hour and I make all buy versus build decisions on that basis. Lots of other decisions too! I'll design something if I have to but not if I can buy it. Arduinos are particularly cheap.
Consider too that when a project is no longer meaningful, I can recover the MCU board and move it to another project.
Arduinoo Nano's are especially cheap at around $4.30 with free shipping. How much design can I do for $5 - about 3 minutes at my billing rate. There's a reason my billing rate is so high! It keeps me from making dumb mistakes like misusing what little time I have left. My "Best Used By Date" is approaching and there's no point in wasting my time trying to reinvent the wheel. Heck, I can't even order the parts in 3 minutes!
https://www.amazon.com/s?k=arduino+nano (https://www.amazon.com/s?k=arduino+nano)
-
Best part about Arduino is
(https://imgur.com/meIHp64.gif)
That’s right for pretty much the entire user base. And I don’t mean that in a derogatory way, I do exactly that when I want a quick and dirty simple automation one-off Arduino solution for my own use. I can’t imagine me using one in a commercial product though, although I know many have.
Yep it’s why we write and share programs.
I’ve used one for automated testing of germanium transistors to palm off on eBay to guitar pedal builders. Literally saved me hours and hours of work. One of them, a cheap UniT Ut61E and python program that told the arduino to switch on a relay then give a go or no go.
But yes in a commercial project or something where you need better control over system interrupts or actually need to understand how broken the arduino libraries are then is run a mile.
Best part about Arduino is
(https://imgur.com/meIHp64.gif)
When you write
#include <stdio.h>
Aren't you doing the same thing?
If you’re using glibc then yes. Bloated POS :-DD
-
Another strategy for dedicated ATmega328 (DIP package) projects is to program the device on the Arduino board and just plug the chip into the main project board. As long as you don't need the USB->Serial Terminal support, this works well.
-
Learning Arduino, that knowledge is somewhat consistent going into the future.
Many years ago I though that my "knowledge" was going to go with me into the future. Since then, so many things changed on me, so I learned to embrace the change. Besides, I found out that if you figure out how to work with one MCU, you can easily transfer your skill to others. I'm pretty sure that if I get a new MCU which I've never seen before, I can figure it out rather quickly. Things are still changing very quickly - if you get fixated on something particular, you're destine to live in the past.
-
^The problem, though. Do I get wiser with age? Maybe. Slower and dumber? Definitely.
-
Arduinoo Nano's are especially cheap at around $4.30 with free shipping. How much design can I do for $5 - about 3 minutes at my billing rate.
For some projects $4.30 might be huge overkill as under-$1 PIC will work just as well (or better). For other projects you may need something for $10. There are thousands if different MCUs which are used for different purposes.
... there's no point in wasting my time trying to reinvent the wheel.
But a tricycle wheel may not fit on Ferrari.
Another strategy for dedicated ATmega328 (DIP package) projects is to program the device on the Arduino board and just plug the chip into the main project board. As long as you don't need the USB->Serial Terminal support, this works well.
You can program almost anything in-circuit. What's the point of dragging DIP chips back and forth?
-
That is one more perk of the arduino platform, there are the classic AVRs, SAM, ARM, ESP8266, ESP32, etc that can all be used fairly interchangeably. It's certainly not the most optimal way of working with any one of them, but for a casual novice it really is about the easiest way to get something up and running. A few months ago I built an environmental monitor for our cabin using an ESP8266 on the neighbor's wifi, the whole software development process took only an hour or two and I'm certainly not a professional developer. For me it was a very quick and easy way to get something up and running that so far has been working perfectly.
-
^Yeah, nothing wrong with that. Even you do that with a raspberry pi, who cares? If it works, it works.
Is this "real embedded design?" Sure. If you need to optimize cost and performance, you might need to do some further tinkering. But I doubt you own that many cabins.
You can program almost anything in-circuit. What's the point of dragging DIP chips back and forth?
Yeah, I dunno this. But Rstopher been at the game for a long time, now, judging from his posts. From way back when IC sockets were more than a curiousity. I think I better learn Arduino, soon, because the older I get, the more appealing "cntrl + C/V" looks. Hopefully, by then I can just outsource or hire younger guns to do the optimizing.
(Also, I think he means to burn the Arduino bootloader in a socket. Then upload the sketches through the serial port on the pcb. As long as the bootloader isn't going to change, that might be easier/cheaper. Bare chips are easier to handle than entire PCB, in general, and last I checked, company like Microchip, even, charges minimum ~20 cents each to burn your chips in bulk!)
-
Arduinoo Nano's are especially cheap at around $4.30 with free shipping. How much design can I do for $5 - about 3 minutes at my billing rate.
For some projects $4.30 might be huge overkill as under-$1 PIC will work just as well (or better). For other projects you may need something for $10. There are thousands if different MCUs which are used for different purposes.
Yup! But get that $1 PIC designed into the project for $3.30 or 1.9 minutes of labor! It's a hobby, component costs are irrelevant. Labor is the deciding factor.
Another strategy for dedicated ATmega328 (DIP package) projects is to program the device on the Arduino board and just plug the chip into the main project board. As long as you don't need the USB->Serial Terminal support, this works well.
You can program almost anything in-circuit. What's the point of dragging DIP chips back and forth?
You certainly can and I have done it quite a bit with the ATmega128 and the early LPC21xx family. JTAG is also a nice way to go.
For my purposes, strictly hobby, I'm not about to get into designing something that already exists.
-
Heck, even a company like Boeing "can't afford" to keep employees that actually build and maintain what isn't really all that complicated. I wonder if their full time engineering staff uses Arduino, lol. Ok, India. <Hands over plane stuffed with Arduinos>. This is what we want. Just make it not suck. We already worked out all the potential issues well in advance, so we know there will be no unforeseen complications, and it should take about 3 months.
You'd think they would hire/buy the group that builds it and keep these guys on full time or at least retainer, for the life of the product, with this particular sorta $$$ and lives at stake.
-
Hi
I`m old tech from 70th without any programming background
But interested in AVR too just for fun
It is so funny and EASY to solder and program AVR now :-+
But every time I google for AVR projects I`m furious about agressive Arduino users :rant:
Is Arduino a sect? :-//
No, more like 'Cargo Cultists' waiting for more free 'libraries' to drop from the sky.
I've never found any posts by Arduino users to be aggressive, they are mainly very happy they can now make something that they simply could not do before Arduino, when designers had to read the 1000 page technical manuals and understand them before even attempting to fire up the Micro.
Arduino users often say "who has the time to read a 1000 page technical manual ?" and my answer is always, "any embedded design engineer" .
Are Arduino users competent in embedded ? absolutely not. They are clueless about the most basic fundamentals of electronics, embedded design and software, because they are artists or basic hobbyists who have the time to watch all 1000 episodes of "Days of our Lives" on television, but not to read a ARM technical manual.
If you are furious with Arduino users then you have a strange view of the Arduino world in my opinion. Perhaps you should stop blaming others and put in a effort to get a clue of your own because nothing is easier than Arduino for the lay person and nothing is more useless than Arduino to a engineer.
Or as claimed, are you just trolling ? If you are then you have wasted your time because Arduino users here seem pretty relaxed, and engineers here don't bother with it.
-
I sort of sneered at Arduinos and the AVR chips in general for a long time. But then I saw the light.
The Arduino scared the holy bejeezus out of the other chip vendors bringing us an embarrassment of riches in the form of cheap dev boards from every chip maker who previously wanted an arm and a leg for a $10 piece of hardware. That has been hugely beneficial to all.
The other notable feature is that the ATMEGA chips are 5 V TTL superglue. So if you want to interface with something like GPIB it's cheap. Driver chips not required unless you *really have to* put 16 devices on a single bus.
Part of my disdain was due to the attitude issue noted in the start of this thread. It's classic "experienced novice" attitude. All of my serious experience is with high end workstations and larger and a major annoyance has been dealing with people who assume that all computers are the same. They are not. Even the same systems in the same company are often different. At a major oil company where I worked on my first contract job I had a standing offer of $100 to anyone who showed me two Unix workstations that were configured the same. I withdrew the offer as I was standing watching a couple of employees working for me clone a system I had built. In response to a comment I made in a meeting 6 months earlier I found myself with two regular employees working full time under my direction.
The good news - bad news about software is that it is *very* hard to ensure that things are the same above a rather low level of complexity.
The developers and promoters of the Arduino have done the EE community a great service. Be grateful even if some of the users are annoying.
Have Fun!
Reg
-
Learning Arduino, that knowledge is somewhat consistent going into the future.
Many years ago I though that my "knowledge" was going to go with me into the future. Since then, so many things changed on me, so I learned to embrace the change. Besides, I found out that if you figure out how to work with one MCU, you can easily transfer your skill to others. I'm pretty sure that if I get a new MCU which I've never seen before, I can figure it out rather quickly. Things are still changing very quickly - if you get fixated on something particular, you're destine to live in the past.
So true. Tech is changing so fast now that it's impossible to keep up with except in very niche areas.
I'm always amazed by some Arduino users extolling the virtues of the Mega328 but who don't seem aware that this MCU is practically prehistoric now as the AVR 8-bit microcontroller architecture was introduced in 1997.
Sure, it still does everything it did 22 years ago, but MCU tech has changed enormously in that time.
If you show them a STM32F777 with its 93 internal peripherals, 2093 registers and 17051 bitfields running up to 216 MHz, they are more likely to exclaim, "what would I need that for" (as tho ignorance is a virtue) and "I don't have the time to read the 1954 page manual!" without realizing that this product is already 2 years old and those that have read the latest Tech manual (dated March 2018) have a massive head start applying this chip in their designs.
-
The converse also seems to be true with people looking at hugely complicated ultra fast MCUs to do something an Arduino will do with ease. Newer doesn't always equate more suited to the job.
-
It's a hobby, component costs are irrelevant. Labor is the deciding factor.
If it's a hobby then labour is supposedly what you want.
-
Talking about sects.
These people totally and blindly follow their gods. :-DD
https://www.thebackshed.com/forum/ViewForum.php?FID=16 (https://www.thebackshed.com/forum/ViewForum.php?FID=16)
https://forum.micropython.org/ (https://forum.micropython.org/)
-
The converse also seems to be true with people looking at hugely complicated ultra fast MCUs to do something an Arduino will do with ease. Newer doesn't always equate more suited to the job.
If you have no expertise regarding "hugely complicated ultra fast MCUs", what leads you to believe that you can make this comparison ?
What you call "hugely complicated ultra fast MCUs", I call "immensely capable modern MCU's that are a designers dream come true".
Newer DOES almost always equate to "more suited to the job", to deny that is to assume that brains far smarter than yours or mine were wasting their time and billions of dollars in embedded chip manufacture for no reason at all.
Given that ST's shares doubled in value in 2017, they must be doing something right ?
-
Talking about sects.
These people totally and blindly follow their gods. :-DD
https://www.thebackshed.com/forum/ViewForum.php?FID=16 (https://www.thebackshed.com/forum/ViewForum.php?FID=16)
https://forum.micropython.org/ (https://forum.micropython.org/)
Yeah. Go on, let's hear how?
I clicked the links and it wasn't immediately evident to me.
-
Newer DOES almost always equate to "more suited to the job", to deny that is to assume that brains far smarter than yours or mine were wasting their time and billions of dollars in embedded chip manufacture for no reason at all.
Sort of depends upon what you are trying to do. If all you want to do is flash LEDs on a jacket or automate a sculpture, what matters is how much of your time does the task consume.
Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does.
Hammers are *very* ancient tools. But in several millenia, nothing has made them obsolete. I've got literally dozens, all of which are designed for different situations. Sometimes it's hard to decide which will be best. Especially if you only get to hit it once and choosing the wrong hammer means everything was ruined and will require major work to fix.
Driving the GPIB bus changed my attitude rather dramatically. I plan on keeping a stock of 328P and 2560 boards on hand, in the future. They are the right hammers for a lot of nails.
-
What you call "hugely complicated ultra fast MCUs", I call "immensely capable modern MCU's that are a designers dream come true".
Newer DOES almost always equate to "more suited to the job", to deny that is to assume that brains far smarter than yours or mine were wasting their time and billions of dollars in embedded chip manufacture for no reason at all.
Given that ST's shares doubled in value in 2017, they must be doing something right ?
I've worked with microcontrollers of many types over the years, from quite powerful and modern to quite primitive and generally I aim to get the most out of the least. IMO it's silly to try using a high end STM32 for something where a low end 8 bit AVR is under-utilized. Likewise it's silly to spend TOO much effort getting a very low end part to do a job that is better suited to the higher end.
Of course ST is doing something right, there are millions of applications for powerful advanced microcontrollers, that doesn't mean that they're necessarily the best option for everything. If a 20 year old part does the job and is readily available then where is the advantage of using a newer more complex part? Your statement is frankly ridiculous, the fact that these smart people are not wasting their time developing powerful parts doesn't mean those parts are the best choice for every application.
A good engineer weighs the pros and cons, and chooses the most suitable part for the task at hand, taking into account many factors, not just blindly choosing the newest most advanced part because "newer = better".
-
It's a hobby, component costs are irrelevant. Labor is the deciding factor.
If it's a hobby then labour is supposedly what you want.
I want enjoyment, not labor. If I just wanted labor I could take the really long road on almost any project, but that would be boring and tedious. Ultimately I want the most enjoyable route to a finished working project, what that means depends on what my particular interest is at the time. Sometimes I just have a specific need and want to hack something together that works, other times I want to experiment with some new part or technology or just see if I can do something. The goal is not just to create the maximum amount of work for myself.
-
Newer DOES almost always equate to "more suited to the job", to deny that is to assume that brains far smarter than yours or mine were wasting their time and billions of dollars in embedded chip manufacture for no reason at all.
Sort of depends upon what you are trying to do. If all you want to do is flash LEDs on a jacket or automate a sculpture, what matters is how much of your time does the task consume.
Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does.
Hammers are *very* ancient tools. But in several millenia, nothing has made them obsolete. I've got literally dozens, all of which are designed for different situations. Sometimes it's hard to decide which will be best. Especially if you only get to hit it once and choosing the wrong hammer means everything was ruined and will require major work to fix.
Driving the GPIB bus changed my attitude rather dramatically. I plan on keeping a stock of 328P and 2560 boards on hand, in the future. They are the right hammers for a lot of nails.
I can understand the usual Arduino Mantras by Lay people who don't know any better but I'm surprised to hear this argument from you.
Please explain why a $0.45 STM32L053 needs $5 in driver chips and a $5 (Arduino) MCU board does not ? Try and be specific, I'm sure most on this forum will be able to follow you.
I don't believe your hammer example is appropriate here because there is a massive difference between a ancient hammer made from bronze compared to a modern hammer made from specially refined and heat treated steel.
However one part of your hammer example does apply to your first assertion ... "how much time does the task consume"
Who uses hammers every day ... a blacksmith!
"The Metal Museum has a two-year apprenticeship program that provides housing, insurance, a living stipend and studio facilities. The intern works in the blacksmith shop and assists with exhibit design and installation during regular business hours. The intern has unlimited access to the blacksmith shop and foundry. At the end of the two-year period, the intern has a body of his or her own work, as well as experience working on large scale projects designed and produced by the Museum. "
If it requires TWO YEARS to learn how to use a hammer to blacksmith, surely it will require that much (time or more) for any decent skill, i.e. embedded design.
Owning dozens of hammers doesn't make you a blacksmith.
-
... I do exactly that when I want a quick and dirty simple automation one-off Arduino solution for my own use. I can’t imagine me using one in a commercial product though, although I know many have.
I do this all the time too. Except I copy from my past projects. And I never use Arduino. Works better that way ;)
Most of the time, I do the same, for example I know the entire PiC ecosystem far, far more than I do Arduino. I also know it well enough that if I want to turn around, say, a USB macro keyboard in under an hour, that’s just not going to happen on a PIC, but is eminently feasible on an Arduino.
Part of this is that the libraries are already there, part of it is that there are examples already there, and part of it is because a PIC will be ten times more complex.
-
What you call "hugely complicated ultra fast MCUs", I call "immensely capable modern MCU's that are a designers dream come true".
Newer DOES almost always equate to "more suited to the job", to deny that is to assume that brains far smarter than yours or mine were wasting their time and billions of dollars in embedded chip manufacture for no reason at all.
Given that ST's shares doubled in value in 2017, they must be doing something right ?
I've worked with microcontrollers of many types over the years, from quite powerful and modern to quite primitive and generally I aim to get the most out of the least. IMO it's silly to try using a high end STM32 for something where a low end 8 bit AVR is under-utilized. Likewise it's silly to spend TOO much effort getting a very low end part to do a job that is better suited to the higher end.
Of course ST is doing something right, there are millions of applications for powerful advanced microcontrollers, that doesn't mean that they're necessarily the best option for everything. If a 20 year old part does the job and is readily available then where is the advantage of using a newer more complex part? Your statement is frankly ridiculous, the fact that these smart people are not wasting their time developing powerful parts doesn't mean those parts are the best choice for every application.
A good engineer weighs the pros and cons, and chooses the most suitable part for the task at hand, taking into account many factors, not just blindly choosing the newest most advanced part because "newer = better".
How old are you James ?
I started building embedded gear in 1975 on a National PACE 16 bit CPU with high speed paper tape and assembler. The project was the worlds first nucleonic iron ore flow gauge designed by a engineer who wrote his own Forth for that CPU and project.
Please don't think that I'm impressed by your vague background.
Frankly, you sound like a hobbyist who has very little real world embedded experience to me.
A engineer highly experienced with STM32xx will use the most appropriate late model STM32 MCU for any new project requiring it. He has a dazzling multitude of models and package sizes to choose from with low end STM MCUs available for cents in 100,000+ quantities.
He wouldn't risk his job to use some old OBSOLETE 8 bit AVR in a new design, except in your wildest dreams.
-
If you have no expertise regarding "hugely complicated ultra fast MCUs", what leads you to believe that you can make this comparison ?
What you call "hugely complicated ultra fast MCUs", I call "immensely capable modern MCU's that are a designers dream come true".
Newer DOES almost always equate to "more suited to the job", to deny that is to assume that brains far smarter than yours or mine were wasting their time and billions of dollars in embedded chip manufacture for no reason at all.
Given that ST's shares doubled in value in 2017, they must be doing something right ?
So Mr. 001, you say you have a more suitable part for our products? What made you come to this conclusion? It's newer you say? I'm interested. It's designed by people you feel are smarter than us? Convincing. It's the most complicated and least proven part we could find and our design team has no experience with it? You have half a dozen other reasons not related to the actual suitability of the MCU? Well 001, sign us up! Make sure we slap that puppy every design. Respin the boards if you have to!
You could stir the pot more subtly but it's certainly hilarious! :-DD
-
And here we go again! [emoji1787]
Sent from my iPhone using Tapatalk
-
High priests of assembly, lol. When someone starts preaching about assembly, today, there's a 90% chance he did some assembly 20 years ago and is now talking out of his ass. Beware the preacher.
The guys who really know their stuff (not me), tend to help when asked. And their answers are infuriatingly like they came out of a datasheet. If I could understand the manual, I wouldn't be asking! :) The reason for this is they understand the stuff so well, they give answers that are carefully crafted to be unequivocally correct. And this is how technical documents are written.
First several months on the Microchip forums, I got the impression some guys were just copypasta'ing crap to answer questions. Over time, I figure out, no. They just understand to a higher level. The guys that know their stuff aren't out there preaching; they're tired of dealing with dummies. It's the lower level disciples that go out and do the preaching.
:clap:
yes.
And everytime i tell guys to go read the datasheet or go look in the product page i expect them to either have an "ooooh" moment or at least read the freaking documentation and come back with at least an idea of what it is really that they are not understanding
some times you even get the prick who believe he is being treated like a child (instead of being treated as a student) and starts telling the compiler guys to fuck off because they know nothing. Those are the funniest moments
-
If you have no expertise regarding "hugely complicated ultra fast MCUs", what leads you to believe that you can make this comparison ?
What you call "hugely complicated ultra fast MCUs", I call "immensely capable modern MCU's that are a designers dream come true".
Newer DOES almost always equate to "more suited to the job", to deny that is to assume that brains far smarter than yours or mine were wasting their time and billions of dollars in embedded chip manufacture for no reason at all.
Given that ST's shares doubled in value in 2017, they must be doing something right ?
So Mr. 001, you say you have a more suitable part for our products? What made you come to this conclusion? It's newer you say? I'm interested. It's designed by people you feel are smarter than us? Convincing. It's the most complicated and least proven part we could find and our design team has no experience with it? You have half a dozen other reasons not related to the actual suitability of the MCU? Well 001, sign us up! Make sure we slap that puppy every design. Respin the boards if you have to!
You could stir the pot more subtly but it's certainly hilarious! :-DD
No no no!
Your competitors want you to keep on using obsolete MCU's in your products, they love you just as you are and would hate you to change a single thing!
-
Wow! It isn't just Arduino users who are agressive.
It all looks like hysteresis, band gaps, local minima and quantum leaps to me.
People (and companies) need compelling reasons to jump to new platforms and tools. The more tightly bound you are to a platform, the bigger the kick required to break free.
I personally think that the Arduino+AVR crowd are missing out of they stick with the original H/W, and would be better served moving to Micropython on a 32-bit platform with an IDE like uPyCraft for the low barrier to entry embedded platform... Like the micro:bit perhaps.
... but that would require a very big kick to get them out of their rut.
-
Wow! It isn't just Arduino users who are agressive.
It all looks like hysteresis, band gaps, local minima and quantum leaps to me.
People (and companies) need compelling reasons to jump to new platforms and tools. The more tightly bound you are to a platform, the bigger the kick required to break free.
I personally think that the Arduino+AVR crowd are missing out of they stick with the original H/W, and would be better served moving to Micropython on a 32-bit platform with an IDE like uPyCraft for the low barrier to entry embedded platform...
... but that would require a very big kick to get them out of their rut.
I'm not trying to convince anyone to change from Arduino, I say 'use what works for you'.
However ... anyone who quotes a Arduino mantra by way of trying to claim that AVR is in *any way* superior to ARM Cortex-M is just begging for a rebuttal from someone like me who has the experience to know otherwise.
Let's take an example of a product dear to eevblogs heart, the 121GW multi meter. What is the MCU in that ?
Is it a AVR ? is it a PIC ?
It's only a multimeter, surely it doesn't need one of those 1000 plus page manual STM Micros ??
I'm sure a Mega328 is PLENTY, just find the Arduino 121GW 'library' and it's done ... 5 minutes with a $5 Arduino Nano board. Perfect! Just ask RMB.
OH HEAVENS!!! it's a ST ARM Cortex M3 processor !!
Now Dave was very tactful about why the designer removed the initial PIC MCU giving no reasons why that might have been so as to not upset anyone and I applaud his marketing skills.
Dave did however go on to rave about how the SD card facility made upgrading and other features very easy in this outstanding instrument which had it been the original PIC would have required a cable, a PickitX or some hardware and lots of warranty returns for bricked units and angry buyers advertising in every online forum "to stay away from this junk".
The designers knew what they were doing :-+
If I didn't already have a decent multimeter, I'd be buying a 121GW tomorrow and as it is I recommend the 121GW to anyone who asks me "what multimeter should I buy".
It's a no brainer, ... thanks to STM32.
-
Hi
I`m old tech from 70th without any programming background
But interested in AVR too just for fun
It is so funny and EASY to solder and program AVR now :-+
But every time I google for AVR projects I`m furious about agressive Arduino users :rant:
Is Arduino a sect? :-//
I've seen quite the opposite: arrogant and sometimes aggressive behavior from "old-school" engineers towards the Arduino or maker community. You can spot it here sometimes in these forums.
The typical scenario is:
- Someone has built a simple circuit with an AVR chip and some Arduino code but has a question/problem, needs a bit of help.
- Old-school" guy will respond with one of these answers:
- Why are you using Arduino? It's for kids, it's bloated, it's badly designed, etc.
- Technical mumbo-jumbo about the "poor" choice of the op-amp, adc, mosfet, or whatever, designed to show that the "old-school" guy is very smart/knowledgeable.
- Harsh comments about the bad layout of the boards or the schematic
- None of the responses help the user with his problem/question, which is often simple.
My take is that these "old-school" guys feel insecure about the fact that tons of new people are doing electronics today for fun, and it's never been so easy. They are no longer the gatekeepers of a complex world unavailable to the profane. They feel that it's unfair that the Arduino UNO sold boatloads while their own project, which is vastly superior in terms of complexity, design, layout, EMC and safety only sold a dozen (costing 20 times more).
Be kind. Be patient. Have fun. Share your knowledge and make it accessible to people who know much less than you. This is what Dave Jones does and this one of the reasons for his success IMO.
-
No no no!
Your competitors want you to keep on using obsolete MCU's in your products, they love you just as you are and would hate you to change a single thing!
Obsolete as in probably the few parts that will still be available in two decades due to them being ubiquitous and sold in huge numbers to a very distributed crowd?
-
:popcorn:
-
I'm not trying to convince anyone to change from Arduino, I say 'use what works for you'.
However ... anyone who quotes a Arduino mantra by way of trying to claim that AVR is in *any way* superior to ARM Cortex-M is just begging for a rebuttal from someone like me who has the experience to know otherwise.
Let's take an example of a product dear to eevblogs heart, the 121GW multi meter. What is the MCU in that ?
Is it a AVR ? is it a PIC ?
It's only a multimeter, surely it doesn't need one of those 1000 plus page manual STM Micros ??
I'm sure a Mega328 is PLENTY, just find the Arduino 121GW 'library' and it's done ... 5 minutes with a $5 Arduino Nano board. Perfect! Just ask RMB.
OH HEAVENS!!! it's a ST ARM Cortex M3 processor !!
Now Dave was very tactful about why the designer removed the initial PIC MCU giving no reasons why that might have been so as to not upset anyone and I applaud his marketing skills.
Dave did however go on to rave about how the SD card facility made upgrading and other features very easy in this outstanding instrument which had it been the original PIC would have required a cable, a PickitX or some hardware and lots of warranty returns for bricked units and angry buyers advertising in every online forum "to stay away from this junk".
The designers knew what they were doing :-+
If I didn't already have a decent multimeter, I'd be buying a 121GW tomorrow and as it is I recommend the 121GW to anyone who asks me "what multimeter should I buy".
It's a no brainer, ... thanks to STM32.
Poor show. Trolls and shills on here tend to be a bit more clever than this. It won't really boost your STM stock either.
-
No no no!
Your competitors want you to keep on using obsolete MCU's in your products, they love you just as you are and would hate you to change a single thing!
Obsolete as in probably the few parts that will still be available in two decades due to them being ubiquitous and sold in huge numbers to a very distributed crowd?
An interesting question but sadly I can't predict the future, however I have a clear memory of the past and I can look there for trends.
20 years ago in 1999 I was selling small quantities of a specialist industrial sensor (my own design) which used a PIC chip. Utterly reliable, some of my original units are still in use today. I used C back then and I'm still 100% happy with PIC reliability.
The price of that PIC MCU, which is still available today is USD 5.50 from Alibaba, however my current MCU of choice the STM32F051 was $0.56 USD each in 2014.
If my old PIC could speak, it would worship the STM32F051 like it was a GOD.
This is in line with my observations of old and obsolete chips, the mfr keeps the line going for replacement parts but the cost keeps going up and up.
So I'm agreeing with you that obsolete parts will still be available in 20 years, but your's won't be the ONLY ones. Most other obsolete chips will probably still be available but expensive.
-
An interesting question but sadly I can't predict the future, however I have a clear memory of the past and I can look there for trends.
20 years ago in 1999 I was selling small quantities of a specialist industrial sensor (my own design) which used a PIC chip. Utterly reliable, some of my original units are still in use today. I used C back then and I'm still 100% happy with PIC reliability.
The price of that PIC MCU, which is still available today is USD 5.50 from Alibaba, however my current MCU of choice the STM32F051 was $0.56 USD each in 2014.
If my old PIC could speak, it would worship the STM32F051 like it was a GOD.
This is in line with my observations of old and obsolete chips, the mfr keeps the line going for replacement parts but the cost keeps going up and up.
So I'm agreeing with you that obsolete parts will still be available in 20 years, but your's won't be the ONLY ones. Most other obsolete chips will probably still be available but expensive.
What's your definition of obsolete? The manufacturer states the 328P is in production. They also recommend it for automotive design which typically means it will be supported for a long time to come. That's as good a guarantee as you can get in this field.
-
I'm not trying to convince anyone to change from Arduino, I say 'use what works for you'.
You just did. With flying colors.
However ... anyone who quotes a Arduino mantra by way of trying to claim that AVR is in *any way* superior to ARM Cortex-M is just begging for a rebuttal from someone like me who has the experience to know otherwise.
Let's take an example of a product dear to eevblogs heart, the 121GW multi meter. What is the MCU in that ?
No. Let's take an example we already know, "flash LEDs on a jacket or automate a sculpture". Both are weekend projects you may never "manufacture" in bigger quantities that one. For such project you just take what's in your bin [edit] and do not plan to write project-specific Forth. For many it is Arduino, you and me would prefer BluePill, others may use BeagleBoard. Nothing wrong with either choice as long as you do not miss your deadline nor blow your budget.
-
Poor show. Trolls and shills on here tend to be a bit more clever than this. It won't really boost your STM stock either.
Cry me a river pal ...
I just checked my STM stock, and no one has 'boosted' it ...
480x STM32f051
20x STM32F103
10x STM32L053
10x STML162
1x STM32L073
2x STM32F407
oh ... were you fantasizing about some other kind of "stock" ?
-
Hi
I`m old tech from 70th without any programming background
But interested in AVR too just for fun
It is so funny and EASY to solder and program AVR now :-+
But every time I google for AVR projects I`m furious about agressive Arduino users :rant:
Is Arduino a sect? :-//
Only in as much as any processor, OS, manufacturer fanboy is.
You'll find the same kind of idiot on Linux, Windows, Apple, Arduino, Pi, PIC, Intel, AMD forums etc. etc. except there's an added layer of stupid on Arduino because it's such a mass market thing.
-
I'm not trying to convince anyone to change from Arduino, I say 'use what works for you'.
You just did. With flying colors.
However ... anyone who quotes a Arduino mantra by way of trying to claim that AVR is in *any way* superior to ARM Cortex-M is just begging for a rebuttal from someone like me who has the experience to know otherwise.
Let's take an example of a product dear to eevblogs heart, the 121GW multi meter. What is the MCU in that ?
No. Let's take an example we already know, "flash LEDs on a jacket or automate a sculpture". Both are weekend projects you may never "manufacture" in bigger quantities that one. For such project you just take what's in your bin [edit] and do not plan to write project-specific Forth. For many it is Arduino, you and me would prefer BluePill, others may use BeagleBoard. Nothing wrong with either choice as long as you do not miss your deadline nor blow your budget.
Absolutely, I could never argue with logic like yours.
I would use Forth and any STM32 MCU that was suitable and in stock as it's a theoretical weekend job with a deadline.
I always write project-specific Forth!
: Jacket1 ." FORTH LOVE? IF HONK THEN " cr ;
-
Cry me a river pal ...
I just checked my STM stock, and no one has 'boosted' it ...
480x STM32f051
20x STM32F103
10x STM32L053
10x STML162
1x STM32L073
2x STM32F407
oh ... were you fantasizing about some other kind of "stock" ?
Well you're obviously very intent on emphasizing the benefits of the latest and greatest STM devices and also obviously intent on causing a stir.
-
So I'm agreeing with you that obsolete parts will still be available in 20 years, but yours won't be the ONLY ones. Most other obsolete chips will probably still be available but expensive.
What's your definition of obsolete? The manufacturer states the 328P is in production. They also recommend it for automotive design which typically means it will be supported for a long time to come. That's as good a guarantee as you can get in this field.
How about "Outmoded in design, style, or construction." ?
Atmel would recommend it for your Grandmothers Pacemaker if they thought it would sell extra units, are you really this gullible ?
-
No no no!
Your competitors want you to keep on using obsolete MCU's in your products, they love you just as you are and would hate you to change a single thing!
Obsolete as in probably the few parts that will still be available in two decades due to them being ubiquitous and sold in huge numbers to a very distributed crowd?
An interesting question but sadly I can't predict the future, however I have a clear memory of the past and I can look there for trends.
20 years ago in 1999 I was selling small quantities of a specialist industrial sensor (my own design) which used a PIC chip. Utterly reliable, some of my original units are still in use today. I used C back then and I'm still 100% happy with PIC reliability.
The price of that PIC MCU, which is still available today is USD 5.50 from Alibaba, however my current MCU of choice the STM32F051 was $0.56 USD each in 2014.
If my old PIC could speak, it would worship the STM32F051 like it was a GOD.
This is in line with my observations of old and obsolete chips, the mfr keeps the line going for replacement parts but the cost keeps going up and up.
So I'm agreeing with you that obsolete parts will still be available in 20 years, but your's won't be the ONLY ones. Most other obsolete chips will probably still be available but expensive.
FYI #1, it's unlikely that you will get a better price than from microchip itself. There is no obsolete PIC, you just need to order one reel if it's something that's not officially in stock.
FYI #2, we still have products going strong after 20 years. the only thing we replaced over time was the PIC, nothing else. The pic was replaced with a pin-to-pin compatible, suggested upgrade mostly because they want you to use new stuff by pumping up the price of the old stuff, and up until very recently it was just a matter of selecting a new chip, correct the configuration bits, recompile, program, test. (More recently with the new interrupt controller it required the rewrite of the ISR but no biggie)
FYI #3, given your apparently big experience you should know that some certification processes are so expensive and require so much time to test that you'd much rather use the old pre-approved part and firmware. (But of course you know it, i'm just pointing this out for the new guys who don't)
back to :popcorn:
-
Why are you using Arduino? It's for kids, it's bloated, it's badly designed, etc.
Well, I do not use Arduino, but if I did, it would be because Massimo Banzi was so funny when he said that "Arduino gives you so much restless power under your fingertips that you can even (potentially?) make your own interface for spaceships".
A few radio telescopes have recorded some activity from Proxima Centauri, it might be intelligent life there, organic or inorganic (IA? surviving the organic life extinction?), so I have always dreamed to reach that place on a homemade rocket.
(sorry, my humor) ;D
-
oh ... were you fantasizing about some other kind of "stock" ?
Well you're obviously very intent on emphasizing the benefits of the latest and greatest STM devices and also obviously intent on causing a stir.
"Well you're obviously very intent on emphasizing the benefits of the latest and greatest STM devices"
Has this become a crime in the last 5 minutes ? Do you have the statutes and regulations handy to paste here for all to see ?
"and also obviously intent on causing a stir."
No, I'm not after your job, so relax.
-
I personally think that the Arduino+AVR crowd are missing out of they stick with the original H/W, and would be better served moving to Micropython on a 32-bit platform with an IDE like uPyCraft for the low barrier to entry embedded platform
Yup, I remember that someone told Banzi something similar years ago when Arduino2 was announced and someone was thinking about putting ucPython in a pocket calculator (now it's a commercial product), and Massimo replied something like "no! because I do know how to run my business and how to teach people, and the Wiring/C++ is the only way".
-
ucPython, or eLUA, anyway.
-
Yes, of course Arduino is a sect... so what?
My STM stock is doing pretty good, thank. Up about 141% since I bought it 4 years ago, not counting the “more than my bank pays me” dividends...
MCHP has done a bit better, but I got scared recently and sold off 75% of my holdings. (Still ambiguous as to whether that was a good idea.)
I wish I could invest in Adafruit. They’re closest to doing “the right stuff” for the hobbyist and similar users..., Imo.
-
No no no!
Your competitors want you to keep on using obsolete MCU's in your products, they love you just as you are and would hate you to change a single thing!
Obsolete as in probably the few parts that will still be available in two decades due to them being ubiquitous and sold in huge numbers to a very distributed crowd?
An interesting question but sadly I can't predict the future, however I have a clear memory of the past and I can look there for trends.
20 years ago in 1999 I was selling small quantities of a specialist industrial sensor (my own design) which used a PIC chip. Utterly reliable, some of my original units are still in use today. I used C back then and I'm still 100% happy with PIC reliability.
The price of that PIC MCU, which is still available today is USD 5.50 from Alibaba, however my current MCU of choice the STM32F051 was $0.56 USD each in 2014.
If my old PIC could speak, it would worship the STM32F051 like it was a GOD.
This is in line with my observations of old and obsolete chips, the mfr keeps the line going for replacement parts but the cost keeps going up and up.
So I'm agreeing with you that obsolete parts will still be available in 20 years, but your's won't be the ONLY ones. Most other obsolete chips will probably still be available but expensive.
FYI #1, it's unlikely that you will get a better price than from microchip itself. There is no obsolete PIC, you just need to order one reel if it's something that's not officially in stock.
FYI #2, we still have products going strong after 20 years. the only thing we replaced over time was the PIC, nothing else. The pic was replaced with a pin-to-pin compatible, suggested upgrade mostly because they want you to use new stuff by pumping up the price of the old stuff, and up until very recently it was just a matter of selecting a new chip, correct the configuration bits, recompile, program, test. (More recently with the new interrupt controller it required the rewrite of the ISR but no biggie)
FYI #3, given your apparently big experience you should know that some certification processes are so expensive and require so much time to test that you'd much rather use the old pre-approved part and firmware. (But of course you know it, i'm just pointing this out for the new guys who don't)
back to :popcorn:
#1, we can't possibly know all the MCU pricing deals in my opinion.
#2, I can't argue there and 20 years is a long time. I have stated my faith in PIC reliability above.
#3, Was that sarcasm :) I personally know the agony of producing products daily by the thousands, month after month, that badly needed design improvement to increase yield by reducing rework but which could not be altered because ... CE certification.
Watch those calories :)
-
(https://cdn-blog.adafruit.com/uploads/2018/12/casio_fx-cg50_PRIZM_calculator.jpg)
(https://cdn-blog.adafruit.com/uploads/2018/12/casio_fx-cg50_PRIZM_calculator_img.jpg)
(https://cdn-blog.adafruit.com/uploads/2018/02/IMG_0393-1.jpg)
(https://cdn-blog.adafruit.com/uploads/2018/02/IMG_0394-1.jpg)
Firstly appeared on NumWorks (https://blog.adafruit.com/2018/02/14/numworks-a-python-calculator-numworks-micropython/), a Python calculator
Python snakes its way to the CASIO (https://blog.adafruit.com/2018/12/06/python-snakes-its-way-to-the-casio-graphing-fx-cg50-prizm-calculator-casioeducate-casiojapan-micropython-micropython/) Graphing fx-CG50 PRIZM
-
Well this thread is a rollercoaster :-DD
-
I personally think that the Arduino+AVR crowd are missing out of they stick with the original H/W, and would be better served moving to Micropython on a 32-bit platform with an IDE like uPyCraft for the low barrier to entry embedded platform
Yup, I remember that someone told Banzi something similar years ago when Arduino2 was announced and someone was thinking about putting ucPython in a pocket calculator (now it's a commercial product), and Massimo replied something like "no! because I do know how to run my business and how to teach people, and the Wiring/C++ is the only way".
-
ucPython, or eLUA, anyway.
I'm a Forth user but don't tell the Arduino users here please ;-)
Are you referring to the NumWorks Graphing Calculator ? Mecrisp-Stellaris Forth has a port for that. It doesn't implement the sleep modes and will flatten the battery after a day so use a power pack.
Flashing of Mecrisp-Stellaris to the numworks calculator:
dfu-util -i 0 -a 0 -s 0x08000000 -D mecrisp-stellaris-numworks-with-sources.bin
No need to disassemble your calculator, terminal is on USART6: PA11 = D- = TX. PA12 = D+ = RX.
Just cut an old USB cable and connect it to a USB-serial-brige with 115200 Baud 8N1.
I also reviewed both ucPython, and eLUA and they are both pretty slick projects, very nicely done I thought. They do require a LOT of Flash and RAM compared to Forth, and are about 300x slower. Forth itself seems about 3x slower than GCC compiled C in my tests.
-
I also reviewed both ucPython, and eLUA and they are both pretty slick projects, very nicely done I thought. They do require a LOT of Flash and RAM compared to Forth
Yup, they are for "big-MPUs", but this can make sense nowadays. For example, ucPython runs decently on the CASIO above, and it's more than useful on the Numworks calculator.
The CASIO-BASIC is cool (and has improved a lot since the first CASIO FX-7500), but ucPython is better :D
There was an interesting project with Forth: the GameDuino1. It's an Arduino-Shield (5V, it fits on Arduino-2009 boards) with a Xilinx FPGA (Spartan3/200-LE-something) on it performing a sort of graphical VDU with a VGA interface, and it's able to accept Forth-like statements via SPI.
The FPGA implements a stack machine (written in Verilog) which is somehow "Forth-modified" but still "Forth-compliant".
Potentially it's very powerful, but ... people have never appreciated it so much, in fact, the second generation, the GameDuino2 is completely different.
-
I also reviewed both ucPython, and eLUA and they are both pretty slick projects, very nicely done I thought. They do require a LOT of Flash and RAM compared to Forth
Yup, they are for "big-MPUs", but this can make sense nowadays. For example, ucPython runs decently on the CASIO above, and it's more than useful on the Numworks calculator.
The CASIO-BASIC is cool (and has improved a lot since the first CASIO FX-7500), but ucPython is better :D
There was an interesting project with Forth: the GameDuino1. It's an Arduino-Shield (5V, it fits on Arduino-2009 boards) with a Xilinx FPGA (Spartan3/200-LE-something) on it performing a sort of graphical VDU with a VGA interface, and it's able to accept Forth-like statements via SPI.
The FPGA implements a stack machine (written in Verilog) which is somehow "Forth-modified" but still "Forth-compliant".
Potentially it's very powerful, but ... people have never appreciated it so much, in fact, the second generation, the GameDuino2 is completely different.
Yes, "big-MPUs" are everywhere now and very cheap, the embedded game is changing rapidly.
in 1975 when I had to build a 128 byte Fusible Link ROM burner I was amazed at this new mass storage.
In 1997 a PIC16C84 had 1KB Flash and 36 Bytes RAM and I thought I was in mass storage heaven!
In 2019 I can write a Forth Blinky on a Ti Tiva running Mecrisp-Across which will apart from emulating Forth on the 2KB Flash Tethered MSP430 Target via JTAG, compile a fully executable binary of 80 bytes and Flash it to the Target. So in 2019, even 2KB of Flash can seem like a lot.
Except in this case the Tethered Target appears to have 64KB Flash :)
https://mecrisp-across-folkdoc.sourceforge.io/index.html
My head is still spinning from your "It's an Arduino-Shield" ... line, some people make the most esoteric things with Forth and the rest of us wonder what and why.
-
Well this thread is a rollercoaster :-DD
More like a lazy trollercoaster. ;D
-
in 1975 when I had to build a 128 byte Fusible Link ROM burner I was amazed at this new mass storage.
You're two years before me on this, but I do remember a 256 byte OTP TTL fuse ROM costing about GBP50 in 1977, or about GBP300/USD370 a pop in today's money. It was the most expensive part of our design. We didn't have emulators, they cost about the same as a house. We grit our teeth and hoped we'd got the firmware right from hand-coded machine code.
-
Well this thread is a rollercoaster :-DD
More like a lazy trollercoaster. ;D
Hahahah :clap:
-
Why so many trolls here? Is Arduino a main framework for EE ? :-//
-
in 1975 when I had to build a 128 byte Fusible Link ROM burner I was amazed at this new mass storage.
You're two years before me on this, but I do remember a 256 byte OTP TTL fuse ROM costing about GBP50 in 1977, or about GBP300/USD370 a pop in today's money. It was the most expensive part of our design. We didn't have emulators, they cost about the same as a house. We grit our teeth and hoped we'd got the firmware right from hand-coded machine code.
Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.
I'm amazed you did that with Machine Code for fusible link ROMS ! I once designed, built and hand Machine Coded a dual 8085 industrial bottle filling machine but luckily I had 2716 Eproms by then. If I'd had to use fusible link ROMS I'd have blown my profits because of the zillions of mistakes I made while coding!
Jump +1 going up vs jump -1 going down, or is it the other way around ? ;-)
R&D is expensive anyway, I can only imagine the cost of the National Semi PACE Development System and its Assembler. I do recall the CPU was $270 AUD, not bad for a 16 bitter that ran at up to 2Mhz.
I've been told, (and haven't verified it yet) that the Chief Design Engineer wrote a Forth for that PACE which would have reduced his development stress by magnitudes I think simply in the cost of non programmable ROMS.
The other engineers told me at the time that it wasn't all that much earlier they had to solder diodes in matrices to make their own small ROMS before fusible link roms came along
-
Dang and I though waiting 30 minutes for a UV box was painful :-DD
-
I have bought a STM32 board that is arduino compatible for 20 euro.
It made me also agressive : the pin layout wont fit a breadboard or experiment board, it is not in the exact 2,54mm offset.
Anyone buy it from me for 10 ?
-
Dang and I though waiting 30 minutes for a UV box was painful :-DD
It was, but at least you *usually* got a nice erased Eprom back :)
I once made up a 48 gang 2732 eprom programmer. All the Eproms were in parallel and it was in continuous daily use.
Occasionally you could tell that someone had put a fresh Eprom in upside down by the scream of the tech collecting the latest batch of programmed units as he flipped them from the Ziff socket into his hand!
Of course that meant that the remaining 47 good ones had to go into the UV eraser ...
-
Why so many trolls here? Is Arduino a main framework for EE ? :-//
Well, why are you here?
-
I want enjoyment, not labor.
One man's enjoyment is other man's labour. It's your hobby. You're enjoy doing something for free while other people may be forced to do the same things for living. Such people may hate the very same thing you enjoy.
-
Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.
The ROMS we used at that time were thankfully bipolar single voltage 5V jobs. The processor and its support chips, being PMOS, needed +5V and -12V, and supposedly needed sequencing, not that I remember particularly trying very hard to do so. I do remember the PMOS 1702(A), and particularly the early 27xx NMOS EPROMS, needing some challenging supplies.
Possibly one of the best learning experiences I ever had of that era was using a CRO to debug programs by probing the address and data buses, one signal at a time, with a pencil and paper. You had to be pretty inventive with your triggering, particularly if you didn't have a delayed timebase feature. And with no storage feature on the scope, you had to be pretty inventive at repetitively reproducing your signals.
It's not all that long ago, it wasn't unusual to do things in our heads that we all take for granted now, like serial decodes.
I feel that having to do things the hard way sometimes gives you a better grounding for understanding the higher level stuff, in that you're not just taking things for granted, you aren't afraid to question and consider possible aberrations under the hood.
The Arduino ecosystem is both admirable and successful in its abstractions, protecting and hiding from the programmer a lot of this lower level nastiness, and it's to be applauded for that.
All too often we all give up on projects because we don't have the bandwidth to be able to deal with all of the details, many of which you won't be aware of until you actually get going on a project. However at some point, it is almost inevitable that you'll need to dig into the abstractions when they don't work the way you expect, or the way you want them to.
-
:popcorn:
- Just a quick break. I don't know about Arduino users being specifically agressive, but debates about the Arduino ecosystem seem to always be pretty heated. It's a bit like debates about using C in embedded development. Many people from either side seem to have a hard time keeping calm while discussing those topics, so they may pass as agressive. ;D -
There are both good reasons and bad reasons to use any kind of tool really, including using Arduino. So whatever you choose, try and make sure you do for mostly good reasons and not bad ones.
I personally find no use for Arduino for the following reasons:
- It would limit me to the supported MCUs only. I don't want to be limited.
- It's a bit the same as when people were using MFC to develop Windows applications. All they were interested in really were the libraries and the hand-holding, even when the tools were just meh. When or if they had to develop apps without MFC (either on Windows or other platforms), they suddenly realized they were completely lost. Those "frameworks" tend to lock you in.
- A corollary of that idea is whatever you personally think is worth investing your time in. Even if Arduino is relatively simple, you still need to invest significant time to be able to do anything useful with it (beyond blinking LEDs). Is that time investment worth it compared to investing it learning to use other tools and approaches? Your call.
- I've noticed that experienced engineers using Arduino often do that for quick prototyping. Again you have to ponder whether this is a wise investment of your time. It 100% depends on your requirements, skills, habits, available tools, whether this is a one-off thing or whether you want it to be reusable, etc. I personally have accumulated enough tools and reusable code over the years that quickly prototyping something on one of the numerous dev boards I have around is pretty quick, so I see no need for anything else. Of course your own situation may be completely different.
- Outside of purely prototyping stuff, I personally use practically NO third-party library whatsoever when developing on MCUs, and as few as possible for embedded development in general. So using some ecosystem the main interest of which are the available libraries makes no sense to me. *My* call, not a general truth.
-
Why would it limit you to supported MCUs? Arduinos are not the only platform I use, they are just the one I tend to reach for when I want to do a quick prototype or work with some specific bit of hardware that has a library. I don't have to limit myself to only one platform.
-
Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does.
Please explain why a $0.45 STM32L053 needs $5 in driver chips and a $5 (Arduino) MCU board does not ? Try and be specific, I'm sure most on this forum will be able to follow you.
Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will.
Check the AR448 thread where some fool is trying to port the code to an STMF103 and now thinks he has broken his 34401A GPIB port. Possible I'm sure, but highly unlikely if he's been applying 3.6 V or less.
I'm building a calibration system to automate annual calibrations of my gear. I'm using ATMEGA2560 R3s because they are cheap and do the job. I'll use 3-4 as I have lots of relays to drive besides driving the GPIB bus. At a minimum I'll have two ST6P Radiall 28 V SMA relays controlled by twelve 5 V relays for RF switching and 40 5 V relays for DC, low frequency AC and resistance switching. I will *not* be using the Arduino IDE. Just a plain Makefile. And won't use the Arduino libraries either as I despise C++.
Most of the skilled trades use hammers specially made for the trade. Blacksmiths generally only use a few hammers, but they do use a lot of tongs which they make as needed.
-
It's a hobby, component costs are irrelevant. Labor is the deciding factor.
If it's a hobby then labour is supposedly what you want.
I want the end result not the path. As long as I get it done, and it works, I don't award points for minimum parts count. Unless I run out of board space. Then I might reconsider...
A couple of replies earlier on the writer was expounding on the increase in capability of the more modern chips as opposed to the older ATmega328. Absolutely they are more capable. They clearly have more peripherals and they are a LOT more complex and difficult to apply.
I like the STM32F chips and especially on the factory Nucleo or Discovery boards. The fact that many of these boards are 'mbed compatible' means I don't have to install a dedicated toolchain. I also like the ARM LPC21xx series because I have spent a lot of time with them but if I need a bit of horsepower I'll go for the mbed LPC1768 (60 MHz). If I'm in a real hurry, I'll use my Blackfin board. It's pretty fast (600 MHz) with uClinux. I really like the old ATmega128 - it has a decent peripheral set and a large number of pins. I like the AVR architecture and absolutely hate the mid-range PICs. In fact, I REALLY like the AVR architecture.
I have played with the PSoC6 and its dual cores - it's a really interesting chip. If I just had an application for BLE, I know which chip I would use.
I also play with FPGAs. To the point that I have a working IBM1130 minicomputer that runs all of the factory software unchanged. Yes, I can still write Fortran IV and do interesting math kinds of things. And I can use the factory plotter library to come up with charts and graphs on my LaserJet compliments of an mbed LPC1768 converting the individual steps from the FPGA to HPGL sentences for the LaserJet. SPI in, TCP/IP out...
So, yes, I get around. But when I need to put on a quick 'show and tell' for my grandson, I reach for the Arduino. It's a fast way to prototype and it is easy for him to replicate. I like simple!
Want to study PID loops? Try "Temperature Control Lab". This little plug-on board uses an Arduino to interface between MATLAB or Python and a heater. Read that again! How powerful is it to be able to instrument an experiment with MATLAB? Talk about interactive! This is just the thing for that required "Control Systems" class.
http://apmonitor.com/pdc/index.php/Main/ArduinoTemperatureControl (http://apmonitor.com/pdc/index.php/Main/ArduinoTemperatureControl)
Arduino is just one tool in the box. It has pluses and minuses but no matter what you want to do, it has probably already been done with an Arduino and the project is on the Internet. Even my reflow oven is controlled by an Arduino...
-
An interesting citation from a different thread which 100% applies to the Arduino discussion:
Every culture on earth has good and bad and has done some good, some bad and some terrible things. But everybody seems to think their culture is special and better.
Having grown and lived in different cultures I get very tired of the ignorance about other cultures and the simplistic attacks. People who have lived and spent time in other cultures have much more nuanced views.
If there is one aspect of any culture that makes it bad it is to believe itself superior to others. That is bad and dangerous.
-
in 1975 when I had to build a 128 byte Fusible Link ROM burner I was amazed at this new mass storage.
You're two years before me on this, but I do remember a 256 byte OTP TTL fuse ROM costing about GBP50 in 1977, or about GBP300/USD370 a pop in today's money. It was the most expensive part of our design. We didn't have emulators, they cost about the same as a house. We grit our teeth and hoped we'd got the firmware right from hand-coded machine code.
Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.
On an earlier attempt to recreate the IBM1130 ('74?) I used these very devices to hold the microcode. I built a programmer of dubious quality. The 2102 RAM hadn't hit the hobby market so I had a CPU with no memory. I moved to the Altair 8800 and put the 1130 project aside for 30 years. FPGAs are the answer!
-
I've been told, (and haven't verified it yet) that the Chief Design Engineer wrote a Forth for that PACE which would have reduced his development stress by magnitudes I think simply in the cost of non programmable ROMS.
The other engineers told me at the time that it wasn't all that much earlier they had to solder diodes in matrices to make their own small ROMS before fusible link roms came along
I spent some time writing BIOS code in the early years of hard drives. Sometimes for S100 bus machines and sometimes for the Apple II. A bit later for the IBM PC. The fun project was using the Z80 adapter that Microsoft built for the Apple II.
https://en.wikipedia.org/wiki/Z-80_SoftCard
One day I visited the manufacturer of the SCSI interface boards I was using. ALL of their test programs were written in Forth simply because a new test could be implemented in a single statement. All the lower level code was already known to work. This pyramid approach to programming is quite powerful. Type in a single statement and an entirely different test sequence is performed. This wasn't a canned test, it was 'new' at the top level.
-
Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does.
Please explain why a $0.45 STM32L053 needs $5 in driver chips and a $5 (Arduino) MCU board does not ? Try and be specific, I'm sure most on this forum will be able to follow you.
Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will.
VIh min for TTL is only about 2V, 3.3V will the drive TTL just fine
-
Techman-001, you are 100% correct, except for one thing. You talk about learning from your past.
Yes, if you are educated and proficient with STM devices and dev tools and supply chain, I'm sure there is almost no reason to use any other microcontroller in a volume product. Today. The cost of these devices can be significantly cheaper, even, than other devices that are way inferior in most ways (other than maybe some electrical specifications in some cases).
But if you learn from your past, you know this is a temporary situation. In X years from now, STM32 is obsolete, too! Perhaps not even due to technological advancement. It might be some other whim of industry or business or some other butterfly effect.
Assuming (some) people will still want a simple way to interact with hardware in ways that don't need the latest cutting edge speeds and memory and floating point math, the Arduino platform may avoid this fate. Either the AVR from 1970 will not become obsolete, because Arduino community will continue to use it in enough volume that Microchip/Atmel will not phase it out. Or the community will adapt and incorporate better more modern microcontrollers to the Arduino platform in a way that the average user will not have to learn much to use the new greatest and latest Arduino Pikachu. (One day, maybe Arduino Techman is created, even... with an STM32 on the board?)
Arduino means you don't have to keep learning in order to do the same things you always did... and not get bent over when that part becomes obsolete and starts to cost 4-5x as much. You can use that hammer for a whole bunch of nails. And you can learn to use the latest greatest fancy biscuit jointer if and when you have to. After you do so, you might like it so much you make everything with it.. but one day it is also badly obsolete and overpriced unobtanium... When that happen, you might still have a trusty hammer, lying around, which is at least good enough to drive nails. And in the future, the latest Arduino has more speed and capabilities and less bugs than it has today, even. The Arduino platform is sustained and evolved by its user base. It is not chained to a particular micro. I kinda doubt it is ever going to deviate from AVR family, but who knows.
If you are a high school or university, do you get to take choose your classes to learn STM32 or modern AVR or modern PIC? Not usually. You would need to find the teachers that continually learn and teach the latest cuttest edge devices and completely change and update curriculum. They can offer classes using Arduino, because it's simpler and because you can bet it will still be relevant in 10-20 years.
-
... Or the community will adapt and incorporate better more modern microcontrollers to the Arduino platform in a way that the average user will not have to learn much to use the new greatest and latest Arduino Pikachu ...
You speak as if learning is something bad which needs to be avoided at all costs.
-
Oh yeah, they were super expensive and IIRC we did blow a few up as timing was critical among the 3 different voltages that had to be applied in sequence.
The ROMS we used at that time were thankfully bipolar single voltage 5V jobs. The processor and its support chips, being PMOS, needed +5V and -12V, and supposedly needed sequencing, not that I remember particularly trying very hard to do so. I do remember the PMOS 1702(A), and particularly the early 27xx NMOS EPROMS, needing some challenging supplies.
Possibly one of the best learning experiences I ever had of that era was using a CRO to debug programs by probing the address and data buses, one signal at a time, with a pencil and paper. You had to be pretty inventive with your triggering, particularly if you didn't have a delayed timebase feature. And with no storage feature on the scope, you had to be pretty inventive at repetitively reproducing your signals.
It's not all that long ago, it wasn't unusual to do things in our heads that we all take for granted now, like serial decodes.
I feel that having to do things the hard way sometimes gives you a better grounding for understanding the higher level stuff, in that you're not just taking things for granted, you aren't afraid to question and consider possible aberrations under the hood.
The Arduino ecosystem is both admirable and successful in its abstractions, protecting and hiding from the programmer a lot of this lower level nastiness, and it's to be applauded for that.
All too often we all give up on projects because we don't have the bandwidth to be able to deal with all of the details, many of which you won't be aware of until you actually get going on a project. However at some point, it is almost inevitable that you'll need to dig into the abstractions when they don't work the way you expect, or the way you want them to.
Your trips down memory lane are very pleasant and bring back some great memories for me.
I'm not sure I agree with "The Arduino ecosystem is both admirable and successful in its abstractions, protecting and hiding from the programmer a lot of this lower level nastiness, and it's to be applauded for that." because my solid grounding in embedded comes from those old days, from the old ways we had to do things and countless hours behind a scope catching fleeting waveforms and NOT being protected from anything by anyone.
For the 8085 bottle filling project I mentioned earlier I used a Intel SDK8085 board with a 7 seg LED display and hex keypad to write the program.
All testing was done out of RAM, but I didn't have a relocatable program to move code between RAM and Eprom, and vice versa so I wired up a large rotary switch to move all the address and data lines between them.
One position to run from from RAM, one to run from Eprom, one to program the Eprom from Ram.
Worked like a charm :-+
-
I want enjoyment, not labor.
One man's enjoyment is other man's labour. It's your hobby. You're enjoy doing something for free while other people may be forced to do the same things for living. Such people may hate the very same thing you enjoy.
Wise words indeed!
Back in the old days of wire wrap I would have to wire up prototypes from a engineers schematics. It was ok, but not my favorite job because on a board with a thousand or so wraps I could never get 100% accuracy, there was always 2 or three mistakes. To me, wirewrapping was definitely "work".
We had a lady by the name of Joyce in the assembly department and Joyce loved wire wrapping, she also made zero errors board after board so we also loved Joyce's skills.
-
You speak as if learning is something bad which needs to be avoided at all costs.
If you knew how to use STM32, and you could buy them for 45 cents, wouldn't you like to use it in many of your projects? Even if the project uses 1% of the memory and peripherals and can do the job clocked down to 1/100th of the max oscillator frequency and sleeping 99% of the time, it still costs half as much as the 8 bit PIC, right? All you have to do is learn, so what's stopping you? (I know clock speed and processor word size is not the end-all be-all regarding response/latency, but just go with it)*.
You have your own reasons. Mine? By the time I learn it, STM32 might no longer be in production, and I and everyone I know, today, might be long dead. Hell might have frozen over. I'm not gonna lie and say it's because I have not had the need, yet. If I had the need, I'd be in trouble. I would be knocking on Techman's door to see if he was available for hire, and if he wouldn't mind being horribly underpaid.
*Assembly, for instance, is great when you need it, and it is actually fairly practical on an 8 bit PIC, IMO. And I mention this because I use assembly, and I get the impression you do, as well. By using assembly, you can actually do a lot of low latency multitasking and get a lot out of said device. But as the number of and length/complexity of opcodes of a device increases, actually harvesting the benefits of this device core through assembly programming becomes exponentially more complicated and cumbersome and time consuming and prone to bugs. When there are 16 different simulaneous operands for every opcode, it becomes very complicated. These new opcodes were intended to be useful to a compiler, from the start.
-
Writing embedded firmware from scratch can be enjoyable, but once it comes to implementing complex stuff like USB or Ethernet, using a library makes things a lot easier.
-
By the time I learn it, STM32 might no longer be in production, and I and everyone I know, today, might be long dead. Hell might have frozen over.
You don't learn peculiarities of different systems. You learn general principles. Then you apply them to a particular system. Of course, you often need to know some peculiarities, but you don't memorize them. If you need to figure something out, you just consult the datasheet. You may inadvertently memorize something (such as register names etc.) along the way, but you may forget these things rather quickly when you move between architectures. That's Ok. The important thing is that the general principles are always with you and you can apply them to any situation.
If you're lacking general principles, you may do some stupid things, such as reading the datasheet from the first page to the last as you would read "War and Piece" thinking that you're learning something. Such activity only clutters your mind with inconsequential, and makes it more difficult for you to come up with a viable solution.
Don't get upset if something becomes obsolete and unusable. Just move on.
-
:popcorn:
- Just a quick break. I don't know about Arduino users being specifically agressive, but debates about the Arduino ecosystem seem to always be pretty heated. It's a bit like debates about using C in embedded development. Many people from either side seem to have a hard time keeping calm while discussing those topics, so they may pass as agressive. ;D -
There are both good reasons and bad reasons to use any kind of tool really, including using Arduino. So whatever you choose, try and make sure you do for mostly good reasons and not bad ones.
I personally find no use for Arduino for the following reasons:
- It would limit me to the supported MCUs only. I don't want to be limited.
- It's a bit the same as when people were using MFC to develop Windows applications. All they were interested in really were the libraries and the hand-holding, even when the tools were just meh. When or if they had to develop apps without MFC (either on Windows or other platforms), they suddenly realized they were completely lost. Those "frameworks" tend to lock you in.
- A corollary of that idea is whatever you personally think is worth investing your time in. Even if Arduino is relatively simple, you still need to invest significant time to be able to do anything useful with it (beyond blinking LEDs). Is that time investment worth it compared to investing it learning to use other tools and approaches? Your call.
- I've noticed that experienced engineers using Arduino often do that for quick prototyping. Again you have to ponder whether this is a wise investment of your time. It 100% depends on your requirements, skills, habits, available tools, whether this is a one-off thing or whether you want it to be reusable, etc. I personally have accumulated enough tools and reusable code over the years that quickly prototyping something on one of the numerous dev boards I have around is pretty quick, so I see no need for anything else. Of course your own situation may be completely different.
- Outside of purely prototyping stuff, I personally use practically NO third-party library whatsoever when developing on MCUs, and as few as possible for embedded development in general. So using some ecosystem the main interest of which are the available libraries makes no sense to me. *My* call, not a general truth.
I usually disagree with a lot of your comments but after reading this well thought out post, I can't remember why :-+
-
Don't get upset if something becomes obsolete and unusable. Just move on.
I notice you did not answer the question.
There's a cheaper and potentially faster solution out there, and you're not using it. And you're in good company.
-
Techman-001, you are 100% correct, except for one thing. You talk about learning from your past.
Yes, if you are educated and proficient with STM devices and dev tools and supply chain, I'm sure there is almost no reason to use any other microcontroller in a volume product. Today. The cost of these devices can be significantly cheaper, even, than other devices that are way inferior in most ways (other than maybe some electrical specifications in some cases).
But if you learn from your past, you know this is a temporary situation. In X years from now, STM32 is obsolete, too! Perhaps not even due to technological advancement. It might be some other whim of industry or business or some other butterfly effect.
Assuming (some) people will still want a simple way to interact with hardware in ways that don't need the latest cutting edge speeds and memory and floating point math, the Arduino platform may avoid this fate. Either the AVR from 1970 will not become obsolete, because Arduino community will continue to use it in enough volume that Microchip/Atmel will not phase it out. Or the community will adapt and incorporate better more modern microcontrollers to the Arduino platform in a way that the average user will not have to learn much to use the new greatest and latest Arduino Pikachu. (One day, maybe Arduino Techman is created, even... with an STM32 on the board?)
Arduino means you don't have to keep learning in order to do the same things you always did... and not get bent over when that part becomes obsolete and starts to cost 4-5x as much. You can use that hammer for a whole bunch of nails. And you can learn to use the latest greatest fancy biscuit jointer if and when you have to. After you do so, you might like it so much you make everything with it.. but one day it is also badly obsolete and overpriced unobtanium... When that happen, you might still have a trusty hammer, lying around, which is at least good enough to drive nails. And in the future, the latest Arduino has more speed and capabilities and less bugs than it has today, even. The Arduino platform is sustained and evolved by its user base. It is not chained to a particular micro. I kinda doubt it is ever going to deviate from AVR family, but who knows.
If you are a high school or university, do you get to take choose your classes to learn STM32 or modern AVR or modern PIC? Not usually. You would need to find the teachers that continually learn and teach the latest cuttest edge devices and completely change and update curriculum. They can offer classes using Arduino, because it's simpler and because you can bet it will still be relevant in 10-20 years.
All excellent points and very well put, but I'm confused about one thing, why would anyone think that Microchip/Avr is any different or has any advantages compared to any other MCU manufacturer such as STM in terms of long term variability?
I doubt that STM will be going away anytime soon because their semiconductor portfolio is MASSIVE.
STM have been supplying power electronics, regulators, triacs, FETS etc for the last 30 years, they are a BEHEMOTH of a company.
Sure, chips will change and eventually these companies will be bought, sold, have name changes and maybe even fade away altogether ... that's life.
I remember being in awe of the Motorola 6800 and it was everywhere, I loved the ISA, to me it was smooth as silk ... but where is the 6800 today compared to ARM or PIC?
Every chip has it's day but the designer who is able to change and adapt will thrive, and ones fixated on a particular product usually fade away.
For me, here and now today, it's STM32, MSP340 and PIC (I have 200 off 18x and 24x PIC types in stock) for my MCU use. Between them they do all I need, and they all run Forth.
-
Writing embedded firmware from scratch can be enjoyable, but once it comes to implementing complex stuff like USB or Ethernet, using a library makes things a lot easier.
Agreed, but sometimes there is no library or driver and you need to write one yourself.
Matthias Koch and Bernd Paysan wrote a Forth Ethernet library for the Ti Tiva Connected Launchpad and it's smooth as silk, they use the board LEDS as connectivity indicators etc.
The biggest hardship they had was working thru the many errors in the Ti datasheet.
-
why would anyone think that Microchip/Avr is any different or has any advantages compared to any other MCU manufacturer such as STM in terms of long term variability?
I agree. I don't know which one will be around longer. I assume they will all change. Today's STM32 will be tomorrow's Z80. Today's modern PIC will be the same.
In many cases, the only reason to not use the latest and greatest - when it actually can do the job at least as well if not better, and it actually is cheaper - is because of the learning curve. To a hobbyist, I suppose that just means more fun.
I am using modern 8 bit PICs, because they still do what I need. And it was easier to get here from where I started. I initially learned to use the basic and midrange, then went on to the first gen enhanced midrange, and now I am transitioning to the most modern enhanced midrange. The first jumps were for additional abilities and features, and the changes were minimal. The latest migration is 100% for availability and cost. I'm driving the same nails I ever was, but my hammer has become too expensive and unreliable to source. This latest migration involves learning a new IDE, which is a necessary evil. I wouldn't do it if I didn't need to. And if I knew how to use an even better and cheaper hammer, I would just go out and get that. One of the biggest reasons for me to stay with PIC is because the transition is easier. Code portability is another reason, due to ongoing project in production. And pin-for-pin compatibility is nice but not that big a deal. Really, the main reason is the whole learning thing.
-
why would anyone think that Microchip/Avr is any different or has any advantages compared to any other MCU manufacturer such as STM in terms of long term variability?
I agree. I don't know which one will be around longer. I assume they will all change. Today's STM32 will be tomorrow's Z80. Today's modern PIC will be the same.
In many cases, the only reason to not use the latest and greatest - when it actually can do the job at least as well if not better, and it actually is cheaper - is because of the learning curve. To a hobbyist, I suppose that just means more fun.
"Today's STM32 will be tomorrow's Z80" ... That's a epic quote because the Z80 slammed into industry's R&D departments like Orman's cannon slammed into the walls of Constantinople in 1453.
The Z80 reps dropped off beautifully written, free databooks and brochures and suddenly the Z80 was everywhere with STATIC registers that allowed the CLOCK to be slowed down and even stopped without data loss !
It was "Shock and Awe" and I was dazed and amazed. I later designed and made thousands of a small Z80 powered device that was coded with assembly on a TRS-80.
While nothing will replace the smooth as silk, orthogonal ISA of the 6800 for me, the legendary status of the Z80 is written in history, well at least my history.
I remember reading the Z80 databook in 1977 and thinking 'how can I possibly understand and use all these registers properly ?' and while the STM32F had a similar effect on me in 2014, good data books, ready product availability, constant coding and projects always reduce the new and unknown to the hundrum, at least for me.
I'm not afraid of the STM32 becoming unavailable, I'm afraid of becoming BORED with it :=\
Finally, I'm not a hobbyist, I've worked as a electronics technician all my life, mostly in R&D assisting engineers and I've loved every single day. I've worked for engineers with zest, passion and foresight who loved what they did and inspired me. We all showed up at work at 7am and left at 10pm every day because the projects were our lives, nothing else mattered.
Some people work to live, I've always lived to work (in electronics).
And finally, to anyone reading this far. If electronics seems like work to you, and you hate the journey looking only to the destination every day .....
---------------------- YOU'RE IN THE WRONG PROFESSION, DO SOMETHING ELSE THAT EXCITES AND AMAZES YOU ! ----------------------
-
Unfortunately, it doesn't matter what I do for a living. If I was a professional athlete, I would not enjoy playing the game. If I was a professional skydiver, jumping out of planes would be a chore.
I'd much rather be earning money off interest.
Now, I do like to make things. I'm just not on the cutting edge of technology. Lots of other people are using variety of microcontrollers that are not the best tool for the job. People use stuff other than STM32. They might say "I get a kick out of pushing a small chip to its limits." That just means they're too lazy to change. I'm just being more honest, and I admit it.
If you were using the most efficient and cheapest micro for every job, you would also have to learn to use 3 cent chinese microcontrollers. We all make tradeoffs with our time and effort.
-
Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does.
Please explain why a $0.45 STM32L053 needs $5 in driver chips and a $5 (Arduino) MCU board does not ? Try and be specific, I'm sure most on this forum will be able to follow you.
Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will.
Thank you for your example above regarding the STM32 which langwadt has already shown in this thread to be fallacious.
However one example you do illustrate clearly is that Arduino users by their very nature are not qualified to make such claims and should leave these things to engineers who actually know what they're saying.
Arduino, (in my opinion) because it draws Lay persons into its ranks like a moth to a flame, is responsible for generating the most ridiculous claims, passed on from one ignorant user to the next. This is perfectly understandable and although it may sound like I'm berating Arduino users, I'm not. Those that make these claims simply don't know any better.
And yours is a typical example.
Ignorant people read this stuff on the Internet and they think it's true so they pass it on.
AVR isn't special, it isn't blessed, angels didn't bring it to Earth in a silver chalice ... it's just another Microprocessor, another old microprocessor.
-
Unfortunately, it doesn't matter what I do for a living. If I was a professional athlete, I would not enjoy playing the game. If I was a professional skydiver, jumping out of planes would be a chore.
I'd much rather be earning money off interest.
Now, I do like to make things. I'm just not on the cutting edge of technology. Lots of other people are using variety of microcontrollers that are not the best tool for the job. People use stuff other than STM32.
If you were using the most efficient and cheapest micro for every job, you would also have to learn to use 3 cent chinese microcontrollers.
Um ... I gotta disagree with you here about every profession being a chore to everyone in it and I'm genuinely sorry for anyone who feels that way.
Without wonder and insight, acting is just a business. With it, it becomes creation.
- Bette Davis
Of course people use stuff other than the STM32, ... they also use STM8 ;-)
Seriously tho, I hope you didn't miss my posts where I mention I currently use and like STM32F and STM32L, MSP430, PIC18 and PIC24 chips ?
I did look at the 3 cent chinese microcontrollers, then I cleaned up the small spot of my vomit on the workshop floor and researched something else more interesting and useful.
-
Um ... I gotta disagree with you here about every profession being a chore to everyone
Never did I suggest that.
I'm genuinely sorry for anyone who feels that way.
Thanks. I wish I could be a happier slave.
Arduino, (in my opinion) because it draws Lay persons into its ranks like a moth to a flame, is responsible for generating the most ridiculous claims, passed on from one ignorant user to the next. This is perfectly understandable and although it may sound like I'm berating Arduino users, I'm not. Those that make these claims simply don't know any better.
And yours is a typical example.
I dunno if it matters, but, FWIW, I have never used an Arduino in my life. But I can appreciate what it does for those who it's catered to.
-
We all showed up at work at 7am and left at 10pm every day because the projects were our lives, nothing else mattered.
I'd rather suicide than live a life without something interesting besides electronics :horse: |O
Live to work is so wrong from so many perspectives.... :palm:
-
Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will.
Thank you for your example above regarding the STM32 which langwadt has already shown in this thread to be fallacious.
You did not explain for those ignorant - how can STM32L053 drive 5V logic bus w/o level converter.
-
Um ... I gotta disagree with you here about every profession being a chore to everyone
Never did I suggest that.
I'm genuinely sorry for anyone who feels that way.
Thanks. I wish I could be a happier slave.
Arduino, (in my opinion) because it draws Lay persons into its ranks like a moth to a flame, is responsible for generating the most ridiculous claims, passed on from one ignorant user to the next. This is perfectly understandable and although it may sound like I'm berating Arduino users, I'm not. Those that make these claims simply don't know any better.
And yours is a typical example.
I dunno if it matters, but, FWIW, I have never used an Arduino in my life. But I can appreciate what it does for those who it's catered to.
Ooops, my BAD, so you didn't. Apologies. You were only describing your own attitude on the matter.
Various employers thought they could make a slave out of me at various times. I left on the spot, walked right out and into a better job. Somehow I survived to this decrepit old age :)
My Arduino quote was directed solely at RHB, not at you.
I have a Arduino kit, I bought 6 for my children. None of them do electronics, none of them will ever read this forum. Arduino is perfect for them.
None of them have ever used the Arduino kits I sent them.
I have never used mine in any project, but I remember being blown away at HOW EASY it was to blink a LED with Arduino.
I plugged the small Arduino PCB into my Linux box, installed the Linux Arduino package, selected the BLINKY sketch and clicked the upload.
The Arduino LED started blinking and I had NO CLUE what had just happened, but it was very impressive. I put the box away in my collection of curios and went back to designing embedded electronics from the bare metal upwards.
-
Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will.
Thank you for your example above regarding the STM32 which langwadt has already shown in this thread to be fallacious.
You did not explain for those ignorant - how can STM32L053 drive 5V logic bus w/o level converter.
Were you born lazy or is your browser scroll button simply broken ?
Scroll down to where langwadt explains why.
-
We all showed up at work at 7am and left at 10pm every day because the projects were our lives, nothing else mattered.
I'd rather suicide than live a life without something interesting besides electronics :horse: |O
Live to work is so wrong from so many perspectives.... :palm:
You think ....
It's people like you that DIDN'T get the USA to a manned Moon landing in 11 years and who DIDN'T make working, self landing, reusable first stage rocket boosters.
Yesterday belongs to you and your ilk, and if you think my enthusiasm is limited solely to electronics then you're as unimaginative as you are mundane.
-
Various employers thought they could make a slave out of me at various times. I left on the spot, walked right out and into a better job. Somehow I survived to this decrepit old age :)
Heh. I have a pretty good thing going. I have been my own boss in my own business for over a decade. I work how I want, when I want. I get to solve unique problems, regularly, and I take pride in my work. Most importantly, I use a large variety of skills and never have to do the same thing for an extended period. This is pretty much as good as I can imagine, short of winning the lottery.
But I'm a slave to a mortgage. I'm a slave to building a retirement. I'm a slave to my health insurance. I was born a slave. Most of us were. We don't wear physical chains, anymore, and we have a great illusion of freedom. But it is what it is. 95% of us are slaves. Money doesn't motivate me; but I need to make it.
I have a Arduino kit, I bought 6 for my children. None of them do electronics, none of them will ever read this forum. Arduino is perfect for them.
My brother has suggested I teach my nephew what I do. I'm reluctant for a couple reasons, but one is because I'm obsolete. I was obsolete when I started, and I didn't gain any ground in the meantime. Arduino is a much better idea for him, IMO.
-
Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will.
Thank you for your example above regarding the STM32 which langwadt has already shown in this thread to be fallacious.
You did not explain for those ignorant - how can STM32L053 drive 5V logic bus w/o level converter.
Were you born lazy or is your browser scroll button simply broken ?
Please keep it professional.
Scroll down to where langwadt explains why.
So you agree to claim that (3.3V) STM32L053 can be directly connected to 5V GBIP bus? That is not even fallacy, that is outright wrong. Hint: GPIB is multi-master bidirectional bus.
-
Live to work is so wrong from so many perspectives.... :palm:
Some/few people may dedicate their whole life to their job and is OK as long as they are happy with it. Doing job you hate - that is so wrong.
-
Various employers thought they could make a slave out of me at various times. I left on the spot, walked right out and into a better job. Somehow I survived to this decrepit old age :)
Heh. I have a pretty good thing going. I have been my own boss in my own business for over a decade. I work how I want, when I want. I get to solve unique problems, regularly, and I take pride in my work. Most importantly, I use a large variety of skills and never have to do the same thing for an extended period. This is pretty much as good as I can imagine, short of winning the lottery.
But I'm a slave to a mortgage. I'm a slave to building a retirement. I'm a slave to my health insurance. I was born a slave. Most of us were. We don't wear physical chains, anymore, and we have a great illusion of freedom. But it is what it is. 95% of us are slaves.
I have a Arduino kit, I bought 6 for my children. None of them do electronics, none of them will ever read this forum. Arduino is perfect for them.
My brother has suggested I teach my nephew what I do. I'm reluctant for a couple reasons, but one is because I'm obsolete. I was obsolete when I started, and I didn't gain any ground in the meantime. Arduino is a much better idea for him, IMO.
I've also worked for myself the last 15 years, I found the perfect employer in the end, one who really understood me ;-)
If I had your outlook, I'd say "I'm a slave to oxygen, if I can't get enough I'll die" or "I'm a slave to water" or "I'm a slave to gravity" . I just don't bother with any of these thoughts.
No man is a island, we all depend on each other in a interlocking maze of webs. Your wisdom and life experience could be very helpful for your nephew, please pass it on before you are lost to the dust of history and to him. If he is intelligent he will relish and benefit from the opportunity. Your brother obviously feels the same way.
Personally I only have the occasional problem with Arduino users, not with people who have used Arduino. I used a Arduino once, it didn't stunt my growth or make the milk curdle.
P.S. If you ever have any STM32 questions at the basic hardware stage and thought I could help, I'd be pleased to do so gratis. Don't hesitate to PM me on this subject. Conditions: no HLL language related questions except Forth, and please understand I may not have a answer or solution.
-
Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will.
Thank you for your example above regarding the STM32 which langwadt has already shown in this thread to be fallacious.
You did not explain for those ignorant - how can STM32L053 drive 5V logic bus w/o level converter.
Were you born lazy or is your browser scroll button simply broken ?
Please keep it professional.
Scroll down to where langwadt explains why.
So you agree to claim that (3.3V) STM32L053 can be directly connected to 5V GBIP bus? That is not even fallacy, that is outright wrong. Hint: GPIB is multi-master bidirectional bus.
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
If I want a hint, I'll phone the Psychic Friends Network not you.
Please take your 'professional' trolling elsewhere or learn to actually put some effort into your followups.
-
BMK?
Not a an English language acronym.
In fact, not an acronym at all.
It's the short version of bimbominkia, an Italian neologism formed adjoining the word for little child "bimbo", and one of the many (vulgar) words for male genitalia "minchia" (with a k instead of ch, a vice many youngsters affect in their electronic communications).
A "Dickchild" is a petulant ignoramus, incapable of understanding any concept that goes further from their immediate gratification, with high feelings of entitlement.
In general, their language skill skill are abominable, in whatever language they try to express themselves.
Hey, there's even an urban dictionary (https://www.urbandictionary.com/define.php?term=Bimbominkia) entry for it, even if it does not convey the full meaning.
Though usually referred to a male young person, I've seen examples of all ages, sex, and political orientation.
-
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
If I want a hint, I'll phone the Psychic Friends Network not you.
Please take your 'professional' trolling elsewhere or learn to actually put some effort into your followups.
You claim STM32 is a functional substitute. The onus is on you to provide evidence. Pointing at messages of other people requires including a link to said message as the onus is still on you. Without the provided evidence the claim is to be considered unproven.
-
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
@langwadt missed to mention 5V-tolerant I/O as precondition. Perhaps Arduino users are ignorant, but seems like stm32 users are arrogant :D
-
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
If I want a hint, I'll phone the Psychic Friends Network not you.
Please take your 'professional' trolling elsewhere or learn to actually put some effort into your followups.
You claim STM32 is a functional substitute. The onus is on you to provide evidence. Pointing at messages of other people requires including a link to said message as the onus is still on you. Without the provided evidence the claim is to be considered unproven.
You're yet another troll unable to follow a thread, or who has a broken browser down button.
:=\
-
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
@langwadt missed to mention 5V-tolerant I/O as precondition. Perhaps Arduino users are ignorant, but seems like stm32 users are arrogant :D
Personally I'll take arrogant over ignorant any day.
I'm still waiting for you to actually read this thread and comprehend it.
It's never going to happen is it ?
-
I'm still waiting for you to actually read this thread and comprehend it.
It's never going to happen is it ?
What are you talking about. Quote or pointer/link please.
-
I'm still waiting for you to actually read this thread and comprehend it.
It's never going to happen is it ?
What are you talking about. Quote or pointer/link please.
There you go, HTH.
https://www.webopedia.com/TERM/T/thread.html (https://www.webopedia.com/TERM/T/thread.html)
Thread
----------
In online discussions, a series of messages that have been posted as replies to each other. A single forum or conference typically contains many threads covering different subjects. By reading each message in a thread, one after the other, you can see how the discussion has evolved.
-
There you go, HTH.
https://www.webopedia.com/TERM/T/thread.html (https://www.webopedia.com/TERM/T/thread.html)
Thread
----------
In online discussions, a series of messages that have been posted as replies to each other. A single forum or conference typically contains many threads covering different subjects. By reading each message in a thread, one after the other, you can see how the discussion has evolved.
Thank you. It helps to simply state your source rather than to assume everyone has seen every single message so far. Including it is a minor effort as you already know where it is. Regardless of that are you claiming 3.3V and 5V logic is completely interchangeable without the need for logic level shifters ever?
-
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
@langwadt missed to mention 5V-tolerant I/O as precondition. Perhaps Arduino users are ignorant, but seems like stm32 users are arrogant :D
first page of STM32L053 datasheet: Up to 51 fast I/Os (45 I/Os 5V tolerant)
-
By reading each message in a thread, one after the other, you can see how the discussion has evolved.
Here we go, speaking of Trolls. :-DD
In this thread people talk about so many things. It is hard to guess what exactly you have in mind now. GPIB, moon landing or slavery?
@langwadt missed to mention 5V-tolerant I/O as precondition. Perhaps Arduino users are ignorant, but seems like stm32 users are arrogant :D
first page of STM32L053 datasheet: Up to 51 fast I/Os (45 I/Os 5V tolerant)
Bingo. Correct answer. Logic level compatibility alone is not enough for successful bidirectional signalling between 3.3V and 5V logic. You did mention *only* logic level.
-
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
@langwadt missed to mention 5V-tolerant I/O as precondition. Perhaps Arduino users are ignorant, but seems like stm32 users are arrogant :D
Personally I'll take arrogant over ignorant any day.
I'm still waiting for you to actually read this thread and comprehend it.
It's never going to happen is it ?
Why so aggressive? Are you trying to confirm the OPs statement, for a different subset of users? Also, you are wrong. :palm:
BTW, excellent trolling by the OP, well done Sir! One short clickbait post leads to 7 pages of blather :clap:
-
There you go, HTH.
https://www.webopedia.com/TERM/T/thread.html (https://www.webopedia.com/TERM/T/thread.html)
Thread
----------
In online discussions, a series of messages that have been posted as replies to each other. A single forum or conference typically contains many threads covering different subjects. By reading each message in a thread, one after the other, you can see how the discussion has evolved.
Thank you. It helps to simply state your source rather than to assume everyone has seen every single message so far. Including it is a minor effort as you already know where it is. Regardless of that are you claiming 3.3V and 5V logic is completely interchangeable without the need for logic level shifters ever?
You'd like me to do your reading for you "because it's easier" and a "minor effort" ?
Hold on a second while I laugh myself into apoplexy ...
If it's such a 'minor effort' perhaps even you could manage reading the entire thread yourself and you never know, it might prevent you from jumping to stupid conclusions and looking like a moron.
... or not.
-
It's up to you to support your claim that the STM32L053 can't be directly connected to 5V GBIP bus.
@langwadt missed to mention 5V-tolerant I/O as precondition. Perhaps Arduino users are ignorant, but seems like stm32 users are arrogant :D
Personally I'll take arrogant over ignorant any day.
I'm still waiting for you to actually read this thread and comprehend it.
It's never going to happen is it ?
Why so aggressive? Are you trying to confirm the OPs statement, for a different subset of users? Also, you are wrong. :palm:
BTW, excellent trolling by the OP, well done Sir! One short clickbait post leads to 7 pages of blather :clap:
One can't please everybody. You call me 'aggressive', other team members in Emergency Services used to tell me I'm wasn't aggressive enough ...
I like to think of myself as 'firm but friendly'.
You'll have to pardon me if I ignore your generic claim that I'm "wrong", because you also can't be bothered doing any actual work to substantiate it.
Started by a troll ? perhaps.
Nevertheless I'm enjoying this topic and if you're from the "international authority of electron wastage and inefficiency" please speak to someone else I'm just a visitor here.
-
You'd like me to do your reading for you "because it's easier" and a "minor effort" ?
Hold on a second while I laugh myself into apoplexy ...
If it's such a 'minor effort' perhaps even you could manage reading the entire thread yourself and you never know, it might prevent you from jumping to stupid conclusions and looking like a moron.
... or not.
In online discussions or even real life your supposed to provide evidence for the claims you make. That's what asked of you. It's also generally expected not to behave like an agressive grating troll.
-
In online discussions or even real life your supposed to provide evidence for the claims you make. That's what asked of you. It's also generally expected not to behave like an agressive grating troll.
Excellent tenets to live by !
Do you plan to start following them any time soon ?
-
Excellent tenets to live by !
Do you plan to start following them any time soon ?
Not quite the clever response I was hoping for but I was probably expecting too much. Start following them and you may even find an employer willing to suffer you again!
-
I notice you did not answer the question.
There's a cheaper and potentially faster solution out there, and you're not using it. And you're in good company.
I will use anything which best fit my requirements.
-
Well OPs theory was just misproven also non Arduino users can be verbally aggressive :-DD
-
If I had your outlook, I'd say "I'm a slave to oxygen, if I can't get enough I'll die" or "I'm a slave to water" or "I'm a slave to gravity" . I just don't bother with any of these thoughts.
You never know the value of water until the well is dry.
-
Well OPs theory was just misproven also non Arduino users can be verbally aggressive :-DD
Note that he never said otherwise. He said Arduino users were agressive. That didn't imply that non-users were not. You guys are hurting my logic. :popcorn:
-
Note that he never said otherwise. He said Arduino users were agressive. That didn't imply that non-users were not. You guys are hurting my logic. :popcorn:
It's hard to prove a negative but so far we've not seen much proof of it being correct.
-
Perhaps Arduino users are ignorant, but seems like stm32 users are arrogant :D
They both are arrogant (not all users, but some of them are). Hence the original point of this thread.
When you choose something based on popularity, you must convince yourself that what you have chosen is great. Hence, you simply must be arrogant.
When you choose things based on some sort of analysis, you don't have to prove anything. You can stay humble.
-
I will use anything which best fit my requirements.
This is something I have heard repeated many times. But it is not very practical. Most people will gravitate towards a tool that is already in the toolbox. If you are going to do the programming, yourself, you start with what you know. It is not like sorting through a list of specs and choosing the cheapest one that meets parameters, then buying it, designing the PCB, and then just figuring out how to program the micro as an afterthought. You might do that sort of search, but then you'll compare it to what you already know.
You also consider time/work to use it. Until you cross a certain threshhold of cost/inconvenience, you might continue using what you already have available, regarding knowledge. I use some PIC that cost more than STM32 (or TI device, or Renesas, or...) in volume, and where the cheaper device should work absolutely fine. I'm sure you do, too. You still avoid answering this question.
Some people are still hoarding logic chips, because that's what they know. Why don't they just use FPGA and/or microcontrollers? (Yeh, I know they can occasionally be quite handy when fixing or modifying stuff; so a raaco drawer filled with every variety can be useful, sure. Live and let live).
Microcontrollers are by their very nature a multitool. You don't need to use the exact best one for every use. You can drive a variety of different screws with any one of them.
I flatten an occasional board with a hand plane. It's not cuz I don't know jointers and power planers exist. It's not cuz I like the workout. It's because I don't do very much of this, and this is just one part of a much bigger process of "making stuff," which requires a lot of other tools and space. If I needed to do a lot of this task, I might buy a jointer and a power planer. AFTER acquiring these tools, even if I have just one board to flatten a year, I would do it the easy way. In the same way, Techman will probably use an STM32 for many things I would do with a PIC. If and when I ever learned how to use an STM32, I would do the same. You call it lazy, if you want. Everyone does it. You do too.
-
On another thread, the OP needs to generate some 400 Hz 3 phase signals. One way to do that is with a function generator chip like the AD9833. There is a possibility, yet to be confirmed, that these need to have 120 degree phase separation. And they need to be amplitude modulated but that's off topic here.
https://www.eevblog.com/forum/projects/trying-to-emulate-three-synchros-using-arduino/ (https://www.eevblog.com/forum/projects/trying-to-emulate-three-synchros-using-arduino/)
The AD9833 allows for setting the phase offset although I have no idea what it is in relation to. Nevertheless, it can be set.
What do you know, there is an Arduino Library for the device. I ordered a couple of demo boards and I probably won't need to write more than 50 lines of code to get both devices running at 400 Hz with the appropriate phase shift. Read that again! I don't have to write a bunch of low level library code. It's already done!
https://github.com/Billwilliams1952/AD9833-Library-Arduino/tree/master/examples (https://github.com/Billwilliams1952/AD9833-Library-Arduino/tree/master/examples)
There's 363 lines of low level code I don't have to figure out. Not that I can't but it's nice that I don't have to!
And there are a couple of examples...
Here are the demo boards, I bought the last two but there are others...
https://www.amazon.com/gp/product/B076LF3LFC/ref=ppx_od_dt_b_asin_title_s00 (https://www.amazon.com/gp/product/B076LF3LFC/ref=ppx_od_dt_b_asin_title_s00)
So why bother with somebody else's project? Well, I do a bit of analog computing and it might be nice to have an adjustable sin()/cos() generator. Maybe it would be nice to have adjustable phase (relative to what?) and I already have analog multipliers for scaling. It has nothing to do with servos but the device might just be fun to play with.
And the vast majority of the code is already done!
-
On another thread, the OP needs to generate some 400 Hz 3 phase signals. One way to do that is with a function generator chip like the AD9833. There is a possibility, yet to be confirmed, that these need to have 120 degree phase separation. And they need to be amplitude modulated but that's off topic here.
The AD9833 allows for setting the phase offset although I have no idea what it is in relation to. Nevertheless, it can be set.
What do you know, there is an Arduino Library for the device. I ordered a couple of demo boards and I probably won't need to write more than 50 lines of code to get both devices running at 400 Hz with the appropriate phase shift. Read that again! I don't have to write a bunch of low level library code. It's already done!
There's 363 lines of low level code I don't have to figure out. Not that I can't but it's nice that I don't have to!
I don't understand what the fuzz about. I've never used AD9833 before, but I looked at the datasheet and pent 5 minutes on it (less time than I spend typing this post).
It is simple SPI interface, with only 4 registers. You just set 28-bit frequency and 12-bit phase register. That's all. See, I already know how to set the phase, and you're yet to figure how to use your library. Reading datasheet has put me way ahead of where you are with the library.
You don't need anywhere close to 363 lines. It's probably easier to control the device directly than using the library - just few lines of code to pass two values through SPI.
-
Of course I know how to do it, with or without the library. For a one-off experiment I'll probably use the library. I won't use an Arduino, in this case, because I have the Teensy 4.0 sitting on my table. Somehow it all works out. I just use a processor that runs at 600 MHz and is at least 20 times faster than the Due. Same crappy IDE...
Now, if the library doesn't work, right out of the box, I'll replace the code with my own. Yes, it will be a lot shorter.
But the point of the library is that the OP on the other thread doesn't even know how to code in C much less understand the machinations of SPI. For a first approximation, he won't need to know much coding.
A better place to start in that it explains the API and the included functions (which I didn't have to write!):
https://github.com/Billwilliams1952/AD9833-Library-Arduino
-
... If you are going to do the programming, yourself, you start with what you know. It is not like sorting through a list of specs and choosing the cheapest one that meets parameters, then buying it, designing the PCB, and then just figuring out how to program the micro as an afterthought. You might do that sort of search, but then you'll compare it to what you already know.
What I know may not fit. So, yes I would do parametric search to find what I need. Say, last month I was looking for a good MCU with HS USB. I haven't found anything really good, but the best candidate I found was SAM (regardless of the fact that there was PIC32MZ which I am familiar with and I even have two boards with PIC32MZ and USB). The project got scrapped, but if it didn't, I would be working with SAM now. Could've been STM32 if it had better characteristics than SAM.
Of course, other things being equal, I would prefer a PIC because I know lots about them and I like lots of things they have. Not because they're cheap, but because they're cycle accurate and have good periphery (from my subjective viewpoint). And they fit the bill most of the time (there are 1000+ of different PICs to choose from, of which I have may be 300 or 400 different models to try immediately if I need to). They often have the best price as well. But this is now. This may no longer be the case 5, or 10, or 20 years from now.
-
Re Ogden:
langwadt, in response to declaration as fact that STM32 can't drive a GBIP bus, stated to the effect: 3.3V is more than enough to exceed TTL Vih of ~2.0V by a safe margin.
You challenge this with:
@langwadt missed to mention 5V-tolerant I/O as precondition.
Langwadt kindly comes back here and explains that most of the I/O are 5V-tolerant.
And so now you're back to :
Logic level compatibility alone is not enough for successful bidirectional signalling between 3.3V and 5V logic. You did mention *only* logic level.
Can you explain why you go round and round? What do you mean by "only" logic level? Do you think there's too much voltage drop and noise over 20 feet of cable? Or that it will significantly limit signal integrity and speeds? 3.3V is obviously not as much as 5V, but are you saying this just doesn't work when reason says it will? Langwadt covered the output side; he covered the input side. Both directions covered; you still not happy.
NorthGuy: "They [PIC] often have the best price as well." I'm not so sure this is true in the last 20 years, at least in the 8 bit arena. I agree there are a lot of variations, but this is not really a plus if the other micro comes with all of the peripherals and still costs less. 20 years ago, PIC was much better than almost any other micro manufacturer for availability in small to medium quantities to small buyer/individual. But increasingly they are not alone in this.
-
But the point of the library is that the OP on the other thread doesn't even know how to code in C much less understand the machinations of SPI. For a first approximation, he won't need to know much coding.
Why not? Is it noble to die without knowing how to code?
And if he's going to learn, why not to start from basics? That's how they do it in college, and it works well, at least it used to.
-
NorthGuy: "They [PIC] often have the best price as well." I'm not so sure this is true in the last 20 years, at least in the 8 bit arena. I agree there are a lot of variations, but this is not really a plus if the other micro comes with all of the peripherals and still costs less. 20 years ago, PIC was much better than almost any other micro manufacturer for availability in small to medium quantities to small buyer/individual. But increasingly they are not alone in this.
We finally agree on something. Things are changing all the time. Impossible to see the future is. Anyone must be prepared to adjust. Restricting your choices is not the best thing to do.
-
But the point of the library is that the OP on the other thread doesn't even know how to code in C much less understand the machinations of SPI. For a first approximation, he won't need to know much coding.
Why not? Is it noble to die without knowing how to code?
And if he's going to learn, why not to start from basics? That's how they do it in college, and it works well, at least it used to.
I don't know how the OP in the other thread will approach it. What I do know is that it will be a shorter hill to climb if the hard stuff is already done.
I suspect he is more interested in getting the indicator to work than he is in a post graduate degree in computer engineering with side helpings of power electronics (100VDC sine wave output) and analog electronics (analog multipliers to modulate the phase amplitude).
For my simple experiment, all I want to do is get two signals generated and then prove that I can shift the phase of one with respect to the other. Whether I ever build up a board to interface with my analog computers is really a separate subject. The knowledge will be there when the application comes around.
But first steps first: Get one board running and sending an output. Then figure out how to do three boards (with or without the library) and then, finally, get the phase shifting working. Rotary encoder to kick the phase a little? Well, there's a library for that...
-
Langwadt covered the output side; he covered the input side. Both directions covered
His initial explanation did not cover input. I was first to mention 5V-tolerant I/O's. For those (Arduino users/preachers) who do not know that most IO's of that stm32 MCU are 5V-tolerant, telling that 3.3V->5V (output direction) logic level compatibility is all what's needed to connect 3.3V IC to 5V bidirectional bus is outright wrong. Is this clear now? Can we end this? Now? :=\
-
Oh ok. Your previous post confused me.
A simple "ok, thanks" to Langwadt's post would have been more clear to me. Personally, I just assumed the micro was 5V tolerant and that he and Techman knew that. But yeah, that could be a problem.
Anyhow Langwadt was not incorrect/incomplete in his first post. The quote he refuted/corrected was the claim you could not DRIVE a GPIB bus from STM32.
-
For my simple experiment, all I want to do is get two signals generated and then prove that I can shift the phase of one with respect to the other.
To synchronize several chips you need to take them out of reset synchronously which requires to send an SPI command to all the chips being reset at the same time (wouldn't it be better to select a DDS with a reset pin?). So, they must be on the same SPI bus with different chip select pins. To figure that out you would need to read the datasheet. The library wouldn't help you with that, would it? Thus, you would have to read the datasheet anyway. After you have read it, you already know how to deal with the device (which is very simple BTW). So, you're ready to go. Few lines of code and you're done. Instead, you suggest:
- figure out how to use the library
- bring 363 lines of mostly useless code into your project (risking bugs and/or restrictions)
Doesn't seem like something helpful. Rather, a lot of extra work which could have been avoided and unwarranted bloat.
-
To synchronize digitally seems problematic for the chip. However, zero crossings could be measured and a digital solution would apply the necessary corrections. This is a lot of work
One solution is to generate just one 400 Hz signal and use analog phase shifting to get the 3 phases (if, and when, it is determined that there even needs to be phase shifting). There would need to be some output op amps (adjustable but fixed gain) to restore the voltage level before the signal goes into the analog multiplier to modulate the voltage followed by some kind of driver circuit to drive the transformers required to step the voltage up to around 100V. The analog end is pretty straightforward. Three DACs forming one input of each multiplier. The flight simulator provides the x,y and z angles, the Arduino eats the data and sets up the 3 amplitude DACs, the AD9833 is set just once without regard to phase angle, analog takes over.
In some cases, analog is a better way to go.
The AD9833 library works as near as I can tell without having the actual boards. They will be here Sunday.
-
To synchronize digitally seems problematic for the chip.
AD9833 is simplest DDS you can get (from AD), with all the consequences. AD9832 is what you would want to use in multi-channel operation, those have phase register selection pins.
-
If I had your outlook, I'd say "I'm a slave to oxygen, if I can't get enough I'll die" or "I'm a slave to water" or "I'm a slave to gravity" . I just don't bother with any of these thoughts.
You never know the value of water until the well is dry.
I'm an Australian and in many places in our country one is a few days away from death if the water runs out, but we don't let it worry us, we take water with us, and if we screw up we die.
Such is life.
-
To synchronize digitally seems problematic for the chip. However, zero crossings could be measured and a digital solution would apply the necessary corrections. This is a lot of work.
What's wrong with releasing all the chips from reset by the same SPI command sent simultaneously to all the chips?
-
Excellent tenets to live by !
Do you plan to start following them any time soon ?
Not quite the clever response I was hoping for but I was probably expecting too much. Start following them and you may even find an employer willing to suffer you again!
I try my best, but some people are never satisfied.
At age 65 I hardly need a new employer, but if the thought helps you to feel good about yourself, fantasize away.
-
To synchronize digitally seems problematic for the chip. However, zero crossings could be measured and a digital solution would apply the necessary corrections. This is a lot of work.
What's wrong with releasing all the chips from reset by the same SPI command sent simultaneously to all the chips?
Absolutely nothing wrong with that approach, once it is known to work. It should work (plus or minus a clock or two). That seems to be suggested in the datasheet and mentioned in the library comments. I was going to try it with just two boards mostly because that is all they had. There were others I could have chosen.
If the reset approach works, the analog end of this project gets a lot simpler.
-
To synchronize digitally seems problematic for the chip.
AD9833 is simplest DDS you can get (from AD), with all the consequences. AD9832 is what you would want to use in multi-channel operation, those have phase register selection pins./
Thanks for that! I'll take a look at the datasheet.
I don't see a low dollar demo board, the kit from AD comes to over $150 (2 boards). I'm not that curious...
If this were a real project, I would just build a board but, again, if I can't do it in 5 wires and a single statement change in an Arduino program (to change from 1000 Hz to 400 Hz), I'm not going to mess with it.
-
It should work (plus or minus a clock or two).
Data sheet says it goes out of reset in 7 or 8 MCLK clocks after the SPI command, so should be within one clock. It all depends on the relationship between MCLK and SPI clock. If you manage to synchronize MCLK and SPI clocks, you should be able to be clock accurate. 25 MHz for MCLK means 40 ns period, so small delays should be negligible.
The best way to synchronize the clocks is to simply clock the MCU with the same MCLK clock. Now you only need to make sure that the MCU you use can be clocked with an external 25 MHz clock. And then you can get everything synchronized to the same clock edge of MCLK.
-
I will use anything which best fit my requirements.
This is something I have heard repeated many times. But it is not very practical. Most people will gravitate towards a tool that is already in the toolbox. If you are going to do the programming, yourself, you start with what you know. It is not like sorting through a list of specs and choosing the cheapest one that meets parameters, then buying it, designing the PCB, and then just figuring out how to program the micro as an afterthought. You might do that sort of search, but then you'll compare it to what you already know.
You also consider time/work to use it. Until you cross a certain threshhold of cost/inconvenience, you might continue using what you already have available, regarding knowledge. I use some PIC that cost more than STM32 (or TI device, or Renesas, or...) in volume, and where the cheaper device should work absolutely fine. I'm sure you do, too. You still avoid answering this question.
Some people are still hoarding logic chips, because that's what they know. Why don't they just use FPGA and/or microcontrollers? (Yeh, I know they can occasionally be quite handy when fixing or modifying stuff; so a raaco drawer filled with every variety can be useful, sure. Live and let live).
Microcontrollers are by their very nature a multitool. You don't need to use the exact best one for every use. You can drive a variety of different screws with any one of them.
I flatten an occasional board with a hand plane. It's not cuz I don't know jointers and power planers exist. It's not cuz I like the workout. It's because I don't do very much of this, and this is just one part of a much bigger process of "making stuff," which requires a lot of other tools and space. If I needed to do a lot of this task, I might buy a jointer and a power planer. AFTER acquiring these tools, even if I have just one board to flatten a year, I would do it the easy way. In the same way, Techman will probably use an STM32 for many things I would do with a PIC. If and when I ever learned how to use an STM32, I would do the same. You call it lazy, if you want. Everyone does it. You do too.
You took the words right out of my fingers!
I also have heard the same mantra "I will use anything which best fit my requirements" thousands of times, and it's true for all of us in different ways.
If a hammer is all that someone has in their toolbox, then it's a hammer which "best fits their requirements".
Another classic ... they keep rolling of your fingers ! "Microcontrollers are by their very nature a multitool. You don't need to use the exact best one for every use. You can drive a variety of different screws with any one of them."
The Arduino fans here keep insisting than I'm here to sell STM32 while ignoring the fact that my toolbox currently contains MSP430's, PIC18x and PIC24x. It has at times also contained National PACE, SC\MP, 6800, 6802, 6805, 68HC11, Z80, 6502, 65F11, 8085, PIC16C/F84, MEGA16, MEGA32 and MEGA128.
You're right I would most probably use a STM32 but I also have a couple of hundred, very useful PIC's in SMT flat pack packages, all running the excellent FlashForth and waiting to be used. They're utterly reliable, robust, fast, and Forth is very portable between chips, (which I probably shouldn't have said because now I'll have the C fanboys here flaming me).
-
But the point of the library is that the OP on the other thread doesn't even know how to code in C much less understand the machinations of SPI. For a first approximation, he won't need to know much coding.
Why not? Is it noble to die without knowing how to code?
And if he's going to learn, why not to start from basics? That's how they do it in college, and it works well, at least it used to.
Ignorance is bliss. If you and all your friends think alike and believe the Earth is flat, not knowing any science that may cause doubt and conflict in your mind makes it so much easier and satisfying to burn a 'round earth heretic' at the stake. Everyone brings marshmellows and a good time is had by all minus one.
(not you personally of course, someone like you would probably be the guy they're burning).
As odd as it seems to you and I, many people don't want to learn about the technology they use.
-
I don't see a low dollar demo board, the kit from AD comes to over $150 (2 boards). I'm not that curious...
Oh. Not "hobby-friendly" at all. BTW popular AD9850 have phase pin as well. Yes, for 400Hz it is overkill (125MHz clock) and cost more, but it is up-to you to decide.
-
The agression spreads toward PIC users now also.
-
Personally, I just assumed the micro was 5V tolerant and that he and Techman knew that. But yeah, that could be a problem.
Anyhow Langwadt was not incorrect/incomplete in his first post. The quote he refuted/corrected was the claim you could not DRIVE a GPIB bus from STM32.
I don't have (nor want to have) a dog in this fight, but is it really driving the GPIB bus to spec, or is it driving it to "works on my bench today with 3 devices connected"?
"Works on my bench today" is perfectly sufficient for a lot of use cases (I'm sure we've all done it), but it's hard to argue that it's a full drop-in replacement.
-
Ignorance is bliss. If you and all your friends think alike and believe the Earth is flat, not knowing any science that may cause doubt and conflict
I never believed the Coriolis effect was something real until I sat down a rotating platform at the luna park with my girlfriend. The game was simple: two persons sit down each one on the opposite side of a rotating platform, and on a turn, each one tries to launch a balloon to the partner, who has to catch the balloon to win the game, but the Coriolis effect makes the gameplay harder than how you would believe because if you sit down on a rotating platform, the trajectory that you see is curved.
Now, I belive it ;D
-
Personally, I just assumed the micro was 5V tolerant and that he and Techman knew that. But yeah, that could be a problem.
Anyhow Langwadt was not incorrect/incomplete in his first post. The quote he refuted/corrected was the claim you could not DRIVE a GPIB bus from STM32.
I don't have (nor want to have) a dog in this fight, but is it really driving the GPIB bus to spec, or is it driving it to "works on my bench today with 3 devices connected"?
"Works on my bench today" is perfectly sufficient for a lot of use cases (I'm sure we've all done it), but it's hard to argue that it's a full drop-in replacement.
The actual start of this thread began when RHB wrote " Using a modern 3.3 V MCU and $5 in driver chips to do what a $5 MCU board will do is fairly silly unless you *really* need something the modern MCU does."
I asked "Please explain why a $0.45 STM32L053 needs $5 in driver chips and a $5 (Arduino) MCU board does not ? "
RHB responded " Because GPIB is 5 V TTL logic and the STM32 will not *drive* 5 V logic unless you add GPIB bus drivers. The ATMEGA line will. "
langwadt responded "VIh min for TTL is only about 2V, 3.3V will the drive TTL just fine"
Which is correct. The STM32 can read and write to TTL on many, (but not all GPIOS).
It all went pear shaped from there, many respondents weren't interested in specs, they weren't even interested in reading the thread to actually find out what was said, all they were interested in was having their say, just like RHB and I :)
This is a general chat forum not a EE design department, so words like "spec" rarely come up, rarely get answered and generally no one really cares. "Works on the bench" is usually plenty good enough.
Possibly RHB was trying to communicate that his "$5 MCU board" was actually a $5 GPIB driver board with a ATMEGA" and that detail was lost.
Nevertheless a STM32 can read and drive TTL, and with a GPIP driver chipset, also talk GPIB, possibly on a "$5 MCU board" as well.
It was a lot of debating about nothing really, but fun was had by most in the usual Internet way. There was no prize for being right, no penalty for being wrong and most posters are anonymous.
-
Ignorance is bliss. If you and all your friends think alike and believe the Earth is flat, not knowing any science that may cause doubt and conflict
I never believed the Coriolis effect was something real until I sat down a rotating platform at the luna park with my girlfriend. The game was simple: two persons sit down each one on the opposite side of a rotating platform, and on a turn, each one tries to launch a balloon to the partner, who has to catch the balloon to win the game, but the Coriolis effect makes the gameplay harder than how you would believe because if you sit down on a rotating platform, the trajectory that you see is curved.
Now, I belive it ;D
I always wondered why spaceships using a rotating living area weren't a more popular concept because they seem like a great way to provide artificial gravity on long trips like those to Mars.
Seems the Coriolis effect is a real PITA in these cases also!
-
Ignorance is bliss. If you and all your friends think alike and believe the Earth is flat, not knowing any science that may cause doubt and conflict
I never believed the Coriolis effect was something real until I sat down a rotating platform at the luna park with my girlfriend. The game was simple: two persons sit down each one on the opposite side of a rotating platform, and on a turn, each one tries to launch a balloon to the partner, who has to catch the balloon to win the game, but the Coriolis effect makes the gameplay harder than how you would believe because if you sit down on a rotating platform, the trajectory that you see is curved.
Now, I belive it ;D
I always wondered why spaceships using a rotating living area weren't a more popular concept because they seem like a great way to provide artificial gravity on long trips like those to Mars.
Seems the Coriolis effect is a real PITA in these cases also!
I always wondered what those ballbearings would cost and how you can get them to stay greased for a decade or so the flight takes in vacuum.
-
...
I always wondered why spaceships using a rotating living area weren't a more popular concept because they seem like a great way to provide artificial gravity on long trips like those to Mars.
Seems the Coriolis effect is a real PITA in these cases also!
Some deep good videos about that concept:
https://youtu.be/gTDlSORhI-k
https://youtu.be/b3D7QlMVa5s
-
https://en.wikipedia.org/wiki/Artificial_gravity
-
For my simple experiment, all I want to do is get two signals generated and then prove that I can shift the phase of one with respect to the other.
To synchronize several chips you need to take them out of reset synchronously which requires to send an SPI command to all the chips being reset at the same time (wouldn't it be better to select a DDS with a reset pin?). So, they must be on the same SPI bus with different chip select pins. To figure that out you would need to read the datasheet. The library wouldn't help you with that, would it? Thus, you would have to read the datasheet anyway. After you have read it, you already know how to deal with the device (which is very simple BTW). So, you're ready to go. Few lines of code and you're done. Instead, you suggest:
- figure out how to use the library
- bring 363 lines of mostly useless code into your project (risking bugs and/or restrictions)
Doesn't seem like something helpful. Rather, a lot of extra work which could have been avoided and unwarranted bloat.
QFT.
Just by chance, I've recently built a little function (for very few functions...) generator based on the AD9834 (that has reset, frequency and phase select pins but is otherwise very similar to AD9833) and an STM32F072 - so I feel pretty much in topic ;D
The driver to set frequency, phase and various control options is about 60 lines of very sparse C - add 3 dB when including a dual DAC driver for amplitude and offset.
I'm sure the time I spent coding it is comparable to the time it would have taken me to find and understand the library.
-
Everything is already
stolen writen before us (https://habr.com/ru/post/357902/#comment_11308856) (in my very rough translation):
Aduino isn't a problem. Program speed isn't a problem, and "young programmers" isn't a problem too.
The problem is that programmers try to write programs for real devices ignoring real world. And in the end, they have to wrap the wires with foil and put iron plates to deal with interference. (https://habr.com/ru/post/221663/) Or use 7805 as level translator (https://habr.com/ru/post/389475/#comment_17226431) to interface 12V tachometer signal with Atmega.
And then, when it turns out that the program that works perfectly in the simulator is buggy and crashes in real hardware, crying starts on all forums that Arduino is shit, microcontrollers are shit and they need to be soldered, electronics is shit, because you need to solder and nothing is clear.
Specifically for Arduino the trouble is that it, like microcomputers at one time, drastically lowered the threshold for entering the ecosystem, and there rushed "housewives" who didn't want to learn nuances. All what they want is just push button/insert wire/type "digitalWrite" - and everything perfectly worked.
-
^All of these same mistakes are also made by people using top of the line, modern microcontrollers and professional IDE and compilers.
I don't have (nor want to have) a dog in this fight, but is it really driving the GPIB bus to spec, or is it driving it to "works on my bench today with 3 devices connected"?
"Works on my bench today" is perfectly sufficient for a lot of use cases (I'm sure we've all done it), but it's hard to argue that it's a full drop-in replacement.
It depends what GPIB specifications are. As long as Vih is being met with 0.4V of extra margin for noise immunity on the other end, it's fine, it meets spec, and it is not a hack... as far as the output side of things.
So it depends on the specs of GPIB. How long cable it is supposed to work across, what gauge/resistance of wiring is the minimum recommended, and possibly how many are supposed to be daisy chained. If that other stuff isn't well defined, then even 5V output will fail at some point.
Add the fact that the logic levels aren't symmetrical to begin with. There is only 0.8V margin on the low side. Even at 3.3V, there's nominal 1.3 margin on the high side. So 3.3V output might work just as well as 5V (if Vil is what is violated, first). I suppose it depends what is the output impedance of the driver high vs low, and what is the amount of current drain caused by the input pins on the bus when high signal vs low signal, if that is asymmetrical, and if you have enough inputs connected for that to even matter.
Input side is another story.
Probably most important thing to check is to see what STM32 considers digital low input. CMOS spec, I think it's 0.5V, which is less than 0.8V. It doesn't mean STM32 is that sloppy/insensitive, just that is could be and still meet CMOS compatability spec. So proper low for TTL, at 0.7V, might not be low enough for STM32. In practice, any given device usually have a smaller/tighter "indeterminate window" than what is allowed by the protocol. That transition of high and transition of low just has to be within the window of that protocol. So in a way, no, this isn't necessarily equivalent to a proper TTL level interface. That is not inherently guaranteed, anyhow, by simple virtue that STM is CMOS compatible. But if 0.8V is recognized by STM as digital input low, which is fairly likely, it will more than likely work fine all the way to most demanding of GPIB specs.
So it would be left to you to determine if your specific CMOS device actually meets TTL specification of ViL 0.8V or not.
-
^All of these same mistakes are also made by people using top of the line, modern microcontrollers and professional IDE and compilers.
I don't have (nor want to have) a dog in this fight, but is it really driving the GPIB bus to spec, or is it driving it to "works on my bench today with 3 devices connected"?
"Works on my bench today" is perfectly sufficient for a lot of use cases (I'm sure we've all done it), but it's hard to argue that it's a full drop-in replacement.
It depends what GPIB specifications are. As long as Vih is being met with 0.4V of extra margin for noise immunity on the other end, it's fine, it meets spec, and it is not a hack. So it depends on the specs of GPIB. How long cable it is supposed to work across, what gauge/resistance of wiring is the minimum recommended, and possibly how many are supposed to be daisy chained. If that other stuff isn't well defined, then even 5V output will fail at some point.
Of course. I had a few moments, so I went to look. One item of the IEEE 488 spec that neither chip meets is "The driver shall be capable of sinking 48mA continuously." (emphasis mine)
It looks like the typical ST limit is 20mA and the AVR limit is 40mA per pin.
It does look like the voltage ranges are within reasonable limits for a 3.3V chip, at VLow of <= 0.5 V at +48mA and VHigh of >= 2.4V at -5.2 mA.
Either chip could meet the letter of the spec by paralleling 3 pins (ST) or 2 pins (Atmel) per line, providing the total chip current limits are not exceeded. It seems very likely that the total current limits would be exceeded in such a case as well as GPIB is a fairly wide parallel bus, not to mention the chips likely running out of pins as well.
With short (small number of devices) GPIB chains, the drivers probably don't need to sink all 48mA, of course, and it's pretty rare for hobbyists to have long chains of GPIB equipment and be using homebrew interfaces.
-
Yeah, I get your point. I also edited my previous post to add the thing to check on the input side. So yeah, and no.
I doubt you need 48mA on high side. Even in your spec, it specifies must "sink" 48mA. That's the part that you would expect to fail first. Any micro that doesn't sink that much should be sketchy, then. Most micro only do 10-25mA. So sketchy, yeah. But the lower voltage rail on the output is probably a red herring.
-
That's sink current per channel (not total) and it is higher than spec'd for individual pins on both families (at least the common parts that I quickly scanned).
I agree that it's unlikely to be seen in a small installation. The high side current required by spec is quoted above. (-5.2 mA)
-
On the bright side, even though the sink capability is technically too low (for a TTL output), the output low of CMOS compatible part is guaranteed to be 0.05V max, rather than 0.5V max for TTL. So there's a lot more (2.5x) guaranteed room for voltage drop due to limitation of sink capability.
You could say XmA sink at max guaranteed VoL of 0.5V would translate into about (2.5)XmA at VoL of 0.05V max.
48ma x (0.8V-0.5V) = XmA x (0.8V-0.05V)
So sink capability of CMOS output need only be around 19.2mA to guarantee ViL of 0.8V is met, compared to 48mA on a TTL lo output that might be as high as 0.5V. This might not be the absolute all inclusive conversion, but I think it's close enough to be useful. A perhaps more inclusive way to test would be to take the STM and see how much it can sink when VoL is allowed to exceed CMOS spec but still maintain TTL spec, to see if it will meet 48mA when VoL is allowed to drift up to 0.5V. I think the 19.2mA is more accurate. But if it could pass the latter test (I doubt it; not on all pins at the same time, lol), that would guarantee it could meet VoL drive spec under any weird circumstance.
So I still think the most important thing to check is the STM's actual ViL. If it happens to flirt on the low end of CMOS spec, then it will not function within TTL spec in this case. And STM input detection of digital low will be the weak and out of spec link. I would bet ViL is actually around 1.0V at 3.3V supply, though. But some testing would be a good idea, if this isn't actually characterized in the electrical characteristics for the chip.
-
The question was never about whether you could use a microcontroller to drive an HPIB bus “in spec”; that was pretty clearly not possible. And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.
What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone. As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.
There are apparently existence proofs that this works with an avr arduino. It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.
(Techman - want to give it a try? It ought to be a sort of ideal stm32 Forth demo project - implement a usb to HPIB bridge, and get a Forth-word command line interface on some side channel “for free”!
And given your age and experience, you probably have some HPIB test equipment lying around...
(This is a real question. Feel free to echo my own “it’s not worth buying an HPIB connector to try out” opinion.))
-
And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.
That's why we have had further discussion.
There are apparently existence proofs that this works with an avr arduino. It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.
It is not enough to put it together and see if it works in one instance. All TTL and CMOS devices are not created equal. They just must work somewhere within their protocol. That model AVR might work on one TTL bus, but not another. And that TTL bus might with with that model AVR, but not another.
It is better to sit down and see where the problems might occur, and make sure you can clear those hurdles.
In this case, test STM for ViL, IMO. Pretty much all you need to know which we don't already. If actual ViL is lower than 0.8V TTL spec, it might work with one TLL circuit, but not another one. I don't think this reality is likely, but there's no implicit guarantee this isn't the case, from what all I personally know about an STM. I know it's going to comply with CMOS standards. I also know it was made to be compatible with 5V TTL, so I believe it is safe to assume ViL will be higher than 0.8V, if you were not going to bother testing or looking it up.
-
The question was never about whether you could use a microcontroller to drive an HPIB bus “in spec”; that was pretty clearly not possible. And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.
What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone. As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.
There are apparently existence proofs that this works with an avr arduino. It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.
(Techman - want to give it a try? It ought to be a sort of ideal stm32 Forth demo project - implement a usb to HPIB bridge, and get a Forth-word command line interface on some side channel “for free”!
And given your age and experience, you probably have some HPIB test equipment lying around...
(This is a real question. Feel free to echo my own “it’s not worth buying an HPIB connector to try out” opinion.))
Don't hold your breath. ;D
-
For my simple experiment, all I want to do is get two signals generated and then prove that I can shift the phase of one with respect to the other.
To synchronize several chips you need to take them out of reset synchronously which requires to send an SPI command to all the chips being reset at the same time (wouldn't it be better to select a DDS with a reset pin?). So, they must be on the same SPI bus with different chip select pins. To figure that out you would need to read the datasheet. The library wouldn't help you with that, would it? Thus, you would have to read the datasheet anyway. After you have read it, you already know how to deal with the device (which is very simple BTW). So, you're ready to go. Few lines of code and you're done. Instead, you suggest:
- figure out how to use the library
- bring 363 lines of mostly useless code into your project (risking bugs and/or restrictions)
Doesn't seem like something helpful. Rather, a lot of extra work which could have been avoided and unwarranted bloat.
QFT.
Just by chance, I've recently built a little function (for very few functions...) generator based on the AD9834 (that has reset, frequency and phase select pins but is otherwise very similar to AD9833) and an STM32F072 - so I feel pretty much in topic ;D
The driver to set frequency, phase and various control options is about 60 lines of very sparse C - add 3 dB when including a dual DAC driver for amplitude and offset.
I'm sure the time I spent coding it is comparable to the time it would have taken me to find and understand the library.
I love reading such accounts as yours and NorthGuy because as a Forth user I always write all my own code. When I see Arduino users talking about 'libraries' for such things I always wonder " does it use DMA or Interrupts or both, what actual chip options are configurable to the user, is it running in a multitasking system, what user tests and calibration are available" and so on.
About January of this year I bought a few Ti LMT-01 temperature sensors, read the small tech manual, then looked around the Internet to see if anyone had used them. I found only two Arduino examples, and both used the Ti reference from the datasheet, namely they ran continuously reading one sensor as fast as they could.
I thought this method was a waste of a MCU, so my Forth design uses any (reasonable) number of LMT-01 sensors and reads them as commanded in a multitasking system using interrupts and timers. This allows the sensors to be used in various applications from reading wet/dry bulb humidity to accurate battery charge levels and it uses almost no CPU time therefore allowing plenty of other things to be done including instant response from a connected interactive realtime serial terminal..
It runs on a STM32F0 Discovery board but only needs a STM32F0xx MCU. I know exactly how it works, what the weak points are, what the strong points are because I designed it.
I also found the Ti LMT-01 is highly accurate out of the box. http://www.ti.com/lit/ds/symlink/lmt01.pdf (http://www.ti.com/lit/ds/symlink/lmt01.pdf)
I apologize in advance for my terrible Forth code, (not that many here will know that) but as it's Open Source I may as well give the link which includes a bonus flowchart, and utube video :-+
https://mecrisp-stellaris-folkdoc.sourceforge.io/project.3temp.sensors.html?highlight=temperature (https://mecrisp-stellaris-folkdoc.sourceforge.io/project.3temp.sensors.html?highlight=temperature)
Waveforms are via my 1994 HP54601A DSO using the RS232 module and a shell script on FreeBSD. No GPIB required ;-)
-
Everything is already stolen writen before us (https://habr.com/ru/post/357902/#comment_11308856) (in my very rough translation):
Aduino isn't a problem. Program speed isn't a problem, and "young programmers" isn't a problem too.
The problem is that programmers try to write programs for real devices ignoring real world. And in the end, they have to wrap the wires with foil and put iron plates to deal with interference. (https://habr.com/ru/post/221663/) Or use 7805 as level translator (https://habr.com/ru/post/389475/#comment_17226431) to interface 12V tachometer signal with Atmega.
And then, when it turns out that the program that works perfectly in the simulator is buggy and crashes in real hardware, crying starts on all forums that Arduino is shit, microcontrollers are shit and they need to be soldered, electronics is shit, because you need to solder and nothing is clear.
Specifically for Arduino the trouble is that it, like microcomputers at one time, drastically lowered the threshold for entering the ecosystem, and there rushed "housewives" who didn't want to learn nuances. All what they want is just push button/insert wire/type "digitalWrite" - and everything perfectly worked.
I can't argue with your logic, but I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?
Some experienced people say "I keep a Arduino on hand" for quick use" ... And I always think, "why keep a ancient, slow, 8 bit MCU with poor ADC resolution, and bugger all peripherals on hand?"
I keep a fairly modern 32 bit, 48Mhz, 12 bit ADC, 8 Timer, Forth powered STM32F on hand for quick projects. I can start a fully documented project with it in about 5 seconds. The dev board cost $10 including the inbuilt USB SWD programmer/debugger.
If I want a even lower unit in a small pcb, I can use one of these: https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32-boards.html?highlight=green%20pill#why-not-make-your-own-green-pill
I hand solder them, and I'm 65 years old so it can't be too hard.
-
What was that saying again? When all you have is Forth everything starts looking like something to argue about? ;D
Writing everything from scratch is fun but stops making sense when the project complexity increases. No same developer would attempt to roll all of the libraries he uses himself directly or indirectly for desktop or server computing. Many highly specialised and optimised libraries exist and while reinventing the wheel is fun people don’t tend to be amused when you produce something a fraction of the quality at many times the costs. I won’t pretend all Arduino libraries are generally that sophisticated mind, although some are.
-
The question was never about whether you could use a microcontroller to drive an HPIB bus “in spec”; that was pretty clearly not possible. And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.
What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone. As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.
There are apparently existence proofs that this works with an avr arduino. It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.
(Techman - want to give it a try? It ought to be a sort of ideal stm32 Forth demo project - implement a usb to HPIB bridge, and get a Forth-word command line interface on some side channel “for free”!
And given your age and experience, you probably have some HPIB test equipment lying around...
(This is a real question. Feel free to echo my own “it’s not worth buying an HPIB connector to try out” opinion.))
No thanks Westfw, but it's a nice challenge :)
I'm already about 20+ projects behind and I dismantled my last GPIB capable device for parts (A very old 8080 powered CRT based HP Logic Analyser) well over 12 months ago.
And frankly, that's a big project for me, I'm not a EE, just a electronics technician. It would be a excellent learning experience because I'd need to use a MCU with USB support and my goto STM32F051 MCU doesn't have it.
I've started wiring up a STM32L053R8 which does have USB 2.0 crystal less support so I may try writing a USB driver for it sometime, but don't hold your breath because I have a nasty modern disease called "usbphobia" :)
https://mecrisp-stellaris-folkdoc.sourceforge.io/prototyping.html?highlight=prototyping#stm32l053
-
And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.
That's why we have had further discussion.
There are apparently existence proofs that this works with an avr arduino. It would take the same (a working example) to show it satisfy anyone that an stm32f chip is up to the task.
It is not enough to put it together and see if it works in one instance. All TTL and CMOS devices are not created equal. They just must work somewhere within their protocol. That model AVR might work on one TTL bus, but not another. And that TTL bus might with with that model AVR, but not another.
It is better to sit down and see where the problems might occur, and make sure you can clear those hurdles.
In this case, test STM for ViL, IMO. Pretty much all you need to know which we don't already. If actual ViL is lower than 0.8V TTL spec, it might work with one TLL circuit, but not another one. I don't think this reality is likely, but there's no implicit guarantee this isn't the case, from what all I personally know about an STM. I know it's going to comply with CMOS standards. I also know it was made to be compatible with 5V TTL, so I believe it is safe to assume ViL will be higher than 0.8V, if you were not going to bother testing or looking it up.
Well put! I was recently reading a old NASA tech article on interfacing MOS MCU's with TTL subsystems and it was quite complex with just some of the important factors mentioned being:-
The usual ViL and ViH and the long term reliability issues of even small over voltages
Rise and fall times (to prevent oscillation)
Noise levels
Regrettably, I can't locate that article again.
-
What was that saying again? When all you have is Forth everything starts looking like something to argue about? ;D
Writing everything from scratch is fun but stops making sense when the project complexity increases. No same developer would attempt to roll all of the libraries he uses himself directly or indirectly for desktop or server computing. Many highly specialised and optimised libraries exist and while reinventing the wheel is fun people don’t tend to be amused when you produce something a fraction of the quality at many times the costs. I won’t pretend all Arduino libraries are generally that sophisticated mind, although some are.
"What was that saying again? When all you have is Forth everything starts looking like something to argue about? ;D "
No not really, the few Forthers I know are highly intelligent, shy and polite people. I'm usually polite ...
"Writing everything from scratch is fun but stops making sense when the project complexity increases."
I find your acolyte like subservience to the Ardunio Priesthood interesting and note with interest that you have swallowed their corporate thrust to the hilt.
Nothing is complicated to a Forth user.
-
I can't argue with your logic, but I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?
Some experienced people say "I keep a Arduino on hand" for quick use" ... And I always think, "why keep a ancient, slow, 8 bit MCU with poor ADC resolution, and bugger all peripherals on hand?"
I keep a fairly modern 32 bit, 48Mhz, 12 bit ADC, 8 Timer, Forth powered STM32F on hand for quick projects. I can start a fully documented project with it in about 5 seconds. The dev board cost $10 including the inbuilt USB SWD programmer/debugger.
The ecosystem is part of it. I can buy a $2-3 Arduino clone and a $5 CAN shield, plug them together, take code from someone else, modify/improve it, pass it along to other people anywhere in the world who can easily buy that same micro and shield and get the same result.
I don't hold myself out as "[deeply] knows what [I'm] doing in embedded", but there's never been a time when I sat down to do something and felt like I would struggle to accomplish it. I've got all kinds of dev boards lying around here; the Raspberry Pi and Arduinos get the most usage because they're often the easiest thing to go reach for. The environment matters. The ecosystem matters. To send/receive CAN traffic to my car, I could start by reading the entire datasheet for the MCP2515, or I could plug in the CAN shield and #include <MCP2515.h> and it's 99% likely to work. One is wildly faster than the other.
Yes, I've written 6502, 8051, 68K, R3000, and x86 assembly. I've written a lot of c and c++ (and C#, SQL, VBA, and Javascript). If I had to get a relay board up on STM, I'm pretty sure I could do it in an evening. I'm more sure I can do it in 5 minutes on a $2 Arduino.
As a user, I often just want the 3/8" hole in my wall; I don't necessarily want the drill and the drill bit.
-
I've also used a few stack-based languages, but never had the occasion to use Forth for anything beyond a toy example.
It's "on the list" (that I'll never get through).
-
Back to the AD9833 Arduino Library...
Here's how it went: I received one of the two demo boards today so I decided to test out the library code after soldering a coax connector and 3 pin headers. I had loaded the library and the example code (it just produces a 1 kHz sine wave) into the Arduino yesterday just to watch the SPI toggle. No reason to do it, no reason not to. Just spending quality time with my scope.
I ran the 5 jumpers from the demo board (sitting on a prototype board) to the Arduino pins and applied power. Instant 1 kHz signal. No pain, no strain.
Literally, if the soldering were already done, it would take, at most, 5 minutes to get the signal from the time the library is downloaded.
So, I have a baseline, something I know works and I can always come back to for testing. I can beat on the code all I want, I always have a working version. If I mess it up, I can download it again.
Incidentally, AD has an App Note on how to program the device and, as luck would have it, the code is for 400 Hz, the original goal.
https://www.analog.com/media/en/technical-documentation/application-notes/AN-1070.pdf (https://www.analog.com/media/en/technical-documentation/application-notes/AN-1070.pdf)
It simply doesn't get any easier than this. From nowhere to clean sine wave in about 5 minutes. No high speed interrupts, no sin() table, no DAC, just a simple programmable waveform generator driven by a really simple MCU.
-
"What was that saying again? When all you have is Forth everything starts looking like something to argue about? ;D "
No not really, the few Forthers I know are highly intelligent, shy and polite people. I'm usually polite ...
"Writing everything from scratch is fun but stops making sense when the project complexity increases."
I find your acolyte like subservience to the Ardunio Priesthood interesting and note with interest that you have swallowed their corporate thrust to the hilt.
Nothing is complicated to a Forth user.
It'd be appreciated if you tried being at least polite on here too. In your haste to condemn the Arduino priesthood and include me in it you overlooked I wasn't speaking for it. I was merely pointing out that your confusion about or even the dislike of the use of libraries contradicts a very large part of the software industry. It has little to do with Arduino or any specific language or platform. Instead of every developer having to rewrite the same routines some spend their days writing specialised and highly optimised libraries for others to use. On the other end there's the question of where to stop. Why use a higher level language instead of assembly? Why not start filling buckets with sand to create your own silicon? If we reject the groundwork of others there's a lot of work to be done.
Regardless, could you give us an indication how much time you spent on the temperature sensor project you posted from start to finish?
-
I can't argue with your logic, but I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?
Some experienced people say "I keep a Arduino on hand" for quick use" ... And I always think, "why keep a ancient, slow, 8 bit MCU with poor ADC resolution, and bugger all peripherals on hand?"
I keep a fairly modern 32 bit, 48Mhz, 12 bit ADC, 8 Timer, Forth powered STM32F on hand for quick projects. I can start a fully documented project with it in about 5 seconds. The dev board cost $10 including the inbuilt USB SWD programmer/debugger.
The ecosystem is part of it. I can buy a $2-3 Arduino clone and a $5 CAN shield, plug them together, take code from someone else, modify/improve it, pass it along to other people anywhere in the world who can easily buy that same micro and shield and get the same result.
I don't hold myself out as "[deeply] knows what [I'm] doing in embedded", but there's never been a time when I sat down to do something and felt like I would struggle to accomplish it. I've got all kinds of dev boards lying around here; the Raspberry Pi and Arduinos get the most usage because they're often the easiest thing to go reach for. The environment matters. The ecosystem matters. To send/receive CAN traffic to my car, I could start by reading the entire datasheet for the MCP2515, or I could plug in the CAN shield and #include <MCP2515.h> and it's 99% likely to work. One is wildly faster than the other.
Yes, I've written 6502, 8051, 68K, R3000, and x86 assembly. I've written a lot of c and c++ (and C#, SQL, VBA, and Javascript). If I had to get a relay board up on STM, I'm pretty sure I could do it in an evening. I'm more sure I can do it in 5 minutes on a $2 Arduino.
As a user, I often just want the 3/8" hole in my wall; I don't necessarily want the drill and the drill bit.
Thank you for the detailed response, I think you could easily deal with STM (if you needed it), the docs are good, the chips power up with sensible defaults and you clearly have the background and experience.
Note: I'm not a STM seller, I'm not connected with them in any way, I eschew their C environment and I could just as easily be using any other decent ARM Cortex-M MCU instead.
I also struggle with this question of logic: " If Arduino is for artists and non technical people, why would any experienced embedded engineer consider the Arduino ecosystem to be anything but a curiosity, a small entertainment" ?
I also can't resist asking, will that CAN shield and Arduino code include real time message decoding if you supply the message format in a .dbc file. ;-)
-
I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?
One of the reasons that I “bother with” Arduino is that code I write is more likely to be useful to “other people.” A sort of “customer oriented” philosophy, I guess. I tend to be interested in writing “deep infrastructure” code, so it’s frequently hard to feel like I’m doing anything “useful”, but if I, say, fix the Adafruit SamD51 arduino core implementation of “delayMicrosecondsuple()”, the I’ve potentially helped a lot of people...
Back to HPIB: feel free to do usb-serial-HPIB if usb is too scary. The “working example” that I found first used an uno, which doesn’t have native usb support, either.
It seems to me that the big stumbling block is likely to be the sink current needed to ensure a logic 0 output from the micro is recognized. A couple of 74F gates with some 2.2k pull-up resistors is going to stress some of those modern 4mA uC outputs (no, I didn’t check the stm32 specs - they are generally better than 4ma, right?)
And yeah, something that doesn’t meet the specs will always require testing in the exact use circumstances that you’ll use. Especially given the long lifetime of GPIB. But one working example is a start...
-
"What was that saying again? When all you have is Forth everything starts looking like something to argue about? ;D "
No not really, the few Forthers I know are highly intelligent, shy and polite people. I'm usually polite ...
"Writing everything from scratch is fun but stops making sense when the project complexity increases."
I find your acolyte like subservience to the Ardunio Priesthood interesting and note with interest that you have swallowed their corporate thrust to the hilt.
Nothing is complicated to a Forth user.
<snip your usual nonsense>
Regardless, could you give us an indication how much time you spent on the temperature sensor project you posted from start to finish?
For that project my Forth coding fun finished way too soon for me but I estimate the time to be about 1.783 x 10 ^ 99 times longer than any coding you have ever done given your fairly obvious horror associated with all things code related.
Were you abused by Emacs or Vi as a small child perhaps ?
-
Were you abused by Emacs
What? TECO was a wonderful programming language!
:)
-
I wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?
One of the reasons that I “bother with” Arduino is that code I write is more likely to be useful to “other people.” A sort of “customer oriented” philosophy, I guess. I tend to be interested in writing “deep infrastructure” code, so it’s frequently hard to feel like I’m doing anything “useful”, but if I, say, fix the Adafruit SamD51 arduino core implementation of “delayMicrosecondsuple()”, the I’ve potentially helped a lot of people...
Back to HPIB: feel free to do usb-serial-HPIB if usb is too scary. The “working example” that I found first used an uno, which doesn’t have native usb support, either.
It seems to me that the big stumbling block is likely to be the sink current needed to ensure a logic 0 output from the micro is recognized. A couple of 74F gates with some 2.2k pull-up resistors is going to stress some of those modern 4mA uC outputs (no, I didn’t check the stm32 specs - they are generally better than 4ma, right?)
And yeah, something that doesn’t meet the specs will always require testing in the exact use circumstances that you’ll use. Especially given the long lifetime of GPIB. But one working example is a start...
Hey if fixing Arduino code is your thing, I apologize for my use of the term "bother with”, no insult was intended, especially not to you.
What percentage of Arduino users would even know the different delay() mechanisms possible with that MCU I wonder ?
.
I agree, there are no doubt plenty of specs to be considered to do the job properly, and I sure didn't claim (and wouldn't) that a STM32F could drive the GPIB bus directly.
For one thing, I've no idea of the specs of the GPIB bus, and I'm not likely to care because I've never needed it, it's old, and we have Ethernet now instead.
What does interest me however is learning the 'typical' parameters of a STM32 talking to some TTL and writing up my findings. I'll do this in the next couple of weeks as soon as I can find the time AND some TTL as I ditched my stock of brand new Ti TTL chips a few years ago.
I lived and worked thru the "Age of TTL" and I was incredibly relieved to see it's demise. Thank you oh God of CMOS!
It is important to note that STM32 GPIOs configured as inputs are 5-V tolerant, not 5-V compliant meaning that 5 V is tolerated by internally clamping the input voltage to VDD.
As far as OUTPUTS are concerned there are a TON of factors, voltage levels, rise and fall times, noise etc. This is proper design territory.
Sure, the STM32 may be far from 'TTL compliant' but what makes everyone think that Arduino MEGA328P is any better ?
-
I've also used a few stack-based languages, but never had the occasion to use Forth for anything beyond a toy example.
It's "on the list" (that I'll never get through).
Such a long list, such a short life ! :)
My gravestone will read:
"~~ I Died Mid Project ~~"
-
=
For that project my Forth coding fun finished way too soon for me but I estimate the time to be about 1.783 x 10 ^ 99 times longer than any coding you have ever done given your fairly obvious horror associated with all things code related.
Were you abused by Emacs or Vi as a small child perhaps ?
You refuse to both acknowledge the purpose and usefulness of libraries and report the time it took you to complete your project because you know it ruins your narrative. Being abusive doesn't change that so you may want to revise your answer.
Although it wouldn't surprise me if your project actually took longer than human history to complete ;D An Ammonite writing Forth is quite a sight to behold. Look at those tentacles tickle the keyboard!
-
=
For that project my Forth coding fun finished way too soon for me but I estimate the time to be about 1.783 x 10 ^ 99 times longer than any coding you have ever done given your fairly obvious horror associated with all things code related.
Were you abused by Emacs or Vi as a small child perhaps ?
<snip usual nonsense>
Although it wouldn't surprise me if your project actually took longer than human history to complete ;D An Ammonite writing Forth is quite a sight to behold. Look at those tentacles tickle the keyboard!
May Malcom forgive you for your blasphemy about tentacles!
"Ammonite, any member of an ancient Semitic people whose principal city was Rabbath Ammon, in Palestine. The “sons of Ammon” were in perennial, though sporadic, conflict with the Israelites. After a long period of seminomadic existence, the Ammonites established a kingdom north of Moab in the 13th century bc. With difficulty, their fortress capital was captured by Israel’s King David. An Ammonite woman, one of many foreigners taken into Israel’s King Solomon’s harem, was responsible for inducing the king to worship the Ammonite god Malcom."
https://www.britannica.com/topic/Ammonite (https://www.britannica.com/topic/Ammonite)
-
May Malcom forgive you for your blasphemy about tentacles!
"Ammonite, any member of an ancient Semitic people whose principal city was Rabbath Ammon, in Palestine. The “sons of Ammon” were in perennial, though sporadic, conflict with the Israelites. After a long period of seminomadic existence, the Ammonites established a kingdom north of Moab in the 13th century bc. With difficulty, their fortress capital was captured by Israel’s King David. An Ammonite woman, one of many foreigners taken into Israel’s King Solomon’s harem, was responsible for inducing the king to worship the Ammonite god Malcom."
https://www.britannica.com/topic/Ammonite (https://www.britannica.com/topic/Ammonite)
It's okay, we understand you need a couple of tries before you understand what's required of you. While we wait for you to acknowledge the purpose and usefulness of libraries maybe you can detail how you wrote an ethernet stack from scratch?
(https://www.bgs.ac.uk/discoveringGeology/time/Fossilfocus/images/ammonites/reconstructions/Aegoceras.jpg)
-
I also struggle with this question of logic: " If Arduino is for artists and non technical people, why would any experienced embedded engineer consider the Arduino ecosystem to be anything but a curiosity, a small entertainment" ?
Because getting results is fast! See my 5 minutes from zero to sine wave output using AD9833 library a few posts back. Literally, less than 5 minutes from downloading library and example code to working sine wave and that time is used to run the interconnects.
The goal is getting the sine wave, not advancing the leading edge of technology.
-
I also struggle with this question of logic: " If Arduino is for artists and non technical people, why would any experienced embedded engineer consider the Arduino ecosystem to be anything but a curiosity, a small entertainment" ?
Because getting results is fast! See my 5 minutes from zero to sine wave output using AD9833 library a few posts back. Literally, less than 5 minutes from downloading library and example code to working sine wave and that time is used to run the interconnects.
The goal is getting the sine wave, not advancing the leading edge of technology.
I did read your AD9833 post with interest (as I read all your posts with interest) and I also read NorthGuy's followup which said in part "It is simple SPI interface, with only 4 registers. You just set 28-bit frequency and 12-bit phase register. That's all. See, I already know how to set the phase, and you're yet to figure how to use your library. Reading datasheet has put me way ahead of where you are with the library."
Perhaps it's not the best example because getting a sine wave takes me about 5 seconds after I turn on my old PM5314 Philips 1 - 20 MHZ function generator.
If you had claimed "Because getting results can be fast!" I couldn't really argue that point, because sure, getting the Arduino Blinky is as fast as the getting the Forth Blinky. Both only take seconds to upload to the chip.
Although you get a complete operating system on your chip with Forth in that time, as well as a blinky, Arduino Blinky is still mega fast. The Arduino Java IDE is kinda cool, the whole thing has a look of easy use about it.
My Forth IDE looks a lot less polished. https://mecrisp-stellaris-folkdoc.sourceforge.io/modern-forth-development-environment.html#a-modern-forth-ide
Unfortunately Arduino is not always fast getting results, especially in instances when where no library is available, such as the LMT-01 two wire (not Dallas 2 wire) temperature sensor from Ti.
Unbelievably I see Ti have even included Arduino example code in their official training webpage ... words fail me.
https://training.ti.com/how-interface-lmt01-temperature-sensor-arduino
I did however find a Arduino user very frustrated in Apr 06, 2018, when trying to get his LMT-01 sensor going. There is no [solved] followup to that thread.
https://arduino.stackexchange.com/questions/51588/lmt01-temperature-sensor-code-does-not-run-need-help
"So to repeat myself only Pin2 is attached with the LMT01 to the Arduino. Why doesn't this &!#^-thing work, it compiled and uploaded correctly. If I had a debugger on this software, moving one line at a time I could fix it myself"
-
I don't think arduino users are aggressive. Maybe a bit blind to using anything else. I find the forum moderators more protective though. For heavens sake don't criticize the library documentation even if others agree that it's bad, you will get banned! I do use it from time to time when i need a one off that designing a PCB for is not feasible. But every time i use it I get unexplained odities. Last one was that one of the PWM outputs would stop working when i wrote a value to one of the others, the forum could not help other than to demand to see my code wich was silly and the problem was very simple and as I explained it code was not neccessary. Having already been banned before for being critical I just abandoned my attempt at pointing out a bug and just fixed it by rewriting to the offending channel every time i wrote to the other one to mask the problem.
The arduino is claimed to be for beginers but the level of knowledge the forum expects you to have is not beginner.
-
I find the forum moderators more protective though. For heavens sake don't criticize the library documentation even if others agree that it's bad, you will get banned!
It seems a thing for kids, where mods have much bias, and a thing that is granted, that's not a place for adults.
-
I also struggle with this question of logic: " If Arduino is for artists and non technical people, why would any experienced embedded engineer consider the Arduino ecosystem to be anything but a curiosity, a small entertainment" ?
Because getting results is fast!
This is what my colleagues think. And I do think the same.
-
horses for courses. I have used the arduino for a test item at work and a one off for a customer of mine. If you are making one that can be achieved with an arduino why not? why design a specific PCB. Of course you are free to just program the boards as you please.
-
...
What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone. As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.
...
This is indeed the question. And there is empirical evidence that Arduino works. Not only one implementation, but several projects. Used by tens or hundreds of people. A quick search will reveal this. Fanboyz of other uC boards or chips are of course free to use or fail with whatever they want.
And "old lab equipment" includes HP3458A - an 8.5 DMM costing some 9k USD or thereabout new, and 3-6k or so used. Even if it today is sold branded Keysight 3458A, it has not changed much in 20+ years, and if you want to talk to it you "must" use GPIB. Volt-nuts and other precision measurement geeks do generally not want to waste money on shamefully overpriced adapters. So some of these world class meters transfer data to the PC via an eBay Arduino clone.
Apart from the 48 mA value mentioned earlier, it might be useful to learn that "VIH = 3.4 volts typical, 2.4 volts minimum" and "All lines in the GPIB are tri-state except for ‘SQR’, ‘NRFD’, and ‘NDAC’ which are open-collector. The standard bus termination is a 3K resistor connected to 5 volts in series with a 6.2K resistor to ground - all values having a 5% tolerance." For electrically sound reliability reasons it is stated that "No more than 15 device loads connected to each bus, with no less than two-thirds powered on".
Sources:
http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm (http://www.hit.bme.hu/~papay/edu/GPIB/tutor.htm)
http://www.interfacebus.com/Design_Connector_GPIB.html (http://www.interfacebus.com/Design_Connector_GPIB.html)
Interesting :blah:
https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Why-must-two-thirds-of-the-instruments-on-a-GPIB-bus-be-on/td-p/760500?profile.language=en (https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Why-must-two-thirds-of-the-instruments-on-a-GPIB-bus-be-on/td-p/760500?profile.language=en)
-
I did read your AD9833 post with interest (as I read all your posts with interest) and I also read NorthGuy's followup which said in part "It is simple SPI interface, with only 4 registers. You just set 28-bit frequency and 12-bit phase register. That's all. See, I already know how to set the phase, and you're yet to figure how to use your library. Reading datasheet has put me way ahead of where you are with the library."
You seem to be making a couple of assumptions that are probably incorrect. I did read the datasheet and know very well how to write the code. I also read the App Note - did you find that? It details the calculations and provides the proper values for a 400 Hz sine wave. Kind of handy... I also read over the library code and there were no surprises and, of course, the application itself just makes a couple of library calls. Over and done.
Perhaps it's not the best example because getting a sine wave takes me about 5 seconds after I turn on my old PM5314 Philips 1 - 20 MHZ function generator.
I could do the same with my 80 MHz Siglent but the application for this gadget is a flight instrument, not a boxcar.
If you had claimed "Because getting results can be fast!" I couldn't really argue that point, because sure, getting the Arduino Blinky is as fast as the getting the Forth Blinky. Both only take seconds to upload to the chip.
Why keep bringing up Forth? It brings nothing to the Arduino topic and even less to the AD9833 sub-topic. I wrote an entire celestial navigation program for the HP48GX calculator about 20 years ago. The HP RPL programming language is a lot like Forth. It worked well. But I'm not going to do it again!
As to why people can't get particular pieces of hardware to work, well, some people should be polishing ball bearings instead of writing code. Sometimes it is actually necessary to read the datasheet but when it runs over 1000 pages, it's going to be a slog. The only way to approach it is one peripheral at a time. To be fair, this isn't a game for the test gear challenged. Without a logic analyzer and/or modern DSO, things will be very difficult. You can't fix what you can't see.
In the end, I'm lazy, not stupid. I can write the code if need be but if it already exists, why not save a bunch of time?
What's to happen with my AD9833 gadget(s)? I'll toss them in a drawer and, maybe, pull them out some day. This exercise was for proof of concept, not production. Chances are good I will never use them for anything practical.
-
What we want to know is whether the microcontroller can directly drive a single HPIB device like a scope, power supply, or printer, so that you can replace those expensive ($100+) real usb-HPIB interfaces with something like a $5 Arduino Micro clone. As a hack for hobbyists, or to add “unbudgeted” connectivity to old lab equipment, perhaps.
https://sigrok.org/wiki/Prologix_GPIB-USB (https://sigrok.org/wiki/Prologix_GPIB-USB)
-
I did read the datasheet and know very well how to write the code. I also read the App Note - did you find that? It details the calculations and provides the proper values for a 400 Hz sine wave. Kind of handy... I also read over the library code and there were no surprises and, of course, the application itself just makes a couple of library calls. Over and done.
How could all that take you 5 minutes?
https://www.youtube.com/watch?v=h9AqbDtSFNU (https://www.youtube.com/watch?v=h9AqbDtSFNU)
-
Why keep bringing up Forth?
Well, I agree this looks sometimes out of place, and I told him so in another topic (I probably got blacklisted ;D ).
That said and to be fair (I try to be), some other people keep bringing up Arduino in threads where the OP never asked anything about it, which can be every bit as annoying.
It brings nothing to the Arduino topic
To be fair again, and I'm not defending his cause, but I think he mentioned Forth to show that there were other options than Arduino that could get you the same level of ease of development than the Arduino ecosystem. Whether this is really true, and true in all cases, is debatable.
Point is, pretty much anyone convinced of the greatness of some tool they're using a lot (or even exclusively) will tend to promote it relentlessly. As someone else here said, that's not specifically the Arduino users who are aggressive, that's just all zealots really.
I wrote an entire celestial navigation program for the HP48GX calculator about 20 years ago. The HP RPL programming language is a lot like Forth. It worked well. But I'm not going to do it again!
As much as I like RPN for instant calculation, I personally wouldn't consider it for a programming language beyond very simple tasks, just because that's pretty much unreadable after a while compared to many other kinds of notation. Of course we're not all the same, and some people may be "hardwired" to find this actually more readable. Maybe.
-
Unfortunately Arduino is not always fast getting results, especially in instances when where no library is available, such as the LMT-01 two wire (not Dallas 2 wire) temperature sensor from Ti.
Unbelievably I see Ti have even included Arduino example code in their official training webpage ... words fail me.
https://training.ti.com/how-interface-lmt01-temperature-sensor-arduino
I did however find a Arduino user very frustrated in Apr 06, 2018, when trying to get his LMT-01 sensor going. There is no [solved] followup to that thread.
https://arduino.stackexchange.com/questions/51588/lmt01-temperature-sensor-code-does-not-run-need-help
"So to repeat myself only Pin2 is attached with the LMT01 to the Arduino. Why doesn't this &!#^-thing work, it compiled and uploaded correctly. If I had a debugger on this software, moving one line at a time I could fix it myself"
Well, he clearly didn't do his homework. Pin 2 is not acceptable, the input must be on AIN1 to use TI's recommended analog comparator approach.
From the datasheet, you know this is a pulse counting operation and you can pretty well guess the code will use interrupts so we're out of the Arduino libraries and into the AVR Libc libraries. And, necessarily, there is an order of magnitude more experience required. But that's the cool part of the Arduino and AVR Libc, you can get down in the dirt if you need to. In fact, you can blow off the Arduino libraries altogether and just use AVR Libc. Same board, same bootloader, same crappy IDE...
The same kind of code is required on any platform and I still don't see where it would be faster to implement the LMT01 with something like STM32F446 because it doesn't even have a comparator. Considering the slow edges and available voltage (from current) span, a Schmidt Trigger would seem to be a minimum requirement but maybe with care a pin change interrupt can work.
It isn't going to be nearly as fast to write the code for the '446 (or whatever) as it is for the Arduino. The total AVR Libc stuff required was one line of code to setup the analog comparator and a one line interrupt handler. Now, true, they have to be the right lines of code... I have nothing for or against the '446, it's just the first datasheet that Google returned. And I like the ST products, I have several of their boards and I really like the ones that are mbed compatible.
Interrupts are going to be beyond many Arduino users but that doesn't get better for them on any other platform and the fact that they chose a pulse counting sensor was their first mistake. If you can't find a library, don't buy the sensor! Unless you can write it yourself, of course.
It was nice of TI to create the tutorial and provide the code. I wonder why they did that? Maybe because the Arduino is so popular? You can bet there was a business reason for producing it.
-
I did read the datasheet and know very well how to write the code. I also read the App Note - did you find that? It details the calculations and provides the proper values for a 400 Hz sine wave. Kind of handy... I also read over the library code and there were no surprises and, of course, the application itself just makes a couple of library calls. Over and done.
How could all that take you 5 minutes?
Nothing else to do while I waited for the delivery. It was boring...
In the case of the library and the AD9833, none of the datasheet information is necessary to get a sine wave. Sure, I read it over but nothing I read was necessary for using the device other than the pinout and that was shown on the silkscreen of the demo board. I didn't need to know there are multiple phase and frequency registers, I didn't need to know 2^28, I didn't even need to know that the crystal was 25 MHz although that could come in handy if I were generating high frequency signals. But given that there are 62,500 clocks in one 400 Hz cycle, I don't imagine I am going to be short on samples. The information was "nice to know" but not necessarily "need to know".
All of the above applies to getting a simple output. Clearly there is more to it than that but the API provides a number of functions for changing frequency and phase, incrementing or decrementing either and so on. It's all laid out in the code and the comments are pretty good.
But, pretty much, it's plug and play. Five wires and out comes a sine wave. Other approaches would have the programmer still reading through the index of the datasheet to find the SPI peripheral, and the power control register and the clock control register and whatever other predicates apply. Oh, wait, you mean the SPI gadget isn't powered up by default? What do you mean I have to turn on the clock? How fast can the SPI bus run and how do I set the clock divider?
-
As much as I like RPN for instant calculation, I personally wouldn't consider it for a programming language beyond very simple tasks, just because that's pretty much unreadable after a while compared to many other kinds of notation. Of course we're not all the same, and some people may be "hardwired" to find this actually more readable. Maybe.
RPN is useful at the keyboard but RPL is the internal programming language and it is somewhat more expansive. Things like selectable menus are written in RPL as is the application user interface. I think I was still using Windows 3.1 when I wrote the celestial stuff. Pretty sure the code is long gone!
I have been using RPN since the early '70s and my HP48GX calculator is right next to my PC keyboard. I have a lot of other calculators but the GX is, by far, my favorite.
-
RPN is useful at the keyboard but RPL is the internal programming language and it is somewhat more expansive.
I know. I've written quite a few utilities in RPL at the time. I meant RPN as in what it means: a notation. RPL uses RPN as a notation, like Forth. It makes a program kinda hard to read after you've written it. AFAIR, the only addition in RPL that made things a bit easier is the ability to store parameters in an ordered fashion in variables with the '->' symbol (old memories so, hoping I remember that right), so that was kind of a "workaround" in some cases to make things a bit clearer than just completely relying on manipulating the stack (which is obviously powerful but hard to read and manipulate once your program grows).
RPN is very practical for calculation entry in calculators, because it minimizes keystrokes and avoids the potential pitfalls of not getting the parentheses right.
In a programming language, it makes the parsing and execution extremely fast and simple, but I personally think it gets unreadable really quick.
I have been using RPN since the early '70s and my HP48GX calculator is right next to my PC keyboard. I have a lot of other calculators but the GX is, by far, my favorite.
I still have a HP48G+. Like it (although I use it less and less). I have also owned a 28S before that. I use many other tools now on computer or phone/tablet, but if I was still using a real calculator on a regular basis, I would consider buying a DM42 (SwissMicros)...
-
Sure, I read it over but nothing I read was necessary for using the device other than the pinout and that was shown on the silkscreen of the demo board.
<snip>
But, pretty much, it's plug and play. Five wires and out comes a sine wave. Other approaches would have the programmer still reading through the index of the datasheet to find the SPI peripheral, and the power control register and the clock control register and whatever other predicates apply. Oh, wait, you mean the SPI gadget isn't powered up by default? What do you mean I have to turn on the clock? How fast can the SPI bus run and how do I set the clock divider?
See. You have looked at the AD9833 datasheet, also the app note, the library comments, and possibly datasheets of other similar DDS devices. This wasn't necessary. Nobody made you to. Nobody paid you to. You did this work voluntarily, at your own free will. And, by your own words, it was nice to know.
However, when it comes to looking at the SPI chapter for the MCU (which is not that dissimilar from looking at the AD9833 datasheet) you regard this as a hard work where every hour is as bad as losing $100. But may be it's nice to know too? May be if you did that, you would find it useful, as it gives you power to write your own code. And this power alone may save you hours when you move beyond the single sine wave to synchronizing multiple devices.
Of course, this is you who decides, but choosing to look at the AD9833 docs and totally despising SPI docs is not very rational. It is not clear why other people would want to follow your approach.
-
I did read your AD9833 post with interest (as I read all your posts with interest) and I also read NorthGuy's followup which said in part "It is simple SPI interface, with only 4 registers. You just set 28-bit frequency and 12-bit phase register. That's all. See, I already know how to set the phase, and you're yet to figure how to use your library. Reading datasheet has put me way ahead of where you are with the library."
You seem to be making a couple of assumptions that are probably incorrect. I did read the datasheet and know very well how to write the code. I also read the App Note - did you find that? It details the calculations and provides the proper values for a 400 Hz sine wave. Kind of handy... I also read over the library code and there were no surprises and, of course, the application itself just makes a couple of library calls. Over and done.
Perhaps it's not the best example because getting a sine wave takes me about 5 seconds after I turn on my old PM5314 Philips 1 - 20 MHZ function generator.
I could do the same with my 80 MHz Siglent but the application for this gadget is a flight instrument, not a boxcar.
If you had claimed "Because getting results can be fast!" I couldn't really argue that point, because sure, getting the Arduino Blinky is as fast as the getting the Forth Blinky. Both only take seconds to upload to the chip.
Why keep bringing up Forth? It brings nothing to the Arduino topic and even less to the AD9833 sub-topic. I wrote an entire celestial navigation program for the HP48GX calculator about 20 years ago. The HP RPL programming language is a lot like Forth. It worked well. But I'm not going to do it again!
As to why people can't get particular pieces of hardware to work, well, some people should be polishing ball bearings instead of writing code. Sometimes it is actually necessary to read the datasheet but when it runs over 1000 pages, it's going to be a slog. The only way to approach it is one peripheral at a time. To be fair, this isn't a game for the test gear challenged. Without a logic analyzer and/or modern DSO, things will be very difficult. You can't fix what you can't see.
In the end, I'm lazy, not stupid. I can write the code if need be but if it already exists, why not save a bunch of time?
What's to happen with my AD9833 gadget(s)? I'll toss them in a drawer and, maybe, pull them out some day. This exercise was for proof of concept, not production. Chances are good I will never use them for anything practical.
You're putting Arduino into FLIGHT INSTRUMENTS ? Well at least if anyone wants some Arduno gear for free they will only have to wait for it to crash land in their back yard. Ok, ok, I know you said "This exercise was for proof of concept, not production." but you might as well have just drawn a nicely colored picture because we both know that has as much chance of going into a flight instrument as anything Arduino.
I keep bringing up Forth because the topic is "Why Arduino users so aggressive?" ... you're not feeling aggressive because I'm suggesting that something else is better than Arduino are you ? ;)
And as to the AD9833 sub-topic, of course Forth is 100% relevant. Forth is perfect for such projects even if you can't see it thru those Arduino colored glasses you're wearing.
In my world it's 100% vital to read the datasheets and it has never been a "slog" for me. I've always loved electronics and datasheets but now I see a whole sub culture of people who don't love electronics, they hate datasheets, they hate taking more than five minutes to code anything and they're proud of it.
I agree that electronics is probably not for these people. However along comes Arduino and sells them the idea that electronics IS for them. Now we have a massive 'community' of people who should never have gone near a soldering iron infesting the Internet with plaintive cries for help because they are utterly lost and alone.
That's not my fault, it's your fault for suggesting to these people that Arduino is so wonderful, just 'load a library' and it's all done in 5 minutes so they still have time to catch today's hour long episode of "Dr Phill" on tv.
Even tho you know what you're doing, you read the data sheet, you read and understood the premade Arduino code, then you used the Arduino code that someone else wrote. How incredibly convenient you didn't have any problems with sharing resources in the MCU for YOUR PART OF THE PROJECT, or want to use multitasking or something DIFFERENT from a "off the rack" solution.
To me that's like reading about the latest strawberry flavoured icecream, driving to the shop and buying some, then giving it to someone else to eat.
-
I still have a HP48G+. Like it (although I use it less and less). I have also owned a 28S before that. I use many other tools now on computer or phone/tablet, but if I was still using a real calculator on a regular basis, I would consider buying a DM42 (SwissMicros)...
I had read about the DM42 quite some time back and had given it some consideration. Probably just to support the effort, I already have calculators. I see where they are still having keyboard problems as of August 2019. I can wait...
However, the DM42 led to Free42 which led to a very capable calculator being installed on my cell phone. Now to find the manuals...
-
Why keep bringing up Forth?
Well, I agree this looks sometimes out of place, and I told him so in another topic (I probably got blacklisted ;D ).
Not by me. I may disagree with you now and again but you're experienced and intelligent, and say it as you see it. I enjoy reading your posts.
If I wanted to be in a community where everyone thought alike, like clones of each other, I'd be an Arduino user ;-)
-
You're putting Arduino into FLIGHT INSTRUMENTS ? Well at least if anyone wants some Arduno gear for free they will only have to wait for it to crash land in their back yard. Ok, ok, I know you said "This exercise was for proof of concept, not production." but you might as well have just drawn a nicely colored picture because we both know that has as much chance of going into a flight instrument as anything Arduino.
Way back in this thread I posted a link to a thread in Projects forum where the OP wants to drive a real ADI (Attitude Director Indicator) from the digital outputs of a hobby grade flight simulator. It turns out that the ADI needs 3 400 Hz signals to rotate the ball. He wasn't clear (to me) on all the details but, at a minimum, the 3 signals need to be amplitude modulated. The amplitude apparently determines the angle of rotation for the ball. It is not clear to me whether there needs to be 120 degree phase shifts. Doesn't matter, the AD9833 will do that.
The proposed alternative was the typical sin() look-up table which quickly gets out of hand if a reasonable number of samples are considered. Think about 400 Hz and 1024 samples: That's 409,600 timer interrupts per second if that is the approached used to feed the DAC. Plus the possibility of handling the phase shifting if that is required. Not even a remote possibility for an ATmega328 and unlikely on most other platforms as well. In any event, since amplitude modulation is likely the only requirement, first generate a baseline 400 Hz sine wave and then use 3 analog multipliers with the Y inputs fed from DACs controlled by the Arduino in response to changes in the digital values thrown off by the flight simulator. The amplitude won't change often but there are extra points if the motion is smooth and accurate. Offloading the sine wave generation leaves a lot of time for the Arduino to receive and interpret the data stream.
Seems simple enough, once the 400 Hz issue is resolved. Done! Proof of concept complete. The rest is just details.
ADI:
https://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/VMS_Artificial_Horizon.jpg/184px-VMS_Artificial_Horizon.jpg
https://worldofaircraftdesign.files.wordpress.com/2012/06/attitude-director-indicator.jpg
-
You're putting Arduino into FLIGHT INSTRUMENTS ? Well at least if anyone wants some Arduno gear for free they will only have to wait for it to crash land in their back yard. Ok, ok, I know you said "This exercise was for proof of concept, not production." but you might as well have just drawn a nicely colored picture because we both know that has as much chance of going into a flight instrument as anything Arduino.
..
The proposed alternative was the typical sin() look-up table which quickly gets out of hand if a reasonable number of samples are considered. Think about 400 Hz and 1024 samples: That's 409,600 timer interrupts per second if that is the approached used to feed the DAC.
...
a +400khz sample rate for a 400Hz sine wave is silly, a few kHz will do. You step through the table at a rate that makes 400Hz at your sample rate, just like the AD9833 does
-
In my world it's 100% vital to read the datasheets and it has never been a "slog" for me. I've always loved electronics and datasheets but now I see a whole sub culture of people who don't love electronics, they hate datasheets, they hate taking more than five minutes to code anything and they're proud of it.
I agree that electronics is probably not for these people. However along comes Arduino and sells them the idea that electronics IS for them. Now we have a massive 'community' of people who should never have gone near a soldering iron infesting the Internet with plaintive cries for help because they are utterly lost and alone.
That's not my fault, it's your fault for suggesting to these people that Arduino is so wonderful, just 'load a library' and it's all done in 5 minutes so they still have time to catch today's hour long episode of "Dr Phill" on tv.
So, rather than help them accomplish their goals we should just tell them they are too stupid to ever understand electronics and they should walk away? Nonsense! If I have time, I'll provide what help I can.
Even tho you know what you're doing, you read the data sheet, you read and understood the premade Arduino code, then you used the Arduino code that someone else wrote. How incredibly convenient you didn't have any problems with sharing resources in the MCU for YOUR PART OF THE PROJECT, or want to use multitasking or something DIFFERENT from a "off the rack" solution.
To me that's like reading about the latest strawberry flavoured icecream, driving to the shop and buying some, then giving it to someone else to eat.
You seem to think that I just blow off the technical stuff. No! I just skip over it when I can. I just focus on where to spend time. If all I want is a 400 Hz sine wave, why spend time on it? Why reinvent the wheel that somebody has already produced. It's 'proof of concept', not production. Get in, get it done, move on!
Had the library not worked, and it doesn't when I try to use it with the Teensy 4.0 (32 bit ARM Cortex M7) then I would need to put in a little more time figuring out why the SPI doesn't work. But the OP wants to use an Arduino and I don't care enough about the AD9833 to write a library for the ARM so the project is complete.
Even if the OP uses an Arduino Nano dedicated to driving the ADI with no other functions, at $5 each, that's a bargain. Get in, get the ADI to work and move on to the next instrument. In fact, I would gang all of the Nanos together on an RS485 bus so each Nano could pick off the part it was interested in and skip over the rest. That could be a very workable scheme.
I did something similar about 10 years back when I was using a bigger AVR chip (ATmega128?) using HID to talk to the Microsoft Flight Simulator. All of my indicators were seven segment but today I would use those small LCD screens and have a CPU dedicated to each instrument. Maybe all of them would work as HID devices or maybe I would have a 'director' that handled the HID and sent the results over RS485. But I'm not working on that any more...
-
a +400khz sample rate for a 400Hz sine wave is silly, a few kHz will do. You step through the table at a rate that makes 400Hz at your sample rate, just like the AD9833 does
Will it? Are you sure? The ball needs to rotate smoothly and I don't know if 10 or 20 samples per waveform will be smooth or not.
The AD9833 sin() ROM uses 12 address bits (4096 steps) and a 10 bit DAC (back to 1024 steps).
-
a +400khz sample rate for a 400Hz sine wave is silly, a few kHz will do. You step through the table at a rate that makes 400Hz at your sample rate, just like the AD9833 does
Will it? Are you sure? The ball needs to rotate smoothly and I don't know if 10 or 20 samples per waveform will be smooth or not.
The AD9833 sin() ROM uses 12 address bits (4096 steps) and a 10 bit DAC (back to 1024 steps).
the 1024 steps is in amplitude, the AD9833 is meant for making 0-12.5MHz with a 25MHz sample rate, at that rate the input to the sin()
ROM will only change every ~15 samples to make 400Hz
44.1kHz is good enough for audio
-
Even tho you know what you're doing, you read the data sheet, you read and understood the premade Arduino code, then you used the Arduino code that someone else wrote. How incredibly convenient you didn't have any problems with sharing resources in the MCU for YOUR PART OF THE PROJECT, or want to use multitasking or something DIFFERENT from a "off the rack" solution.
You want multitasking? How about FreeRTOS on Arduino?
https://create.arduino.cc/projecthub/feilipu/using-freertos-multi-tasking-in-arduino-ebc3cc
It looks like the memory utilization isn't truly horrible in the Mega at just 3%
Complete, from bare metal, projects will take longer. They may be beyond the abilities of most Arduino users but they are certainly doable with AVR Libc. Don't like AVR Libc? Write your own! It's all workable on the Arduino plaltform even if the only Arduino left in the project is the board and chip. You can get as far down in the weeds as you want.
Personally, I'll build on the work of others.
-
It seems to me that the big stumbling block is likely to be the sink current needed to ensure a logic 0 output from the micro is recognized. A couple of 74F gates with some 2.2k pull-up resistors is going to stress some of those modern 4mA uC outputs (no, I didn’t check the stm32 specs - they are generally better than 4ma, right?)
The reason a TTL outputs needs to have such high sink capability is because ViL is allowed to be as low as 0.8V, but VoL is allowed to be as high as 0.5V, so there's no room to play in. CMOS outputs must have VoL no higher than 0.05V to be in spec. At the 25mA max sink (per another post; maybe this is wrong) for SMT32 part, the voltage of the pin is still no higher than 0.05V.
To compare current capability directly is comparing apples to oranges. 2.2K pullup to 5V is only 2.3 mA of current. I don't know how many you will want to put on the same bus line, but even if it's 10 of these 2.2K pullups, the worst 25mA sink-rated CMOS output should still produce lower node voltage than the worst example of 250mA rated TTL output. TTL output at this current draw might be lower than 0.05V (unlikely if it's a true BJT device; collector-emitter drop will probably be 0.2-0.3V off the bat), or it could be between that and 0.5V. The CMOS part will maintain 0.05V or less on its pin, as long as it is sinking less than its max rating. This leaves a lot more margin for noise immunity and cable loss than worst case of the TTL part.
Most modern 5V CMOS parts are made to be compatible with 5V TTL, even though CMOS spec allow it to not be compatible and still be in spec. Some 3.3V CMOS part are made that way, too, which is the case for STM32. Many CMOS microcontrollers should work just fine for GPIB. I guess what makes Arduino special is someone did it and shared it, and now you can just google it and make assumption that your case is the same. And you don't have to "reinvent the wheel" of learning basic electronics and understanding specs and datasheets. This is great, but to turn around and "demand working proof" that Techman can make STM32 do it is just crazy. Unless some errata, of course it works. You can tell that from the datasheet; there's no need to wait for someone else to do it and then tell you it's ok. The component company invested many man hours in compiling and detailing all of this information.
If you are building TTL bus that draws more than 25mA per data lines, you might want to try some higher efficiency technology, like maybe step your game up to vacuum tubes.
-
the 1024 steps is in amplitude, the AD9833 is meant for making 0-12.5MHz with a 25MHz sample rate, at that rate the input to the sin()
ROM will only change every ~15 samples to make 400Hz
44.1kHz is good enough for audio
Every 15 samples is about 1.6 MHz. It is well above 44 kHz.
However, the resolution is not necessary. If only 400 Hz sine wave is needed everything can be smoothed by a low-pass filter with a knee close to 400 Hz. Perhaps, even a relatively low frequency PWM may work. You can simulate the filter and see what frequency PWM produces acceptable results. If your CPU can produce the frequency, then you can replace the three AD9833 with a single MCU which costs a fraction of the AD9833 price.
-
You want multitasking? How about FreeRTOS on Arduino?
Good one. Old generation simply can't stand that grandkids spend 5 minutes for task that required many days of blood, sweat & smell of rosin for them.
-
the 1024 steps is in amplitude, the AD9833 is meant for making 0-12.5MHz with a 25MHz sample rate, at that rate the input to the sin()
ROM will only change every ~15 samples to make 400Hz
44.1kHz is good enough for audio
Every 15 samples is about 1.6 MHz. It is well above 44 kHz.
sure, and 1.6MHz is very much overkill for 400Hz
However, the resolution is not necessary. If only 400 Hz sine wave is needed everything can be smoothed by a low-pass filter with a knee close to 400 Hz. Perhaps, even a relatively low frequency PWM may work. You can simulate the filter and see what frequency PWM produces acceptable results. If your CPU can produce the frequency, then you can replace the three AD9833 with a single MCU which costs a fraction of the AD9833 price.
agreed
-
You're putting Arduino into FLIGHT INSTRUMENTS ? Well at least if anyone wants some Arduno gear for free they will only have to wait for it to crash land in their back yard. Ok, ok, I know you said "This exercise was for proof of concept, not production." but you might as well have just drawn a nicely colored picture because we both know that has as much chance of going into a flight instrument as anything Arduino.
Way back in this thread I posted a link to a thread in Projects forum where the OP wants to drive a real ADI (Attitude Director Indicator) from the digital outputs of a hobby grade flight simulator. It turns out that the ADI needs 3 400 Hz signals to rotate the ball. He wasn't clear (to me) on all the details but, at a minimum, the 3 signals need to be amplitude modulated. The amplitude apparently determines the angle of rotation for the ball. It is not clear to me whether there needs to be 120 degree phase shifts. Doesn't matter, the AD9833 will do that.
The proposed alternative was the typical sin() look-up table which quickly gets out of hand if a reasonable number of samples are considered. Think about 400 Hz and 1024 samples: That's 409,600 timer interrupts per second if that is the approached used to feed the DAC. Plus the possibility of handling the phase shifting if that is required. Not even a remote possibility for an ATmega328 and unlikely on most other platforms as well. In any event, since amplitude modulation is likely the only requirement, first generate a baseline 400 Hz sine wave and then use 3 analog multipliers with the Y inputs fed from DACs controlled by the Arduino in response to changes in the digital values thrown off by the flight simulator. The amplitude won't change often but there are extra points if the motion is smooth and accurate. Offloading the sine wave generation leaves a lot of time for the Arduino to receive and interpret the data stream.
Seems simple enough, once the 400 Hz issue is resolved. Done! Proof of concept complete. The rest is just details.
ADI:
https://upload.wikimedia.org/wikipedia/commons/thumb/c/c5/VMS_Artificial_Horizon.jpg/184px-VMS_Artificial_Horizon.jpg
https://worldofaircraftdesign.files.wordpress.com/2012/06/attitude-director-indicator.jpg
Nice project, I see why you chose the AD9833 and if it's in a hobby FS, who cares what's driving it.
-
Buying a waveform generator to make a sine wave is like buying a CNC machine to draw a circle.
CNC machine guy: But can you draw other shapes with your string?
Guy with a string: No. What are you using your CNC machine for, again?
-
You can build a GPIB to USB adapter with almost ANY microcontroller. (If it does not have USB, you will have to use or emulate serial communication towards an RS232 to USB adapter).
All it needs to do is to be able to pull LO 0.5v sinking max 3.2mA, and HI 2.5v sourcing max 2.5mA. This assuming that you connect only a single GPIB device to the adapter. I am sure all the GBIB commenters here would have realized this had they investigated the easy searchable relevant GBIP specs before they had posted:
IEEE-STD-488 I/O Characteristics Single Type Digital Value
Input Voltage High: VIH = 3.4 volts typical, 2.4 volts minimum
Input Voltage Low: VIL = 0.22 volts typical, 0.4 volts maximum
Input Current High: IIH = 2.5mA maximum
Input Current Low: VIL = -3.2mA maximum
Output Voltage High: VOH = 3.4 volts typical, 2.5 volts minimum
Output Voltage Low: VOL = 0.22 volts typical, 0.5 volts maximum
Output Current High: IOH = -5.2mA maximum
Output Current Low: IOL = 48mA maximum
The confusion about current arises from the 48mA value above: The bus is speced for max 16 devices. One of these will pull the line LO, and the other 15 will read the LO level with a max current draw of 15x3.2mA=48mA. Voila. Avoided by connecting a single or a few instruments at the same time.
The reason Arduino was used to make these devices first is simple. They were made by people who were interested in GPIB connectivity, and neither had much knowledge nor interest in microcontrollers.
And the reason they took the effort was that these adapters often were and in some cases still today are priced up to 1kUSD (Please note that the IEEE-STD-488 bus is some 30 years old and is phased out by many vendors).
A typical example would be:
(https://s7.images.keysight.com/s7viewers/html5/ZoomViewer.html?asset=Keysight/PROD-851808-IS)
US$ 594 https://www.keysight.com/en/pd-851808-pn-82357B/usb-gpib-interface-high-speed-usb-20?cc=US&lc=eng (https://www.keysight.com/en/pd-851808-pn-82357B/usb-gpib-interface-high-speed-usb-20?cc=US&lc=eng)
Finally, since probably most of the people wanting such an adapter are satisfied if the gadget works, my guess is that none of the users find it fruitful to use their often scarce spare time to "reinvent" anything at all. Hence it appears that most of these adapter boards still are based on Arduino.
-
Input Voltage Low: VIL = 0.22 volts typical, 0.4 volts maximum
Output Voltage Low: VOL = 0.22 volts typical, 0.5 volts maximum
It must have been harder to make thing work, back then.
-
.
.
I love reading such accounts as yours and NorthGuy because as a Forth user I always write all my own code. When I see Arduino users talking about 'libraries' for such things I always wonder " does it use DMA or Interrupts or both, what actual chip options are configurable to the user, is it running in a multitasking system, what user tests and calibration are available" and so on.
About January of this year I bought a few Ti LMT-01 temperature sensors, read the small tech manual, then looked around the Internet to see if anyone had used them. I found only two Arduino examples, and both used the Ti reference from the datasheet, namely they ran continuously reading one sensor as fast as they could.
I thought this method was a waste of a MCU, so my Forth design uses any (reasonable) number of LMT-01 sensors and reads them as commanded in a multitasking system using interrupts and timers. This allows the sensors to be used in various applications from reading wet/dry bulb humidity to accurate battery charge levels and it uses almost no CPU time therefore allowing plenty of other things to be done including instant response from a connected interactive realtime serial terminal..
It runs on a STM32F0 Discovery board but only needs a STM32F0xx MCU. I know exactly how it works, what the weak points are, what the strong points are because I designed it.
I also found the Ti LMT-01 is highly accurate out of the box. http://www.ti.com/lit/ds/symlink/lmt01.pdf (http://www.ti.com/lit/ds/symlink/lmt01.pdf)
I apologize in advance for my terrible Forth code, (not that many here will know that) but as it's Open Source I may as well give the link which includes a bonus flowchart, and utube video :-+
https://mecrisp-stellaris-folkdoc.sourceforge.io/project.3temp.sensors.html?highlight=temperature (https://mecrisp-stellaris-folkdoc.sourceforge.io/project.3temp.sensors.html?highlight=temperature)
Waveforms are via my 1994 HP54601A DSO using the RS232 module and a shell script on FreeBSD. No GPIB required ;-)
Now I suddenly remember why I dropped Forth sometime in the early 80'...
The "reason you as a Forth user writes your own code", maybe because no one else uses it, so not much to copy from ?
Are you kidding ???
[attach=1]
-
^Oh, that's not too bad.
One of these will pull the line LO, and the other 15 will read the LO level with a max current draw of 15x3.2mA=48mA. Voila.
Aha, yeah. My bad. I was wrong about the current sink needs. I looked up some old datasheets, and Iil (Current input lo) of 7400 series was -2mA, with the more recent LS versions (in what the 70 or 80's) at around 0.4mA. Holy cow. But Iih still very low, like microamps. So I don't know when rstopher learned to use such beefy pullup resistors, but I think it was a long time ago. More recent BJT parts should be pretty ok with 10K+? 100K maybe?
-
Now I suddenly remember why I dropped Forth sometime in the early 80'...
The "reason you as a Forth user writes your own code", maybe because no one else uses it, so not much to copy from ?
Are you kidding ???
(Attachment Link)
It's true that there are few STM32 Forth users (at least from my observations) but that's not why I write my own code any more than any other developer using any other language.
You're right there isn't much online Forth code for my MCU to copy from, and for a while when I was learning STM32 Cortex-M I was using any online C and assembly examples I could find, preferring Assembly because of the greater detail at the low level, but it was slow going.
So a few years ago I wrote my own XSL Transformations to process CMSIS-SVD xml files into Forth memory maps and bitfield templates.
A lot of the text in the picture you attached are AUTOMATICALLY generated BITFIELD configuration templates. The names are the same as you will find in the STM32 technical documents for the model of MCU used here.
This one is for the CEN bit, CR1 Register, TIM6 peripheral in a STM32F051. and I can ENABLE it with the following command "tim6_cr1_cen".
: tim6_cr1_cen ( -- ) %1 0 lshift tim6_cr1 hbis! ; \ tim6_cr1_cen counter enable
There is nothing beautiful about such auto-generated code any more than a auto-generated C header file. Note that it has the STM 'description' field at the end, it's the same as in the databook and makes manual selection from the template file a lot easier as I can see at a glance that it's the TIM6 "counter enable bit".
This one is a function I've written to power up the first LMT-01 temperature sensor, number 1. First it configures the GOIO pin connected to the sensor as a OUTPUT, then it performs a Atomic write to the GPIO pin setting it HIGH. These lines are pasted from the template file as described above so I have written very little of the code myself.
: lmt01-1.power.on ( -- )
output ( %xx -- ) 2 lshift gpioc_moder bis! \ gpioc_moder_moder1 PC1
%1 1 lshift gpioc_bsrr bis! \ gpioc_bsrr_bs1; output high
;
Does it still look as strange as it first did ?
-
.
.
.
Does it still look as strange as it first did ?
Yes.
Almost all (not quite but close) programming languages you can read and understand most of, even if you don't know the language already (talking about high-level languages here).
Not so much with this gibberish.
I had a co-worker some 30 years ago, he tried to convince me about the virtues of Forth, he never succeeded, now I remember why :)
I have programmed almost everything (I do this for a living) from PLM, Modula II, Ada, Pascal, C, C++, C# and Java (and probably more that I can't remember) the last 35 years, and these languages (most of them) you could read and understand most of, even if you did not know them before (aka "natural language").
-
Does it still look as strange as it first did ?
Yes.
The Forth world will just have to shoulder the bitter disappointment that a genius like you can't understand Forth without actually, you know .... LEARNING IT FIRST.
-
Does it still look as strange as it first did ?
Yes.
The Forth world will just have to shoulder the bitter disappointment that a genius like you can't understand Forth without actually, you know .... LEARNING IT FIRST.
OK :) I think most of us non-Forth users can live with that, not much chance of stumbling across something interesting written in Forth anyway ;)
-
Does it still look as strange as it first did ?
Yes.
The Forth world will just have to shoulder the bitter disappointment that a genius like you can't understand Forth without actually, you know .... LEARNING IT FIRST.
OK :) I think most of us non-Forth users can live with that, not much chance of stumbling across something interesting written in Forth anyway ;)
To be totally fair to you, most people don't program in 'Forth' anyway.
Forth is always used to construct a unique language (PDL) for the problem that is being solved, and every one is different.
Unlike PLM, Modula II, Ada, Pascal, C, C++, C# and Java programs, which always have the same syntax, Forth PDL syntax is always different.
For example the HLL part of my temperature code which takes the sensor number as input and prints the temperature is below and sensor number one is being read:
1 read.temperature
You would be very unlikely to find this syntax anywhere else, and the command "read.temperature" is perfectly legal for *this Forth* PDL of mine. I'm fairly sure that you could get some idea what "1 read.temperature" means without knowing Forth ?
I could have named the syntax "1 degC?" or " 1 whats-the-temperature?" or anything I felt appropriate for the circumstances.
Nothing interesting in the Forth World ?
We have a 144 core native Forth speaking computer, the GA-144, not interested ?
The F18A is an unclocked, fully asynchronous computer which can execute basic instructions in 1.5
nanoseconds without instruction fetches, and sustained rates of 1.8 nanoseconds when instruction
words are fetched inline from RAM, with Vdd at 1.8V. The energy required to execute a basic
instruction is on the order of 7 picojoules (pJ).
http://www.greenarraychips.com/home/products/index.html (http://www.greenarraychips.com/home/products/index.html)
For those who are interested, this very well presented 2018 video shows a heart rate monitor design using the GA-144 above.
https://www.youtube.com/watch?v=1lcIn69umvU (https://www.youtube.com/watch?v=1lcIn69umvU)
-
Back to the AD9833: The goal was never to use the AD9833 demo board with an actual Arduino. I really wanted to play with my 600 MHz Teensy 4.0 board which uses the same infrastructure. Since the Arduino library didn't seem to work, I rolled my own from initialization values given in the App Note (AN1070).
As usual with SPI, the devil is in the settings. The App Note wanted to use 16 bit transfers and the device wanted the clock to idle high and clock the output on the falling edge (MODE2)
Without further fanfare:
#include <SPI.h>
#define FSYNC 10
void setup() {
uint16_t commands[] = {0x2100, 0x50c7, 0x4000, 0xC000, 0x2000};
uint8_t numOfCommands = sizeof(commands) / sizeof (commands[0]);
pinMode (FSYNC, OUTPUT);
digitalWrite(FSYNC, HIGH);
SPI.begin();
SPI.beginTransaction( SPISettings(4000000, MSBFIRST, SPI_MODE2) );
for (uint8_t i = 0; i < numOfCommands; i++) {
digitalWrite(FSYNC, LOW);
SPI.transfer16( commands[i] );
digitalWrite(FSYNC, HIGH);
}
SPI.endTransaction();
}
void loop() {
}
Having done this, I now have the 400 Hz sine wave with zero remaining overhead on the Teensy. It's over and done.
AFAICT, this code 'should' work on the Arduino. Maybe I'll check it someday but, for now, I'm done with this project. Really!
ETA: I changed the board to an Arduino Uno and recompiled the code. It works fine!. That's a pretty powerful concept: The code works on an ARM Cortex M7 or on an ATmega328P. 8 bit, 32 bit, doesn't matter! Same pins, same code, same crappy IDE...
-
Maybe I'll check it someday but, for now, I'm done with this project. Really!
Congratulations!
-
And the existing Arduino libraries were of no use! :P
-
Maybe I'll check it someday but, for now, I'm done with this project. Really!
Congratulations!
I did the test (edited reply above) and it works on the Uno
-
And the existing Arduino libraries were of no use! :P
Well, as a first approximation, the library didn't seem to work on the Teensy (although it certainly worked on the Arduino Uno) but let's not discount operator error. As I get older, that becomes more frequent.
-
Nothing interesting in the Forth World ?
No. Especially when you see that Forth preacher can't even read simple temperature sensor without language extension.
-
you can't understand Forth without actually, you know .... LEARNING IT FIRST.
Heh. I've notice that a FEATURE of "languages I like" is that programs are at least readable, and perhaps modifiable, by people who are NOT experts in the language. The set of Algol-inspired languages are pretty good in that respect. Assembly languages are sort-of OK for moderately traditional architectures, assuming that you have some expertise in SOME assembly language.
Forth and APL - not so much...
that Forth preacher can't [do anything] without language extension.
But ... that's how Forth DOES THINGS.Not allowing for that is like complaining that you can't program in Smalltalk without constantly referring to the Class Browser, or about C++ redefining a shift operator to do IO, or about bash shell scripts using large applications to do simple things (all of which I've complained about, BTW.)
Arduino Users (and Forth Users, and a lot of other XXX Users) aren't so much "aggressive" as "defensive."And they're defensive because they're often attacked...
-
Why not use Brainfuck while we're at it? It is Turing-complete apparently: http://www.iwriteiam.nl/Ha_bf_Turing.html (http://www.iwriteiam.nl/Ha_bf_Turing.html)
https://en.wikipedia.org/wiki/Brainfuck (https://en.wikipedia.org/wiki/Brainfuck)
Anyone willing to try implementing a version of Brainfuck for Cortex-M targets? ;D
-
<snip the interesting AD9833 work, if you're done with it, so am I >
ETA: I changed the board to an Arduino Uno and recompiled the code. It works fine!. That's a pretty powerful concept: The code works on an ARM Cortex M7 or on an ATmega328P. 8 bit, 32 bit, doesn't matter! Same pins, same code, same crappy IDE...
That is pretty neat, Arduino works 'equally well' driving a VW Beetle or a F22 fighter jet!
I have to wonder how the VW Beetle handles at Mach1 or the F22 driving to the local drive in cinema to see a film ?
-
Nothing interesting in the Forth World ?
No. Especially when you see that Forth preacher can't even read simple temperature sensor without language extension.
I don't understand, could you elaborate what you mean by "language extension" ?
-
That is pretty neat, Arduino works 'equally well' driving a VW Beetle or a F22 fighter jet!
Yes, there's even a rumor about Tesla considering using Arduino for their next gen autonomous driving units. :-DD
-
that Forth preacher can't [do anything] without language extension.
But ... that's how Forth DOES THINGS.
That was exactly my point - adding *unnecessary* language extensions is bad style of programming because it leads to unreadable, unsustainable in the long run code.
Not allowing for that is like complaining that you can't program in Smalltalk without constantly referring to the Class Browser, or about C++ redefining a shift operator to do IO
Redefining shift operator is common (cstdio) practice, it does not obfuscate anything. Every C++ programmer will immediately know what "shift operator to do IO" means.
Arduino Users (and Forth Users, and a lot of other XXX Users) aren't so much "aggressive" as "defensive."And they're defensive because they're often attacked...
Here Forth User promotes his "Forth mantra" very aggressively. That is far from "defensive".
I don't understand, could you elaborate what you mean by "language extension" ?
Language extensions means - you are *extending* programming language, adding new keywords & operators.
-
you can't understand Forth without actually, you know .... LEARNING IT FIRST.
Heh. I've notice that a FEATURE of "languages I like" is that programs are at least readable, and perhaps modifiable, by people who are NOT experts in the language. The set of Algol-inspired languages are pretty good in that respect. Assembly languages are sort-of OK for moderately traditional architectures, assuming that you have some expertise in SOME assembly language.
Forth and APL - not so much...
that Forth preacher can't [do anything] without language extension.
But ... that's how Forth DOES THINGS.Not allowing for that is like complaining that you can't program in Smalltalk without constantly referring to the Class Browser, or about C++ redefining a shift operator to do IO, or about bash shell scripts using large applications to do simple things (all of which I've complained about, BTW.)
Arduino Users (and Forth Users, and a lot of other XXX Users) aren't so much "aggressive" as "defensive."And they're defensive because they're often attacked...
So true and I think that the more common languages one knows, the easier others are to understand. That's a maxim for programmers anyway.
Forth is the exception along with LISP. Even the designer of Forth, Charles Moore said when asked "what is Forth" ... "I can't say for sure, but I know it when I see it".
Westfw; a very insightful explanation about Forth's main strength, you obviously "get it".
-
that Forth preacher can't [do anything] without language extension.
But ... that's how Forth DOES THINGS.
That was exactly my point - adding *unnecessary* language extensions is bad style of programming because it leads to unreadable, unsustainable in the long run code.
Not allowing for that is like complaining that you can't program in Smalltalk without constantly referring to the Class Browser, or about C++ redefining a shift operator to do IO
Redefining shift operator is common (cstdio) practice, it does not obfuscate anything. Every C++ programmer will immediately know what "shift operator to do IO" means.
Arduino Users (and Forth Users, and a lot of other XXX Users) aren't so much "aggressive" as "defensive."And they're defensive because they're often attacked...
Here Forth User promotes his "Forth mantra" very aggressively. That is far from "defensive".
I don't understand, could you elaborate what you mean by "language extension" ?
Language extensions means - you are *extending* programming language, adding new keywords & operators.
So you're a computer language scientist? obviously one of renown to be able to make such sweeping condemnations of Forth, especially here among this distinguished company.
I'm sorry if you feel threatened by me, I hope you have a "safe space" nearby ?
It must be horrible for you to have your dearly held programming paradigms shoved aside so brutally by Forth, I can only imagine your confusion and distress.
-
That is pretty neat, Arduino works 'equally well' driving a VW Beetle or a F22 fighter jet!
Yes, there's even a rumor about Tesla considering using Arduino for their next gen autonomous driving units. :-DD
You must be right because I heard a rumor about Big Oil buying Microchip/Atmel so they can close the factories and end the whole product line!
-
I’m sure people are terrified by the paradigms of what at this point is a curiosity from the digital middle ages. They quiver at the convenience of having to write half the language themselves.
-
I’m sure people are terrified by the paradigms of what at this point is a curiosity from the digital middle ages. They quiver at the convenience of having to write half the language themselves.
Actually Forth was developed during the First Age of Enlightenment, long before the Arduino Dark Ages when trolls like you were dispatched by their masters to spread FUD to the far corners of the Earth.
While plagiarism is clearly your best skill, there are designers who enjoy and excel at crafting their unique designs, and these often include software.
You just don't know any.
-
So you're a computer language scientist?
No credentials are necessary to know that Forth is playground programming language for prototyping, research and hobby. No serious things are made using Forth and if they were - better manufacturers put "Forth inside" sticker on so we know what to avoid. There is no "MISRA Forth" for a reason, but MISRA C and MISRA C++ instead.
-
So you're a computer language scientist?
No credentials are necessary to know that Forth is playground programming language for prototyping, research and hobby. No serious things are made using Forth and if they were - better manufacturers put "Forth inside" sticker on so we know what to avoid. There is no "MISRA Forth" for a reason, but MISRA C and MISRA C++ instead.
NASA may disagree with you, not that you'd (obviously) ever acknowledge it.
MISRA - The Motor Industry Software Reliability Association.
"MISRA C is a set of software development guidelines for the C programming language developed by MISRA. Its aims are to facilitate code safety, security, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C / C90 / C99."
It seems that MISRA is claiming that C and C++ are unsafe in the context of embedded systems?
"aims are to facilitate code safety, security, portability and reliability in the context of embedded systems"
Maybe they should use Forth like NASA ?
-
It seems that MISRA is claiming that C and C++ are unsafe in the context of embedded systems?
:palm:
Maybe they should use Forth like NASA ?
Stack-based, no type checking programming language for mission critical systems? - LOL. NASA used Forth exclusively on science, research & some comms hardware. Their Forth project page is long gone, last seen 14 April 2003: https://web.archive.org/web/20110204160744/http://forth.gsfc.nasa.gov/ (https://web.archive.org/web/20110204160744/http://forth.gsfc.nasa.gov/)
-
I think it's a mistake to assume that decisions in space flight are made totally on the merits or that space flight is any less fraught with personal preferences and politics than any other engineering endeavor that humans undertake.
The saga of Lisp at JPL: http://www.flownet.com/gat/jpl-lisp.html (http://www.flownet.com/gat/jpl-lisp.html)
I'm sure we can find screeds railing against other languages as well.
-
Maybe they should use Forth like NASA ?
Stack-based, no type checking programming language for mission critical systems? - LOL. NASA used Forth exclusively on science, research & some comms hardware. Their Forth project page is long gone, last seen 14 April 2003: https://web.archive.org/web/20110204160744/http://forth.gsfc.nasa.gov/ (https://web.archive.org/web/20110204160744/http://forth.gsfc.nasa.gov/)
Forth was used in 8 on board mission critical computers on the ESA Philae Spacecraft in 2014, that's a little later than 14 April 2003, not that you would ever acknowledge it.
Forth is being used right now, today. One new device is a wearable unit for the treatment of chronic back pain.
Perhaps they will make one for people like you who suffer debilitating mental pain every time they see the word "Forth" ?
-
I think it's a mistake to assume that decisions in space flight are made totally on the merits or that space flight is any less fraught with personal preferences and politics than any other engineering endeavor that humans undertake.
The saga of Lisp at JPL: http://www.flownet.com/gat/jpl-lisp.html (http://www.flownet.com/gat/jpl-lisp.html)
I'm sure we can find screeds railing against other languages as well.
Thanks for the link, it's a fascinating story and so believable.
-
^You can just hit the thank you button, rather than copypasta an entire post just to say thank you.
Advice: when more than half the posts in a thread are from the same person, that person can appear to be a bit of a troll. Sitting down and quote/replying to 4-5 posts in a row? Not a good look.
I have no problem with anyone sharing something they are passionate about or proficient in, and even better if it is both. Keep it coming. Stop worrying about other people.
No need to quote/reply to this thread. If you read it, great. If you didn't, fine. Please don't reply.
-
But ... that's how Forth DOES THINGS.
That was exactly my point - adding *unnecessary* language extensions is bad style of programming because it leads to unreadable, unsustainable in the long run code.
Sort of like C++ operator overloading, or (more generally) objects with inconsistent method names and/or inheritance leading to inappropriate behavior and excessive memory use? Or, for that matter, macro use in assembly language. Seems to me that it's all a matter of programming style - if you do things that are widely, or even locally, standardized and common, it should all be OK. Redefine stuff or head off in weird directions, and you get an unreadable mess. (for example, I've looked at some of the C++ STL code, and find it ... so far removed from "basic C++" as to be essentially unreadable. (there's enough consistency there that I'm sure all that would clear up, given an appropriate style guide, mentor, and/or a couple of years of experience. Exactly!))
Forth was developed during the First Age of Enlightenment
Alas, I'd say that was developed somewhat before the first age of enlightenment, and suffers significantly from the whole "identifiers should be short to save storage space and typing" (like APL!) And thus it was standardized. Forth would be improved, IMO, if there were a standard set of "long" names for all the standard words (you know, like "print" instead of "." and "store" instead of "!")
(Heh. You'd get something that looked like Postscript, I guess. I rather liked Postscript...)
That is far from "defensive".
"The best defense is a good offense."
And we're talking about the "Aggressive Arduino Folk" too, remember.
Redefining shift operator is common (cstdio) practice ... Every C++ programmer will immediately know what "shift operator to do IO" means.
Well, too many "C++ programmers" won't know that it was a shift operator. They come into the embedded arena asking questions like "I don't see how UARTSTATUS & 1<<RXRDY checks the status bit when << is an output operation." (which really isn't that far from the confusion I experienced the first time I (a longtime embedded C programmer) saw stdio << "my number is" << mynumber. "Oh we'll just take a well-known binary operator and have the result of the operation be the same as the first operand, and do nothing but side-effects with the second operand." Yeah, that makes perfect sense.)
Language extensions means - you are *extending* programming language, adding new keywords & operators.
Technically speaking, I don't think that Forth HAS "operators" or "keywords." Everything is a function. Some functions are standardized...
-
Technically speaking, I don't think that Forth HAS "operators" or "keywords." Everything is a function. Some functions are standardized...
If you say so. BTW "command" was the name used by @techman-001. I assumed he had operator in mind. My bad.
Forth was used in 8 on board mission critical computers on the ESA Philae Spacecraft in 2014, that's a little later than 14 April 2003, not that you would ever acknowledge it.
Thank you. Now it is clear why it failed to fire thrusters during landing :D
Forth is being used right now, today. One new device is a wearable unit for the treatment of chronic back pain.
You managed to find not one but even two "Forth inside" embedded products dated after 2003. Congrats! With such approach one perhaps can prove that Perl or even PHP is very popular embedded language. My point of mentioning MISRA C/C++ was fact that those are standards for safety-critical systems including drive-by-wire. We rely our lives on MISRA C/C++ while driving modern cars. I do not see anybody using Forth in such systems. Every programming language have it's rights to exist, use Forth as much as you like, but as soon as you come with blanket statement "Forth computer is better than Arduino/whatever" - expect to defend your arguments. Perhaps fight was your intention, that's why you promoted your Forth so annoyingly?
-
Actually Forth was developed during the First Age of Enlightenment, long before the Arduino Dark Ages when trolls like you were dispatched by their masters to spread FUD to the far corners of the Earth.
While plagiarism is clearly your best skill, there are designers who enjoy and excel at crafting their unique designs, and these often include software.
You just don't know any.
In the mind of the extremist anyone who doesn't advocate his camp is part of the enemy. The real world obviously isn't black and white. I understand the acuity of the mind fading as you start running out of years and creativity may suffer as a consequence, but the troll remark didn't pan out the first three times so repetition is unlikely to yield different results. For someone who claims to have lived through the entirety of human history you seem confused about the order in which things occurred but I can imagine the memory fading after the first half century or so. The Dark Ages came before the Age of Enlightenment.
The use of libraries in which you partake but somehow also prefer to ridicule by calling it "plagiarism" would be a prime example of Isaac Newton's famous remark "If I have seen further it is by standing on the shoulders of Giants". As it happens this remark was part of the person and movement which launched Europe from the Middle Ages into Enlightenment by organizing the development of knowledge into something more structured. It's a method which allows people to utilize the work of others in useful ways. As fun as it is to reinvent the wheel it's not effective to start over from scratch every time. So much so that essentially the entire software industry works with building blocks developed by others. You can either roll your own inevitably shoddy version or use a library optimized to the hilt. Besides just writing your own code is an entirely arbitrary hill to die on. Why not design your own language or chips or get a shovel and some sand and get baking? You're blagging other's hard work whatever you do.
-
Forth is being used right now, today. One new device is a wearable unit for the treatment of chronic back pain.
You managed to find not one but even two "Forth inside" embedded products dated after 2003. Congrats!
You're welcome. it wasn't hard. I would have given more examples but why waste my time with you ?
-
Actually Forth was developed during the First Age of Enlightenment, long before the Arduino Dark Ages when trolls like you were dispatched by their masters to spread FUD to the far corners of the Earth.
While plagiarism is clearly your best skill, there are designers who enjoy and excel at crafting their unique designs, and these often include software.
You just don't know any.
In the mind of the extremist anyone who doesn't advocate his camp is part of the enemy.
Yes, yes, we all know that ... but enough about you and Arduino.
-
You managed to find not one but even two "Forth inside" embedded products dated after 2003. Congrats!
You're welcome. it wasn't hard. I would have given more examples but why waste my time with you ?
Don't bother indeed. It is clear that Forth is failing language because 50% of the examples you mention had programming error and remaining 50% has no trace in the internet search engines. Have a good one.
-
I think it's a mistake to assume that decisions in space flight are made totally on the merits or that space flight is any less fraught with personal preferences and politics than any other engineering endeavor that humans undertake.
The saga of Lisp at JPL: http://www.flownet.com/gat/jpl-lisp.html (http://www.flownet.com/gat/jpl-lisp.html)
I'm sure we can find screeds railing against other languages as well.
The one thing I took from that document was the inclination of the author to attribute code quality to the language it is written in. That's so common. You can write good reliable code in C and bad code in LISP.
-
Yes, yes, we all know that ... but enough about you and Arduino.
We know you like to needlessly repeat matters that have already been done but ignoring almost all of the very post you're responding to is a bit worrisome. It seems your mind may have slipped more than we already feared. Read the post a couple times more if you must. We'll go as slow as is needed for you to keep up. Meanwhile you may tell us how long it took you to write the temperature sensor code from start to finish so we have some objective metrics to compare.
-
No credentials are necessary to know that Forth is playground programming language for prototyping, research and hobby. No serious things are made using Forth and if they were - better manufacturers put "Forth inside" sticker on so we know what to avoid.
Ahem (https://web.archive.org/web/20101024223709/http://forth.gsfc.nasa.gov/).
-
No credentials are necessary to know that Forth is playground programming language for prototyping, research and hobby. No serious things are made using Forth and if they were - better manufacturers put "Forth inside" sticker on so we know what to avoid.
Ahem (https://web.archive.org/web/20101024223709/http://forth.gsfc.nasa.gov/).
You needed a webarchive to find that :-DD
NASA is not really representative for this sort of thing, they are looking for a COBOL / Fortran programmer to maintain their Voyager spacecraft that were launched when the Vietnam War was still going on and already left the solar system, cool hell yes, representative for businesses , hell no!
https://www.geek.com/news/nasa-seeks-programmer-fluent-in-60-year-old-languages-to-work-on-voyager-1638276/ (https://www.geek.com/news/nasa-seeks-programmer-fluent-in-60-year-old-languages-to-work-on-voyager-1638276/)
-
It was also already posted by ogden just a few posts earlier.
https://www.eevblog.com/forum/microcontrollers/why-arduino-users-so-agressive/msg2645217/#msg2645217 (https://www.eevblog.com/forum/microcontrollers/why-arduino-users-so-agressive/msg2645217/#msg2645217)
-
The use of libraries ... would be a prime example of Isaac Newton's famous remark "If I have seen further it is by standing on the shoulders of Giants".
You're confusing Engineering for Science. Newton was a scientists, who discovered laws of physics which existed before him. He just managed to see them. Similarly, a person who invented a wheel discovered that you need less effort to roll things than to drag them. For sure, he didn't create the principle. The principle existed before him. Then he used the newly discovered to create his first wheel. That's what engineers do - they do not discover laws of physics, they use them do design things. Over the centuries, they engineered lots of stuff based on the wheel principle - ball bearings, conveyors etc.
Once the principle is known, you cannot discover it again. You cannot discover Newton's laws because they're already discovered, and you cannot re-invent the wheel. However, you can engineer all sorts of mechanisms which use laws of physics discovered by others.
If you build something, you use a wheel which fits your goals. If you build a tricycle, you buy a tricycle wheel. If you build a Ferrari, you buy a Ferrari wheel. If you're not satisfied with any previously designed wheel, you design your own. Sure, there will be lots of people who yank your sleeve and convince you not to re-invent the wheel. But if these people were listened to, we would still use the same primordial wooden wheels instead of huge variety of wheels you see around you now. Fortunately, there always were (and hopefully will be) people who design new wheels, and all of them use the same old principle which was used by the original wheel inventor. How wonderful.
-
Good points.
The famous "don't reinvent the wheel" can be as reasonable as it can be utterly misleading.
Using something not quite adapted to your requirements just because it already exists is not always the smartest thing to do engineering-wise.
As I already said, whatever solution you choose, make sure you do it for a reason, not just out of sheer luck or lazyness. And if possible, make sure this is a good reason. There are often more bad reasons to do something that there are good reasons.
We can illustrate this with even very simple examples, that may be too simple to even be considered, at first glance, as a good reason to "reinvent the wheel".
Let's take an apparently very simple and mundane thing: a sorting function. Let's suppose you're developing code for a small embedded target. Now there are thousands of existing code to be found on the Internet, and more obviously the well-known 'qsort' function from the C Std library. So it would be easy to think that rewriting such a function for your project is completely stupid and insane. With that in mind, you'll be tempted to use qsort. Sounds good, except that 1/ there's a good chance it's been implemented as a recursive function - something that you may not want depending on the coding rules you use - and 2/ depending on typical size of the arrays you need to sort, there's a chance it will take more time to execute than a simple, hand-written function with any O(n²) algorithm... finally 3/ if you need to port your code to another target, the function in question may not be available (probably little chance of that for qsort(), but very possible in many other cases). Now you may be convinced of that, and choose not to use qsort(), but may be thinking: let's not reinvent the wheel, and just pick up a random function doing this you just found on a random blog. It may be completely buggy and ruin your project, or at least make you waste hours debugging, whereas writing that yourself could have taken you just a few minutes.
So as always, thinking before doing is not necessarily the best approach for all areas of life, but it's certainly a reasonable one for engineering tasks.
-
I held off replying to this thread, as I saw it spin off to other topics. But in a naive attempt to get it back on track, and for my own curiosity, what do people consider to be an "Arduino" ?
I mean, I often use the Atmega series for work, sometimes with USB-serial converters, and for convenience, the Arduino bootloader. Does that count? What if one uses the IDE but none of the built in libraries? Or... the hardware, but Atmel studio writing bare metal? If I used an Atmega328, at 16MHz, wrote the code in the Arduino IDE, would that count?
My point is, it seems some have very strong views on how problems/projects should be solved/completed, and some appear to be vehemently against anything Arduino, I suspect possibly because some of the libraries aren't great (whoever claimed they were?).
But what exactly are these prejudices about? Is it
1) The use of libraries
2) the hardware abstraction, or is it the hardware?
3) the fact that it is a handy, cheap, and useful platform for Artists and non-electronic engineers to blink some LED's for a larger project?
4) Or is it that some feel those who are fully capable of writing their own libraries shouldn't be using existing libraries?
Unless we have a nice clear definition of what using an Arduino is about, people could be arguing about different points.
Seriously, I'm curious. Also, just to add another data point - I haven't noticed Arduino "users" to be any more aggressive than any other area of engineering. It seems to be more related to age than anything else.
-
Also, just to add another data point - I haven't noticed Arduino "users" to be any more aggressive than any other area of engineering. It seems to be more related to age than anything else.
Just a quick thought about this: people can be vehement when "promoting" a solution they use and think is great, but aggressiveness usually manifests itself when people feel attacked. Two different things.
-
I mean, I often use the Atmega series for work, sometimes with USB-serial converters, and for convenience, the Arduino bootloader. Does that count?
Absolutely!
What if one uses the IDE but none of the built in libraries?
Close enough! Just having the IDE installed is enough to condemn all future work. On any chip!
Or... the hardware, but Atmel studio writing bare metal? If I used an Atmega328, at 16MHz, wrote the code in the Arduino IDE, would that count?
Again, this would absolutely count!
Now, there's no rhyme or reason for my answers above but, as this thread is completely off the rails in terms of rationality, why add any at this late stage.
My point is, it seems some have very strong views on how problems/projects should be solved/completed, and some appear to be vehemently against anything Arduino, I suspect possibly because some of the libraries aren't great (whoever claimed they were?).
But what exactly are these prejudices about? Is it
1) The use of libraries
2) the hardware abstraction, or is it the hardware?
3) the fact that it is a handy, cheap, and useful platform for Artists and non-electronic engineers to blink some LED's for a larger project?
4) Or is it that some feel those who are fully capable of writing their own libraries shouldn't be using existing libraries?
[/quote[
Unless we have a nice clear definition of what using an Arduino is about, people could be arguing about different points.
Seriously, I'm curious. Also, just to add another data point - I haven't noticed Arduino "users" to be any more aggressive than any other area of engineering. It seems to be more related to age than anything else.
The complaint against libraries, in general, can't be justified unless one is willing to write in assembly language or rewrite the C library. Libraries are libraries, if you don't like Arduino libraries because they may not be 'perfect', how do you know the C library works under all conditions? After all, AVR Libc is just a derivative of glibc... Libraries are built on other libraries, how far down do the complainers want to condemn?
The complaint that the libraries are suboptimal because they are written by amateurs doesn't stand up well when you consider that ALL open source software is written by amateurs, for amateurs. If it was professional code, it would cost money! Lots and lots of money. You wouldn't use 'open source' software for any life safety applications, right? Not GCC, certainly not glibc and absolutely not the Arduino libraries. Right? You would buy professional software, right? You would want a guarantee, right? Well, if you want a guarantee, buy a toaster!
A few pages back I was talking about my experience with a library for the AD9833 Waveform Generator and how I could drop it into the IDE, compile the example and get a waveform. In about 5 minutes. Now, true, I would have to sort out the pins on the Arduino and the pins on the demo board but that's pretty straight forward and applies to ALL SPI peripherals so there are a lot of examples.
Then I rewrote the code from scratch. Trust me, it took a lot longer than 5 minutes and is nowhere near as general or 'API like'. My code rmeets a specific requirement and is clearly not 'general purpose'. More to the point, I had to spend time figuring out which of the 4 CPOL/CPHA attributes matched the device and then I had to figure out what the Arduino SPISettings() function calls them. Of course I also had to verify that my Clk speed wasn't too fast for the part. Datasheet kinds of things that aren't necessary when using the library. They are already dealt with.
Now, given somebody who is new to uC and, particularly SPI, how are they supposed to know? How do they, as an 'Artist', understand from the timing diagram that CPOL is high and CPHA is falling (SPI_MODE2). The thing about the library is that they don't have to know. It's already handled. Just plug and play.
Earllier somebody pointed out that much of the whining is a result of the speed with which 'Artists' can accomplish their goals. Everything that can be done with an Arduino has been done and the code is on the Internet. Today, embedded programming at the more superficial level is available to everyone!
Then somebody wants to get clever and talk about multitasking. What about multitasking? Well, there's an Arduino library that uses FreeRTOS (yet another library, I'm afraid).
At the end of the day, the complainers are talking out of their ***. The platform works, the platform is popular because it works and I can buy a perfectly capable small CPU with USB interface for about $4 because it is popular. It disturbs their view of their position in the hierarchy. It's no longer necessary to spend years and years in college just to create a sine wave with an Arduino. Anybody can do it! Even really old guys, long retired and kickin' back.
And, no, the Arduino Uno is not the cure for world hunger. I think we need a bigger chip. Maybe the Mega 2560...
As a side issue, my incantation of the code is known to work on an Arduino Nano, Arduino Uno (both 8 bit CPUs) and the Teensy 4.0 (32 bit Cortex M7) with no changes. It's about the library! That's why I can choose from a number of chips and use the same source code. That's a pretty powerful idea.
Sometimes the libraries are just the ticket to success.
-
Reminds me of a discussion with an assembly language programmer on a project years ago (where I was coding in a higher level language) - "You're cheating! Each single line in a program like that can execute THOUSANDS of assembly language instructions!!!!"
He never did accept that this could possibly be perceived as a benefit by anyone.... including completing your work quickly.
-
And the first thing the assembler writers did was add macro capability to abstract the instruction set and become more 'high level'.
-
... how do you know the C library works under all conditions?
You don't. You either avoid the library or you take the risk.
-
And the first thing the assembler writers did was add macro capability to abstract the instruction set and become more 'high level'.
That's how C works. C looks a lot like macro-assembler. Traditionally, the output of the C compiler is the assembler source code. You can even insert assembler commands directly into your C code which go straight to the output.
-
Reminds me of a discussion with an assembly language programmer on a project years ago (where I was coding in a higher level language) - "You're cheating! Each single line in a program like that can execute THOUSANDS of assembly language instructions!!!!"
He never did accept that this could possibly be perceived as a benefit by anyone.... including completing your work quickly.
I read an article many years ago that the average programmer could generate 100 lines of debugged/documented code per day. I doubt that it has changed much - in terms of line count.
What has changed is how much work you can get done with 100 lines.
-
This isn't real work stuff but one good project I had for "Arduino" was making my daughter's play kitchen. Added lights sound and a small stereo to the thing. Took an hour to wire, program, and assemble some small boards for interfacing. Add an extra hour if you'd like to touch up on a couple libraries I used. Using a Teensy 3.5 made it very easy. The libraries made it very simple to play sounds from an SD card and interface with buttons and microswitches to activate different functions. Pairs with a meanwell 5VDC ac-dc power supply. Been plugged in for years with no issues and works every time.
-
And the first thing the assembler writers did was add macro capability to abstract the instruction set and become more 'high level'.
That's how C works. C looks a lot like macro-assembler. Traditionally, the output of the C compiler is the assembler source code. You can even insert assembler commands directly into your C code which go straight to the output.
I not infrequently refer to C as "portable assembly".
I generally mean high praise when I say that.
-
I not infrequently refer to C as "portable assembly".
I generally mean high praise when I say that.
I wonder if people use C compiler just to primarily code in assembly, in some instances. Seems like the way you do defines and syntax of denoting register,bit and whatnot would remain consistent across all devices that are supported by that compiler. Rather than learning the quirks of syntax each individual assembler. E.g, with one assembler you might need to use a period, here, and the other a comma. Little things like that.
edit: In hindsight, defines are probably IDE-specific? But same idea, that a compiler that supports multiple IDE, the compiler would mask those things with another layer of abstraction that works across all of them.
-
I read an article many years ago that the average programmer could generate 100 lines of debugged/documented code per day. I doubt that it has changed much - in terms of line count.
What has changed is how much work you can get done with 100 lines.
I seem to recall that the bar is only at 10 lines of documented, debugged code per day... but the principle of your observation is true. One line of VBA code can invoke an entire application...
-
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
― Bill Gates
-
...so how many lbs of code did you produce today? ;D
-
ALL open source software is written by amateurs, for amateurs. If it was professional code, it would cost money! Lots and lots of money. You wouldn't use 'open source' software for any life safety applications, right? Not GCC, certainly not glibc and absolutely not the Arduino libraries. Right? You would buy professional software, right? You would want a guarantee, right? Well, if you want a guarantee, buy a toaster!
Talking about me, usually, the toolchain is Greenhills { C, C++, Ada } or Windriver DiabCC, with their libc, whistles, and bells.
This stuff costs a lot of money, and we also have to use crazy software like tools for the architecture analysis and design languages, whose licenses can cost around 50K euro per package, which is more than the double the cost for the toolchain (usually 5-10K euro) and for the RTOS (usually around 20K euro), but not so much if compared to the hardware, which costs much more money even because it has a lot of top requirements, and even debugging stuff costs a fortune since it has to be able to perform a lot of extra analysis such as the dynamic coverage -called- "realtime equivalent", which means down-clocking the CPU(1), but the most of FPGA and ASIC circuits, and especially the external simulators of the turbines and sensors, or whatever is "input and output", cannot be "too-much" down-clocked, and simulators cost around 100K euro each, and those for supersonic machines are even more expensive.
So ... definitely, the Open Source is all another planet :D
(1) PowerPC with its cache somehow forced to be constantly invalidated in order to avoid weird effects when extracting triplets for the analysis, and it's a lot of data to be moved fast and accurately.
-
The complaint that the libraries are suboptimal because they are written by amateurs doesn't stand up well when you consider that ALL open source software is written by amateurs, for amateurs.
Reality is different:
"In the latest "Linux Kernel Development" report produced by the Linux foundation, the vast majority of the contributions to kernel development -- more than 80 percent -- are "demonstrably done by developers who are being paid for their work." Translation: The work is being done by programmers contributing to Linux in the service of some corporate paymaster, be it Red Hat, Intel, Suse, Samsung, or Oracle."
https://www.infoworld.com/article/2610207/who-writes-linux--corporations--more-than-ever.html (https://www.infoworld.com/article/2610207/who-writes-linux--corporations--more-than-ever.html)
You wouldn't use 'open source' software for any life safety applications, right?
Also not quite true :)
"Arm, BMW Car IT GmbH, KUKA, Linutronix, and Toyota join ELISA project to advance open source functional safety across transportation, manufacturing, healthcare, and energy industries"
https://www.linuxfoundation.org/press-release/2019/02/the-linux-foundation-launches-elisa-project-enabling-linux-in-safety-critical-systems/ (https://www.linuxfoundation.org/press-release/2019/02/the-linux-foundation-launches-elisa-project-enabling-linux-in-safety-critical-systems/)
-
Open source benefits everyone in the computer industry... the corporations know that, which is why they're contributing.
-
"Arm, BMW Car IT GmbH, KUKA, Linutronix, and Toyota join ELISA project to advance open source functional safety across transportation, manufacturing, healthcare, and energy industries"
https://www.linuxfoundation.org/press-release/2019/02/the-linux-foundation-launches-elisa-project-enabling-linux-in-safety-critical-systems/ (https://www.linuxfoundation.org/press-release/2019/02/the-linux-foundation-launches-elisa-project-enabling-linux-in-safety-critical-systems/)
I suspect there will be a lot of changes for this project. I can't see any way in the world that life safety applications want to run on a kernel with 17 million lines of code. At a minimum, I suspect they will toss many of the drivers as they contribute over half to the line count.
I haven't followed RT Linux but if Linux is to be industrialized, it absolutely must support realtime operation.
And, of course, the reason that corporations are contributing is that they use the kernel in cell phones and that's a pretty big business. Canonical, distributor of Ubuntu, contributes almost nothing, according to the article.
-
There's safety in numbers. E.g. if a corp uses the same base software as other manufacturers for their self driving car, they are following "industry best practices" and are in a perceived (and probably actual) lower risk situation compared to the "maverick" corporation that does everything their own way (Tesla, we're looking at you). This also relates somewhat to the need for a sizeable ecosystem of producers and consumers - if too small, the zoo collapses (Blackberry and Windows Phone, we are looking at you). Open source goes a long way towards alleviating both these concerns.
-
"Arm, BMW Car IT GmbH, KUKA, Linutronix, and Toyota join ELISA project to advance open source functional safety across transportation, manufacturing, healthcare, and energy industries"
https://www.linuxfoundation.org/press-release/2019/02/the-linux-foundation-launches-elisa-project-enabling-linux-in-safety-critical-systems/ (https://www.linuxfoundation.org/press-release/2019/02/the-linux-foundation-launches-elisa-project-enabling-linux-in-safety-critical-systems/)
I suspect there will be a lot of changes for this project. I can't see any way in the world that life safety applications want to run on a kernel with 17 million lines of code. At a minimum, I suspect they will toss many of the drivers as they contribute over half to the line count.
I haven't followed RT Linux but if Linux is to be industrialized, it absolutely must support realtime operation.
And, of course, the reason that corporations are contributing is that they use the kernel in cell phones and that's a pretty big business. Canonical, distributor of Ubuntu, contributes almost nothing, according to the article.
afaik Tormachs PathPilot is linuxcnc running on linux with realtime
-
The complaint that the libraries are suboptimal because they are written by amateurs doesn't stand up well when you consider that ALL open source software is written by amateurs, for amateurs.
Meh. The non-open-source libraries written by supposed professionals seem to be sub-optimal as well. "Everyone" agrees that STMCube, Atmel ASF, TI's Tivaware, and etc, all are pretty awful. Buggy, bloated, slow, poorly written, and difficult to read (remembering that "not open-source" does not mean that you can't look at the source.)
ALL open source software is written by amateurs, for amateurs.
and I don't agree that that's true...
(Hey, you get a choice: vendor libraries written by interns, university code written by ivory tower purists, OSSW written by amateurs, abandoned libraries written by professionals and released as OSSW when the company went broke, or would-be "professional" code written by companies that haven't gone broke or been acquired yet, which turns out to be "Two Guys and a Vax" or similar. Or I guess you could write it all yourself.)
-
It seems that MISRA is claiming that C and C++ are unsafe in the context of embedded systems?
Oh, well ... talking about what I do in avionics and military avionics for a living, the real problem is not *the programming language* but rather the life-cycle of a product, which has several serious problems with team-working, and Misra-C for C and Spark for Ada are the best-fit for being compliant to D0178/B, which is the only way to keep things under control (and in-budget) in large teams of people with inhomogenous skills.
If you develop something that the testing-squad is not able to test ... the team has a problem, the QA has a problem, and even lawyers have a problem.
Guys in the QA group uses their AADL language to address common problems in the development of products for mission- and safety-critical systems, such as avionics systems in aircraft systems, and I can assure you that AADL is neither C, Ada, nor Matlab or Forth, it's a purely symbolic language (a thing for scientists, specifically for mathematicians) which aims for addressing problems such as mismatched assumptions about the physical system, computer hardware, software, and their interactions that can result in system problems detected too late in the development lifecycle.
This is usually the reason why they give us orders and restrictions such as being strictly compliant to MisraC and SparkAda: because from their point of view, and considering devs and testers, and the whole team in the product lifecycle, well the not being compliant creates an increasingly-unaffordable and potentially dangerous situation for developers and users of mission- and safety-critical technologies.
-
Maybe they should use Forth like NASA ?
If you can elaborate a solid plan and a framework which allows the analysis of system designs *prior* to development, and *if* this does support an architecture-centric, model-based development approach throughout the system lifecycle, and if *Forth* can find its place in this making things better ...
... then -YES- you have a solid chance to convince AADL-guys to approve Forth :D
-
I haven't followed RT Linux but if Linux is to be industrialized, it absolutely must support realtime operation.
Linux ... is like a restless bull in a rodeo, it cannot be ridden more than 5 minutes, Linux is a bad beast for cowboys on the console, and it cannot be certified, not even for the lowest DO178B level E ... it's too "rolling" and completely out of control, in fact, there were several attempts (e.g. FNM Linux 2012, aka Linux revisioned) to do it ... all failed in avionics. Sorry.
But, in the Formula One Management (Automotive/FOM), we have a couple of Linux gears on the car. They are a kind of "routers with an antenna" that download data to the ground during the pit stop :D
-
Maybe they should use Forth like NASA ?
If you can elaborate a solid plan and a framework which allows the analysis of system designs *prior* to development, and *if* this does support an architecture-centric, model-based development approach throughout the system lifecycle, and if *Forth* can find its place in this making things better ...
... then -YES- you have a solid chance to convince AADL-guys to approve Forth :D
Your work is fascinating and so are your posts :-+
I'm definitely not here to do convince anyone to use Forth, I'm a technician myself and have no understanding of the rigorous methodologies that highly skilled professionals use for mission critical areas.
I doubt that many do.
I remember when NASA accountants tried to close the Orbiter Software Testing Team because the Orbiter hadn't suffered from any bad software for a long period ... so they saw that department as a waste of money ...
NASA had two teams, the software writers and the software testers. Apparently the groups were kept totally separate and not permitted to fraternize.
-
I haven't followed RT Linux but if Linux is to be industrialized, it absolutely must support realtime operation.
Linux ... is like a restless bull in a rodeo, it cannot be ridden more than 5 minutes, Linux is a bad beast for cowboys on the console, and it cannot be certified, not even for the lowest DO178B level E ... it's too "rolling" and completely out of control, in fact, there were several attempts (e.g. FNM Linux 2012, aka Linux revisioned) to do it ... all failed in avionics. Sorry.
Several IFE (in flight entertainment) systems are Linux based (you can plainly see this during booting). While those aren't safety critical (obviously), I suspect they may still be DO178B-E (no safety impact) certified.
-
While those aren't safety critical (obviously), I suspect they may still be DO178B-E (no safety impact) certified.
Ummm, I have recently seen two projects for helicopters, both are sort of high-tech parking sensor which uses four LIDAR each with dual lightwave. This system has the highest IP-requirement for the hardware (waterproof, acid-fog proof, etc) even if the software is not critical in term of mission-critical because it's only used at the beginning and at the end of a mission, so someone proposed to convert an already existent (already tested and debugged) AXIM System, which is Linux based.
AXIM is not for avionics, but it has the same IP-class for the hardware. So it looked a good deal, and they tried somehow to make it Level D compliant. They worked hard and they didn't fail, and the unit got almost approved. But then AADL guys pointed out that ... well, a helicopter might use the LIDAR even during the mission, for example, to discover a high voltage cord or little objects during a low flight, so the system requirements got escalated to Level C, and the Linux proposal got again abandoned because not compliant and too expensive to be made compliant, especially because in the meanwhile the Company which produces the LIDAR sensor ... well released a new model with a new kernel driver which requires a new kernel (back porting from kernel v4.* to kernel v3.* is usually problematic, I mean not impossible, but it consumes a lot of time), and this would have requested more work to re-certify everything.
... this is what I mean with being too rolling.
The only commit I have ever seen about Linux is about a Light controlling system also able to play DVDs for the passengers' entertainment, and it's considered a sort of "aesthetic accessory" (level E) mounted inside a not-military helicopter :-//
-
NASA had two teams, the software writers and the software testers. Apparently the groups were kept totally separate and not permitted to fraternize.
Yup, with only two partners, the company will break out at the first skirmish, while with three partners ... the third can mediate.
So, this is probably the main reason why we have QA and AADL guys. One of their duty is to address and readdress problems from devs to testers and vice versa, in a way that is not exactly democratic, but that it works :D
QA guys also interface our lawyers with the customers lawyers (which is a very hard job), while AADL guys interface managers and all the big-guys with money (lenders, which is probably the hardest job).
-
Maybe they should use Forth like NASA ?
If you can elaborate a solid plan and a framework which allows the analysis of system designs *prior* to development, and *if* this does support an architecture-centric, model-based development approach throughout the system lifecycle, and if *Forth* can find its place in this making things better ...
... then -YES- you have a solid chance to convince AADL-guys to approve Forth :D
Yup...
Now you may be able to use Forth in some very restricted parts of your system without having to go to this full extent, if you can prove that whatever the Forth part does is NOT critical (meaning amongst other things that it would be well isolated from any critical path). Good luck with that... (and anyway, if it doesn't do anything critical, it wouldn't really qualify as a replacement for any approved language...)
Interestingly, one obvious thing that could be in favor for Forth is the extreme simplicity of the language and the tools to compile or interpret it. Correctness for the tools themselves should be pretty straightforward to assert, whereas it certainly is no picnic for a typical C compiler (not even talking about C++ and ADA). Now of course there are many other aspects that would NOT be in favor for Forth though...
-
Toyota Unintended Acceleration is perfect example of safety-critical coding gone wrong (http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code). Further reading would be Barr group slides (http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf) containing some analysis & comments. The best part is watchdog reset in a timer tick ISR (page 41).
-
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328. Personally, I include the entire set of Arduino compatible boards that can be used with the Arduino IDE + libraries. I bought an Arduino Uno years ago just to see what the fuss was about. Then I bought an Arduino Due (with cortex-m3) mainly because it had more RAM and I wanted to use it for data acquisition. Then I discovered Teensies. I have a half dozen Teensy 3.6 (cortex-m4) and just got a Teensy 4.0 (cortex-m7 @600MHz, 1MB RAM, 2MB flash.) I consider all of them Arduinos.
FWIW, I rarely use the IDE to write code; I use Notepad++ and use the IDE as a compiler. Is this a sophisticated and flexible programming system? Heck no. But it's entirely adequate for its intended purpose.
About me: I am an EE. Currently I spend about 1/2 of my time as an educator and the other 1/2 as a consultant. At my last full time job I designed embedded systems. I didn't program them though, and I typically let the software engineer pick the MCU. When I needed something in the lab with GPIO for control or data collection, I started by reprogramming an existing product; usually something with a 16bit PIC. Then I discovered Arduinos and never bothered trying to repurpose existing boards. I used them to control prototypes of other products that didn't include in on board MCU, or some that did have their own MCU but needed to be tested through some low level interface.
Again, I had piles of non-Arduino boards with analog and digital io at my disposal. All I had to do was program them. But when I found out I could spend $20 on a Teensy and cut my coding/debug time by an order of magnitude, I pushed all of those other boards into a box and put it on the shelf.
Did I or anyone else at that company ever consider incorporating an Arduino into one of our products instead of a $2 PIC? Of course not, that would be silly. Point is, I found good uses for both $2 MCU's and $20 Arduinos.
A project that I'm currently working on as a consultant involves reading a 3-axis accelerometer, doing a little DSP, then sending the result over Bluetooth. My first prototypes used the ADXL343 accelerometer (same that I will use in the final product) connected to a Teensy 3.6. With this I was able to perform both proof of concept and develop the DSP. There's only a few hundred lines of code and that include a command interpreter. The only thing missing is Bluetooth. For the commercial product, should I design in the Teensy coupled with more hardware for Bluetooth? Should I consider an STM32 because it's the new Z80? Maybe I should program it in Forth too...
No, I'll use a TI CC2640R2F. It includes a general purpose MCU, as well as a Bluetooth module, but the real reason I'll use it is because the tools and libraries available from TI will make programming the thing way easier than programming a PIC or STM32 from scratch to perform the same job. I expect that the time to write and debug the code will be reduced by a factor of 4 or 5. Hey, that's the same reason I used the Arduinos for prototyping!
-
Toyota Unintended Acceleration is perfect example of safety-critical coding gone wrong (http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code). Further reading would be Barr group slides (http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf) containing some analysis & comments. The best part is watchdog reset in a timer tick ISR (page 41).
The timer ISR clearing the watchdog is fantastic stuff. :-DD
-
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328.
Right. Those who have definite opinion that "Arduino sux", most likely have no idea what Arduino *actually* is or simply don't care because they have divinity (like Forth) to worship.
-
Toyota Unintended Acceleration is perfect example of safety-critical coding gone wrong (http://www.safetyresearch.net/blog/articles/toyota-unintended-acceleration-and-big-bowl-%E2%80%9Cspaghetti%E2%80%9D-code). Further reading would be Barr group slides (http://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf) containing some analysis & comments. The best part is watchdog reset in a timer tick ISR (page 41).
The timer ISR clearing the watchdog is fantastic stuff. :-DD
makes sure the interrupts are running ;)
-
[...avoid Arduino because...] they have divinity (like Forth) to worship.
Of course, nothing stops you from running Forth on an Arduino, if that floats your boat...
https://weblambdazero.blogspot.com/2016/10/go-forth-with-arduino.html
-
The users here - generally - arrive with burned fingertips, and fried components.
The - typical - ‘retail’ Arduino user gets hot & bothered if their project doesn’t do ‘what they wanted it to’ - despite lacking any hardware or programming experience to achieve their wish.
Ouch.
-
The - typical - ‘retail’ Arduino user gets hot & bothered if their project doesn’t do ‘what they wanted it to’ - despite lacking any hardware or programming experience to achieve their wish.
Ouch.
That is by design.
What is Arduino? (https://www.arduino.cc/en/Guide/Introduction)
Arduino was born at the Ivrea Interaction Design Institute as an easy tool for fast prototyping, aimed at students without a background in electronics and programming...
A worldwide community of makers - students, hobbyists, artists, programmers, and professionals - has gathered around this open-source platform
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328.
Yeah, like people who think that Linux == PC, or motor vehicle == internal combustion engine. Just because 99% do doesn't mean they all do. In fact there is no guarantee that an 'Arduino' will have any MCU in it at all! It's one of the charming things about it. Hardware agnostic, and so simple that anyone can just upload a sketch and... "No, not that Arduino, you idiot!"
-
the problem I often see, is those players that purchase a ‘board’ that can blink a LED- expect it to solve their home automation, irrigation and robotics needs by throwing on some shields and a few buggy instructable libraries.
No concerns for power, compatibility or suitability to the role at hand.
This isn’t criticism of individuals, but simply a dim hope they might
Read the book before they criticise it.
-
I've learned a lot from reading books. I've also learned a lot from making mistakes. I'm grateful for both opportunities.
-
I find it interesting that at least some of the contributors to this thread seem to think that Arduino == atmega328.
Indeed. In some senses, Arduino is a better "bare basics" library than most vendor's libraries. Because Vendor libraries are NEVER portable to other Vendors :-(
Whereas Arduino is portable to ... quite a few different architectures (sadly, it's weak point is that will tend to support only a couple of chips in each family. So there is SAM3X8E support via Arduino Due, but ... not Other SAM3 chips, nor SAM4, nor SAM7... Not without some effort, anyway.
-
Arduino is not really portable in the usual sense of the word. It’s a hack job. The header file is the only really portable so they rewrite the implementation from scratch for each platform. Each port has its own nuances. Read the source code for digitalWrite for example.
-
I think the point is that the code is the same. You say digitalWrite, well to achieve the same thing on many different platforms you will be using many different register names so code for one family will never wor on another.
-
That's the main problem though. Each hardware implementation is different. On AVR for example it does unholy things with PWM internally on digitalWrite. Other platforms it doesn't.
-
If one bitches let alone about different GPIO register names, he/she probably just should not program MCUs at all. ;)
...and shall return to writing java applets.
-
Certainly not bitching about that. Bitching about the futility of hiding it all behind the same API call.
In fact hiding the differences where possible makes it more like java! And it has the same weird ass edge cases as java.
-
That's the main problem though. Each hardware implementation is different. On AVR for example it does unholy things with PWM internally on digitalWrite. Other platforms it doesn't.
Yes true. You will be reduced to the lowest common denominator. Your standard code will only be able to do as much as the least capable device. digitalWrite is a simple example of a universal function that with little work you can implement bare bones but as the periphery gets more complex it can be useful to have agnostic code but one has to understand that micro-controllers are that different that doing it this way severely limits your options.
Yes I was furious to find "weird shit" to be going on with 2 of the PWM outputs on the Mega having been unfortunate enough to pick those exact 2 channels that have the issue. I recently found that the UNO has an issue where the PWM channel disables itself when other channels are written to. I tried reporting it on the forum, but they wanted to see my code. So I think now that they are trying to support so many platforms bugs are creeping in.
-
java
I still have some love for my old TiniJava/S390 tiny board made around the year 2001, when Dallas semiconductors and Maxim tried to put a Java Virtual Machine on an 8051 MPU under steroids: 21bit on the address bus, 40Mhz clocked with a built-in ethernet, an FTP client/server in the firmware allowing the user to download your code via FTP. It looked futuristic for those years!
It was before Arduino, before everything, and Oh, you can program an 8051 in Java!!! And virtually a program that runs on your PC can even run there.
There was a technology called "jump51" under the hood, but seriously ... people have always tried to bypass the JVM to directly access the hardware, sometimes with a lot of assembly code directly called from Java. And things went even worse when they launched the S400 model, more advanced than the S390, faster, with more ram, more whistles, and bells, but on which "practically" you needed to hack the java code made for the S390.
So ... Java on MPUs ... what has been? :D
-
That's the main problem though. Each hardware implementation is different. On AVR for example it does unholy things with PWM internally on digitalWrite. Other platforms it doesn't.
Yes true. You will be reduced to the lowest common denominator. Your standard code will only be able to do as much as the least capable device. digitalWrite is a simple example of a universal function that with little work you can implement bare bones but as the periphery gets more complex it can be useful to have agnostic code but one has to understand that micro-controllers are that different that doing it this way severely limits your options.
Yes I was furious to find "weird shit" to be going on with 2 of the PWM outputs on the Mega having been unfortunate enough to pick those exact 2 channels that have the issue. I recently found that the UNO has an issue where the PWM channel disables itself when other channels are written to. I tried reporting it on the forum, but they wanted to see my code. So I think now that they are trying to support so many platforms bugs are creeping in.
Yeah don't even bother with bug reports. I reported one in the Arduino IDE which stopped it actually working using a USBasp for nearly a year. Had to drop back a version or two of the IDE. That was what finally killed it for me to be honest.
Then I discovered AVR-libc which is pretty good. I managed, within a week, to turn my entire codebase into interrupt and timer driven where the CPU was asleep nearly all the time. Doing that in Arduino was hopeless.
Also being GCC and make based I have extensive experience of that so it was just slinging shit together.
java
I still have some love for my old TiniJava/S390 tiny board made around the year 2001, when Dallas semiconductors and Maxim tried to put a Java Virtual Machine on an 8051 MPU under steroids: 21bit on the address bus, 40Mhz clocked with a built-in ethernet, an FTP loaded on the firmware, you downloaded your code via FTP. It looked futuristic for those years!
It was before Arduino, before everything, and Oh, you can program an 8051 in Java!!! And virtually a program that runs on your PC can even run there.
There was a technology called "jump51" under the hood, but seriously ... people have always tried to bypass the JVM to directly access the hardware, sometimes with a lot of assembly code directly called from Java. And things went even worse when they launched the S400 model, more advanced than the S390, faster, with more ram, more whistles, and bells, but on which "practically" you needed to hack the java code made for the S390.
So ... Java on MPUs ... what has been? :D
And JavaCard. I bet no one remembers that. I actually crapped on a toilet powered by Java once too at an exhibition. Impressive that the dunny had more brains than my phone at the time.
-
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.
-
Yeah the overhead is terrible in some cases. Also where the abstraction is fragile like around interrupts and timers. Ugh.
-
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.
-
Another thing that’s a ball ache is managing all the licenses. Forgot to mention that earlier.
-
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.
-
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.
-
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/ (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.
-
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!
-
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 (http://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.
-
Have you looked at the windows API recently? :-DD
-
Have you looked at the windows API recently? :-DD
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...
-
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 (http://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
-
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.
-
Have you looked at the windows API recently? :-DD
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 :-DD). 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.
-
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.
-
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.
-
That is why you do NOT use a printf, but snprintf or vsnprintf respectively.
That's what I do as well.
-
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!
-
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++
-
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...
-
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. :P
-
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/ (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 :-DD
-
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.
-
awww yeah, 600MHz arduino, for blinkenlights using a delay()... :-DD
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.
-
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.
-
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.
As a few others have said (and others argued strenuously against), I'd spend my first $40 and 20 hours with Arduino (clone) straight as it comes out of the box.
That is a very easy learning curve as you get back into it, tons of examples, easy installation, 5 minutes to blinking LED, etc. That little bit of investment will give you reasonably clear guidance whether to continue down that path or deviate (and if deviate, in which direction is most important to you). I don't consider that time or money "wasted" by any means.
-
awww yeah, 600MHz arduino, for ...
It might be interesting for an IMU, or for dynamically calculating the curve distance between two GPS points. This stuff consumes a lot of quaternions in the first case and trigonometric and hyperbolic functions in the second case. IMU's sensors can be all SPI as well a GPS can stay on a second serial line.
I am still too busy with my B+tree filesystem at the moment to play with these two ideas :D
-
awww yeah, 600MHz arduino, for ...
It might be interesting for an IMU, or for dynamically calculating the curve distance between two GPS points. This stuff consumes a lot of quaternions in the first case and trigonometric and hyperbolic functions in the second case. IMU's sensors can be all SPI as well a GPS can stay on a second serial line.
I am still too busy with my B+tree filesystem at the moment to play with these two ideas :D
Did I mention that the ARM M7 chip in the Teensy 4 also has an FPU? 600 MHz PLUS a FPU. What's not to like?
https://www.pjrc.com/store/teensy40.html (https://www.pjrc.com/store/teensy40.html)
ETA: It's $20
-
As a few others have said (and others argued strenuously against), I'd spend my first $40 and 20 hours with Arduino (clone) straight as it comes out of the box.
That is a very easy learning curve as you get back into it, tons of examples, easy installation, 5 minutes to blinking LED, etc. That little bit of investment will give you reasonably clear guidance whether to continue down that path or deviate (and if deviate, in which direction is most important to you). I don't consider that time or money "wasted" by any means.
The Arduino Uno R3 is the latest standard platform BUT it isn't easily compatible with a breadboard. The Nano version is perfect to plug right in to the board. Either way...
Education has never been free. I buy something related to each family as soon as they are announced. I have a drawer full of demo boards. Some I will play with, others I will abandon. Even those that I abandon have provided something toward my education.
Perhaps those who advocate against the Arduino have forgotten how they got started. One thing I believe is absolutely true: The Arduino with libraries is the best documented system on the market. Furthermore, everything that can possibly be done with the chip has already been done and out on the Internet. There is a lot of help. Help can be useful when starting out.
Everybody has to start somewhere. A multicore ARM isn't the place. In my view, neither is the STM32F or any similar mid to high range ARM.
In the end, it's just a decision. Some are in favor, some opposed. I don't think I would relegate the decision to a coin-toss. It's far too important because early success keep a person interested.
-
Did I mention that the ARM M7 chip in the Teensy 4 also has an FPU? 600 MHz PLUS a FPU. What's not to like?
indeed, I said that it's more than perfect for those tasks! I simply to not have the time at the moment :D
-
Thanks for the advice and pointers. I'm well past the "blinking lights with an Arduino" stage, and am not afraid of wiring up protoboards or laying out and building simple SMD (or leaded) circuit boards. I've been playing with the Arduino IDE, and been able to modify the libraries as needed to get some particular feature enabled on a peripheral. I'm not really competent with c++ but have been able to modify and expand existing code. I've got an assortment of Arduino and Adafruit "Feather" boards that I've used on various projects (and a bunch of RPis.)
I guess what I'm looking for is an easy to use toolchain that will be somewhat consistent when working within the arduinoverse, with custom cards I may want to design, and perhaps RPi projects as well. I realize that the RPi world has many more reasonable options for development, so it's OK if that doesn't really fit in.
PlatformIO looks interesting!
I do appreciate all the input. Thanks again!
-
I guess what I'm looking for is an easy to use toolchain that will be somewhat consistent when working within the arduinoverse, with custom cards I may want to design, and perhaps RPi projects as well. I realize that the RPi world has many more reasonable options for development, so it's OK if that doesn't really fit in.
As pointed out above, the base Arduino toolchain is based on avr-gcc (compiler/linker) and arv-libc (the C library). Both are present in the Arduino home directory along with AVRdude which handles device programming for other than Arduino cards. Every tool you need is there.
But how to use them? Two paths: Use the Arduino IDE (and bootloader) and just call the avr-libc functions instead of the Arduino functions (or do both). There is probably another header to #include - search Google for 'avr-libc on Arduino board' or something like that. Also search for 'using avr-gcc in Arduino IDE' or whatever. I haven't done it so I can't give you the canned answer but it is being done all the time.
You can find the documentation for avr-libc on Google. The compiler is going to be called anyway, that's what Arduino uses for the toolchain.
You may or may not include the Arduino bootloader in your custom projects. If you do, no problem, just plug the board in as before. If you don't, you need to Google for 'using avrdude directly with ICSP and ATmega328' or something like that. It is your responsibility to bring out the ICSP pins. This is the way I used to work.
You don't really have to install another toolchain, everything you need is sitting in the Arduino home directory.
-
For the Atmel stuff you can of course run Atmel studio and import AVR projects.
-
For the Atmel stuff you can of course run Atmel studio and import AVR projects.
I really liked working with the ATmega128 in a Linux environment using a Makefile and gedit as the editor. I don't use Linux as a daily workstation but I do like it for writing code.
-
Linux as a daily workstation
Or a Windows machine sharing files over CIFS to a remote Linux machine where you have your toolchains and dev-tools. This allow me to use commerical tools like Codewarrior and Avocet with their hardware-dongles (which - I don't know why, but they - do suck on Virtual Machines) without any troubles.
I use MobaXterm as ssh shell and X11 server (the personal edition is free, the professional edition only costs 60 euro) :D
-
For the Atmel stuff you can of course run Atmel studio and import AVR projects.
I really liked working with the ATmega128 in a Linux environment using a Makefile and gedit as the editor. I don't use Linux as a daily workstation but I do like it for writing code.
Windows Subsystem for Linux and an xserver (I use X410 ) works pretty good
-
I use WSL as well. It works but it's bloody awfully slow thanks to being backed with NTFS
-
I use WSL as well. It works but it's bloody awfully slow thanks to being backed with NTFS
Copycon on DOS :-DD
I dumped Windows in 1997 and moved to Linux full time. I've been on FreeBSD the last 3 years.
Because the Forth I use has a MCU resident optimizing compiler, the only development support it needs is a serial terminal.
Sourcecode is handled by GNU Screen remotely controlled by the "make" button in my Vim editor which strips all comments before uploading to the MCU at 460800 Baud with hardware handshaking.
I can read/write/test any STM32 register or bitfield with a quick editor search that will insert the code line into the source ready to run on the target. The Bitfield file is auto generated from CMSIS-SVD, so all naming is CMSIS compliant.
With this system I get realtime MCU interactivity for development, I work from a GUI editor with colour syntax and Fossil code versioning. Any compiler issues detected by the MCU beep my Workstation bell and are highlighted in red (errors) or blue (warnings) on the terminal.
Frankly, a Raspberry Pi could be used for all of this. Imagine that, a completely interactive STM32 development system on a RPI with a STM32Xxx Discovery/Nucleo board!
I didn't write the GPL'd Forth (Mecrisp-Stellaris) but I designed every other part of my system myself because ... "Open Source" :)
-
Let’s add OSs and IDEs to this thread. That’s just what it needs!
-
Let’s add OSs and IDEs to this thread. That’s just what it needs!
Might as well -- it was a silly thread to start with. The thread drift has been the best part.
-
Let’s add OSs and IDEs to this thread. That’s just what it needs!
how about dvorak vs. qwerty
-
Let’s add OSs and IDEs to this thread. That’s just what it needs!
how about dvorak vs. qwerty
dvorak!
-
A single tab is worth eight spaces.
-
We should also add VIM vs gedit.
-
MCU Vs MPU? Scotch Vs whiskey?
-
A tab is worth eight spaces.
Only two on my computer.
-
Let’s add OSs and IDEs to this thread. That’s just what it needs!
how about dvorak vs. qwerty
dvorak!
ahh so you are like those forth guys ;)
-
why? and what's forth?
-
FORTH is a very low level stack based programming language yet at the same time a very high one. It's a bit of a weird one.
Examples here: https://learnxinyminutes.com/docs/forth/ (https://learnxinyminutes.com/docs/forth/)
A FORTH interpreter and compiler is so small it can run on the target rather than being cross compiled. Literally you can write your code on an AVR for example on the actual device with a serial terminal.
It is however immensely powerful and it's possible to do some cool tricks like sandboxed code.
How to make an Arduino good: http://amforth.sourceforge.net/TG/recipes/Arduino-HelloWorld.html (http://amforth.sourceforge.net/TG/recipes/Arduino-HelloWorld.html) (there back on topic :-DD)
Then things get reaaaaally good: http://amforth.sourceforge.net/TG/recipes/Multitasking.html (http://amforth.sourceforge.net/TG/recipes/Multitasking.html)
-
But how about Rust on Arduino?
;D
-
But how about Rust on Arduino?
;D
tin the leads ;)
-
FORTH is a very low level stack based programming language yet at the same time a very high one. It's a bit of a weird one.
Examples here: https://learnxinyminutes.com/docs/forth/ (https://learnxinyminutes.com/docs/forth/)
A FORTH interpreter and compiler is so small it can run on the target rather than being cross compiled. Literally you can write your code on an AVR for example on the actual device with a serial terminal.
It is however immensely powerful and it's possible to do some cool tricks like sandboxed code.
How to make an Arduino good: http://amforth.sourceforge.net/TG/recipes/Arduino-HelloWorld.html (http://amforth.sourceforge.net/TG/recipes/Arduino-HelloWorld.html) (there back on topic :-DD)
Or for Forth on STM32 instead of X86 or AVR see my sig below.
Arduino users please don't get all aggressive now .... there back on topic :-DD
-
Excellent stuff :-+
I used to get copies of TCJ back in the 90s. Brad Rodriquez ran a series on building FORTH interpreters from scratch. Learned a lot. Then got distracted by common lisp :-DD
Articles here: https://www.bradrodriguez.com/papers/index.html (https://www.bradrodriguez.com/papers/index.html)
TCJ here: https://archive.org/details/the-computer-journal (https://archive.org/details/the-computer-journal)
TCJ was about the trailing edge of computing. Doing less with more. tggzzz would like it if he doesn't already know about it.
-
There you go... http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-uno/ (http://jakegoulding.com/blog/2016/01/02/rust-on-an-arduino-uno/)
:popcorn:
-
Forth also runs on the STM8 family, and here is a sub-$2 thermostat board with 3 7-segments, 3 push buttons, a temperature probe, and a relay:
https://github.com/TG9541/stm8ef/wiki/Board-W1209
-
Excellent stuff :-+
I used to get copies of TCJ back in the 90s. Brad Rodriquez ran a series on building FORTH interpreters from scratch. Learned a lot. Then got distracted by common lisp :-DD
Articles here: https://www.bradrodriguez.com/papers/index.html (https://www.bradrodriguez.com/papers/index.html)
TCJ here: https://archive.org/details/the-computer-journal (https://archive.org/details/the-computer-journal)
TCJ was about the trailing edge of computing. Doing less with more. tggzzz would like it if he doesn't already know about it.
What a blast from the past with TCJ :clap:
The March/April 1995 edition centerfold is the Rockwell 65F11 which I worked with in 1987. It had Forth pre-loaded in internal ROM from the factory. That era was my heyday in embedded and incredible fun :-+
-
: 1 2 ;
-
Forth also runs on the STM8 family, and here is a sub-$2 thermostat board with 3 7-segments, 3 push buttons, a temperature probe, and a relay:
https://github.com/TG9541/stm8ef/wiki/Board-W1209
I like STM8, it's cheap, has lots of peripherals, is big endian and e4th Forth is very nice.
If I wasn't so invested in STM32 I'd probably be using STM8 myself.
-
is there any Forth rom for hc11? My handyboard was shipped preoloaded with two ROMs: BUFALO and IC (by MIT).
-
is there any Forth rom for hc11? My handyboard was shipped preoloaded with two ROMs: BUFALO and IC (by MIT).
Sure!
The HC11 is one of my original all time favorite MCU's, I LOVE Motorola 6800 Assembly, it's as smooth as silk!
The HC11 was targeted by a few Forth writers way back, have a look at http://forth.org/library/eforth_SOC/eforth_SOC_source/eForth1/68eforth.zip (http://forth.org/library/eforth_SOC/eforth_SOC_source/eForth1/68eforth.zip)
-
Can you be more specific so that we can try to figure out things?