Title: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 24, 2013, 01:55:32 pm
Post by: matseng on July 24, 2013, 01:55:32 pm
Hi all,
As most of you know I'm doing the PAWs "Project A Week" or "PCB A Week" (I'm not really sure which it is, but I suppose they're basically the same). Most of the time I either come up with a PAW and show the finalized board and schematics, some times I directly present a finished PCB and sometimes I show parts of the entire design process here.
Most of the PAWs are rather simple but I'd like to to some more involved/advanced projects every now and then.
So I would like to propose a new series of projects - the COLDES - Collaborative Design. Where we are a few that uses our shared time and experiences to come up with a design and then as a team makes a few PCBs and writes the firmware.
I suggest that we keep the pcb files at Github and the rest of the design documents at Google Drive.
Just to get the ball rolling, and to check if there are any interest in this, I'd like to do a fairly simple project first. I came up with a idea of making a small module that can be plugged in as as replacement (or possibly in parallel) with a standard HD44780 LCD display and emulate the LCD onto a TV screen via a composite output.
I can't recall that I've seen something like this, but I haven't actively searched for it either so it might already exist a gadget that does precisely this.
I made a first block schematics of how I envision the device:
https://docs.google.com/drawings/d/10UN ... sp=sharing (https://docs.google.com/drawings/d/10UNResmISLTi_FfAYL0Fbxrz1CXVZ1Kg_ewsg0UDW1k/edit?usp=sharing)
[attachment=0]
So if anyone is interested to collaboratively work on this project (at any pace, slow or fast) please raise your hand here so we can figure out how to do this practically. There's no need to be an "expert" or anything like this, I think that most people can chip in with something, coding, doc, ideas, testing, hardware, whatever....
As most of you know I'm doing the PAWs "Project A Week" or "PCB A Week" (I'm not really sure which it is, but I suppose they're basically the same). Most of the time I either come up with a PAW and show the finalized board and schematics, some times I directly present a finished PCB and sometimes I show parts of the entire design process here.
Most of the PAWs are rather simple but I'd like to to some more involved/advanced projects every now and then.
So I would like to propose a new series of projects - the COLDES - Collaborative Design. Where we are a few that uses our shared time and experiences to come up with a design and then as a team makes a few PCBs and writes the firmware.
I suggest that we keep the pcb files at Github and the rest of the design documents at Google Drive.
Just to get the ball rolling, and to check if there are any interest in this, I'd like to do a fairly simple project first. I came up with a idea of making a small module that can be plugged in as as replacement (or possibly in parallel) with a standard HD44780 LCD display and emulate the LCD onto a TV screen via a composite output.
I can't recall that I've seen something like this, but I haven't actively searched for it either so it might already exist a gadget that does precisely this.
I made a first block schematics of how I envision the device:
https://docs.google.com/drawings/d/10UN ... sp=sharing (https://docs.google.com/drawings/d/10UNResmISLTi_FfAYL0Fbxrz1CXVZ1Kg_ewsg0UDW1k/edit?usp=sharing)
[attachment=0]
So if anyone is interested to collaboratively work on this project (at any pace, slow or fast) please raise your hand here so we can figure out how to do this practically. There's no need to be an "expert" or anything like this, I think that most people can chip in with something, coding, doc, ideas, testing, hardware, whatever....
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: dolabra on July 24, 2013, 02:03:49 pm
Post by: dolabra on July 24, 2013, 02:03:49 pm
I love this idea, both the colaborative design and the tv out concept. I'm in, but might be in the slow pace category.
My first comment: is the latch necessary? Can't the pic buffer the data?
Things that come to mind that we need:
1. character set
2. NTSC and PAL timing code
3. specs for the LCD controller interface.
Design question
1. what should the LCD connector look like --- SIP or DIP?
2. USB -- do we want to make this a TV backpack sort of thing also?
3.serial input/output?
My first comment: is the latch necessary? Can't the pic buffer the data?
Things that come to mind that we need:
1. character set
2. NTSC and PAL timing code
3. specs for the LCD controller interface.
Design question
1. what should the LCD connector look like --- SIP or DIP?
2. USB -- do we want to make this a TV backpack sort of thing also?
3.serial input/output?
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 24, 2013, 09:03:04 pm
Post by: Bertho on July 24, 2013, 09:03:04 pm
I think it is a very good idea to do collaborative design. There are some real challenges as to what type of design software is used. For example, I do not have or want eagle and use free tools for almost everything (pickit2 is half an exception). There will also be some logistics and maybe financials to tackle when dealing with physical goods.
The project look like a very intriguing one indeed. I've not seen it before and like the concept. Maybe it should support CGA/VGA output for use on (old) monitors. You can make composite from there quite easily.
Have you tried to do video out on a PIC before? It seems to me at the edge of stable timing when I think back at my own projects (even with 8:1 pixel clock reduction using serial).
A 20xN display will need 119 pixels (5 for the letter, one for spacing 20*6-1; make it an even 120). At full width, which is 52us line-time (effective visible part in PAL, 64us total), that is ~288461Hz byte-clock (~2307692Hz pixel clock or baudrate @ 8bit). You probably want some more edge left and right, making it a 326923Hz byte-clock (2615384Hz pixel clock). You need to double the numbers @ 40xN display emulation. Those numbers are very high for a PIC (~55..48 instructions @Fosc/4 = 16MHz). Probably doable, but quite a challenge.
The project look like a very intriguing one indeed. I've not seen it before and like the concept. Maybe it should support CGA/VGA output for use on (old) monitors. You can make composite from there quite easily.
Have you tried to do video out on a PIC before? It seems to me at the edge of stable timing when I think back at my own projects (even with 8:1 pixel clock reduction using serial).
A 20xN display will need 119 pixels (5 for the letter, one for spacing 20*6-1; make it an even 120). At full width, which is 52us line-time (effective visible part in PAL, 64us total), that is ~288461Hz byte-clock (~2307692Hz pixel clock or baudrate @ 8bit). You probably want some more edge left and right, making it a 326923Hz byte-clock (2615384Hz pixel clock). You need to double the numbers @ 40xN display emulation. Those numbers are very high for a PIC (~55..48 instructions @Fosc/4 = 16MHz). Probably doable, but quite a challenge.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 24, 2013, 11:51:05 pm
Post by: Bertho on July 24, 2013, 11:51:05 pm
After thinking a bit more about the problem, I must conclude that a pic18f is a poor choice.
After looking a bit through the options, I suggest to use an ARM core with a proper DMA channel on SPI ports. I'm eyeing LPC1759 (or 1758) initially, but that may be reduced to smaller one later if it can be done. Or another vendor if that is more appropriate.
I suggest to use an 74LVC821A as input buffer (10 bit D-FF) which is 5V tolerant. There also needs to be some output buffer for read actions... TBD ;-) All interesting logic is 3.3V nowadays and I see no reason not to go 3.3V internally.
The trick I propose is to set up the SSP0 channel in 16-bit SPI mode (back-to-back) and continuously sending data on it via DMA transfers to have the pixel data at exactly the correct rate (at 180x128 or 360x256 pixels PAL and 160x120 or 320x240 NTSC). The sync-signals can be generated on DMA interrupts (giving ~50..150ns jitter) or could be generated in parallel with SSP1 channel running in sync with SSP0. Find the correct crystal to get the timing exactly right and all display work is done in the background.
A really big advantage with this method is that the frame interlacing and accompanying serrated pulses on the sync-line are much more easy to generate with exact timing. Video sync signals are a bitch.
Another advantage is that you can do much more than just HD44780 emulation and you can make it a completely independent display slave. At low resolution it is possible to aggregate 3 or 4 bits at the pixel-stream to generate colors too.
(Oh man, what a funny design!)
After looking a bit through the options, I suggest to use an ARM core with a proper DMA channel on SPI ports. I'm eyeing LPC1759 (or 1758) initially, but that may be reduced to smaller one later if it can be done. Or another vendor if that is more appropriate.
I suggest to use an 74LVC821A as input buffer (10 bit D-FF) which is 5V tolerant. There also needs to be some output buffer for read actions... TBD ;-) All interesting logic is 3.3V nowadays and I see no reason not to go 3.3V internally.
The trick I propose is to set up the SSP0 channel in 16-bit SPI mode (back-to-back) and continuously sending data on it via DMA transfers to have the pixel data at exactly the correct rate (at 180x128 or 360x256 pixels PAL and 160x120 or 320x240 NTSC). The sync-signals can be generated on DMA interrupts (giving ~50..150ns jitter) or could be generated in parallel with SSP1 channel running in sync with SSP0. Find the correct crystal to get the timing exactly right and all display work is done in the background.
A really big advantage with this method is that the frame interlacing and accompanying serrated pulses on the sync-line are much more easy to generate with exact timing. Video sync signals are a bitch.
Another advantage is that you can do much more than just HD44780 emulation and you can make it a completely independent display slave. At low resolution it is possible to aggregate 3 or 4 bits at the pixel-stream to generate colors too.
(Oh man, what a funny design!)
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 06:21:35 am
Post by: matseng on July 25, 2013, 06:21:35 am
[quote author="dolabra"]My first comment: is the latch necessary? Can't the pic buffer the data?[/quote]
It sure can, but not fast enough. Looking at the datasheets it is specified that from the active edge of the E signal the unit controlling the LCD only need to keep the data on D0-D7 stable for like 10nS or so. So the pic is not guaranteed to be able to read the data before it might have changed again.
That's why we need a real latch that will latch the data at "hardware level".
I had hoped that the Atmel XMega series would have some "capture data at ports by external trigger", but the only capture it can do is to capture the current count of the internal timers.
[quote author="dolabra"]Things that come to mind that we need:
1. character set
2. NTSC and PAL timing code
3. specs for the LCD controller interface.
[/quote]
Character set - yes. With support for the 8 user definable characters as well, so at least parts of it needs to be in ram.
Agree, both standards should be supported. And as Bertho mentions in a later post also VGA would be nice.
There's plenty of HD44780 datasheets out there, and also the rather compatible KS0666 (or whatever its name is), so that should not be an issue.
We need to start collecting document and put them up on the Drive (if that is what we're going to use for documents).
[quote author="dolabra"]Design question
1. what should the LCD connector look like --- SIP or DIP?
2. USB -- do we want to make this a TV backpack sort of thing also?
3.serial input/output?[/quote]
I'd like to support both the regular SIP as well as the DIP that is used for the small 2x8 line displays. Since they are electrically identical they can just be put in paralell.
USB.... Hmm. I vote against it. It will require a lot more firmware, have timing issues that will/might affect the video generation timing and it's a bit of "feature creep" (meaning adding stuff that is not really core). Doing a USB video board as a separate project when this is done sounds like a cool idea though.
Serial... A bit of feature creep here as well. The EUSART might already be used for shifting out the data to the video as well, so unless we have a software serial port (or a second hardware port) it will be hard from a timing perspective. But it would be cool to have a build in VT100/VT220 emulator in it. So the device will send all LCD updates to a terminal emulator as well.
And that might be a much simpler project. We don't need the video generation then. And that will remove almost all timing issues.
Now I'm not sure that outputting it to a TV/Monitor is the best. Maybe it's more practical to get it on a terminal emulator on your computer instead. But still... Having it blown up large on a TV is much more impressive and cool.
It sure can, but not fast enough. Looking at the datasheets it is specified that from the active edge of the E signal the unit controlling the LCD only need to keep the data on D0-D7 stable for like 10nS or so. So the pic is not guaranteed to be able to read the data before it might have changed again.
That's why we need a real latch that will latch the data at "hardware level".
I had hoped that the Atmel XMega series would have some "capture data at ports by external trigger", but the only capture it can do is to capture the current count of the internal timers.
[quote author="dolabra"]Things that come to mind that we need:
1. character set
2. NTSC and PAL timing code
3. specs for the LCD controller interface.
[/quote]
Character set - yes. With support for the 8 user definable characters as well, so at least parts of it needs to be in ram.
Agree, both standards should be supported. And as Bertho mentions in a later post also VGA would be nice.
There's plenty of HD44780 datasheets out there, and also the rather compatible KS0666 (or whatever its name is), so that should not be an issue.
We need to start collecting document and put them up on the Drive (if that is what we're going to use for documents).
[quote author="dolabra"]Design question
1. what should the LCD connector look like --- SIP or DIP?
2. USB -- do we want to make this a TV backpack sort of thing also?
3.serial input/output?[/quote]
I'd like to support both the regular SIP as well as the DIP that is used for the small 2x8 line displays. Since they are electrically identical they can just be put in paralell.
USB.... Hmm. I vote against it. It will require a lot more firmware, have timing issues that will/might affect the video generation timing and it's a bit of "feature creep" (meaning adding stuff that is not really core). Doing a USB video board as a separate project when this is done sounds like a cool idea though.
Serial... A bit of feature creep here as well. The EUSART might already be used for shifting out the data to the video as well, so unless we have a software serial port (or a second hardware port) it will be hard from a timing perspective. But it would be cool to have a build in VT100/VT220 emulator in it. So the device will send all LCD updates to a terminal emulator as well.
And that might be a much simpler project. We don't need the video generation then. And that will remove almost all timing issues.
Now I'm not sure that outputting it to a TV/Monitor is the best. Maybe it's more practical to get it on a terminal emulator on your computer instead. But still... Having it blown up large on a TV is much more impressive and cool.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: dolabra on July 25, 2013, 06:30:42 am
Post by: dolabra on July 25, 2013, 06:30:42 am
mats, what is your vison of how this thing would be used? what would be driving it?
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 06:50:18 am
Post by: matseng on July 25, 2013, 06:50:18 am
[quote author="Bertho"]I think it is a very good idea to do collaborative design. There are some real challenges as to what type of design software is used. For example, I do not have or want eagle and use free tools for almost everything (pickit2 is half an exception). There will also be some logistics and maybe financials to tackle when dealing with physical goods.[/quote]
Ok, maybe we should try one of the online pcb design tools? A real project to see if they are usable or not.
http://www.pcbweb.com/ (http://www.pcbweb.com/) for instance...
[quote author="Bertho"]The project look like a very intriguing one indeed. I've not seen it before and like the concept. [/quote]
That's good. We're breaking new ground here :)
[quote author="Bertho"]Maybe it should support CGA/VGA output for use on (old) monitors. You can make composite from there quite easily.[/quote]
Yes, why not. I've seen homebrew designs supporting both vga and composite. And this will make it more flexible by just adjusting the video timings - something we still need to do anyways to support both pal and ntsc.
[quote author="Bertho"]Have you tried to do video out on a PIC before? It seems to me at the edge of stable timing when I think back at my own projects (even with 8:1 pixel clock reduction using serial).
A 20xN display will need 119 pixels (5 for the letter, one for spacing 20*6-1; make it an even 120). At full width, which is 52us line-time (effective visible part in PAL, 64us total), that is ~288461Hz byte-clock (~2307692Hz pixel clock or baudrate @ 8bit). You probably want some more edge left and right, making it a 326923Hz byte-clock (2615384Hz pixel clock). You need to double the numbers @ 40xN display emulation. Those numbers are very high for a PIC (~55..48 instructions @Fosc/4 = 16MHz). Probably doable, but quite a challenge.[/quote]
Yes, the low end 20MHz PICs are so much more crappy compared to AVRs running at 20MHz. But with the more modern 64/80 MHz PLL devices it will be so much easier.
I've never done it on a PIC I've just played around with the https://code.google.com/p/arduino-tvout/ (https://code.google.com/p/arduino-tvout/) library that generates up to 160 hor pixels on a lowly mega328.
I've of course made my own video hardware a looong time ago. Both with the early 80'es era CTR controllers like 6545, and with a cpu and discrete logic modelled after the classic "Cheap Video Cookbook" by Don Lancaster.
Ok, maybe we should try one of the online pcb design tools? A real project to see if they are usable or not.
http://www.pcbweb.com/ (http://www.pcbweb.com/) for instance...
[quote author="Bertho"]The project look like a very intriguing one indeed. I've not seen it before and like the concept. [/quote]
That's good. We're breaking new ground here :)
[quote author="Bertho"]Maybe it should support CGA/VGA output for use on (old) monitors. You can make composite from there quite easily.[/quote]
Yes, why not. I've seen homebrew designs supporting both vga and composite. And this will make it more flexible by just adjusting the video timings - something we still need to do anyways to support both pal and ntsc.
[quote author="Bertho"]Have you tried to do video out on a PIC before? It seems to me at the edge of stable timing when I think back at my own projects (even with 8:1 pixel clock reduction using serial).
A 20xN display will need 119 pixels (5 for the letter, one for spacing 20*6-1; make it an even 120). At full width, which is 52us line-time (effective visible part in PAL, 64us total), that is ~288461Hz byte-clock (~2307692Hz pixel clock or baudrate @ 8bit). You probably want some more edge left and right, making it a 326923Hz byte-clock (2615384Hz pixel clock). You need to double the numbers @ 40xN display emulation. Those numbers are very high for a PIC (~55..48 instructions @Fosc/4 = 16MHz). Probably doable, but quite a challenge.[/quote]
Yes, the low end 20MHz PICs are so much more crappy compared to AVRs running at 20MHz. But with the more modern 64/80 MHz PLL devices it will be so much easier.
I've never done it on a PIC I've just played around with the https://code.google.com/p/arduino-tvout/ (https://code.google.com/p/arduino-tvout/) library that generates up to 160 hor pixels on a lowly mega328.
I've of course made my own video hardware a looong time ago. Both with the early 80'es era CTR controllers like 6545, and with a cpu and discrete logic modelled after the classic "Cheap Video Cookbook" by Don Lancaster.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 07:01:24 am
Post by: matseng on July 25, 2013, 07:01:24 am
[quote author="dolabra"]mats, what is your vison of how this thing would be used? what would be driving it?[/quote]
Well, *that* is a good question....
The inspiration for the project came from a question that I got a while back if it was possible to display the image on the LCD display on a credit card payment terminal and display that on a tv or beamer for training purposes. I then said "no, just point a video camera to it and connect to the tv to blow it up."
So I'm not sure of whenever I'd use this device that only does character displays. It might be a step towards a more advanced product - a proof-of-concept so to speak. And a design challenge. And a reasonably advanced test for the Collaborative Design idea.
But probably there are others that actually would have use for it.
My idea is that this unit should not make any assumptions at all on how the LCD is being used by the device. It should be able to just sit there and passively listen to the conversation and do its thing. Or if the LCD is disconnected and this unit should be able to not only listen but also handle read requests from the device (if used). Most devices just drive the LCD with delay-timing instead of polling for when the next instruction can be sent.
Well, *that* is a good question....
The inspiration for the project came from a question that I got a while back if it was possible to display the image on the LCD display on a credit card payment terminal and display that on a tv or beamer for training purposes. I then said "no, just point a video camera to it and connect to the tv to blow it up."
So I'm not sure of whenever I'd use this device that only does character displays. It might be a step towards a more advanced product - a proof-of-concept so to speak. And a design challenge. And a reasonably advanced test for the Collaborative Design idea.
But probably there are others that actually would have use for it.
My idea is that this unit should not make any assumptions at all on how the LCD is being used by the device. It should be able to just sit there and passively listen to the conversation and do its thing. Or if the LCD is disconnected and this unit should be able to not only listen but also handle read requests from the device (if used). Most devices just drive the LCD with delay-timing instead of polling for when the next instruction can be sent.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: jaromir on July 25, 2013, 07:35:09 am
Post by: jaromir on July 25, 2013, 07:35:09 am
Regarding the latch - some PIC18F, like PIC18F4620 do have PSP - paralell slave port, which seems to be suited for this task. MCUs like 18F46J11 do have paralell master port (PMP), which can be configured to PSP-like fashion.
But after all, I would use some 16-bit PIC (PIC24 or even dsPIC33). Those are really simple to program in assembly language (very nice instruction set, IMHO better than 8-bitters I worked with), quite powerful, but yet easy to calculate timing (no prefetch cache and stuff to make it complicated). And there is paralell master/slave port too.
Just for inspiration http://benryves.com/journal/3672273 (http://benryves.com/journal/3672273)
But after all, I would use some 16-bit PIC (PIC24 or even dsPIC33). Those are really simple to program in assembly language (very nice instruction set, IMHO better than 8-bitters I worked with), quite powerful, but yet easy to calculate timing (no prefetch cache and stuff to make it complicated). And there is paralell master/slave port too.
Just for inspiration http://benryves.com/journal/3672273 (http://benryves.com/journal/3672273)
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 09:55:32 am
Post by: Bertho on July 25, 2013, 09:55:32 am
[quote author="matseng"][quote author="Bertho"]I think it is a very good idea to do collaborative design. There are some real challenges as to what type of design software is used. For example, I do not have or want eagle and use free tools for almost everything (pickit2 is half an exception). There will also be some logistics and maybe financials to tackle when dealing with physical goods.[/quote]
Ok, maybe we should try one of the online pcb design tools? A real project to see if they are usable or not.
http://www.pcbweb.com/ (http://www.pcbweb.com/) for instance...[/quote]
Hm, that might be a possibility, but I guess that "real" design requires a bit more advanced tools.
Designing a PCB and creating diagrams is normally a one-man job, so I do not think that there would be a problem if you, I, or anyone else would take the front for that part and then use the tools preferred. Just make sure that a "readable format" (i.e. pdf) version is available for others to check. For both schematics and PCB, well, if you cannot write down your changes/suggestions/concerns in text, then this would be a good opportunity to learn ;-)
We already see several different tools being used on the net for open designs, so I guess that it is not worth to start a flamewar on this issue.
Ok, maybe we should try one of the online pcb design tools? A real project to see if they are usable or not.
http://www.pcbweb.com/ (http://www.pcbweb.com/) for instance...[/quote]
Hm, that might be a possibility, but I guess that "real" design requires a bit more advanced tools.
Designing a PCB and creating diagrams is normally a one-man job, so I do not think that there would be a problem if you, I, or anyone else would take the front for that part and then use the tools preferred. Just make sure that a "readable format" (i.e. pdf) version is available for others to check. For both schematics and PCB, well, if you cannot write down your changes/suggestions/concerns in text, then this would be a good opportunity to learn ;-)
We already see several different tools being used on the net for open designs, so I guess that it is not worth to start a flamewar on this issue.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 10:05:13 am
Post by: Bertho on July 25, 2013, 10:05:13 am
[quote author="matseng"]Yes, the low end 20MHz PICs are so much more crappy compared to AVRs running at 20MHz. But with the more modern 64/80 MHz PLL devices it will be so much easier.
I've never done it on a PIC I've just played around with the https://code.google.com/p/arduino-tvout/ (https://code.google.com/p/arduino-tvout/) library that generates up to 160 hor pixels on a lowly mega328.[/quote]
But PIC18F goes to max. Fosc/4 = 16MHz (16MIPS). That is with a x4 PLL enabled on a 16MHz oscillator (either internal or external). Those that can support faster crystal oscillators cannot enable the PLL at that speed.
You would be able to get a video signal going on PIC18, but you will have almost no time left to run other code.
[quote author="matseng"]I've of course made my own video hardware a looong time ago. Both white the early 80'es era CTR controllers like 6545 and with cpu and discrete logic modelled after the classic "Cheap Video Cookbook" by Don Lancaster.[/quote]
/me too :-)
I've never done it on a PIC I've just played around with the https://code.google.com/p/arduino-tvout/ (https://code.google.com/p/arduino-tvout/) library that generates up to 160 hor pixels on a lowly mega328.[/quote]
But PIC18F goes to max. Fosc/4 = 16MHz (16MIPS). That is with a x4 PLL enabled on a 16MHz oscillator (either internal or external). Those that can support faster crystal oscillators cannot enable the PLL at that speed.
You would be able to get a video signal going on PIC18, but you will have almost no time left to run other code.
[quote author="matseng"]I've of course made my own video hardware a looong time ago. Both white the early 80'es era CTR controllers like 6545 and with cpu and discrete logic modelled after the classic "Cheap Video Cookbook" by Don Lancaster.[/quote]
/me too :-)
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 10:09:15 am
Post by: Bertho on July 25, 2013, 10:09:15 am
[quote author="matseng"]We need to start collecting document and put them up on the Drive (if that is what we're going to use for documents).[/quote]
May I suggest to put everything in one git-repo per project? That is easier to handle and you have everything together in one spot.
I use this for all my own projects with both HS and SW, including datasheets, cost calculations, etc...
May I suggest to put everything in one git-repo per project? That is easier to handle and you have everything together in one spot.
I use this for all my own projects with both HS and SW, including datasheets, cost calculations, etc...
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 10:13:46 am
Post by: Bertho on July 25, 2013, 10:13:46 am
[quote author="jaromir"]Regarding the latch - some PIC18F, like PIC18F4620 do have PSP - paralell slave port, which seems to be suited for this task. MCUs like 18F46J11 do have paralell master port (PMP), which can be configured to PSP-like fashion.[/quote]
But the PSP/PMP is only 8-bit and at least 9 bits need to be latched (D0-D7, RS), 10 bits with R/W, but that is debatable. So you would still need some extra hardware there.
But the PSP/PMP is only 8-bit and at least 9 bits need to be latched (D0-D7, RS), 10 bits with R/W, but that is debatable. So you would still need some extra hardware there.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 10:25:05 am
Post by: Bertho on July 25, 2013, 10:25:05 am
[quote author="matseng"][quote author="dolabra"]mats, what is your vison of how this thing would be used? what would be driving it?[/quote]
So I'm not sure of whenever I'd use this device that only does character displays. It might be a step towards a more advanced product - a proof-of-concept so to speak. And a design challenge. And a reasonably advanced test for the Collaborative Design idea.[/quote]
Doing more than simple LCD emulation is possible if the design is sound. There are "user-defined" characters in the LCD, and this could be extended to full graphics display. Once you have a proof-of-concept, the sky is the limit.
[quote author="matseng"]My idea is that this unit should not make any assumptions at all on how the LCD is being used by the device. It should be able to just sit there and passively listen to the conversation and do its thing. Or if the LCD is disconnected and this unit should be able to not only listen but also handle read requests from the device (if used).[/quote]
An "LCD-extender" is a perfect example. The point, and I agree fully with you, is that people find uses for all kinds of things which were not originally designed for it. That makes it so much fun.
[quote author="matseng"]Most devices just drive the LCD with delay-timing instead of polling for when the next instruction can be sent.[/quote]
That is the real challenge. One of the reasons why I think neither PIC18 or AVR8 are up to the task.
So I'm not sure of whenever I'd use this device that only does character displays. It might be a step towards a more advanced product - a proof-of-concept so to speak. And a design challenge. And a reasonably advanced test for the Collaborative Design idea.[/quote]
Doing more than simple LCD emulation is possible if the design is sound. There are "user-defined" characters in the LCD, and this could be extended to full graphics display. Once you have a proof-of-concept, the sky is the limit.
[quote author="matseng"]My idea is that this unit should not make any assumptions at all on how the LCD is being used by the device. It should be able to just sit there and passively listen to the conversation and do its thing. Or if the LCD is disconnected and this unit should be able to not only listen but also handle read requests from the device (if used).[/quote]
An "LCD-extender" is a perfect example. The point, and I agree fully with you, is that people find uses for all kinds of things which were not originally designed for it. That makes it so much fun.
[quote author="matseng"]Most devices just drive the LCD with delay-timing instead of polling for when the next instruction can be sent.[/quote]
That is the real challenge. One of the reasons why I think neither PIC18 or AVR8 are up to the task.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: jaromir on July 25, 2013, 10:29:36 am
Post by: jaromir on July 25, 2013, 10:29:36 am
Bertho - you are right about tme PSP in those small PIC devices. I forgot about RS and RW. Those in bigger packages do have 16-bit PMP, but this is probably out of question for now.
So, extra latch will be needed, probably.
So, extra latch will be needed, probably.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 10:42:28 am
Post by: matseng on July 25, 2013, 10:42:28 am
Git merges of source code works just fine, but having a a design document or spreadsheet being edited at multiple locations will be a nightmare during push/merge operations.
Being able to open a document, spreadsheet or even a drawing and work on it simultaneously from multiple locations (and see the changes made by the others in realtime) is totally excellent whenever more than one might be updating the documents. I've started to use this where I work and it makes life so much easier, no more mailing of files with unknown revision numbers and all the headaches involved. Test of a fully open document https://docs.google.com/document/d/1Pr3 ... OpyZk/edit (https://docs.google.com/document/d/1Pr3wAfqcrt4XQGzAoCIo4aai_-iBiegQrTlRNqOpyZk/edit)
Keeping a list of URL's for the working documents in git is cool though. And also keep datasheets in git of course.... And pdf snapshots of the documents...
Being able to open a document, spreadsheet or even a drawing and work on it simultaneously from multiple locations (and see the changes made by the others in realtime) is totally excellent whenever more than one might be updating the documents. I've started to use this where I work and it makes life so much easier, no more mailing of files with unknown revision numbers and all the headaches involved. Test of a fully open document https://docs.google.com/document/d/1Pr3 ... OpyZk/edit (https://docs.google.com/document/d/1Pr3wAfqcrt4XQGzAoCIo4aai_-iBiegQrTlRNqOpyZk/edit)
Keeping a list of URL's for the working documents in git is cool though. And also keep datasheets in git of course.... And pdf snapshots of the documents...
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 11:02:53 am
Post by: matseng on July 25, 2013, 11:02:53 am
[quote author="Bertho"][quote author="matseng"]Most devices just drive the LCD with delay-timing instead of polling for when the next instruction can be sent.[/quote]That is the real challenge. One of the reasons why I think neither PIC18 or AVR8 are up to the task.[/quote]
Isn't the timing rather slow even for simple command like write a character. Like 40-50 uS or so. But if that can't be handled maybe we can just put the command on a queue and process them as fast as we can, but signal the busyflag with a better timing.
I'd like to avoid, if possible, using any "exotics" when it comes to the mcu. But as long as the hardware is reasonably cheap and the compiler and development environment is free and decent I'm open for anything. It might be fun to leave the avr8/pic16[18] world and move on to something better.
The Cortex M0 is certainly cheap. Is a 48MHz M0 doing 48mips?
Isn't the timing rather slow even for simple command like write a character. Like 40-50 uS or so. But if that can't be handled maybe we can just put the command on a queue and process them as fast as we can, but signal the busyflag with a better timing.
I'd like to avoid, if possible, using any "exotics" when it comes to the mcu. But as long as the hardware is reasonably cheap and the compiler and development environment is free and decent I'm open for anything. It might be fun to leave the avr8/pic16[18] world and move on to something better.
The Cortex M0 is certainly cheap. Is a 48MHz M0 doing 48mips?
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 11:37:04 am
Post by: Bertho on July 25, 2013, 11:37:04 am
[quote author="matseng"]Isn't the timing rather slow even for simple command like write a character. Like 40-50 uS or so. But if that can't be handled maybe we can just put the command on a queue and process them as fast as we can, but signal the busyflag with a better timing.[/quote]
Standard timing for most commands is 37us. That may seem like a long time, but problem I see is that the cpu is already heavily loaded with handling the video. It might be doable, but it will certainly be on the edge. If you need to start doing internal queuing, then it becomes even more difficult; especially with the limited register set of a PIC.
[quote author="matseng"]I'd like to avoid, if possible, using any "exotics" when it comes to the mcu. But as long as the hardware is reasonably cheap and the compiler and development environment is free and decent I'm open for anything. It might be fun to leave the avr8/pic16[18] world and move on to something better.[/quote]
Well, ARM is no exotic architecture and we could actually make a proof-of-concept on a simple (cheap) dev-board, which are available in multitude for a lot of them. ARM is price-wise actually a lot better for the performance you get. I prefer to use ARM and not PIC24/32 or AVR32. The toolchain for ARM is a lot easier cross-platform than PIC/AVR (multiple vendors vs. single vendor).
[quote author="matseng"]The Cortex M0 is certainly cheap. Is a 48MHz M0 doing 48mips?[/quote]
48MHz doing anything from 24..96MIPS, depending instruction scheduling. The cpu core may actually decide to delete instructions from the queue if they are determined superfluous. Also, (physical) memory transactions are queued and handled in a way that the CPU may perform best (there are memory "ordering" regions with different rules). It is a true 32bit CPU with all running as much async as possible to optimize for performance.
I'd suggest M3 to start with. Most M0 series do have DMA, but that is a lot more difficult to get right (much more bandwidth constrained). Most M3s have a real general purpose DMA which is much easier to handle and the bandwidth constraints are not so severe.
I think that the priority should be to make a (cut-down) proof-of-concept on a breadboard to find out the required bandwidth and timing. Maybe some experiments with different cores and then see what would fit best.
Standard timing for most commands is 37us. That may seem like a long time, but problem I see is that the cpu is already heavily loaded with handling the video. It might be doable, but it will certainly be on the edge. If you need to start doing internal queuing, then it becomes even more difficult; especially with the limited register set of a PIC.
[quote author="matseng"]I'd like to avoid, if possible, using any "exotics" when it comes to the mcu. But as long as the hardware is reasonably cheap and the compiler and development environment is free and decent I'm open for anything. It might be fun to leave the avr8/pic16[18] world and move on to something better.[/quote]
Well, ARM is no exotic architecture and we could actually make a proof-of-concept on a simple (cheap) dev-board, which are available in multitude for a lot of them. ARM is price-wise actually a lot better for the performance you get. I prefer to use ARM and not PIC24/32 or AVR32. The toolchain for ARM is a lot easier cross-platform than PIC/AVR (multiple vendors vs. single vendor).
[quote author="matseng"]The Cortex M0 is certainly cheap. Is a 48MHz M0 doing 48mips?[/quote]
48MHz doing anything from 24..96MIPS, depending instruction scheduling. The cpu core may actually decide to delete instructions from the queue if they are determined superfluous. Also, (physical) memory transactions are queued and handled in a way that the CPU may perform best (there are memory "ordering" regions with different rules). It is a true 32bit CPU with all running as much async as possible to optimize for performance.
I'd suggest M3 to start with. Most M0 series do have DMA, but that is a lot more difficult to get right (much more bandwidth constrained). Most M3s have a real general purpose DMA which is much easier to handle and the bandwidth constraints are not so severe.
I think that the priority should be to make a (cut-down) proof-of-concept on a breadboard to find out the required bandwidth and timing. Maybe some experiments with different cores and then see what would fit best.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 12:00:42 pm
Post by: Bertho on July 25, 2013, 12:00:42 pm
[quote author="Bertho"]I think that the priority should be to make a (cut-down) proof-of-concept on a breadboard to find out the required bandwidth and timing. Maybe some experiments with different cores and then see what would fit best.[/quote]
Cheap board: http://http://www.nxp.com/demoboard/OM13000.html
M3 core dev-board for $27. The NXP debug interface can be severed and normal JTAG can be used (that is what I usually do)
(Mouser: http://http://dk.mouser.com/ProductDetail/NXP-Semiconductors/OM13000598/?NXP-Semiconductors/OM13000598/&NXP-Semiconductors/OM13000598/&qs=sGAEpiMZZMsf26MmFqIJrOnYBXMlAWgjgeD0VGDe9gI=)
You can also have a look at ST, TI or EM cores, but they tend to be slightly more expensive than NXP.
Cheap board: http://http://www.nxp.com/demoboard/OM13000.html
M3 core dev-board for $27. The NXP debug interface can be severed and normal JTAG can be used (that is what I usually do)
(Mouser: http://http://dk.mouser.com/ProductDetail/NXP-Semiconductors/OM13000598/?NXP-Semiconductors/OM13000598/&NXP-Semiconductors/OM13000598/&qs=sGAEpiMZZMsf26MmFqIJrOnYBXMlAWgjgeD0VGDe9gI=)
You can also have a look at ST, TI or EM cores, but they tend to be slightly more expensive than NXP.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 12:03:55 pm
Post by: matseng on July 25, 2013, 12:03:55 pm
EDIT: I see you already answered my questions :)
Sounds reasonable.
LQFP48 is easier to solder than a QFN version. So what about a STM32F103C6T6 to do some initial testing; $3 , 32K flash, 10k ram, ADC, DMA, PWM, Timer, CAN, I2C, SPI, UART, USB? And it's available locally for me. :-)
I'm open for suggestions...
What's needed to upload firmware and debug them?
Sounds reasonable.
LQFP48 is easier to solder than a QFN version. So what about a STM32F103C6T6 to do some initial testing; $3 , 32K flash, 10k ram, ADC, DMA, PWM, Timer, CAN, I2C, SPI, UART, USB? And it's available locally for me. :-)
I'm open for suggestions...
What's needed to upload firmware and debug them?
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 12:06:58 pm
Post by: matseng on July 25, 2013, 12:06:58 pm
I can get the OM13000 locally for $40 at Element14/Singapore, no too bad.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 12:10:17 pm
Post by: matseng on July 25, 2013, 12:10:17 pm
There's two versions. The Eval- and and the Dev-board.
http://my.element14.com/jsp/search/brow ... obalsearch (http://my.element14.com/jsp/search/browse.jsp?N=541&Ntk=gensearch_001&Ntt=OM13000&Ntx=mode+matchallpartial&suggestions=false&ref=globalsearch)
I should get the slightly more expensive Dev board. Right? (The Dev board is not in stock here anyways :)
http://my.element14.com/jsp/search/brow ... obalsearch (http://my.element14.com/jsp/search/browse.jsp?N=541&Ntk=gensearch_001&Ntt=OM13000&Ntx=mode+matchallpartial&suggestions=false&ref=globalsearch)
I should get the slightly more expensive Dev board. Right? (The Dev board is not in stock here anyways :)
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 12:40:28 pm
Post by: Bertho on July 25, 2013, 12:40:28 pm
[quote author="matseng"]LQFP48 is easier to solder than a QFN version. So what about a STM32F103C6T6 to do some initial testing; $3 , 32K flash, 10k ram, ADC, DMA, PWM, Timer, CAN, I2C, SPI, UART, USB? And it's available locally for me. :-)[/quote]
That is possible, but probably too small to start with. It has only one SPI channel and that will make it more of a challenge ;-) The memory limit may also be sligtly problematic.
[quote author="matseng"]I'm open for suggestions...[/quote]
The reason for me to suggest the larger NXP version is because it has local AHB memory on both peripheral legs, which can be accessed without compromising CPU performance. ST also has them, but there you also need to go into the slightly larger versions.
[quote author="matseng"]What's needed to upload firmware and debug them?[/quote]
The easiest way is to use a chip with full JTAG interface. Then you can use openocd, program the flash and use gdb.
The second method is using the ISP, in which you can invoke the internal bootloader to accept serial data to program the flash. I use this method on chips lacking JTAG and instead have SWD (openocd has no SWD support yet). And then I have "printf" debugging ;-)
Anyhow, you may want to look around a bit and see what you have of tools at home. Setting up an dev-environment for the first time is a steep learning curve. (you may want to go for coocox for a QaD headstart http://http://www.coocox.com/index.html)
For the Xpresso you may try mbed (http://https://mbed.org/). It is said to be very easy, but is not my favorite as I like to have control.
That is possible, but probably too small to start with. It has only one SPI channel and that will make it more of a challenge ;-) The memory limit may also be sligtly problematic.
[quote author="matseng"]I'm open for suggestions...[/quote]
The reason for me to suggest the larger NXP version is because it has local AHB memory on both peripheral legs, which can be accessed without compromising CPU performance. ST also has them, but there you also need to go into the slightly larger versions.
[quote author="matseng"]What's needed to upload firmware and debug them?[/quote]
The easiest way is to use a chip with full JTAG interface. Then you can use openocd, program the flash and use gdb.
The second method is using the ISP, in which you can invoke the internal bootloader to accept serial data to program the flash. I use this method on chips lacking JTAG and instead have SWD (openocd has no SWD support yet). And then I have "printf" debugging ;-)
Anyhow, you may want to look around a bit and see what you have of tools at home. Setting up an dev-environment for the first time is a steep learning curve. (you may want to go for coocox for a QaD headstart http://http://www.coocox.com/index.html)
For the Xpresso you may try mbed (http://https://mbed.org/). It is said to be very easy, but is not my favorite as I like to have control.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 12:41:42 pm
Post by: Bertho on July 25, 2013, 12:41:42 pm
[quote author="matseng"]There's two versions. The Eval- and and the Dev-board.
http://my.element14.com/jsp/search/brow ... obalsearch (http://my.element14.com/jsp/search/browse.jsp?N=541&Ntk=gensearch_001&Ntt=OM13000&Ntx=mode+matchallpartial&suggestions=false&ref=globalsearch)
I should get the slightly more expensive Dev board. Right? (The Dev board is not in stock here anyways :)[/quote]
I actually do not know what the difference is... The dev-board looks to be the one you want, yes.
Edit: check http://http://www.nxp.com/demoboard/OM13000.html#ordering for details
http://my.element14.com/jsp/search/brow ... obalsearch (http://my.element14.com/jsp/search/browse.jsp?N=541&Ntk=gensearch_001&Ntt=OM13000&Ntx=mode+matchallpartial&suggestions=false&ref=globalsearch)
I should get the slightly more expensive Dev board. Right? (The Dev board is not in stock here anyways :)[/quote]
I actually do not know what the difference is... The dev-board looks to be the one you want, yes.
Edit: check http://http://www.nxp.com/demoboard/OM13000.html#ordering for details
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 01:10:21 pm
Post by: matseng on July 25, 2013, 01:10:21 pm
[quote author="Bertho"]That is possible, but probably too small to start with. It has only one SPI channel and that will make it more of a challenge ;-) The memory limit may also be sligtly problematic.[/quote]
Now you're being silly... Think of Richard Gunee that did a Pong game using a frikking 3mips 16F84 many years ago. And you want 72 MHz 32 bit, dual SPI and DMA? :)
The OM13000 seems nice enough, I'll order one on Monday so I can get it delivered to my home in Kuala Lumpur on Tuesday before I fly back to Bangkok again. My weekend will be spent in Singapore at the Makerfaire....
I've never been a big friend of Eclipse, but it seems like I can use GCC separately and then upload via the LPC-Link anyways so that should not be an issue.
Now you're being silly... Think of Richard Gunee that did a Pong game using a frikking 3mips 16F84 many years ago. And you want 72 MHz 32 bit, dual SPI and DMA? :)
The OM13000 seems nice enough, I'll order one on Monday so I can get it delivered to my home in Kuala Lumpur on Tuesday before I fly back to Bangkok again. My weekend will be spent in Singapore at the Makerfaire....
I've never been a big friend of Eclipse, but it seems like I can use GCC separately and then upload via the LPC-Link anyways so that should not be an issue.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 25, 2013, 01:15:21 pm
Post by: matseng on July 25, 2013, 01:15:21 pm
I sure hope that the final mcu will be cheaper than the $10 LPC1769......
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 25, 2013, 04:55:19 pm
Post by: Bertho on July 25, 2013, 04:55:19 pm
[quote author="matseng"]Now you're being silly... Think of Richard Gunee that did a Pong game using a frikking 3mips 16F84 many years ago. And you want 72 MHz 32 bit, dual SPI and DMA? :)[/quote]
Well, maybe silly, but the dual SPI on DMA was my idea of doing the entire video stuff autonomously. One SPI for data and one SPI for sync. Using only one SPI port will introduce jitter on the sync/video relation, which is very annoying (and I am picky here).
Secondly, I propose to be able to do 320x240 and 360x256 for 40xN LCD emulation, which is somewhat higher resolution than a pong game, is it now?
[quote author="matseng"]I've never been a big friend of Eclipse, but it seems like I can use GCC separately and then upload via the LPC-Link anyways so that should not be an issue.[/quote]
I never use eclipse (or an IDE for that matter). I have (g)vim and everything on the command-line using make. I like control :-)
[quote author="matseng"]I sure hope that the final mcu will be cheaper than the $10 LPC1769[/quote]
We should be able to find something in the order of $4..$5 and cheaper in volume. The 1769 is the biggest in the series and is definitely overkill. But is is just easy to get going and see where the limits are.
Well, maybe silly, but the dual SPI on DMA was my idea of doing the entire video stuff autonomously. One SPI for data and one SPI for sync. Using only one SPI port will introduce jitter on the sync/video relation, which is very annoying (and I am picky here).
Secondly, I propose to be able to do 320x240 and 360x256 for 40xN LCD emulation, which is somewhat higher resolution than a pong game, is it now?
[quote author="matseng"]I've never been a big friend of Eclipse, but it seems like I can use GCC separately and then upload via the LPC-Link anyways so that should not be an issue.[/quote]
I never use eclipse (or an IDE for that matter). I have (g)vim and everything on the command-line using make. I like control :-)
[quote author="matseng"]I sure hope that the final mcu will be cheaper than the $10 LPC1769[/quote]
We should be able to find something in the order of $4..$5 and cheaper in volume. The 1769 is the biggest in the series and is definitely overkill. But is is just easy to get going and see where the limits are.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: BrianGriffin on July 26, 2013, 04:01:09 am
Post by: BrianGriffin on July 26, 2013, 04:01:09 am
About a year ago I used a PIC32 with SPI as a monochrome 1-bit colour VGA for pushing pixels. It is quite effective as the peripheral bus clock is fast enough. Even on that, a PIC32 could drive 8-bit colour in 256x240 resolution using DMA for pushing pixels. However, the PIC32's data bus is narrow, and all the pixel pushing action already occupies like 90% of it, therefore any other work inside is limited. The Atmel AT91SAM3XE (Arduino Due's processor) has a few of those data buses (I don't know the exact name), so it would be simpler.
I'm not sure for the "updating the LCD panel" thing though, because these things are very slow, and you have to juggle between rendering on the monitor and updating the panel.
You will do well if you use 1-bit colour, and a small PIC32MX or an ARM Cortex M0/M3 chip.
I'm not sure for the "updating the LCD panel" thing though, because these things are very slow, and you have to juggle between rendering on the monitor and updating the panel.
You will do well if you use 1-bit colour, and a small PIC32MX or an ARM Cortex M0/M3 chip.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 26, 2013, 09:15:51 am
Post by: Bertho on July 26, 2013, 09:15:51 am
[quote author="BrianGriffin"]About a year ago I used a PIC32 with SPI as a monochrome 1-bit colour VGA for pushing pixels. It is quite effective as the peripheral bus clock is fast enough.[/quote]
Two questions:
- How did you generate the H/V sync-signals?
- Did you use planar or interlace frames?
Two questions:
- How did you generate the H/V sync-signals?
- Did you use planar or interlace frames?
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 26, 2013, 09:32:34 am
Post by: Bertho on July 26, 2013, 09:32:34 am
An informative link to VGA video timing:
http://http://www.tinyvga.com/vga-timing
See also wikipedia: http://http://en.wikipedia.org/wiki/VGA
and, very interesting listing of (nearly) all modes: http://http://en.wikipedia.org/wiki/Graphic_display_resolutions
edit: PAL and NTSC: http://http://martin.hinner.info/vga/pal.html
http://http://www.tinyvga.com/vga-timing
See also wikipedia: http://http://en.wikipedia.org/wiki/VGA
and, very interesting listing of (nearly) all modes: http://http://en.wikipedia.org/wiki/Graphic_display_resolutions
edit: PAL and NTSC: http://http://martin.hinner.info/vga/pal.html
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on July 26, 2013, 10:01:04 am
Post by: matseng on July 26, 2013, 10:01:04 am
Just for reference compared to what we're trying to do here.... Made by a Swede ( what else ^_^ )
Atmega8 - RGB color on VGA, 3D, scrolling and multichannel music http://youtu.be/sNCqrylNY-0 (http://youtu.be/sNCqrylNY-0)
http://www.linusakesson.net/scene/craft/index.php (http://www.linusakesson.net/scene/craft/index.php)
Atmega8 - PAL color on Composite http://youtu.be/sCN1bqRG-7o (http://youtu.be/sCN1bqRG-7o)
http://www.linusakesson.net/scene/phasor/index.php (http://www.linusakesson.net/scene/phasor/index.php)
Atmega8 - RGB color on VGA, 3D, scrolling and multichannel music http://youtu.be/sNCqrylNY-0 (http://youtu.be/sNCqrylNY-0)
http://www.linusakesson.net/scene/craft/index.php (http://www.linusakesson.net/scene/craft/index.php)
Atmega8 - PAL color on Composite http://youtu.be/sCN1bqRG-7o (http://youtu.be/sCN1bqRG-7o)
http://www.linusakesson.net/scene/phasor/index.php (http://www.linusakesson.net/scene/phasor/index.php)
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: neslekkim on July 26, 2013, 10:21:32 am
Post by: neslekkim on July 26, 2013, 10:21:32 am
that dude have done some amazing stuff, ie: http://www.linusakesson.net/bitbuf/index.php (http://www.linusakesson.net/bitbuf/index.php) and http://www.linusakesson.net/chipophone/index.php (http://www.linusakesson.net/chipophone/index.php)
But I cannot find it documented in a way to replicate it.
ok, a bit offtopic.. :)
But I cannot find it documented in a way to replicate it.
ok, a bit offtopic.. :)
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on July 26, 2013, 10:34:22 am
Post by: Bertho on July 26, 2013, 10:34:22 am
[quote author="matseng"]Just for reference compared to what we're trying to do here.... Made by a Swede ( what else ^_^ )[/quote]
I'm seriously impressed by the skill. But, if nationality says something about skills, then I must blow the scales of all tests (don't know which direction, though).
That said, it is using table driven output. That is something different from doing framebuffer output. The atmega88 has only 1k RAM, so full-frame framebuffering is out of the question. There might be time to do real-time character generation, but that is speculative imo.
However, the real question here is whether you want to make this gadget for showing l33t skills, or you want a flexible device. Hardware is cheap and pressing it to the limit, although fascinating and challenging, will cost much time and frustration. Which way do you want to go?
I'm seriously impressed by the skill. But, if nationality says something about skills, then I must blow the scales of all tests (don't know which direction, though).
That said, it is using table driven output. That is something different from doing framebuffer output. The atmega88 has only 1k RAM, so full-frame framebuffering is out of the question. There might be time to do real-time character generation, but that is speculative imo.
However, the real question here is whether you want to make this gadget for showing l33t skills, or you want a flexible device. Hardware is cheap and pressing it to the limit, although fascinating and challenging, will cost much time and frustration. Which way do you want to go?
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: neslekkim on July 26, 2013, 10:41:08 am
Post by: neslekkim on July 26, 2013, 10:41:08 am
Arent you going to emulate an 1602 lcd on the tv?
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: BrianGriffin on July 26, 2013, 06:25:47 pm
Post by: BrianGriffin on July 26, 2013, 06:25:47 pm
[quote author="Bertho"][quote author="BrianGriffin"]About a year ago I used a PIC32 with SPI as a monochrome 1-bit colour VGA for pushing pixels. It is quite effective as the peripheral bus clock is fast enough.[/quote]
Two questions:
- How did you generate the H/V sync-signals?
- Did you use planar or interlace frames?[/quote]
I borrowed Lucio Di Jasio's "Programming 32-bit microcontrollers" book's example - it is for the composite video, and I have to modify it.
The H/V syncs are all done using Output Compare modules inside, and there are no interlacing. Since putting a 256x240 (this is a reason I choose this resolution - Nintendo Entertainment System uses that, and it's easier for me to relate), the screen on a 17" monitor is staying at the corner, so I have to adjust the DMA's streaming speed and zero-fill the sides for alignment. Plus, on the vertical side, I have to extend the lines so that it fills up the whole screen.
It's been a year I wrote this, and I find there are other alternatives to driving video better. Displaying video and doing the game code is not any easy. As I mentioned, that's why dedicated video controller exist.
Here's one of my toys I made for a contest: http://http://www.youtube.com/watch?v=BGqP_jg-IAc This version is with 256-colour, and it is not using SPI. Instead it uses PMP (Parallel Master Port) with DMA. I find the PIC32's DMA module easier to understand and the datasheet for it is quite understandable, with examples for some important components inside.
Two questions:
- How did you generate the H/V sync-signals?
- Did you use planar or interlace frames?[/quote]
I borrowed Lucio Di Jasio's "Programming 32-bit microcontrollers" book's example - it is for the composite video, and I have to modify it.
The H/V syncs are all done using Output Compare modules inside, and there are no interlacing. Since putting a 256x240 (this is a reason I choose this resolution - Nintendo Entertainment System uses that, and it's easier for me to relate), the screen on a 17" monitor is staying at the corner, so I have to adjust the DMA's streaming speed and zero-fill the sides for alignment. Plus, on the vertical side, I have to extend the lines so that it fills up the whole screen.
It's been a year I wrote this, and I find there are other alternatives to driving video better. Displaying video and doing the game code is not any easy. As I mentioned, that's why dedicated video controller exist.
Here's one of my toys I made for a contest: http://http://www.youtube.com/watch?v=BGqP_jg-IAc This version is with 256-colour, and it is not using SPI. Instead it uses PMP (Parallel Master Port) with DMA. I find the PIC32's DMA module easier to understand and the datasheet for it is quite understandable, with examples for some important components inside.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: matseng on August 02, 2013, 09:15:08 am
Post by: matseng on August 02, 2013, 09:15:08 am
Ok, I've got myself a OM13000 LpcXpresso.
Now I just have to get a development environment up and running without installing their bigass Eclipse-based IDE. The compiler should be easy, but can I use the LPC-Link JTAG-programmer without it?
[attachment=0]
Now I just have to get a development environment up and running without installing their bigass Eclipse-based IDE. The compiler should be easy, but can I use the LPC-Link JTAG-programmer without it?
[attachment=0]
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: BrianGriffin on August 05, 2013, 09:41:28 am
Post by: BrianGriffin on August 05, 2013, 09:41:28 am
I have these LPC thing also, won from a contest some years back. However, I haven't got a compiler to go with this one yet, and the board has an onboard programmer to go with.
If you can get the DMA to work right - driving the VGA or composite signal will be mostly correct. To sift out the correct information in a datasheet in other ARM microcontrollers is a tedious task.
If you can get the DMA to work right - driving the VGA or composite signal will be mostly correct. To sift out the correct information in a datasheet in other ARM microcontrollers is a tedious task.
Title: Re: COLDES1 (COLlaborative DESign) - LCD 2 TV Out
Post by: Bertho on August 05, 2013, 04:17:45 pm
Post by: Bertho on August 05, 2013, 04:17:45 pm
[quote author="matseng"]...but can I use the LPC-Link JTAG-programmer without it?[/quote]
Currently only LPC programming suite (and Red Suite). OpenOCD has no support as of yet for LPC-Link. I generally cut the link off and use a standard jtag dongle.
Currently only LPC programming suite (and Red Suite). OpenOCD has no support as of yet for LPC-Link. I generally cut the link off and use a standard jtag dongle.