Search results

Great work you too. When I see your demo, we can tell teensy CPU has a lot of computing power because all is performed without any dedicated hardware.

As Frank B says, these messages are normal. This first message acts as a reminder of the current resolution. Most of the time, default resolution is set but default resolution depends on teensy frequency. This message is a notice about special case occuring in scroll function where it is...

displaying more than 256 colors using ... 8 bits While googling to find a solution to my flexbus latch problem, I find an interesting page. Instead of encoding pixel in RGB332 (RRRGGGBB), it is encoded in RGBI2222 (don't know if the term exists :cool:). Each component is encoded on 2 color...

As I am kind of stuck on flexbus demuxing, I am trying a different approch using flexbus controller "twin", sdram controller :) Unlike flexbus, sdram bus is not multiplexed and thus requires no additionnal component compared to "resistor only" version but keeps some of advantages of flexbus...

New trigger added: end of line. Note: this trigger is driven by Hsync FTM. It triggers at position hsync_start if Hsync polarity is positive and hsync_end if Hsync polarity is negative.

I just pushed a new set of changes. The library now provides 3 possible triggers: start of image: at X=0, Y=-1 to avoid image disturbance end of image: just after last pixel of last line start of display line: occurs when beam reaches left side of the screen. This lets a little time because...

That's also the solution I think of yesterday evening. This FTM channel cycle at the exact moment a new line start, between the last pixel of the previous line and the first pixel of the new line, roughly in the middle and unlike pixel DMA, it occurs on all lines, having pixel line or not...

I made an error, minor loop channel num linking is not in the same register as address adjustment but with major loop counter. Triggering will be a problem only if frame buffer height is greater than 511 lines with line repeat = 1 and frame buffer totally fitting in SRAM_L (or DMA forced to...

37.8MHz is the line frequency but if I trigger on end of pixel line, it is not the obtained frequency, it is 37.8Mhz * vres / vtotal ~= 36.18993Mhz because the trigger will not occur during Vsync line. An alternative whould be to trigger on Hsync FTM restart because this interrupt exists with...

I just taked a look to eDMA registers and make a first attempt (not yet pushed on github). My code should already be able to trigger DMA channel in all modelines just after the last image pixel and before the first image pixel. In this case, it occurs in fact at X=0, Y=-1, not at X=-1, Y=0 but...

I think all of this is doable using either 1 DMA channel or one for each case. At the end of each pixel DMA transfer (= 1 VGA line), it is possible to trigger another DMA channel. This is how the copy of SRAM_U line into SRAM_L buffer is done to avoid conflict with pixel DMA transfer. It is...

I think I am close to find a solution. I first tried to add various capacitors from 1-2pF to 100nF between latch VCC and GND but it changes nothing. I then add capacitor on VGA connector between GND and red/green/blue lines. Very little capacitances (1-3pF) have very little effect except grey...

If the solution solves your usb-host problem, I think I can convert your code into DMA requests. There is already one request at end of each SRAM_U line, adding one more TCD should not be a problem. I have no DMA request on FTM0 but I should be able to attach a new DMA channel to it or maybe add...

No. I was wondering if I should put one on latch power input or one on each latch outputs.

mysterious grey lines I change my image settings to produce a wonderful 15x300 picture (yes, fifteen). Flexbus runs at 1/3 of bus speed, CS signal is delayed by 3 cycles and 63 wait-state cycles are added. This lets plenty of time before and after latch trigger and the latch only triggers 16...

Unfortunately, no. Grey lines are always present, whatever the CPU does. Weird thing, the logical analyzer shows nothing on flip-flop outputs (voltage may be too low due to resistors). Even weirder, the lines are nearly non-existant on my TV :confused:. I think I will order a PCB to have clean...

Here is few news about flexbus version. Yesterday, I finally received my LVTH574DW and I solder everything this morning. Unlike my first prototype on breadboard, I have no more noise now. The image is rock solid, even when USB is connected. The awful image produced when using Serial5 (see post...

It was my fault. lowering flexbus frequency or increasing analyzer speed fixed the problem. Now, I am waiting for my latest component (8 bit positive trigger flip-flop in soic20). The previous one (16 bit in tsop 44) was too hard to wire on a breadboard, all the wires produced a lot of noises...

I think I need more holidays (or sleep, perhaps 5hr/day is not enough :eek:), yesterday was sunday and no mail is delivered on sunday. @Frank B: I have not received your parcel today but I have received my logic analyzer. I tried my analyzer on my flexbus code and I think I missed something. I...

Not yet, no mail today at all but it still can come until ~2pm.

It is not mandatory. About pin 9, I found this: Where did you pick 5V from ? Vin or VUSB ? booster from 3.3v ?

I successfully moved the sections by modifying mk66fx1m0.ld and verified using objdump but unfortunately, it changes nothing. I should receive my new logic analyzer soon. It will be able to work at 100MHz. With it, I may find what occurs. Perhaps the problem does not come from DMA at all but...

Or not :mad:, one more time...

I think I have found why usb usage is disturbing image generation. The problem is not in fact USB itself but the location of its descriptors and buffers. 2 sections are defined in usb_dev.c and usb_mem.c, .usbdescriptortable and .usbbuffers. These 2 sections are located at address 1fff0000 and...

What a nice little board :) I PM you address. Thanks.

Unfortunately, that's already what I did. The only solution I can see is fixed point arithmetic but this means uint64_t usage at least during multiplications and divisions which may be even slower. Using large precalculated arrays is not a solution because with double buffering, less than 30KB...

Yes, all of them with a bunch of sqrt, sin, cos, * and / . FPU is not bad at all but integer<=>float conversions seems to be rather slow. Performing all computations is faster than having a part of them in integer

I just committed code allowing creation of modelines with black border on top and bottom of the screen. I also add a new 240MHz demo (puls) using such a modeline. The demo is a bit slow (~ 2 fps) because it uses a lot of floating computations and I think little teensy is a bit too underpower to...

As expected, my monitor rejects both mode because they are not 60Hz. My TV also fails to recognized them and cycle between backlight on and off. Does these modes works with 60MHz F_BUS ?

I plan to add new parameters to modeline settings to create something like letterbox image. Only 2 new parameters should be required, the number of lines to display as empty lines at top and bottom of screen.

I will try them on my TV this evening because my monitor seems to reject all non-60Hz modelines. Position shifts have no formula, they are obtained through experiments. The only constraints are they must be between 0 and hsync_end. Values in the middle of the range will probably give nothing...

I though this just worked only when pin is used as input ? In any case, even is this work on output pin, you may waste some useful time. An interrupt on DMA end occurs when the last pixel of frame buffer. Your interrupt will be triggered when modeline's vsync_start is reached which in the best...

Technically, it is possible to have an interrupt when the last pixel of the frame buffer is sent by the DMA but polling a variable set by interrupt will be slower than polling DMA register directly. Yes, no problem with timing. Only Vsync is generated by DMA, Hsync remains on flextimer. The...

I also have it. This kind of problem appears when something is not drawn fast enough to be present on each frame. Here is an example. From the start of Vsync, do the following things: Clear screen draw several bars from top of screen to bottom of screen, drawing them from left to right...

Nice find, I totally missed this part of the reference manual. This morning, I tried my new flexbus hardware and I discovered several things: soldering a 74LVC1G04 (NOT gate) in SOT353-1/TSSOP5 package on a SSOP20 breakout pcb is really hard because pins (0.425mm long) are barely long enough...

I checked and it is a monitor glitch. If you draw a black or white Vline at x=228, you can see the line width (1 pixel) is bigger than the size of the dark line. The funny thing is we both have the same artifact despite use of different monitor and the artifact seems to be repeated regularly on...

FTM channels should not be affected by F_BUS change. However, the exact value and the truncated value obtained in FTM MOD computation may be too far which generate this side effect. This means I should define additional modelines taking into account F_BUS, not only F_CPU.

My video was made on my TV and I add no problem at this time. It is an old (>12yo) 42" 1080i toshiba (not even 1080p).

I just tested TX because I have nothing really connected. The code is very simple. I use add Serial5.begin(115200); in setup and Serial5.println("x");in loop. My loop is empty because the whole screen is built in setup(). I can send you the full code this evening because I don't have it at work.

I know. Serial1 and Serial 2 both have 8 bytes FIFO, all other Serial only have 1 byte fifo. This weekend, I plan to try 2 things. Using a different FTM as Hsync generator, I have seen that FTM0_CH0 uses the same pin as Serial1 RTS (or CTS, can't remember). I will also try to connect an I2C...

If you draw your bars using my uVGA functions, maybe you encountered a bug. In uVGA_gfx.cpp, you can try to disable a little optimization by commenting the line #define FAST_HLINE

I just did a little test on all Serial. When transmittiing data on Serial2 and Serial4, there is no problem, image is perfectly stable. Serial3 is not usable because its pins are used by Red signal. Serial5 produces a very disturbed image, a lot more than when using USB. The image is so bad...

Sometimes, I have a similar problem. I just force the monitor to auto-adjust and it fixes the problem. How do you force F_BUS @120MHz ? I though it should not go higher than 60Mhz

I just noticed something in what you say. Does this means you have no problem when using serial[2-5] or even serial1 as long as it is not connected using USB ?

Well, I forgot to say spheres demo runs only @240MHz. The code works in all resolutions with your change but in 703x300, it takes too much time to clear the frame buffer. When there is too many spheres (~1209 here), the beam reaches the bottom of the screen before the text is printed. Later...

The line displacements are very weird. It seems to affect more some color than other. On the following photo, blue lines seem to be more disturbed than green lines. The strangest one are the 3rd and 4th blue lines. The right side of 3rd blue line is partially moved to the right but it does not...

I think there is at least one problem coming from either noise or grounding problem. I don't think DMA slows down, I think the pixel displacements are a side effect produced by the monitor due to malformed/not sharp enough signals The problem is instable end of line like on the following photo...

I just committed a new version allowing static frame buffer usage. I tried to make it as simple as possible to use. I add various macros at the end of uVGA.h and I add an example in README.txt (2b). I could not make it in less than ... 2 lines :)

Another explanation is a shielding problem. USB signals may generate electromagnetic noise disturbing the VGA signals. How wonderful is my cable shielding :rolleyes: but I used small cat6 network cable conductors ;) 800x600@60 VGA uses ~24MHz signal. USB 2.0 seems to use 24/48Mhz signal and...

I finally took time to make a video. The video shows the hardware and all demos. I packed nearly all of them in a single program. Teensy runs @240MHz and frame buffer resolution is 703x300. The sphere demo runs separately because its resolution is 452x300 and everything is in realtime, no...