Search results

I just want to add a FYI for users of the PWM feature on the T3.5 ( and others). So I am using the T3.5 to control a NEC uPD765 floppy disk controller chip, for investigation of how this chip operates in DMA mode. I was using a 8MHz xtal block as the main chip clock (CLK), which was divided by...

Just a quick thank you Paul. I have never used PWM commands previously. By chance yesterday I was working on an ATmega128, and found out that it had no analogWriteFrequency() command. So I assume this has been added for the Teensy. I need to fake a floppy index pulse, and the two commands...

I have connected a NEC uPD765 floppy disk controller to a Teensy3.5 , in order to experiment and understand how to program it. This chip needs a 4MHz main CLK and a phase aligned 500kHz WCLK (write clock). I thought - "oh this might be easy to do on the T3.5 without adding xtal and divider...

When I remove the USB IRQ disables (mentioned above) and instead use the correct IRQ for the T3.2, so setting the port interrupt as the highest priority, the code works flawlessly. const byte fromFDDreadPinIRQ = 43; // IRQ_PORTD = 43, // kinetis.h (Teensy 3.0) I last worked on this code...

Progress! The problem appears to be fixed for the T3.1 and T3.1 boards. Code for the T3.5 does work but needs further debug. Before calling the code which reads and decodes the data stream (on the fly) and where timings are critical, when I add the following two lines the returned timer values...

Thank you for taking the time to reply. Apologies. I cut and pasted code, leaving out a big section [ if (readmode==DECODE_EVENTS) {...} ] which wasn't relevant for debug, also omitting the final [ asm volatile("dsb"); ] (by mistake) which I believe is similar to to the asm you suggest.

It's been nearly a year, but I am re-visiting this issue. It has really bugged me as to what is going on. I have now done some work to generate a clean data stream, from a Teensy3.5, to help investigate. The new code will allow me to generate a double density Atari floppy disk compatible...

Hi Tim, I can't comment about the Teensy4.1 code, since this SoC goes up a level of complexity. I get the impression that it has some kind of pin re-mapping, but that's all I know. Using my code on the Teensy3.5 (but should port to any Teensy3) you have to use pins from the same port. It helps...

I just noticed that for the Teensy3.1, for every "slightly too long" captured value, there is a matching "too short value". Looking at the middle table. Expected value = 46. Pair values 51 and 43. (43+51)/2 => 47. Pair values 56 and 36. (56+36)/2 => 46. It seems to confirm that something is...

I replaced the Teensy3.0 with a Teensy3.1 and re-ran the experiment. Total number of event captured 700 00000 _____ _____ _____ _____ _____ _____ _____ _____ 00008 _____ _____ 00001 _____ _____ _____ _____ _____ 00016 _____ _____ _____ _____ _____ _____ _____ _____ 00024 _____ _____ _____ _____...

I have made some further investigation. I am now using a Teensy3.5 to generate a sequence of 4us "read-data" pulses and some fake index pulses. See my posting in another thread about using DMA and the PIT timers to stream an 8-bit array to a 8-bit GPIO port. I have connected the fake read-data...

Oops forgot to mention. I added some code to DMAChannel.h to support PIT continuous trigger mode. Add around line 477 just below the function void triggerAtHardwareEvent(uint8_t source). // Use a PIT to make the DMA channel run void triggerByPIT(uint8_t source) { volatile uint8_t...

Thank you. I have been playing with DMA today on a Teensy3.5 and I have learnt quite a lot. It's not too difficult, however I haven't seen it clearly documented. The datasheet is a bit unclear in my opinion.

I have been reading the K64 Sub-Family Reference Manual, and various postings found online. The Teensy3.5 DMA is composed of two parts, the DMAMUX and the eDMA. I would describe the DMAMUX as the thing that selects which module will trigger each of the 16 DMA transfer modules or "channels"...

// // program top experiment with streaming an 8 bit array to an I/O port using DMA // // Written by badsector/migry // // 20-Dec-2023 : First write taking toggle example code from PJRC forum posting. // - Did eventually see a 500kHz datta stream on digital pin 13 (PORT C pin). //...

OK I have spent an interesting day or two trying to understand the operation of the DMA and get something working. I now can stream from a byte array to the lower 8 bits of PORT C (maps to various digital pin numbers). The bottom blue trace is a spare pin I toggle to show where I am in the...

Could you give a pointer to your code please, and title of thread (if applicable) ?

You might have given me an idea about a "how do I" thread I started earlier. I am hoping to use a Teensy3.5, so plenty of RAM. I need a continuous single bit stream (it does need to start, run, and then stop). It could be done if I had an array of bytes which were sent by DMA to a set of port...

Continuing my floppy disk read saga.... I would like to understand what methods I might use on a (spare) Teensy 3.5 to generate a data stream which would be used to write floppy data. The idea would be to use this to feed into my Teensy3.1 board to see how the pulses are measured, but it could...

Thank you for your suggestion Chris. I tried adding the suggested change, as follows. // slew rate CORE_PIN11_CONFIG |= PORT_PCR_SRE; CORE_PIN12_CONFIG |= PORT_PCR_SRE; CORE_PIN14_CONFIG |= PORT_PCR_SRE; CORE_PIN15_CONFIG |= PORT_PCR_SRE; CORE_PIN16_CONFIG |= PORT_PCR_SRE...

I don't know if I am wasting my time by going down a long rabbit hole.... I am intrigued as to what the problem could be, and my curiosity is to investigate it, even though I have a work flow using the Teensy3.0 and FTDI module for serial transfer. While developing the code to decode the data...

Yes, thank you. That was the posting. I added the asm command, which was after a digitalWriteFast(), so it did follow a hardware write. Unfortunately the problem has not been fixed. :-(

Sorry. I don't have a blog or a GitHub. Nevertheless I am very happy to share the code with anyone interested. If you want deeper details/information, probably best to PM me and I will answer ASAP. I kept many of my Atari ST floppies from the 80's. I have now been able to recover much of my old...

Apologies. Please ignore my "read ZERO" from the FTM. It was a bug in my debug routine in the ISR which records values in an array.

NVIC_SET_PRIORITY(fromFDDreadPinIRQ, 0); // HIGHEST priority I am pretty sure that during the track/sector read only the index pulse and read-data can generated interrupts. I switched off the SysTick. Other sources of interrupt, well I'm unsure. I haven't disabled USB interrupts, but this...

const byte fromFDDindexPin = 22; const byte fromFDDreadPin = 21; // PORT-D IRQ #43 const byte fromFDDreadPinIRQ = 43; // IRQ_PORTD = 43, // kinetis.h (Teensy 3.0)

I have done some further investigation, looking at the raw data captured from the FTM timer module. I also compared a good data stream against the place where it was corrupted. I tried to line up the re-constructed floppy read pulses, but when I did I found the corrupted data needed an extra...

I would appreciate any pointers (other postings, web sites) as to how to identify all sources of interrupts and the code needed to disable them. The MK20 SoC is a complicated and sophisticated architecture and I am no expert. It's significantly more complex than the good old 8031 :-) . My idea...

OK, so I now have a working system (work flow) using the Teensy3.0 (with the needed 96MHz overclock). I searched around and found a FDTI board, the common red type, and likely a Chinese clone/fake. I played around with TeraTerm and flow control, but it was another rabbit hole. The FDTI board...

Wow! Great. Looks like a really useful little program. Many thanks. For some reason I had problem with Serial starting so I removed the millis() part. I'm pretty sure my board is a Teensy3.0. It has no text indicating this on the bottom of the PCB (nether does the 3.1), but the 3.2 does have...

A quick update. I have a Teensy3.1, but it needed to be de-soldered from it's current usage. I tried the floppy decode/read and the behaviour was the same as observed on the Teensy3.2. Only about 1 read in 10 returns the correct data. Note: this was compiled with the 96MHz overclock. I did try...

Some additional information regarding USB/Teensy3.X/overclock. I replaced the Teensy3.0 board with a Teensy3.1. I re-ran the "serial USB transfer debug" program (all hardware code removed). At 96MHz overclock I got random lock-ups. Serial stopped working completely. Serial worked but froze...

Following on from a previous thread regarding serial data corruption over USB, likely due to using the 96MHz overclock on a Teensy3.0. The project uses a Teensy3.0 to decode the read-data stream from a double density disk in an Atari ST disk drive. I replaced the 3.0 with a 3.2 board. I copied...

The ASCII printing of the data from the floppy in 512 byte chunks as hex and ASCII data is how I collect the floppy data, so is critical to the application. The same Perl script as posted above processes the log, extracts the hex numbers and converts then into a 720k byte binary image of the...

After some more experiments, I might have found a reason for the problem. Due to needing to decode the floppy data stream "on the fly" I was over-clocking the Teeny3 to 96MHz. I experimented with compiling for a CPU speed of 48MHz. I captured data from the debug program three times, with no...

Perl code to create the binary from the hex ASCII log capture. Execute with something like: /path/perl hex_2_bin.pl -i CAPTURE.log #!/usr/bin/perl #use strict; print "#########################\n"; print " Simple hex to bin v1.01\n"; print "#########################\n"; if ($ARGV[0] =~...

Here is the stripped down code. All (floppy) hardware references have disappeared. What is left is the transfer of 720k of data in hex/ASCII format. The function that generates most of the text is "dumpSector()" which I have tried to leave as much as possible. There is a single #define to...

Thank you once again for your reply. Yes I can make a test sketch by removing all the code to do with floppy hardware control and read stream decode. I already fill the track buffer with default values before doing the read, so that any missing data can be easily spotted. I can leave in the...

Thank you for the reply. I have been trying various things and I have got very confused. Sorry of the text below is unclear. I am updating it as I try more code changes. I had a moment when I thought that I had figured out what was wrong. I hadn't selected "hardware" flow control in TeraTerm...

I did search the forum but didn't find a solution, but some related information about USB. I have a Teensy3.0 from which I print ASCII data via Serial (which is the USB connection) and capture the data in TeraTerm. I am intermittently losing small chunks of text. I am unsure as to where in the...

OK Paul, I appreciate you taking the time to reply. Apologies if I insulted you in any way. I do realise just how difficult it can be to catch every possible error/overflow. If nothing else at least there is a thread which might be found by anyone inthe future who might make the same mistake...

Well yes, I agree, we **cked up. It's now clear now that not allocating enough memory blocks when using the "delay" module, was the cause of the problem. My friend wrote the code. After my friend asked for help, I failed to go to the web site and rigorously read the Audio Tool documentation. As...

Please advise (PM?) if I ought to report this in a better location (Git? etc.). I am helping a friend (a C and Teensy noob) with a controller project based around the Teensy3.5. He is using the Audio library and the tool to create the patch links. He is using one of the two DAC ports of the...

Thank you @luni once again! I have had some bad experiences recently in a varied range of forums where I have asked questions, so nice to get a friendly reply :-) I saw the page you reference, and I am now thinking that... seconds led_timeout = 1s * settings_timeout_timer(); // func returns an...

Dear @luni, many thanks for taking the time to reply. It is getting clearer, and will make sense once we have had a play. My friend and I had another session tonight and managed to get our first 5 second delay to work as wanted! Re my comment about "You can use ns, us, ms, s, min, h". I simply...

This new(?) TeensyTimerTool message thread has been very helpful... I (C++ noob) and helping my friend (C noob) with writing control software on a Teensy3.5 to implement a custom hardware solution. We have been trying to use TeensyTimerTool. Due to needing delays of upto a few minutes we have...

Hi luni, much appreciate you answering my questions. I am a C++ noob, so I appreciate your explanation of "namespace". I had no idea that you could use multiple libraries whose name(?) is the same. Apologies I am not 100% on the correct C++ terminology.

Can someone please confirm that if using this library, then the "using namespace" is required? #include "TeensyTimerTool.h" using namespace TeensyTimerTool; What is the impact of missing out the "using namespace". Some time ago I did read somewhere in this thread, but the penny hasn't dropped...

Final post! I modified part of Adafruit_SSD1306.h to this. The #define for the Teensy LC is "KINETISL" (not TEENSY_LC !). #if defined(__AVR__) typedef volatile uint8_t PortReg; typedef uint8_t PortMask; #define HAVE_PORTREG #elif defined(__SAM3X8E__) typedef volatile RwReg PortReg; typedef...

Sorry, this is now getting off topic (Adafruit SSD1306 / GFX library). BTW digitalWrite works correctly with digital pin 0 and 1. Note: I am using the terminology from the MC68000 :) , byte = 8 bits, word = 16 bits and long = 32bits. I have no idea what the correct ARM terminology is. So I...