First go with Teensy 3.2 board

For stand-alone microprocessors

First go with Teensy 3.2 board

Postby Doug Coulter » Mon Oct 19, 2015 1:47 pm

Well, there I was trying to stuff 200 pounds of stuff into a 50 pound box...in this case, a combined gas and ion grid controller for the fusor, to be part of the data aq and control for fully remoting and automating it.
It almost fit. And I could have forced it, but it would have required re-writing a couple of the base arduino libraries for I/O to get the speed I needed to have a stable loop for certain, and it probably would have stumbled slightly when a host PC wanted to send it a command or get data. Since we are not yet at the end of the world, and resources are there - what the heck, I thought about trying out the new Teensy from PJRC. After the usual bit of fiddling around to get the toolchain going (it requires any version of the arduino IDE except the one I had, a few slight system file edits, and so on - nothing unusual) - it's one really nice piece of work. Thanks Paul and Robin for making this so I didn't have to and can just move on to programming it and making use of it in a practical application.

There was (and is) of course the usual learning curve. As Paul wrote - the dox are kinda hard to read - even if you can find them all and you're an engineer experienced in translating obscure data into useful information. Such is life with ARM things (and a few others that are almost as weird). Obviously, Paul alone can't re document everything. So there are a few glitches along the way. Example - arduino.cc says an integer (for uno) is 16 bits, but here it's 32. No big deal unless you weren't paying attention. I suppose that's why a lot of the raw code additions use things like int16_t as typedefs for stuff - so there is simply no question about that kind of thing - the bitness is right in the definition itself. This is good for the few of us that work on many different platforms at a time, versus using C's "int" and so on...as my email sig says "Why guess when you can know?".

One of the reasons I got interested in the Teensy in the first place was the built in D/A, as I'm doing a PID loop control for the ion grid bias, along with other things, and that requires an analog output. While the Uno could do this via an MCP4725(from Adafruit), the combined delay from the I2C and the conservative a/d timing (max wait between samples on different channels to let the S/H acquire) meant I was really pushing things.

While I have not yet tested the A/D performance on the Teensy (coming up, one thing at a time) - the D/A is nicely quick, around 3.5 us/sample when fishing samples out of a table. I also need interrupts for this project, so I wrote a little test. I make a sine table of 50 samples at startup and push that out to the D/A, then wait 5uS and do the next sample. I set up an interrupt from timer one to go 10 Hz, and watched to see if there were any issues (like the famous "pentium pause") - but nope, after a couple days, they're still in the same exact sync as when it first powered up with this sketch. Not too shabby...I will go on to other tests and provide the code for those as well, but here's the picture - same one for about 72 hours of running, not one sample off. I had the scope triggering on the interrupt which also toggled the LED pin, so it's showing 5 hz, or a very close approximation - at that many digits, it's hard to tell which one is closer to the truth - this is darned good.
DS0000.gif
Scope triggering on 10 hz sq wave and showing D/A output as well.
DS0000.gif (4.89 KiB) Viewed 8485 times


And of course, here is the test code I was running as a sketch in arduino IDE 1.6.5r5+teensy tools. FWIW, I'm using Mint-Mate 17.2 as the PC host system, which is based closely on Ubuntu except for having a far nicer desktop and user interface (obviously, a matter of opinion, but a lot of people have this one, having fled from Unity being crammed down our throats with only options for an incomplete and broken GTK3). Works fine. I haven't yet really run into any problems with ubuntu things working fine on Mate - they just look nicer and are easier to use than with Unity.
TeensyDA_ino.zip
Simple sketch to test D/A and interrupts
(729 Bytes) Downloaded 239 times
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: First go with Teensy 3.2 board

Postby Doug Coulter » Tue Jan 12, 2016 2:25 pm

With a little more under my belt on this guy, I have to say - I really like this thing. Yes, the dox are bad/obscure, but you barely need them outside of some perfectionist goal. The fact that pjrc has some and there's a forum for these is helpful. It's not just a one-person thing anymore. At the same price as non-China arduino UNOs, it's a total no-brainer.
While the produced code isn't as compact - there's plenty extra room. Everything I test works...that's a fairly big deal for me. I've upgraded most of my machines to arduino 1.6.7 IDE version - it's blazingly faster than the older ones and fixes a lot of minor annoyances, too bad there's not a port of it for pi yet (and I'm too lazy to make one). It's even acceptable on my ancient lenovo centrino laptop now, which I use for "field service" on things like that once they've been deployed, often to a nasty place...It beats pulling something out of a bad spot, bringing it inside, fixing it (and not being able to test the fix) re-installing and so on. Just take the laptop to it and fix it in place.

They named them right - here's my test rig for the current project, so I can test without having it in the (currently chilly) shop hooked up to all the big power supplies and so on. I'll be blowing a signal generator into some of the inputs to tune the PID to the point of it "being on the right page" - but the code allows for remote tuning as well. The tuning parameters are stored in eeprom under host command, which is convenient.
teensy.JPG



Code du jour is for an ion grid supply controller, which will at some point also control the gas inlet and outlet valves for the fusor - bascially, when the ion gun refuses to draw current, it will let in gas. When the main grid refuses to draw the desired current, even with the ion source off - it'll let some out. Kind of "if the PID loop for ion control hits a stop - do something else - get things back into the operating control range". This uses my now-standard human-readable master-slave protocol, which allows for "unit numbers" when used in a wired-or setup with a raspberry pi (or other serial) master as well. Unit numbers are not required so much when on USB, but it was easy to just copy the code from elsewhere and replace the commands with ones unique to this job, as usual - pretty much all (no exceptions so far) of the older arduino code just comes over, but some things are nicer if you use the teensy libraries instead, as the hardware has all kinds of nifty features...ring-buffer DMA A/D, you betcha. You do have to pay attention to one thing - ints on this machine are 32 bits, not 16 like on an uno - so you have to pay attention if you're using something that depends on a rollover or that size.

There is a new variable type of elapsedMicros which is kind of nifty - declare it and it gets bumped once per. No call needed. I'm not using it in this sketch, but it can be really handy - you can zero one out for a stopwatch kind of thing.

This code is getting around loop() at a few hundred khz (and it's not overclocked). The ISR, which is hit once/millisecond, takes a/d and outputs d/a values after some floating point math comes in at about 100uS - plenty of headroom!
I have no doubts that if I got into the A/D library and used more hardware-magic. I could make that a goodly bit faster, but as of now, there's no need and other things need to be written and debugged.
TGasIon.ino.zip
Current ion grid power controller in teensy 3.1
(3.83 KiB) Downloaded 231 times
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: First go with Teensy 3.2 board

Postby Jerry » Thu Jan 14, 2016 3:19 am

I use the teensys whenever I need an arduino type device and recommend them to whoever asks. I also know the guy who makes them, he is part of the local dorkbot group, dorkbotpdx.
Jerry
 
Posts: 573
Joined: Sun Jul 18, 2010 12:07 am
Location: Beaverton, OR

Re: First go with Teensy 3.2 board

Postby Doug Coulter » Wed Jan 20, 2016 6:52 am

Glad to know you agree, Jerry - I'm finding these things really nice in real world uses. They are indeed well-made - 4 for 4 here are basically perfect builds. The only thing an arduino does better is fit the standard "shields", as far as I can tell. I think I saw that someone makes an adapter for that too if one really needs it.
Like you, I just build what I need - I used to do this sort of thing with other uP's on the bare metal, and am grateful that I don't have to do that part myself anymore, these things "just work".

Note the above code is just a "mechanical sample" for me to get the PID tuning "on the page" while on my bench, not the stuff I'll really be running. The PID machine in the ISR will become one of the states of a state machine there rather than the whole show it is now, for example - as I won't want it "winding up" during the gas adjustment phases of operation - for those the ion source will be set to some fixed value, likely different for the "gas inlet" and "gas takeout" stages of operation, so I can operate the valves till things are "in range" for the finer regulation via the ion source power - then switch back to a PID with all the errors set to zero initially. Since this will have a couple of unique connections to the fusor rig, it will also do some data collection for eventual stuffing into a database on the "master fusion data aq" machine for later analysis, and accept some control input from that; things like "when to run, or shut down" at a minimum, and allow some manual remote tuning. The "desired" setpoint input to the controller will be from the main Spellman power supply - it has an analog output corresponding to each front panel control, which I'll use for that, and I will simply setup a voltage divider (Spellman signals are 0-10v) such that the teensy will "think" it's on target when the actual current is around 90% of the front panel setpoint, to give it some leeway without "clipping" due to the supply itself going into current limit. I kind of went big on the Spellman specs - so there's plenty of headroom to set that up here, I never use even half of it's 2.5 kW or so possible output.

I've found in the past that the best DSP (digital signal processing) often happens when you can add some logic to an otherwise linear process, where a simple simulation of an analog linear thing - a PID loop in this case - can be augmented by some logic that "does the right thing" at the limits, instead of just "running into a wall". In fact, in this case, "running into a wall" - being unable to control main current via the ion source alone - is what will trigger going into some other state, such as letting in more gas, or taking excess out, before reverting to the simple analog control simulator. The ability to just "jam" an analog system (or simulation) to some known internal state instantly is not often found in a pure analog setup, but definitely has its uses.

I like my dumb little protocol for comm here - while using a "unit number" is redundant when a thing is on USB - I have other ways of identifying what to send where in that case - it also works in the case of a wired-or type return serial interface where the "master" sends the same stuff to the whole string, but only the right unit sees the commands - and can "speak only when spoken to" so a 3 wire interface (send, receive, ground), usable over long distances, can suffice for a lot of units.

For now I'm using all human-readable ascii for this, though it's not a constraint if more codes are needed - it's essentially just a byte oriented thing, with timing constraints for error detection and recovery; the master is expected to retry if any expected response isn't forthcoming, the units just ignore anything they don't understand or that looks like an error or incomplete command within a timing window. I'm using this also in my "Lan of things" projects, with a beefy buffer on the master (raspberry pi, in most cases) driving a "long" cable with slave units strung along it, and each unit wired-or on the return serial line (ttl level UART for now), and it's working fine at fairly high speeds (115.2kbaud) and reasonable lengths (30 feet or so at the moment in one setup). I posted some more detail on this on Ada's blog: http://forums.adafruit.com/viewtopic.php?f=25&t=73938
With some series resistors and diodes (to accomplish the wired-or effect), this can be changed to differential (RS-485-like) if ground loops are an issue. So far, this is working without that complexity and added power draw.

I guess my only whine is that, like most ARM parts - the documentation on the hardware details is scattered all over the place at best, and finding those details to really utilize the nifty features can be quite a challenge as the documentation sends you from the "general module overview" to a "detail of this implementation" document that can be either impossible to find, or which just sends you back to the overview in a loop with no info. This is sad because these parts really have some cool stuff built in, and I'd like to use more of it, just from some perhaps misguided sense of perfection - I say that because they seem quick enough for most anything without using them to the max as is. It's also an issue with Raspberry Pi, though there, the use of linux, a boon for some things, means the definition of "real time" has to be severely relaxed, as any pre-emptive opsys is not going to let you do certain timing-critical things without going off on the odd errand of it's own right when you need some cycles...for that, the teensy shines bright - no fancy opsys. So in my lashups, I use each for what it does best - I can run "real" big blocks of functionality - like webservers, databases, GUI stuff - on a Pi, and do realtime control and data aq on a teensy "slaved" to the pi, with any required buffering on the teensy, so that data doesn't get lost due to the "big opsys going off on some demented errand of its own" issue. Using each for what it does best works around most of the problems.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA


Return to Embedded software

Who is online

Users browsing this forum: No registered users and 1 guest

cron