Do you have capacitors (for buffering) on your board ?
No. I was wondering if I should put one on latch power input or one on each latch outputs.
Do you have capacitors (for buffering) on your board ?
Hi qix,
I have a solution for my usb-host problem, I think.
I add two more channels to the FTM with modified timing. They have interrupts enabled and let me en/disable the usb-host thing and read gpios (gpio-access causes flicker, too (same periphal bus))
What do you think ? Does this make sense, and do you know a better way?
Edi: I greatly under-estimated the needed communication to the keyboard. Keypresses have a little lag now, but that's the maximum time to enable USB - a bit more causes flicker, again...
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 TCD to existing TCDs.
I need a bit more testing before, but I think that would be great.
I'd need
a) write to DAC every 2. rasterline on the right border
b) read all GPIO_PDIR on every rasterline, right border (Port A , B, C, D, E , 32 Bit to 32-Bit Variables)
c) disable/enable USB on every rasterline, right border (enabled completely on all lines between 593 and 51 (line not visible, black, or c64-screenborder))
Do you think this is possible ?
a) write to DAC every 2. rasterline on the right border
b) read all GPIO_PDIR on every rasterline, right border (Port A , B, C, D, E , 32 Bit to 32-Bit Variables)
c) disable/enable USB on every rasterline, right border (enabled completely on all lines between 593 and 51 (line not visible, black, or c64-screenborder))
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 a DMA event already occurs at this time and I kind of piggyback on it
Triggering channel on each line is unexpectedly harder than expected because the minor loop channel num linking and minor loop address adjustment are stored in the same register and if linking is enabled, address adjustment has less bit to store adjustment to perform. I still don't know if it will be a problem. I will try to take a look tomorrow morning at work .
I expect to push a working code by sunday noon if all goes well.
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.Wow..that's fast
I'm still working on Audio.. the line-frequency is modeline.pixel_clock / modeline.vtotal = 37878.7878 Hz (452x600x60Hz), is this correct ?
37878.7878 seems to be ok, but is faster than my current setup - don't know if the teensy is fast enough to emulate the sid and all the rest.
The half (=every 2. scanline) would be 18939 Hz ... dunno if this is OK, too Again, need to try this, first..
Can the trigger configured to be a bit earlier ? I have many black pixel on the right border,so it would not be visible.
Triggering channel on each line is unexpectedly harder than expected because the minor loop channel num linking and minor loop address adjustment are stored in the same register and if linking is enabled, address adjustment has less bit to store adjustment to perform. I still don't know if it will be a problem.
//dma.triggerAtHardwareEvent(DMAMUX_SOURCE_PDB);
dma.triggerAtHardwareEvent(DMAMUX_SOURCE_FTM0_CH7);
audioSampleFreq = ((float)modeline.pixel_clock / (float) modeline.htotal);
...
FTM0_C7SC |= FTM_CSC_DMA;
Ok..
I have audio solved - is (with default setting) FTM channel 7 as trigger correct ? It sounds ok, at least..
Code:FTM0_C7SC |= FTM_CSC_DMA;
so the remaining "TODO" is to read all GPIOs on every line
Somehow I missed this post !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 ). Each component is encoded on 2 color bits +2 intensity bits. All components shares a common "intensity". No need to modify the library to use this mode, only wiring should be adapted
View attachment 11957
Technically, each pixel can only contains 64 colors but each pixel can use a different intensity. Technically, it is 64 colors sharing intensity among 4096 possible colors.
These messages are perfectly OK and normal.
Try to connect VGA-PIN 9 to 5 Volt - Some Displays (eg my TV) seem to want this.
C:\Program Files (x86)\Arduino\libraries\uVGA-master/uVGA_valid_settings_240MHz.h:48:17: note: #pragma message: 240Mhz 703x300
#pragma message "240Mhz 703x300"
C:\Program Files (x86)\Arduino\libraries\uVGA-master\uVGA_gfx.cpp: In member function 'void uVGA::scroll(int, int, int, int, int, int, int)':
C:\Program Files (x86)\Arduino\libraries\uVGA-master\uVGA_gfx.cpp:1103:17: note: #pragma message: multiscroll not finished, where should col pixel be put if source and destination area intersect ?
#pragma message "multiscroll not finished, where should col pixel be put if source and destination area intersect ?"
Thanks for this awesome library!
I used it for an old school demo in my little YM2149 emulation project, TY2149