And saying “a 3.3V cmos high output is compatible with 5v ttl high inputs” is not a sufficient answer.
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.
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.))
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
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 alreadystolenwriten before us (in my very rough translation):QuoteAduino 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. Or use 7805 as level translator 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.
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.))
QuoteAnd 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.QuoteThere 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.
What was that saying again? When all you have is Forth everything starts looking like something to argue about?
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.
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.
"What was that saying again? When all you have is Forth everything starts looking like something to argue about? "
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 wonder why would anyone who actually knows what they're doing in embedded bother with Arduino in the first place ?
"What was that saying again? When all you have is Forth everything starts looking like something to argue about? "
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?
Were you abused by Emacs
QuoteI 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...
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).
=
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 ?
=
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 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