Why Arduino users so agressive?

[KL27x]

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.

[NorthGuy]

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.

[ogden]

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.

[langwadt]

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

[techman-001]

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.

[KL27x]

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?

[AG7CK]

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:

Code: [Select]


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:


US$ 594 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.

[KL27x]

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.

[cgroen]

.
.

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

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

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

[KL27x]

^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?

[techman-001]

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 ?

[cgroen]

.
.
.
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").

[techman-001]

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.

[cgroen]

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

[techman-001]

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

For those who are interested, this very well presented 2018 video shows a heart rate monitor design using the GA-144 above.



 

[rstofer]

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:

Code: [Select]

#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...

[NorthGuy]

Maybe I'll check it someday but, for now, I'm done with this project.  Really!

Congratulations!

[SiliconWizard]

And the existing Arduino libraries were of no use!

[rstofer]

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

[rstofer]

And the existing Arduino libraries were of no use!

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.

[ogden]

Nothing interesting in the Forth World ?

No. Especially when you see that Forth preacher can't even read simple temperature sensor without language extension.

[westfw]

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...

[SiliconWizard]

Why not use Brainfuck while we're at it? It is Turing-complete apparently: http://www.iwriteiam.nl/Ha_bf_Turing.html
https://en.wikipedia.org/wiki/Brainfuck

Anyone willing to try implementing a version of Brainfuck for Cortex-M targets?

[techman-001]

<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 ?

[techman-001]

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" ?