Just had a look at Octopart. There are plenty at "unsusal" suppliers. https://octopart.com/search?q=mcp23S17¤cy=USD&specs=0&in_stock_only=1 (click on "show all" below the standard distributor...
Type: Posts; User: luni
Just had a look at Octopart. There are plenty at "unsusal" suppliers. https://octopart.com/search?q=mcp23S17¤cy=USD&specs=0&in_stock_only=1 (click on "show all" below the standard distributor...
Sure, something like this should work (untested, first value will be wrong)
#include "Arduino.h"
#include "EncoderTool.h"
using namespace EncoderTool;
Encoder spindleEnc;
Oh, that's bad. I assume you checked all the usual sources... Just saw RSComponents has 3 on Stock but a MOQ of 5 :-))
Your'e welcome.
Make sure to get a MCP23S17 which is the SPI version. The MCP23017 are I2C which is slower.
Here an example how to use a MCP23S17 to read out encoders with the EncoderTool (working example here: https://github.com/luni64/EncoderTool/tree/master/examples/2_multiplexing/multiplexed_MCP23S17)....
The nice thing about this approach is, the whole thing runs completely in the background. Your foreground code can do whatever it wants, as long as it doesn't disable interrupts your leadscrew will...
If you don't find a possibility to do non blocking writes to the display you might consider a different approach:
If you can assure that the number of encoder counts per spindle rev is always...
Yes, I just looked through my stock of bought but never used parts and found a couple of 23S017. Starting to rain here. So, extending the EncoderTool might be a nice weekend project :-)
Discussions about encoder readout strategies seem to always end up like windows vs. linux discussions :-)
I'm the author of the EncoderTool library which, to avoid those discussions, supports...
Thanks for the shout out but the TimerTool only uses the timing functions, counting is a different thing. I recommend manitous collection of snippets https://github.com/manitou48/teensy4 instead. You...
Thanks, I'll have a look. But this will take some time (working on another project currently...)
Quick Idea, can you change the GPT1/GPT2 to PIT and see if it works then?
Thats nice indeed :-)
setPeriod changes the period immediately. I.e., it will end the current period and restart the timer with the new period. setNextPeriod is supposed to set a new period after the current one is done...
Ups, thought I had changed them all. Thanks for spotting this.
You change the period by t1.setPeriod(...)
Great, hope you show the progress here. At least I'd be very interested.
Long...
I just saw that you are using the depricated Timer API. You should have got a corresponding warning from the compiler!
Instead of
Timer t1(GPT1);
say
If you tell me where you have problems to understand it I can try to explain. Your code basically does the same but a bit more verbose.
You can use both GPT1 or GPT2. Setting it to 150MHz will...
Either one as long as you stick to it :-)
Not a good idea to ask the same question in two threads....
see here: https://forum.pjrc.com/threads/59112-TeensyTimerTool?p=305466&viewfull=1#post305466 for an answer
Your code is a bit convoluted. The problems you get are probably due to the short period and the relatively (to the calling period) long blocking in the callbacks.
I'd do something like this:
...
Whatever timer you use, the drift will always be the drift of the corresponding crystal (IIRC: ~20ppm). If you need less you might be better off with a clock module like this one...
Ah, that makes sense.
Let me know if you need further support with TeensyStep
As mentioned in #2 you must not call a move command while the motor is still moving. The code in #1 calls moveAsync every 2 seconds regardless if the motor moves or not. -> the movement will be...
It is running from a timer interrupt. I.e., the moveAsync() sets up all parameters for the movement and starts a timer which generates the pulses, adjusts the timing as needed and keeps track of the...
moveAsync is not blocking (hence the name). In loop you call moveAsync every 2 seconds, i.e. you call moveAsync while the motor still runs which will mess up the controller. Try using...
Looks like you are using a stock gcc compiler. Teensyduino expects some math libs copied into the gcc folders. See here...
Please test and let me know if it works for you before I push it to the master branch.
As defragster mentioned, all TCK timers (TCK, TCK64, TCK_RTC) run from yield. Anyway, I never had issues ...
Pushed a test version to the RemainingTime branch. Here a usage example:
#include "TeensyTimerTool.h"
using namespace TeensyTimerTool;
OneShotTimer t1(TCK64);
volatile bool start = true;
Currently not but I can have a look later this weekend. There is no FTM64 did you mean TCK64?
Looks like you want a timer interrupt? If so, use the IntervalTimer which is the native timer for all ARM Teensies.
IntervalTimer t1;
void onTimer()
{
...
I had a closer look at the StreamUtils library which is quite nice. The StringStream is really useful for converting printables like a crashreport to Strings:
#include "StreamUtils.h"
void...
Yes, the streamUtils library seems to be an overkill for this. (However the library looks very interesting for other stuff).
The code shown in #3 could be done much simpler, unfortunately a bug...
Actually CrashReport derives from Printable not Stream. Anyway, you can easily capture the content of a printable object with the following helper class. The constructor of the StringDumper "prints"...
Try this:
Adafruit_SSD1306 dispay[]
{
{SCREEN_WIDTH, SCREEN_HEIGHT, &Wire2, OLED_RESET},
{SCREEN_WIDTH, SCREEN_HEIGHT, &Wire2, OLED_RESET},
{SCREEN_WIDTH, SCREEN_HEIGHT,...
I had a look at TimerOne, actually it uses an FTM Timer, not an IntervalTimer under the hood. Anyway, the Intervaltimer seems to be a better fit.
TimerOne is a compatibility wrapper around the native IntervalTimer. So, unless you need to write code compatible to AVR you'd be better of with an IntervalTimer. This code generates a 50µs pulse...
Here the link to said 64bit code https://github.com/TeensyUser/doc/wiki/Using-the-cycle-counter
I added a helper class which automatically maintains a list of all currently existing instances of a class to my TeensyHelpers repository.
Such a thing comes in handy if you design a class which...
https://github.com/Koromix/tytools/releases
Comparing the addresses of the port objects as you did is perfectly OK. The only 'drawback' (if at all) is, that it needs to be done at runtime (if the compiler is not able to optimize it away...)
...
Reading out encoders and communicating the values to the PC are two completely different stories. You don't need to add 16 encoders to the 4067, 8 will work just as well. Or you use the 4051 which is...
Using the EncoderTool (https://github.com/luni64/EncoderTool) you can easily multiplex rotary encoders and their pushbuttons which reduces the number of needed digital pins significantly. Here some...
The connection you described in your connection scheme is definitely wrong and can't work. You need to connect the channels A and B to the input pins 1 and 3 and the common pin C to GND. However,...
My gut feeling is this will get unstable with 6 motors. Your 2MHz Manchester stream generates a lot of data which needs to be copied around and analyzed. Plus, there are only 4 HW quadrature decoders...
Does anything speak against a simple:
void setup()
{
while (!Serial) {}
DMAChannel dma;
// code that sets valReg programmatically here
First, I'm no expert in DMA at all so take the following information with a grain of salt.
The DMA (direct memory access) controller is able to copy data from one location to another location using...
I just uploaded a DMA based version. The DMA setup is surprisingly simple. Here the relevant code. Full version here...
Even 100ns seems strange maybe Paul knows what's running there with high priority or disabling interrupts when serial printing.
Actually I was thinking the same. @PaulStoffregen: any idea which high priority (probably prio 0) interrupt runs for about 400-800 µs? It seems to be related to the CDC interface. But the only USB...
Yes, here is the code which makes sure that the frames are read in consecutively...
Usually you want to separate the actual code (the definition) from the declaration in the header. There are various reasons for that.
If you have all the code in the header it needs to be...