New double speed arduino nano clone

[Doug Coulter]

I'm building a new vacuum setup to test some things, which means I'm also building some new data acquisition stuff - it'll be modeled on the big rig, but perhaps incorporate some different measurements as well as "lessons learned". While thinking about all this, I ran across a youtube video describing a "new kid" on the block - which isn't that new except for outside of China, that emulates (roughly) an arduino nano. There are some bumps in the carpet as with all new things, but you can develop in the arduino IDE and so on after adding the requisite support stuff.
(links below)
1. It really does run 32 mhz, and the "fastio" is actually very fast - just doing that it'll get around the loop function toggling a pin such that my scope says 3.5 mhz (which means it's making it at 7 or so).
Now, almost everything slows that down...adding serial setup slows it down even if not otherwise used - and so on. I intend to publish a "demo" sketch that will have my little version of an opsys/scheduler and examples of things like "zero loss" counting, a/d with DSP improvement (it's already 12 bits now!) and whatever else I think of - it's early times on this guy just now, I'm feeling it out and it's looking good. A couple of these slaved to the usual raspberry pi will make a completely killer data acquisition and control setup. I tend to use arduinos for stuff I want to have hard real time, but use a pi to gather all that up with timestamps, then put it in a database, and run any GUI type control code. It's a good match. The pi usually isn't taxed very much, just that with linux, you can get all this cool stuff like high level languages, drivers for databases and whatnot. A pi 3 is more than enough - I don't use wifi for this - and a pi 2 is probably plenty if you're not using the camera stuff.

As is usual for me, I'm here using the website for off-site backup on some of this, and why not share?
Here's the sort-of data sheet:

LGT8F88A V1_1.pdf

Minimal data sheet for the cpu

(782.85 KiB) Downloaded 533 times

Now, there are evidently two ways to add support to the arduino IDE, and both have issues. The "official/original" one uses the old sketchbook/hardware folder - which hasn't been used by the IDE for a bunch of releases now, and some things don't work (lots of things). A developer going by dbuezas came up with a json link you can add to your preferences, and download support - that works off the bat, but some of the files from the original appear to be missing (that fastio_digital.h among them) - and regardless, you have to explcitly #include some things that aren't mentioned or are different than described in the youtube video Ralph Bacon created, below. Such is life for early adopters. I went for the json and copied in some files from the "official" and explicitly include them - that works for me so far, but I've not tested everything yet.

Larduino_HSP-master.zip

The older/official support stuff - install instructions or something else a bit off, but has all the files.

(541.72 KiB) Downloaded 463 times

I got it from here: https://github.com/LGTMCU/Larduino_HSP

I got my hardawre at Bangggood as Ali Express is so messed up I couldn't get them to take my money. I hear others saying that as well. The price was right - $7.72 for 3 of them.
Takes awhile to get here, but you really can't complain too loudly at those prices.

https://www.banggood.com/3pcs-Wemos-TTG ... rehouse=CN

I might be getting more of these...so far, they seem really nice.

Ralph's video: https://youtu.be/Myfeqrl3QP0
Yeah, that's me in the comments too - it seems to be where the people working on making this nice are gathered at the moment.

Here's the guy who got the now normal install going: https://github.com/dbuezas/lgt8fx

Here's the full line I have in my arduino preferences for board support - I do esp's as well.

Code: Select all

http://arduino.esp8266.com/stable/package_esp8266com_index.json,https://dl.espressif.com/dl/package_esp32_index.json,https://adafruit.github.io/arduino-board-index/package_adafruit_index.json,https://raw.githubusercontent.com/dbuezas/lgt8fx/master/package_lgt8fx_index.json

[Doug Coulter]

For grins, though this demo is FAR from complete, here's a sample bit of code that schedules data reporting over serial at exactly (well...hardware limited) 100ms and sends time in ms and the results of sampling the first 4 a/d channels 4 times each and summed. I'm not yet really using the scheduler for things that might be put off till the next round of loop() yet...
It looks like modulo the usual LSB error, it really has 12 bits of a/d goodness. I'm testing with a new alkaline battery as a voltage reference, the 4 sample sum has a peak deviation of around 5 counts. Not bad for a chip that also has other things going on. It's getting around the loop on average at around 300khz (with the odd one taking around a ms or two...). The beauty of doing your own opsys is being able to make the slow stuff happen when it doesn't matter...
Probably the most valuable info here is my comments on what does and does not work, and how long things take.

Code: Select all

/*
 This is meant to become a set of demo/examples
 for this LG chip on the WeMos board

*/

#include <fastio_digital.h>
#include <MsTimer2.h>
/////////////////////////////////// defines
/* @@@ DOES NOT WORK with fastio
#define TOGGLE_PIN D10
too many layers of define?
*/
#define ONE_SEC 1000
#define TENTH_SEC 100
// a/d sample time to get in 4 per 100ms or so
#define SAMP_TIME 23

////////////////////////////////// variables

/* "opsys" seheduling stuff */
unsigned long loop_millis; // so only needs to call once per loop
unsigned long sec_z;
unsigned long tenthsec_z;
unsigned long samptime_z;
bool did_something; // set false at loop begin, true if something was done (time control)

// "app" stuff
int analog_0; // test a/d converter

// testing analog read and speed
byte ch;
byte numsamples;
unsigned int channels[4];

unsigned long benchs; // for benchmarking
unsigned long benche;
unsigned long bencht; // total




unsigned long seconds;

//////////////////////////////////
void init_ram ()
{
  // I group types together for faster init, like a=b=c=0
  did_something = false;
  seconds = 0;
   for (ch=0;ch < 4;ch++)
  {
    channels[ch] = 0;

  }
  numsamples = 0;
  loop_millis = millis();
}

//////////////////////////////////
void setup() {
  // run-once code:
  fastioMode(D10, OUTPUT); // this is a new mode for this board
  fastioWrite(D10, LOW); // and it is indeed very fast
  
 Serial.begin(115200);
 Serial.println ("In setup...");
 init_ram(); // gets its own routine for clarity
}
//////////////////////////////////
void sample_ad()
{
  int ch;
  // get one sample from all 4 channels 0-3 and add to running sum
  for (ch=0;ch < 4;ch++) channels[ch] += analogRead(ch);
  numsamples++;
  did_something = true; // let rest of scheduler know we ate some time
}
//////////////////////////////////
void report_data()
{
  //send our our stuff on serial port

  did_something = true; // serial takes time
  Serial.print (loop_millis); // time of observations
  Serial.print ("\t");
  for (ch = 0; ch <4; ch++)
  {
   Serial.print (channels[ch]);
   channels[ch] = 0; // clear them for next time
   Serial.print ("\t");
  }
  numsamples = 0; // ready to start a/d again
  
  Serial.println();
}
//////////////////////////////////
//////////////////////////////////

/* @@@ bare fast toggle runs 3.95 mhz on scope (real times are twice that fast)
 *  but with Serial.gegin runs slower - 1.44 mhz,
 *  it must check every roundy of loop()
 *  Adding 1 and 1/th sec millis check slows to 247 khz loop
 *
 
 */
 
void loop() {
 fastioToggle(D10); // how fast is this loop?
 loop_millis = millis(); // what time is it?
 did_something = false; // because we haven't yet on this roundy

 if (loop_millis - samptime_z >= SAMP_TIME) // SAMP_TIME has to let us get in 4 every time
 {
  samptime_z = loop_millis;
  if (numsamples < 4) sample_ad(); // took 678 us/call in other tests
 }

 if (loop_millis - tenthsec_z >= TENTH_SEC)
  {
   tenthsec_z = loop_millis;  // restart timing
   // schedule 10 per second stuff here
   report_data(); // not optional, this is our timebase for data acq
  }
 
 if (loop_millis - sec_z >= ONE_SEC)
  {
   sec_z = loop_millis;  // restart timing
   // schedule once per second stuff here
   seconds++;

  }

} // end of loop()
 

I'll get something more complete up here that exercises a lot more of the features and in more-readable form when I get there - you know how it is. Stay tuned.

[Doug Coulter]

I'm testing this one function at a time to find out who's naughty and nice. I'll rate this A/D as "not bad". Neither miraculous nor horrible.

For this test, I'm doing my usual stunt of reporting data at 100 ms intervals, and right now I'm digitizing the first 4 a/d channels and looking at how "good" they might be.
Summing 8 samples per channel per 100ms is getting me a few-count spread on pretty well filtered inputs - about as good as one can do on a kludge board -100uf to ground, using a new battery with 100k in series (it's a good voltage reference) and I've also set up a pot across the supply (3.3v internal at the moment) divided 101:1 with 100k/1k and 100uf filter.
If I use .1uf caps, I pick up about double that count spread. Now, we could make this look a lot nicer if we used an infinite impulse response (IIR) filter, vs what I'm doing now - simply summing the samples - but then we'd be seeing a moving average that would include things that happened before _this_ 100ms interval. It would not only look nicer, one couple probably cut the number of samples in half, and even with the now-required floating point math, improve the cpu usage. Right now, a 678 us per call to sample each channel once, we're using around half the cpu time to just do that, which cuts the loop cycle time to 149kz (the real number is twice that, I'm reporting what the scope reads as I simply toggle a data line once per loop - so it's divided by 2).

So, at least on varying signals, we've got 13 or 14 bits useful resolution perhaps - using the inevitable noises as a source of dither. I haven't yet nailed down accuracy, but it seems fairly linear.

One really important thing to note is that full scale for this "12 bit" a/d is 4064, not 4095, which made me a little suspicious at first - that's the lowest 4 bits as zero...hmmm. But it really does seem to be a 12 bitter, just has this limit at the top (at 3.3v supply voltage, and putting in a little more doesn't change that - I used some series R to avoid smoke when trying that).

I've not yet tried out David Buezas' diff amplifier code as the app I'm heading for here doesn't want it - but I'll sneak in a test at some point. It IS cool that the new hardware is in there.

For certain, it seems good to drive this with a really low impedance - say less than 1k - else the other noises close by toggle a few of the lsbs. It's always not-trivial to have an a/d on the same chip with other things that can make significant noise.

It looks like there are pads to solder-bridge on the board to run at either 3.3v or 5v. I need to figure out if that's the case and try that too. 5v is better for the data acq and control app, as it'll be a little less noise sensitive and also drive a low threshold fet that much better for doing power things (my solenoid valves).

[Doug Coulter]

High speed counting is one reason I decided to fool with these, with a faster system clock they ought to be able to count faster too.
Here's the code I use - works in this and in unos at least.
http://www.coultersmithing.com/forums/v ... =32&t=1150
So far, so good. David Buezas version is good with this. The "new" master, not so much - it grabs timer1 for pwm use.

[Doug Coulter]

I have now tested the version of MsTimer2 that was in my libraries folder from way back. Not sure it's the latest, but it does work on the new hardware with David Buezas' json url support.
Paul Stoffregen has written a newer version that also supports teensies, which I don't think is the one I tried, but knowing him, it probably works too.
This generates a repetitive interrupt that calls a callback you specify in the setup at a rate you tell it in its setup, on very precise milliseconds using the same timer as millis();

Here's what documentation there is on it:
https://playground.arduino.cc/Main/MsTimer2/

Since I'm using fastio.h as well, I did things slightly differently than the example there.
I used pin D12 because the onboard LED is on that pin (which will mess up SPI with default pinouts).

#include <MsTimer2.h>
So in setup, one has:

Code: Select all

  fastioMode(D12,OUTPUT); // ok, this is our led on lgt8
  MsTimer2::set(200, flash); // 200ms period
  MsTimer2::start();

And the flash routine is simpler:

Code: Select all

//////////////////////////////////
void flash()
{
//  static bool output;
  fastioToggle(D12);
}

// Why did I use the funky names for the D12 pin?  Because #define LED_PIN D12 doesn't work in the Larduino library...evidently it's too many defines deep for the Arduino compiler.

Sometimes hard to decide where to put these examples, as some of this info is hardware, some software...oh well. See the software section for other examples.

The example here hits flash() every 200ms forever. There's a stop function to make it quit. this is analogous to the GTK3 library functioin: Glib::Timeout::add() I use in the pies to get things polled without locking up the cpu in infinite spin-busy stuff.

[Jerry]

Lol, try the Teensy 4.0 with a 600MHz ARM cortex M7. It benchmarks at 330x the speed of a 328. I picked one up for work the other day.

https://www.pjrc.com/store/teensy40.html

Still $20

[Doug Coulter]

Oh, no doubt - teensy kicks butt, I've got some of the older ones. Here, I don't really even need the speed of these things, though - other than to be able to count robustly up to fairly fast count rates, and for these I have code to do that - for the teensy I don't....and for around $25 (not that it really matters on this scale, other than to have some ready spares in stock), I just got 9 more of these little guys - it's a fit to purpose thing, I never said a teensy didn't kick butt (and PaulS for sure does - I use his stuff lots).

Good to hear from ya, Jerry. So what are you gonna use that new teensy for? I see lots of possibilities. Here, the hardware counter was a big feature for a specific thing I need - I'd love to find something with multiple "at least that many bits and speed" hardware counters to use instead, but didn't find such a thing. I'm not even using David Buezas differential amp code on the a/d, but I'm getting what looks like around 14 bits good out of it at the speeds I need with a little help from math. So this thing isn't exactly a complete loser.

Sometimes more of this or that spec doesn't fit the engineering tradeoffs. I know diddly about the direct use of teensy hardware counters for example (how many and how to use them?), and here, even this thing is loafing computationally - that's not the issue for this job. This looked attractive vs poring through the horribly organized peripheral dox (usually generic with specifics for this chip left to the imagination of the engineer to test, and separate dox from the cpu core stuff - some assembly required) for the teensy to figure out how to get deterministic counting at speeds faster than ISR latency. Another example, I recently got a pi-4, it's nice - it would make a good kinda-weak desktop. But I've got pies back to rev2 here in various jobs - mostly collating data from arduinos for realtime stuff, running mysql, NGINX, various cgis, a camera, and so on - and they max out at 10% or so load - running my water, power, car charging, and heating systems - no fan required, either. The pi4 is like "what do I need that extra heat and power draw for, given that?". I already have a decent desktop machine in every room - some have two! So while it's a neat thing, it's just a bench toy at present. Different strokes and all that kinda jazz.

So the only reason to like the faster clock here - for this app - is that it's used to sync external inputs for that hardware counter....and my time to write code. I can just port over code I just proved works on this too with little effort - already finished that part. Sometimes my time/speed is a real parameter in the trade-off space. The stuff in the vacuum tank is what's important, this is just a tool on the way for some experiments there.

[Jerry]

I needed to talk to a propriety serial bus we use at work that would have to clock in data at 50mhz (~50 megabytes a sec) but its just a tad too slow for that. Going with a FPGA board from Opal Kelly. More expensive but it already has the LVDS lines and serializers, deserializers built in.

I picked this up at the Tektronix company store a couple months ago. All that was wrong with it was a dead bios battery. Runs XP.

LeCroy WaveRunner 64xi by Jerry Biehler, on Flickr

[Doug Coulter]

Yep, one size just doesn't fit all. It's the job of any engineer to pick the right tool for this particular job - for these cases, it wasn't a teensy - Or well, in my case it might have been if there was in-hand good clear documentation on how to just get at any hardware counters it might have - there wasn't for atmel 328's either - but I had long since found some that let me have my way with it, just register-bashing, and that's some nice hardware. This application just doesn't need the cpu speed, only the counter logic...

In tests here, it counts past 12 mhz on clean signals before it starts making noticeable errors, which is well past what anything but a PM + fast scintillator can produce. Rollover is handled perfectly, so that part is "job done".