Interfacing Graphic Displays with Parallel Port to the SPI Bus #1649
Replies: 10 comments 6 replies
-
|
That is how typical Raspberry Pi TFT's work, they use a 16 bit shift register but design issues with the way the write strobe is generated in that design limits the speed to 20Mbps. |
Beta Was this translation helpful? Give feedback.
-
|
I simply want to mention, somewhere, that the work you're doing here is bloody amazing! |
Beta Was this translation helpful? Give feedback.
-
|
Incidentally, I modified a Raspberry Pi TFT so it had a GPIO controlled write strobe. This means that for a block fill, a colour can be loaded into the 16 bit shift register and the WR toggled very fast N times, where N Is the number of pixels to write. This means a 320x480 screen can be cleared in less that 10ms. |
Beta Was this translation helpful? Give feedback.
-
|
I fully agree with your statements. In my region the parallel port displays are available on very reasonable prices. But often those can not be used in low cost applications as the number of IOs is not available. This is the reason for starting this development. As the idea is the merging of reasonable displays to low cost systems the interface must also consist of reasonable components only. For the frequency used by the Arduions the speed of the 74HC is more than sufficient. |
Beta Was this translation helpful? Give feedback.
-
|
@GeorgHelmut i find your proposal very interesting, however it adds substantial complexity. Reading the ST7789 datasheet (and other similar popular display controllers), they support both a parallel interface and a low pin count SPI/serial interface. And i am assuming that the display controller SPI slave is implemented by using a similar, dedicated shift register to parallelize the display data flow inside the controller....? so, can you clarify what is the benefit of parallelizing the data external to the display vs using the controller's built in SPI interface? |
Beta Was this translation helpful? Give feedback.
-
|
In technical applications the displayed image very often consists of areas
with uniform color. In this case, transmitting the 16 bit color code for
every single bit via the SPI is a waste of time, as ithe color for the next
pixel is already known. Avoiding the retransmission of the 16 bit color
code via SPI will significantly speed up the writing cycle to the display.
However, the increase of speed will depend on the image that should be
displayed. Speed increase for clearing the display with uniform color will
be at maximum, wherever the speed increase for displaying a picture will be
less to zero. I tested the system with an LGT8F328p/40MHz and a 480*330
8bit parallel display. In this configuration the clearing of the display
takes 35ms, which if found very impressive.
As long as the connection between microcontroller and display should be
done via a SPI interface, it's needed for having the 16 bit color
information available at the display; this would require a 16 bit register
at the display controller that can be addressed for the next pixel. So far
I tested but I could not find any display controller that's capable of
writing the next pixel with the same color as the previous pixel by simply
repeating the write command (toggling the write pin). 16bit display
controller interfaces require a static input a the 16 IO-lines, 8bit
display controller interfaces require 8bit alternate in highbyte and
lowbyte. This is where the idea of an 16bit shift register at the display
frontend comes handy. If you can find any display controller that has this
implemented I would be happy to know. The ST7789 definitely is not prepared
for this.
In general, to speed up the writing cycle to a display we have 3 options:
1. Use a parallel interface between display and microcontroller.
Disadvantage is the requirement of more ports and more wiring. 2. Get a
microcontroller with faster SPI. Disadvantage is a more costly controller.
3. Use the proposed solution with an external shift register at the display
frontend. Disadvantages are additional hardware (shift registers and
logic) and an acceleration that depends on the display content. Which
solution to go with will depend on the application.
Am Fr., 7. März 2025 um 06:19 Uhr schrieb avivgr ***@***.***>:
… @GeorgHelmut <https://github.com/GeorgHelmut> i find your proposal very
interesting, however it adds substantial complexity. Reading the ST7789
datasheet (and other similar popular display controllers), they support
*both* a parallel interface and a low pin count SPI/serial interface. And
i am assuming that the display controller SPI slave is implemented by using
a similar, dedicated shift register to parallelize the display data flow
inside the controller....?
so, can you clarify what is the benefit of parallelizing the data
*external* to the display vs using the controller's built in SPI
interface?
—
Reply to this email directly, view it on GitHub
<#1649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWY5RGV5PSPB7HLJ3OWYD3L2TDJZZAVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBRHE4DENY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the response, this makes a lot of sense. The optimization you mention - repeating the same color by toggling CS without loading a new value to the shift register is indeed useful. However, do you know if this optimization is compatible with DMA? i'd assume that the MCU needs to compare the current color value with the prev one to tell if this write can be optimized out... but not sure how this would work with a DMA. Do you have any insights? I took a quick glance at ST7789 datasheet and could not find a "write many of same value" or a "clear screen" command which is surprising, as i would expect they optimize this common use case too. |
Beta Was this translation helpful? Give feedback.
-
|
There is no DMA realized at the ST7789. In general the command set of such
display drivers is kept very simple: You define a rectangular area of any
size, somewhere on the LCD and then you fill this area bit by bit with
16/18 color information. That's all. If the display should be cleared the
rectangle to be defined is the LCD's entire area, the color information is
the desired background color. To draw a horizontal or vertical line a
rectangle with the width of one pixel is defined and filled with the line
color. A line in any other direction than horizontal or vertical is done by
stacking multiple h/v lines. A single pixel is set by defining a rectangle
of one by one and filling it with color.
Ihe ST7789 interfacing mode is defined by the Inputs IM0 to IM3. Those
inputs are set by the display manufacturer. Usually they are not accessible
by the user. Hence you need to define the method of interface when
purchasing the display.
In case you have got a display with serial input, the display will expect a
transmission of 16/18 bit color data followed by a write sequence for every
pixel. The write sequence is a sequence of low/high of the write pin. The
internal data transfer is done on the low to high transition. Additional
toggling of the write pin without previous color data transfer is not
accepted by the display controller. Regardless of the next pixel color the
serial transfer for every single pixel needs to be done. There is no other
way to speed up such a display than having a MCU with a faster SPI
interface.
It comes very differently with a ST7789 that is set up for a 16/18 bit
parallel interface. Here the parallel input pins need to be set to the
color information and then a write command by low/high sequencing is given
to the write pin. In case the defined rectangle is in uniform color the
data on the parallel interface can be kept static. For an image with
different colors the parallel data must be updated for every pixel.
Providing this data can be done by 16/18 parallel datalines connected to
the MCU or, as in my proposal with a shift register that is connected to
the display. In this configuration the color filling of a rectangle will
happen at the same speed as a wired 16/18 pin interface, as the shift
register only needs to be loaded once. Lets have an example: Clearing a
320*240 pixel display with a SPI interface will require the serial
transmission of the color information for 76800 times, the parallel
interface with connected shift register will require the serial transfer of
the color information by 1 time.
Third case is a ST7789 that is set up for 8/9 bit parallel input. Here the
color sequence is split into two cycles: Set the parallel input pins to the
low byte, do a write sequence by toggling the write pin, then set the
parallel inputs to the color high byte and toggle the write pin for a
second time. In this configuration it comes to the need that the parallel
input pins alternate between low byte and high byte for every pixel,
regardless if the next pixel should be of the same color. In this
configuration the proposed acceleration interface with the 16 bit serial
input and 2x8 bit output comes very handy. First the color information is
SPI transferred to the shift register for one time. Then, by the logic
circuits it's determined which of the two 8 bit parallel outputs of the
shift register are activated. In this way the color low byte or high byte
can be written to the display's parallel input without involving the MCU
for as many pixels as needed. This is a perfect solution for a less
powerful 8 bit MCU.
For sure, you will need a software library that's designed for this kind of
interfacing. The standard libraries will not fit. Maybe I can support you
in some way if you provide a little more information about your application.
Am Sa., 8. März 2025 um 04:47 Uhr schrieb avivgr ***@***.***>:
… Thanks for the response, this makes a lot of sense. The optimization you
mention - repeating the same color by toggling CS without loading a new
value to the shift register is indeed useful. However, do you know if this
optimization is compatible with DMA? i'd assume that the MCU needs to
compare the current color value with the prev one to tell if this write can
be optimized out... but not sure how this would work with a DMA. Do you
have any insights?
I took a quick glance at ST7789 datasheet and could not find a "write many
of same value" or a "clear screen" command which is surprising, as i would
expect they optimize this common use case too.
—
Reply to this email directly, view it on GitHub
<#1649 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWY5RGW3TAPFAAEPDDZKXF32TIHX7AVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBTGEYTAMA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
thanks again for the detailed response. i really appreciate your time and willingness to share your knowledge and offer support. flowchart LR
MCU-- DMA -->sr["Shift Register"];
sr-->LCD;
Regarding the application. I saw this cool project on hackaday, it is a mini computer based on Microchip's ATSAMD51J20A, and has a 3.2" display. This project is great but is way too expensive for me, so i was wondering what would it take to build something similar but with lower cost, maybe handheld or a smaller/external keyboard. The display performance looks great on the demo videos, with some old games running with good FPS. The project does not provide full schematic, but there is a block diagram on that page that shows a shift register used for the display..... so while trying to reverse engineer that block diagram i encountered your article :) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your response to the OP, it contained I lot of interesting
information for us "amateurs" in Arduino!
(Feeling strange to be an amateur, after 40+ years in electronic systems 😉)
…On Sat, Mar 8, 2025, 08:04 GeorgHelmut ***@***.***> wrote:
There is no DMA realized at the ST7789. In general the command set of such
display drivers is kept very simple: You define a rectangular area of any
size, somewhere on the LCD and then you fill this area bit by bit with
16/18 color information. That's all. If the display should be cleared the
rectangle to be defined is the LCD's entire area, the color information is
the desired background color. To draw a horizontal or vertical line a
rectangle with the width of one pixel is defined and filled with the line
color. A line in any other direction than horizontal or vertical is done
by
stacking multiple h/v lines. A single pixel is set by defining a rectangle
of one by one and filling it with color.
Ihe ST7789 interfacing mode is defined by the Inputs IM0 to IM3. Those
inputs are set by the display manufacturer. Usually they are not
accessible
by the user. Hence you need to define the method of interface when
purchasing the display.
In case you have got a display with serial input, the display will expect
a
transmission of 16/18 bit color data followed by a write sequence for
every
pixel. The write sequence is a sequence of low/high of the write pin. The
internal data transfer is done on the low to high transition. Additional
toggling of the write pin without previous color data transfer is not
accepted by the display controller. Regardless of the next pixel color the
serial transfer for every single pixel needs to be done. There is no other
way to speed up such a display than having a MCU with a faster SPI
interface.
It comes very differently with a ST7789 that is set up for a 16/18 bit
parallel interface. Here the parallel input pins need to be set to the
color information and then a write command by low/high sequencing is given
to the write pin. In case the defined rectangle is in uniform color the
data on the parallel interface can be kept static. For an image with
different colors the parallel data must be updated for every pixel.
Providing this data can be done by 16/18 parallel datalines connected to
the MCU or, as in my proposal with a shift register that is connected to
the display. In this configuration the color filling of a rectangle will
happen at the same speed as a wired 16/18 pin interface, as the shift
register only needs to be loaded once. Lets have an example: Clearing a
320*240 pixel display with a SPI interface will require the serial
transmission of the color information for 76800 times, the parallel
interface with connected shift register will require the serial transfer
of
the color information by 1 time.
Third case is a ST7789 that is set up for 8/9 bit parallel input. Here the
color sequence is split into two cycles: Set the parallel input pins to
the
low byte, do a write sequence by toggling the write pin, then set the
parallel inputs to the color high byte and toggle the write pin for a
second time. In this configuration it comes to the need that the parallel
input pins alternate between low byte and high byte for every pixel,
regardless if the next pixel should be of the same color. In this
configuration the proposed acceleration interface with the 16 bit serial
input and 2x8 bit output comes very handy. First the color information is
SPI transferred to the shift register for one time. Then, by the logic
circuits it's determined which of the two 8 bit parallel outputs of the
shift register are activated. In this way the color low byte or high byte
can be written to the display's parallel input without involving the MCU
for as many pixels as needed. This is a perfect solution for a less
powerful 8 bit MCU.
For sure, you will need a software library that's designed for this kind
of
interfacing. The standard libraries will not fit. Maybe I can support you
in some way if you provide a little more information about your
application.
Am Sa., 8. März 2025 um 04:47 Uhr schrieb avivgr ***@***.***>:
> Thanks for the response, this makes a lot of sense. The optimization you
> mention - repeating the same color by toggling CS without loading a new
> value to the shift register is indeed useful. However, do you know if
this
> optimization is compatible with DMA? i'd assume that the MCU needs to
> compare the current color value with the prev one to tell if this write
can
> be optimized out... but not sure how this would work with a DMA. Do you
> have any insights?
>
> I took a quick glance at ST7789 datasheet and could not find a "write
many
> of same value" or a "clear screen" command which is surprising, as i
would
> expect they optimize this common use case too.
>
> —
> Reply to this email directly, view it on GitHub
> <
#1649 (reply in thread)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AWY5RGW3TAPFAAEPDDZKXF32TIHX7AVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBTGEYTAMA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#1649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBMPKRG2G3KZOL5CNRAMGT2TKI6NAVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBTGMZDMNI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, I got your idea. Bur as long as SPI is involved, this is the
bottleneck. Let's assume a SPI of 8 MHz, a color depth of 16bit and 76800
pixels.This will end up in 153 ms for a full screen image, just for the SPI
transfers. Adding the control sequences I would assume that transferring a
full screen image from external RAM to the display will take a minimum of
200ms. In my opinion this result is not satisfying. I already thought about
a DMA system based on classic parallel RAM like the 62256 memory chip. This
would avoid the SPI bottleneck. The needed control logic would come with
some complexity, as logic is needed to write data into the RAM and then
initiate DMA towards the display. After a short evaluation I came to the
conclusion that in this case it's better to just switch to a more powerful
MCU that can provide faster SPI operation. This is a better, more up to
actual standards solution.
The answer to the question, if the shift register may be targeted by DMA is
a clear yes. With the help of the proposed simple logic writing to the
shift register is exactly the same as writing directly to the display
controller .
For the following examples I'm using the port commands, as they are much
faster then the arduino output commands. That's important for
maintaining the speed.
The code for loading a pixel to the16bit parallel display via 16bit shift
register is:
.......................................................................
*SPI.transfer16(color);PORTB&=B11111110;PORTB|=B00000001;*
.......................................................................
...where PORTB bit0 is the write command, either directly to the display
controller or to the shift register - exactly the same code.
Here is the code for transfering an image with all pixels the *same color* to
a 16bit parallel display via a 16 bit shift register (very fast, as SPI is
only used once)
.......................................................................
*SPI.transfer16(color);*
*for (int i =0; i< width*height; i++){*
* PORTB&=B11111110;*
* PORTB|=B00000001;*
*}*
.......................................................................
Here is the code for transfering an image with *different colors* to a
16bit parallel display (not fast, as SPI is within the loop for every pixel)
.......................................................................
for (int i =0; i< width*height; i++){
SPI.transfer16(color[i]);
PORTB&=B11111110;
PORTB|=B00000001;
}
.......................................................................
In case of a 8bit parallel display the code for loading a pixel to the
display via a 16bit_in / 2x8bit_out shift register is as follows:
.......................................................................
*SPI.transfer16(color); // loading the shift
registerPORTB&=B11111101;PORTB|=B00000010; // latching the
lowBytePORTB&=B11111110;PORTB|=B00000001; // latching the highByte*
.......................................................................
where PORTB bit0 is writing the highByte, bit1 is writing the lowByte.
Finally, in case you want to dive deeper into the logic, her is the
explanation how the logic works for the 16bit / 8bit parallel displays:
For a 16bit parallel display, once the writing is initiated by setting the
output line to logicLow, two things happen at the shift register (2
cascaded 74Hc595): The output is enabled and the serial information is
transferred to the parallel output. Once the output line is back to
logicHigh the parallel output of the shift register is transferred to the
display controller. As the writing sequence is done within a single strobe
of the write line, the MCU doesn't even know if it's writing to an external
shift register or a display with SPI interface. The sequence is exactly the
same.
In case of a 8bit parallel display the shift register is set up as a
16bit_in 2x8bit_out register. This will maximise the performance. The
writing is initiated by setting the respective output line for lowByte or
highByte to logicLow. This will activate the transfer of the serial data to
the parallel output of the respective 74HC595 chip and enable the
respective output. Once the writing line is back to logicHigh the transfer
to the display controller is initiated. By the logic NAND this transfer
will take place regardless whether the lowByte or highByte register is
activated. This is the sequence that is expected by the display controller.
As seen in the code example, in this case the MCU has to serve two write
lines.
If the control of the 8bit parallel display by shift register should work
in exactly the same way as directly writing to the display, the shift
register should be reduced to a 8bit register. Then two cycles by SPI_8
instead of one cycle SPI_16 are needed. As this will slow down the
performance I realized the interface with an 16bit_in / 2*8bit_out shift
register plus the simple logic.
Following the idea of DMA the two shift registers could be replaced by two
62256 RAM chips and adding an increment counter for the RAM address. In
this case the data to the display will be the lowByte out of RAM0 and the
highByte out of RAM1. This will be a very fast solution as no SPI or MCU is
involved. But for completion a logic for writing the data into the RAMs
needs to be added. This makes the logic more complex as bidirectional octal
buffers are needed. This is a solution which is ending up in TTL graveyards
like in the old days. Nowadays you simply take a more powerful MCU. That's
why I don't want to dive deeper into this. Make your life easy by taking a
more powerful MCU.
Am So., 9. März 2025 um 12:43 Uhr schrieb avivgr ***@***.***>:
… thanks again for the detailed response. i really appreciate your time and
willingness to share your knowledge and offer support.
when i asked about DMA, i did not mean on the display controller side, but
on the MCU side. Modern ARM MCUs have DMA hardware which can offload IO
from the CPU, and execute the data transfer by a DMA hardware instead. This
allows an application running on the MCU to program the DMA to perform data
transfer (e.g write some data from a memory buffer to SPI, or read some
data from DAC via i2s to a memory buffer) which will happen
*asynchronously* by the DMA hardware, leaving the main CPU to do other
things. Offload using DMA is critical when moving large amounts of data
(such as screen frames at a high rate), in order to free the CPU to perform
other tasks (such as compute the next frame). So, I was simply wondering if
an MCU DMA can target the shift register (i guess it depends on how the MCU
port is configured) and secondly, how to implement the "write data once,
send many of same value" using a DMA.
flowchart LR
MCU-- DMA -->sr["Shift Register"];
sr-->LCD;
Loading
Regarding the application. I saw this cool project
<https://hackaday.io/project/202450-rimer-sbc> on hackaday, it is a mini
computer based on Microchip's ATSAMD51J20A, and has a 3.2" display. This
project is great but is way too expensive for me, so i was wondering what
would it take to build something similar but with lower cost, maybe
handheld or a smaller/external keyboard. The display performance looks
great on the demo videos, with some old games running with good FPS. The
project does not provide full schematic, but there is a block diagram on
that page that shows a shift register used for the display..... so while
trying to reverse engineer that block diagram i encountered your article :)
—
Reply to this email directly, view it on GitHub
<#1649 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWY5RGVRLI4MRH5VTAQVGSD2TPIGLAVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENBTHAYTMOA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much. It's always a pleasure discussing with someone who is
interested in the optimization of the hard-/ software interface. It's only
a small community going into this topic.
Am Mi., 19. März 2025 um 21:08 Uhr schrieb lohikarhu <
***@***.***>:
… I simply want to mention, somewhere, that the work you're doing here is
bloody amazing!
Thanks for making the lowly microcontroller space, s prettier place!
—
Reply to this email directly, view it on GitHub
<#1649 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWY5RGQ4EQHKTYHFCZWLAEL2VF2WFAVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJVGI2DSNQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you again for the detailed responses! |
Beta Was this translation helpful? Give feedback.
-
|
I started with MC6800 in 1976, did "front end processor" for a scientific
sonar, 1978, with the prototypes XC6803NR from Motorola (kindly sampled
from Austin Application Engineering group) the first microcontroller with
hardware multiply and true 16-bit math, plus counter-timers, parallel I/O,
UART, bi-phase serial,, then moved to MC 68000, 68hc11... after Tek,
Agilent, Nokia (best job! Lp5523 is one of mine) Rohde &:Schwarz, now
retired, trying to get my feet wet with STM32 and ESP32...
So, having worked on "the pointy end" for 40 years, much appreciate what it
takes to do this, and deal with some hard questions, and some... RTFM
questions, too!
Alles gute, freundlichen Grüßen aus Süd Deutschland!
…On Wed, Mar 19, 2025, 16:40 GeorgHelmut ***@***.***> wrote:
Thank you so much. It's always a pleasure discussing with someone who is
interested in the optimization of the hard-/ software interface. It's only
a small community going into this topic.
Am Mi., 19. März 2025 um 21:08 Uhr schrieb lohikarhu <
***@***.***>:
> I simply want to mention, somewhere, that the work you're doing here is
> bloody amazing!
> Thanks for making the lowly microcontroller space, s prettier place!
>
> —
> Reply to this email directly, view it on GitHub
> <
#1649 (reply in thread)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AWY5RGQ4EQHKTYHFCZWLAEL2VF2WFAVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJVGI2DSNQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#1649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBMPKXHUWOZYOIVGJCU3HL2VGFVHAVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJVGM3TQNA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hallo nach Süddeutschland. Ich habe in den 70er Jahren Elektrotechnik studiert. In dieser Zeit realisierte ich einige Projekte mit dem 8052. Meine weitere Laufbahn hat mich dann aber in die industrielle Produktion verschlagen, wo sich der Schwerpunkt Schritt für Schritt vom Engineering in das Management verschoben hat. Das beinhaltete die Leitung von Produktionsstätten in Fernost. Jetzt bin ich ebenfalls Rentner und habe mich in Thailand niedergelassen. Hier kann ich mich nach vielen Jahren der Pause hobbymäßig wieder der Elektronik widmen. Den Lp5523 werde ich mir einmal ansehen. Bisher habe ich mit dem ICN20385 gearbeitet. In Thailand hat man den großen Vorteil, dass die Komponenten aus China gut und schnell verfügbar sind. Viele Grüße von Rentner zu Rentner. |
Beta Was this translation helpful? Give feedback.
-
|
Hi: I think that Thailand gives you good "bang for the buck", the pension
goes further!
I've been astounded by the small amount of work pension, I'm pretty lucky
that I got a decent amount from my time in Finland..
About 4x the amount of time I salary, compared to what I got from my German
employment. I was kind of upset with how small the amount was, until I saw
what people get for a life of work in lower-income jobs.
My work in Finland was the global responsibility for the development of
LEDs and LED drivers, so I co-developed 6-10 drivers, was influential in
multiple phosphor "white" LEDs with rather better color rendering than was
available, and developed RGB LEDS with embedded memory devices, 128-bit
calibration data, and developed a method for reading and writing data
to/from the LED, without requiring any extra pins!
Lp5523:was a great cooperation with the National Semiconductor design team
in Oulu Finland, and it's a device that has some very interesting, but
non-obvious, features.. I did 5522/22/23 with them and we co-developed a
user interface co-processor, starting in about 2008, years ahead of Apple,
but Microsoft had not built in any kind of coprocessor capabilities in
their OS! In 2010, we could do inertial navigation, good to about 10 m per
500-750 m Walking, with just accelerometers and gyros, from an initial GPS
fix... With only 125 uA average Current... And, had buck/boost converter,
that could change output on different LEDs, on the fly... We did a
prototype phone that could tell if you were holding it in left or right
hand, did firmware to wake up, determined by the trajectory of the phone as
you picked it up.
Fantastic job!
…On Thu, Mar 20, 2025, 05:33 GeorgHelmut ***@***.***> wrote:
Hallo nach Süddeutschland. Ich habe in den 70er Jahren Elektrotechnik
studiert. In dieser Zeit realisierte ich einige Projekte mit dem 8052.
Meine weitere Laufbahn hat mich dann aber in die industrielle Produktion
verschlagen, wo sich der Schwerpunkt Schritt für Schritt vom Engineering in
das Management verschoben hat. Das beinhaltete die Leitung von
Produktionsstätten in Fernost. Jetzt bin ich ebenfalls Rentner und habe
mich in Thailand niedergelassen. Hier kann ich mich nach vielen Jahren der
Pause hobbymäßig wieder der Elektronik widmen. Den Lp5523 werde ich mir
einmal ansehen. Bisher habe ich mit dem ICN20385 gearbeitet. In Thailand
hat man den großen Vorteil, dass die Komponenten aus China gut und schnell
verfügbar sind. Viele Grüße von Rentner zu Rentner.
—
Reply to this email directly, view it on GitHub
<#1649 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGBMPKVEB4DR2ZLEMA5JSGT2VJAKVAVCNFSM6AAAAABYP4ZFQWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJVHEZDSNA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
SPI Interface for TFT.pdf
Connecting Graphic displays with parallel interface to the SPI without loosing speed but reducing the number of IOs. Is this possible? Yes, I developed some interface converters for this job. See the attached PDF.
Beta Was this translation helpful? Give feedback.
All reactions