disp module revision

[Dado Sutter]

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Bittencourt]

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[CF Kwok]

Hi,

 In my experience of using the LM3S8962, the off and disable have different effect. When I disable the display, the oled still keep turn on but any drawing to screen is ignored. I worry about the merge of on/enable and off/disable might cause any effect but I am not sure.

I think on/off is more useful than enable/disable IMHO. Since OLED has a quite limited life time when always on.

Best,
CF

---

寄件人﹕ Dado Sutter <[hidden email]>
收件人 eLua Users and Development List <[hidden email]>
傳送日期﹕ 2009 年 2月 27 日 星期五 上午 4:38:43
主題： [eLua-dev] disp module revision

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

---

Yahoo!香港提供網上安全攻略，教你如何防範黑客!了解更多
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Well, the disp module is platform (LM3S) dependent and, afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

This said, couldn't  disp.on could always call rit128x96x4_init(1000000) ?  (1MHz SPI Clock ....)

If by LM3S-dependent we mean MCU-dependent and not LM kits-dependent, we would have to leave disp.init(freq) out of my "integration proposition", merging only on+enable and off+disable.
But do you think we will find many other (non Luminary Micro) LM3Sxxxx kits with an integrated RIT OLED Display too ?

Thanks
Dado







2009/2/26 Pedro Bittencourt <[hidden email]>

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Bittencourt]

Maybe... maybe as an optional parameter to on where default is 1M ?

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 10:37 PM, Dado Sutter <[hidden email]> wrote:

Well, the disp module is platform (LM3S) dependent and, afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

This said, couldn't  disp.on could always call rit128x96x4_init(1000000) ?  (1MHz SPI Clock ....)

If by LM3S-dependent we mean MCU-dependent and not LM kits-dependent, we would have to leave disp.init(freq) out of my "integration proposition", merging only on+enable and off+disable.
But do you think we will find many other (non Luminary Micro) LM3Sxxxx kits with an integrated RIT OLED Display too ?

Thanks
Dado







2009/2/26 Pedro Bittencourt <[hidden email]>

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Hi,
   You're right CF. off releases the SPI channel for other uses and disable simply turns off the dc/dc converter, to "blank" (and save!) the screen (or maybe the oposite, I always forget :)
   We would "loose" these two separate "features", combining them in just one. But IMO this would not be a problem for the final user, much on the contrary, this would hide this and make it simpler.
   But if anyone think it is really necessary/usefull to keep both features in separate functions, we can keep disp the way we first wrote it, binding exactly the low-level driver functions. My vote is to KISS.

Best
Dado

2009/2/26 CF Kwok <[hidden email]>

Hi,

 In my experience of using the LM3S8962, the off and disable have different effect. When I disable the display, the oled still keep turn on but any drawing to screen is ignored. I worry about the merge of on/enable and off/disable might cause any effect but I am not sure.

I think on/off is more useful than enable/disable IMHO. Since OLED has a quite limited life time when always on.

Best,
CF

---

寄件人﹕ Dado Sutter <[hidden email]>
收件人 eLua Users and Development List <[hidden email]>
傳送日期﹕ 2009 年 2月 27 日 星期五 上午 4:38:43
主題： [eLua-dev] disp module revision

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

---

Yahoo!香港提供網上安全攻略，教你如何防範黑客!了解更多

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Yes, we could keep that too, if really needed. It would cost a simple test and on a normaly used-just-once function.
But it would be a disp.on(freq) optional parameter and disp.init() would be really dropped.

Thanks
Dado

2009/2/26 Pedro Bittencourt <[hidden email]>

Maybe... maybe as an optional parameter to on where default is 1M ?

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 10:37 PM, Dado Sutter <[hidden email]> wrote:

Well, the disp module is platform (LM3S) dependent and, afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

This said, couldn't  disp.on could always call rit128x96x4_init(1000000) ?  (1MHz SPI Clock ....)

If by LM3S-dependent we mean MCU-dependent and not LM kits-dependent, we would have to leave disp.init(freq) out of my "integration proposition", merging only on+enable and off+disable.
But do you think we will find many other (non Luminary Micro) LM3Sxxxx kits with an integrated RIT OLED Display too ?

Thanks
Dado







2009/2/26 Pedro Bittencourt <[hidden email]>

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

One quick note here:

I'm not sure what API you may be settling upon, but you may want to consider the following:

The display is on an SSI port that can, and in some cases (like LM3S6965) is shared with another device (like the micro-SD slot).  I've not checked which/if any of the commands correspond to turning of the chip select for the display, but you may wish to wrap drawing commands in functions that enable and disable the chip select for the display so that when we add the flash card support that Jesus Alvarez ported, we can use both devices.

-jsnyder

On Feb 26, 2009, at 7:55 PM, Dado Sutter wrote:

Yes, we could keep that too, if really needed. It would cost a simple test and on a normaly used-just-once function.
But it would be a disp.on(freq) optional parameter and disp.init() would be really dropped.

Thanks
Dado

2009/2/26 Pedro Bittencourt <[hidden email]>

Maybe... maybe as an optional parameter to on where default is 1M ?

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 10:37 PM, Dado Sutter <[hidden email]> wrote:

Well, the disp module is platform (LM3S) dependent and, afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

This said, couldn't  disp.on could always call rit128x96x4_init(1000000) ?  (1MHz SPI Clock ....)

If by LM3S-dependent we mean MCU-dependent and not LM kits-dependent, we would have to leave disp.init(freq) out of my "integration proposition", merging only on+enable and off+disable.
But do you think we will find many other (non Luminary Micro) LM3Sxxxx kits with an integrated RIT OLED Display too ?

Thanks
Dado







2009/2/26 Pedro Bittencourt <[hidden email]>

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

This was a good reminder James,
   I am not recoding any low-level functions of the LM drivers at this moment though. All I did was to wrap them in Lua-bind functions, in a one-to-one basis, offering in Lua the exact API  (init, on, off, enable, disable, clear, print, draw) that the Luminary Micro drivers offer. My proposition was to simplify it, merging some of the functions.
   I am not sure if the LM drivers make an "exclusive" use of the port but if they do, we'll have some extra work fixing it. To be able to use mmc/sd cards and the rit oled at the same time is a must.
  (by the way, I could not make Alvarez driver work on my LM3S8962 yet, probably because of some bad contact or bad card formatting but I'll get there :)

Best
Dado

2009/2/27 James Snyder <[hidden email]>

One quick note here:

I'm not sure what API you may be settling upon, but you may want to consider the following:

The display is on an SSI port that can, and in some cases (like LM3S6965) is shared with another device (like the micro-SD slot).  I've not checked which/if any of the commands correspond to turning of the chip select for the display, but you may wish to wrap drawing commands in functions that enable and disable the chip select for the display so that when we add the flash card support that Jesus Alvarez ported, we can use both devices.

-jsnyder

On Feb 26, 2009, at 7:55 PM, Dado Sutter wrote:

Yes, we could keep that too, if really needed. It would cost a simple test and on a normaly used-just-once function.
But it would be a disp.on(freq) optional parameter and disp.init() would be really dropped.

Thanks
Dado

2009/2/26 Pedro Bittencourt <[hidden email]>

Maybe... maybe as an optional parameter to on where default is 1M ?

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 10:37 PM, Dado Sutter <[hidden email]> wrote:

Well, the disp module is platform (LM3S) dependent and, afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

This said, couldn't  disp.on could always call rit128x96x4_init(1000000) ?  (1MHz SPI Clock ....)

If by LM3S-dependent we mean MCU-dependent and not LM kits-dependent, we would have to leave disp.init(freq) out of my "integration proposition", merging only on+enable and off+disable.
But do you think we will find many other (non Luminary Micro) LM3Sxxxx kits with an integrated RIT OLED Display too ?

Thanks
Dado







2009/2/26 Pedro Bittencourt <[hidden email]>

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

I'm not suggesting that you rewrite anything low level.  What I meant was that you could wrap the code to draw or write text in RIT128x96x4Enable/RIT128x96x4Disable, which are driver provided functions that I believe will toggle chip select for the display.  This way you wouldn't need the disable function, since whenever done writing to the display you'd set the display to not pay attention to stuff that might be going to the SD.

-jsnyder

On Feb 27, 2009, at 10:20 AM, Dado Sutter wrote:

This was a good reminder James,
   I am not recoding any low-level functions of the LM drivers at this moment though. All I did was to wrap them in Lua-bind functions, in a one-to-one basis, offering in Lua the exact API  (init, on, off, enable, disable, clear, print, draw) that the Luminary Micro drivers offer. My proposition was to simplify it, merging some of the functions.
   I am not sure if the LM drivers make an "exclusive" use of the port but if they do, we'll have some extra work fixing it. To be able to use mmc/sd cards and the rit oled at the same time is a must.
  (by the way, I could not make Alvarez driver work on my LM3S8962 yet, probably because of some bad contact or bad card formatting but I'll get there :)

Best
Dado

2009/2/27 James Snyder <[hidden email]>

One quick note here:

I'm not sure what API you may be settling upon, but you may want to consider the following:

The display is on an SSI port that can, and in some cases (like LM3S6965) is shared with another device (like the micro-SD slot).  I've not checked which/if any of the commands correspond to turning of the chip select for the display, but you may wish to wrap drawing commands in functions that enable and disable the chip select for the display so that when we add the flash card support that Jesus Alvarez ported, we can use both devices.

-jsnyder

On Feb 26, 2009, at 7:55 PM, Dado Sutter wrote:

Yes, we could keep that too, if really needed. It would cost a simple test and on a normaly used-just-once function.
But it would be a disp.on(freq) optional parameter and disp.init() would be really dropped.

Thanks
Dado

2009/2/26 Pedro Bittencourt <[hidden email]>

Maybe... maybe as an optional parameter to on where default is 1M ?

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 10:37 PM, Dado Sutter <[hidden email]> wrote:

Well, the disp module is platform (LM3S) dependent and, afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

This said, couldn't  disp.on could always call rit128x96x4_init(1000000) ?  (1MHz SPI Clock ....)

If by LM3S-dependent we mean MCU-dependent and not LM kits-dependent, we would have to leave disp.init(freq) out of my "integration proposition", merging only on+enable and off+disable.
But do you think we will find many other (non Luminary Micro) LM3Sxxxx kits with an integrated RIT OLED Display too ?

Thanks
Dado







2009/2/26 Pedro Bittencourt <[hidden email]>

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Got it.
  It just seem that it would be more efficient to recode some things, as it is really simple and clear on the LM drivers.
  To wrap enable/disable in draw and print could thus solve the SPI sharing for the OLED and mmc/sd (and others) and it seems indeed very important, lowering the priority of my disp api simplification proposition.
  disp.on and disp.off would still be kept or a simple disp.clear would do for screen saving purposes ?

Dado

On Fri, Feb 27, 2009 at 15:59, James Snyder <[hidden email]> wrote:

I'm not suggesting that you rewrite anything low level.  What I meant was that you could wrap the code to draw or write text in RIT128x96x4Enable/RIT128x96x4Disable, which are driver provided functions that I believe will toggle chip select for the display.  This way you wouldn't need the disable function, since whenever done writing to the display you'd set the display to not pay attention to stuff that might be going to the SD.

-jsnyder

On Feb 27, 2009, at 10:20 AM, Dado Sutter wrote:

This was a good reminder James,
   I am not recoding any low-level functions of the LM drivers at this moment though. All I did was to wrap them in Lua-bind functions, in a one-to-one basis, offering in Lua the exact API  (init, on, off, enable, disable, clear, print, draw) that the Luminary Micro drivers offer. My proposition was to simplify it, merging some of the functions.
   I am not sure if the LM drivers make an "exclusive" use of the port but if they do, we'll have some extra work fixing it. To be able to use mmc/sd cards and the rit oled at the same time is a must.
  (by the way, I could not make Alvarez driver work on my LM3S8962 yet, probably because of some bad contact or bad card formatting but I'll get there :)

Best
Dado

2009/2/27 James Snyder <[hidden email]>

One quick note here:

I'm not sure what API you may be settling upon, but you may want to consider the following:

The display is on an SSI port that can, and in some cases (like LM3S6965) is shared with another device (like the micro-SD slot).  I've not checked which/if any of the commands correspond to turning of the chip select for the display, but you may wish to wrap drawing commands in functions that enable and disable the chip select for the display so that when we add the flash card support that Jesus Alvarez ported, we can use both devices.

-jsnyder

On Feb 26, 2009, at 7:55 PM, Dado Sutter wrote:

Yes, we could keep that too, if really needed. It would cost a simple test and on a normaly used-just-once function.
But it would be a disp.on(freq) optional parameter and disp.init() would be really dropped.

Thanks
Dado

2009/2/26 Pedro Bittencourt <[hidden email]>

Maybe... maybe as an optional parameter to on where default is 1M ?

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 10:37 PM, Dado Sutter <[hidden email]> wrote:

Well, the disp module is platform (LM3S) dependent and, afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

This said, couldn't  disp.on could always call rit128x96x4_init(1000000) ?  (1MHz SPI Clock ....)

If by LM3S-dependent we mean MCU-dependent and not LM kits-dependent, we would have to leave disp.init(freq) out of my "integration proposition", merging only on+enable and off+disable.
But do you think we will find many other (non Luminary Micro) LM3Sxxxx kits with an integrated RIT OLED Display too ?

Thanks
Dado







2009/2/26 Pedro Bittencourt <[hidden email]>

There is a little problem there, the init parameter is clock dependent...so a little "intelligence" would be necessary (like checking the clock and make some maths to discover the appropriate param to the initialization...

--Pedro Bittencourt

On Thu, Feb 26, 2009 at 5:38 PM, Dado Sutter <[hidden email]> wrote:

Hello,
   For the sake of kiss on the platform-dependent disp module, I was thinking about reducing our current:

init
on
off
enable
disable
print
draw  (pls note that drawString and drawImage are beeing renamed for print and draw respectively, on v0.6)

..... to simply:

on
off
print
draw

on/enable and off/disable functionalities would be merged (spi channel setup and release, dc/dc converter powering on/off)
also, init would be combined with on/enable, initializing the spi clock always to 1000000. It is very unlikely that this spi channel would be used concurrently for another function.
A typical diplay usage would be:

disp.on()  and
disp.print() and/or disp.draw() at will...........

The user would not care anymore for the concept of an "spi frequency", display/channel initialization and would simply use on to begin use the display. disp.off would be used only in some cases and mostly at the very end of the program.

The only functionality that we seem to loose is that an off-on cicle would force a clear (I think so, if init forces a clear) and contents would have to be rewritten/redrawn in case of a "screen-saver" usage. But again, this doesn't seem to hurt or frequently used.

Comments are welcome.

Best
Dado

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Jesus Alvarez]

> afaik, all the LM3S kits have 50MHz clocks (pls correct me if I'm wrong).

Current LMI microcontroller cores run at 20, 25 or 50 MHz. Luminary is
previewing 80-MHz parts to be available in the second quarter. That means
you can have LM3S boards with any of those core clocks.

Most production applications will not use the small RIT units on the LMI
kits so the interface should be more flexible. One alternative would be to
consider a generic interface that can accommodate different display drivers
in the future. Maybe a simple setOption() and getOption() interface would
work for options? Then the person implementing the display driver can decide
what options to implement without requiring language changes.

  disp.getOption("colors")
    --> returns 2 for monochrome, 256 for 8-bit color, etc.
  disp.getOption("gui")
    --> returns 0 if on text mode, 1 for GUI mode
  disp.getOption("backlight")
    --> returns 0 if backlight 0ff, 1 if backlight on

  disp.setOption("colors=256")
    --> changes to 8-bit color, returns nil if that color depth is not
available
  disp.setOption("gui=0,backlight=1")
    --> changes to text mode and turns backlight on

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Jesus Alvarez]

In the default configuration, four GPIO pins of the LM3S MCUs are used for
JTAG. The eLua GPIO APIs do not appear to provide a method for switching
pins from JTAG to GPIO. This causes some GPIO pins (e.g. PB7 and PC0-3 in
the LM3S6918; these are the more common ones but there may be some MCUs that
use others) to be non-functional from eLua applications. An example of the
logic required to switch from one mode to the other was posted for
discussion to the eagle_mmc branch of the SVN (see jtag.c and jtag.h in
src/platform/lm3s). What would be the proper way to handle this within eLua
applications? Since most applications would not use a JTAG in production,
should the switch should be done automatically at startup and provide a
function for developers to switch back to JTAG mode? Allowing applications
to change individual pins is probably not necessary. When a JTAG is not in
use, all four pins should be configured for GPIO.

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Jesus Alvarez]

I noticed today that the mmc.c driver posted in February to the eagle_mmc
branch does not handle some FatFs 0.06 features. It was originally developed
by Luminary for FatFs 0.04b. Although it worked fine on my test system,
there could be potential problems with some boards and/or cards. I rolled
back the FatFs on the eagle_mmc branch to 0.04b. Those that had problems
with the mmc feature may want to test using the files posted today in the
src/fatfs directory of that branch. It would be desirable to eventually
update the driver to handle the 0.06 features but my time is over-committed
at the moment.

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Great point !
   Indeed, GPIO should be the default for those precious pins, we'll check.
   Your code seems to do all we need (!!!) but the pins/port should not be hardcoded, to support other LM kits (like our 3S8962) if other pin/ports are used. Maybe the default DIR could be output too or be set on the function call (not really needed) but this can be done later by usual GPIO functions.
   By the way, do you all prefer the module to be called PIO or GPIO (or doesn't matter) ? Just a curiosity pool :)

Best
Dado

On Wed, Mar 25, 2009 at 23:42, Jesus Alvarez <[hidden email]> wrote:

In the default configuration, four GPIO pins of the LM3S MCUs are used for
JTAG. The eLua GPIO APIs do not appear to provide a method for switching
pins from JTAG to GPIO. This causes some GPIO pins (e.g. PB7 and PC0-3 in
the LM3S6918; these are the more common ones but there may be some MCUs that
use others) to be non-functional from eLua applications. An example of the
logic required to switch from one mode to the other was posted for
discussion to the eagle_mmc branch of the SVN (see jtag.c and jtag.h in
src/platform/lm3s). What would be the proper way to handle this within eLua
applications? Since most applications would not use a JTAG in production,
should the switch should be done automatically at startup and provide a
function for developers to switch back to JTAG mode? Allowing applications
to change individual pins is probably not necessary. When a JTAG is not in
use, all four pins should be configured for GPIO.

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

I couldn't make it work on my EK-LM3S8962 board yet and I wish this was the reason :)
But I'm afraid I'm doing something wrong somewhere else, because Bogdan was able to make it run on the same board.
I'll find more time to test it better.
Thanks for the code !

Best
Dado

On Wed, Mar 25, 2009 at 23:47, Jesus Alvarez <[hidden email]> wrote:

I noticed today that the mmc.c driver posted in February to the eagle_mmc
branch does not handle some FatFs 0.06 features. It was originally developed
by Luminary for FatFs 0.04b. Although it worked fine on my test system,
there could be potential problems with some boards and/or cards. I rolled
back the FatFs on the eagle_mmc branch to 0.04b. Those that had problems
with the mmc feature may want to test using the files posted today in the
src/fatfs directory of that branch. It would be desirable to eventually
update the driver to handle the 0.06 features but my time is over-committed
at the moment.

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Thu, Mar 26, 2009 at 12:19 PM, Dado Sutter <[hidden email]> wrote:

I couldn't make it work on my EK-LM3S8962 board yet and I wish this was the reason :)
But I'm afraid I'm doing something wrong somewhere else, because Bogdan was able to make it run on the same board.

Actually I didn't. I didn't even try to run it just yet.

Best,
Bogdan

On Wed, Mar 25, 2009 at 23:47, Jesus Alvarez <[hidden email]> wrote:

I noticed today that the mmc.c driver posted in February to the eagle_mmc
branch does not handle some FatFs 0.06 features. It was originally developed
by Luminary for FatFs 0.04b. Although it worked fine on my test system,
there could be potential problems with some boards and/or cards. I rolled
back the FatFs on the eagle_mmc branch to 0.04b. Those that had problems
with the mmc feature may want to test using the files posted today in the
src/fatfs directory of that branch. It would be desirable to eventually
update the driver to handle the 0.06 features but my time is over-committed
at the moment.

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Oh, that may be good news :)
Can't wait to get back to Rio and try again with the new code.
Did anybody else make it run on an EK-LM3S8962 board ?

Best
Dado

On Thu, Mar 26, 2009 at 07:22, Bogdan Marinescu <[hidden email]> wrote:

On Thu, Mar 26, 2009 at 12:19 PM, Dado Sutter <[hidden email]> wrote:

I couldn't make it work on my EK-LM3S8962 board yet and I wish this was the reason :)
But I'm afraid I'm doing something wrong somewhere else, because Bogdan was able to make it run on the same board.

Actually I didn't. I didn't even try to run it just yet.

Best,
Bogdan

On Wed, Mar 25, 2009 at 23:47, Jesus Alvarez <[hidden email]> wrote:

I noticed today that the mmc.c driver posted in February to the eagle_mmc
branch does not handle some FatFs 0.06 features. It was originally developed
by Luminary for FatFs 0.04b. Although it worked fine on my test system,
there could be potential problems with some boards and/or cards. I rolled
back the FatFs on the eagle_mmc branch to 0.04b. Those that had problems
with the mmc feature may want to test using the files posted today in the
src/fatfs directory of that branch. It would be desirable to eventually
update the driver to handle the 0.06 features but my time is over-committed
at the moment.

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Thu, Mar 26, 2009 at 4:42 AM, Jesus Alvarez <[hidden email]> wrote:

In the default configuration, four GPIO pins of the LM3S MCUs are used for
JTAG. The eLua GPIO APIs do not appear to provide a method for switching
pins from JTAG to GPIO.

This will happen when the lm3s.gpio module is implemented, and it will have a method for this. I managed to completely kill an older (8-bit) Luminary devboard by switching the JTAG pins to GPIO though :) Hope this changed in their newer CPUs.
 
Best,
Bogdan

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

   By the way, do you all prefer the module to be called PIO or GPIO (or doesn't matter) ? Just a curiosity pool :)

Don't even TRY to go there again :)

Best,
Bogdan
 

On Wed, Mar 25, 2009 at 23:42, Jesus Alvarez <[hidden email]> wrote:

In the default configuration, four GPIO pins of the LM3S MCUs are used for
JTAG. The eLua GPIO APIs do not appear to provide a method for switching
pins from JTAG to GPIO. This causes some GPIO pins (e.g. PB7 and PC0-3 in
the LM3S6918; these are the more common ones but there may be some MCUs that
use others) to be non-functional from eLua applications. An example of the
logic required to switch from one mode to the other was posted for
discussion to the eagle_mmc branch of the SVN (see jtag.c and jtag.h in
src/platform/lm3s). What would be the proper way to handle this within eLua
applications? Since most applications would not use a JTAG in production,
should the switch should be done automatically at startup and provide a
function for developers to switch back to JTAG mode? Allowing applications
to change individual pins is probably not necessary. When a JTAG is not in
use, all four pins should be configured for GPIO.

Regards,
Jesus Alvarez


_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev