Search results

I've been actively tracking the whole thing for a couple of years now. It's pretty much exactly like the capacitor famine, which, we are actually at the tail end of. You can blame a couple of things for the whole mess, which are very similar to the capacitor famine. Of course, the big guys...

Never use it to be honest. Instead I use stainless steel stencils and stainless steel squeegee.

I use chipquilk stuff here exclusively. Both the regular and low temp stuff is fabulous, and the flux is very easy to remove unlike a lot of competitor's offerings. Basically I use the entire product line for SMD. As for thruhole, I use MG chem's SN99.

Not such a big deal, @Paul Thanks for all the efforts on the chip, I really learned a huge amount. I too have been hit hard by NXP not getting all sorts of MCU's that I use. Not entirely sure what their problem is, if it is some sort of effort to kill the entire lower end line. Either way it is...

One way I can think of doing this with the least amount of hassle would be to choose one pin for "sync" on a pin group different than the other four and to set the priority lower than the pins on a different port, or set different port IRQ as a higher priority.

UHS3.0 does this on the K66... You still will get a "wait" while enumerating, but it's fine after that. The reason it has to "wait" is because it's doing a lot of work. https://github.com/felis/UHS30 Also supports the SDcard on the 3.6 too, with just one simple modification... connecting the...

I was going to suggest that...

Depending on the SSD, currently the maximum consumption (during a write) is ~17watts, or about 3 amps. These spikes aren't sustained long, though, so you possibly could get away with a 2amp power supply and some helper capacitors on the USB power supply line. Check the specs of the device...

Usually does. Many people don't realize that you are trying to supply power to two things plugged into one USB port, and it may have a 500mA limit of current. After traveling down a long usb cable, power kind of ends up as much less, and then, you add another at the end of that. Now you have...

P.S. All questions can be easily answered by checking out the repository here: https://github.com/xxxajk/fbcon

The actual text and attributes are stored in RAM. The display is updated one when: A character changes A character with the blink attribute is set and it needs to invert the character The cursor flashes A full display refresh and blink is set for 0.5 Seconds, however refresh can be forced at...

No, it is display agnostic though.

Well, it may interest you, or perhaps not, but... with my (unfinished) console lib, you can even have flashing text. :-D Should work if your library is fairly normal-ish. Doesn't depend too much on what is under the hood. Even works on monochrome displays. Also \007 can output a beep to a buzzer...

Looks fantastic. Is that using my console library?

The console program that I have designed does 8x8 characters, none of that silly anti-aliasing nonsense, and no possibility yet to scale up the size. Why 8x8 pixels fixed? Because I like my pixels to look like pixels, not like I need a new set of glasses. Anti-aliasing drives me nuts when...

It's never too late. Pixels might be a bit small, but that's actually a pretty good find. I guess I could even use the unused screen real estate for other data. I'm mostly interested in running https://github.com/xxxajk/fbcon which if you try out, will show you the reason why I'd like to have...

Very cool. Note I do not mind if data sent out is polled, I can imagine that DMA could have an advantage in many cases. Keep up the haxxoring!

T3.6 direct register writing, not released yet, because it's not good enough.

Some polling results Been optimizing the parallel display here (polled, 8bit and 16bit) and I thought I would share my results: 8bit ILI9341 Test! Display Power Mode: 0x9C MADCTL Mode: 0x48 Pixel Format: 0x5 Image Format: 0x0 Self Diagnostic: 0xC0 Benchmark Time (microseconds)...

That sounds like DSPI/QSPI...

Nope, not. I did this board back in 1996... I've moved on since then.

Note there's no ROM on it... The 6502 is halted, code uploaded, and unleashed. There's a mailbox bit for ISA to basically say "freeze me, I got something for you". The PC then stops the 6502, and has access to the 64k of RAM. The PC does whatever, and then resumes the 6502. The other way is true...

@jonathan322 Don't forget that 65xx/85xx CPU does RMW for writes, i.e. on the bus does Read/Modify/Write, this is in sync with theta 2. And you need to account for that, *Cough!* Yes 65xx was the first CPUs that I did hardware with, and I've done ISA 8088 <-> 6502 ISA bus cards.

@miciwan Think on how the classic Hardware Serial (and actually, USB does it to) buffers, in order to handle bursts. Since there's only one DMA controller, you just use the CPU as the "second DMA controller". Yes, it ties up the CPU, but the idea is to have a buffer to store while other things...

@miciwan perhaps a double-buffered DMA or interleave could work for you? Idea 1: Single stage FIFO Loop DMA to a "fast dma buffer" and then another DMA relays that to the EXTMEM, which can use bursts, and that way you could possibly not lose any data. The idea is that while EXTMEM is working...

Yes, input from cameras is another use case.

Nice! So, where are these wonderful libraries located? I have the components here to try things.

Yeah, there lies the difference in end-goals. You are rendering entire frames, I'm not always doing that, thus I only update areas that are changed. You could get a huge speed boost if you could mark dirty lines or areas instead, and only blit those. The ILI chips do support blitting in a...

Yeah, but I just got 2 320x240 ILI9341, which has a flash chip, and SPI resistive touch controller on-board for under $12 delivered, from Amazon. The date codes suggest that they're new-old-stock, as they're from 2015. Flash chip I'm going to pop onto one of my Teensy 4.1 boards. Might be...

Yes, but no price listed, and anything else I've managed finding cost over 100USD... :-(

What I'd love to see is a 4:3 TFT that's 640x480, seems that they're no where to be found, because everyone thinks 16:9 is all cool and stuff, bleh. Why? well, I'm not rendering fancy graphics, I just want a terminal I can stuff in my pocket :-)

DemoSauce https://www.youtube.com/watch?v=Vjb6h8Yx78Q Benchmark https://www.youtube.com/watch?v=BbsSy956H8Q

My library is for teensy 3.[01256]. There's the difference. The library also isn't as efficient as it could be. With an under 10ms update rate, there's no reason why you couldn't break the update into smaller chunks, perhaps a couple of lines at a time, via an ISR. Totally doable with my class...

Direct to port writing, and delayNanoseconds for pacing the signals. Full screen blit takes ~7.7ms. I'll be sharing the library soon, and I just got DemoSauce going. Uploading a video to ewwtwob of DemoSauce and the graphics test. I wIll post links here when they're ready videos are ready. It's...

...interesting idea, however I've not found a use case where DMA can help. As of right now, I have a Teensy 3.6 operating in 8-bit parallel mode with an almost complete library. It's good enough to run the typical "graphics_test.ino" but can't quite run Demo Sauce yet... seems to have problems...

While it doesn't actually use microsecond resolution, the project that uses this code does, so it made sense to just leave it as-is and share it with the world.

I've just released a no-frills fb console that's easily portable to just about any LCD/TFT display. Included is an example doing direct displaying of the character set on both the monochromeST7565 and ILI9341 (using ILI9341_t3). More examples to follow as I get time. Features: Uses my latest...

Why not use a static variable that the user can set before threads start?

Kinetis is for Teensy 3.[012] :-) The other is for MAX3421E on SPI, and yes, you can use that (up to two MAX3421E) plus native USB at the same time, AND SDcard after 2 simple soldering modifications. Configuring returned 00 <-- means it was successful. mount isn't happening because your storage...

@wwaton It was a bug that crept in. Fixed and working.

Is this a powered hub by any chance?

Ok, that sort of makes sense... I managed to get him rolling again. He needed to plug-in the T3.6 while holding down the upload button, and recover by uploading good old reliable blink.ino. What's really strange (and I've noticed this on occasion) is sometimes, for no reason at all, the 3.x and...

Friend of mine in India is having a VERY strange problem with TD 1.54. The compile is fine, but the TD uploader shows something WAY out of wack. See photo. No way the hex file is too large for the T3.6. Any ideas I can pass along? He's using Ubuntu 20.04 64bit. He would ask himself but the...

@wwatson More improvements have been pushed, pull and try again. More information can be gathered by turning on the host debugging in the sketch

Status code 0x01 and error 0x11 shouldn't be possible...

And now for the universal one... // PROGMEM fix for section type conflict #define QUO(x) #x #define QLINE(x,y) QUO(x)QUO(y) #define PFIX QLINE(.progmem.variable, __COUNTER__) #define PROGMEM __attribute__((section(PFIX))) // You are welcome! --AJK :-)

@Paul (and everyone else) I have a working magic set of macros that fix this Here you guys go! #define DMAMEM __attribute__ ((section(".dmabuffers"), used)) #define FASTRUN __attribute__ ((section(".fastrun") )) // PROGMEM fix for section type conflict #define QUO(x) #x #define QLINE(x,y,z)...

Macro magic anyone? :-D all you need to do (yes, I just said that) is have a macro that adds another subsection. In theory, that's the fix.

Technically, there is a fix, but it has to happen on the teensy4 core side of things. #‎define‬ PROGMEM __attribute__((section(".progmem.vars"))) **note fixes global variables ONLY, but PSTR() needs something different

I too just ran into this :-) Apparently there's a VERY tight constraint that GCC is using during the compilation, and marks the sections different if it's global, or not. :-/