Embedded/elua
1
0
Fork 0
mirror of https://github.com/elua/elua.git synced 2025-01-08 20:56:17 +08:00
Code Issues Projects Releases Wiki Activity

Fix typos

Browse Source
This commit is contained in:
Martin Guy 2011-07-19 18:05:33 +02:00
parent 1730329faf
commit 2e2bcba26e
5 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/eluadoc/refman_ps_str9_pio.lua
View File

@ -10,7 +10,7 @@ data_en =
menu_name = "pio",
-- Overview
overview = [[This module contains functions for accesing the particular features of the PIO subsystem of the STR9 family of CPUs. This subsystem is very flexible, allowing things like
overview = [[This module contains functions for accessing the particular features of the PIO subsystem of the STR9 family of CPUs. This subsystem is very flexible, allowing things like
configurable output types (push-pull or open collector), multiple alternate functions for the PIO pins, and others. For a full description of the STR9 PIO module check the STR9 CPU
Reference manual, available from ST at @http://www.st.com/mcu/devicedocs-STR912FAW44-101.html@this address@. Note that this module is a supplement of the platform independent
@refman_gen_pio.html@pio@ module, not a replacement. Use this module only for setting up the STR9 PIO pins, and the @refman_gen_pio.html@pio@ module for all the other PIO related operations.]],

2
doc/eluadoc/refman_ps_str9_rtc.lua
View File

@ -10,7 +10,7 @@ data_en =
menu_name = "rtc",
-- Overview
overview = [[This module contains functions for accesing the particular features of the RTC - Real Time Clock - subsystem of the STR9 family of CPUs.
overview = [[This module contains functions for accessing the particular features of the RTC - Real Time Clock - subsystem of the STR9 family of CPUs.
This internal subsystem offers functions to keep track of a real time clock calendar, as well as some other features like alarms and auxiliar functions.
Reference manual, available from ST at @http://www.st.com/mcu/devicedocs-STR912FAW44-101.html@this address@.]],

2
doc/en/arch_platform.html
View File

@ -9,7 +9,7 @@ $$HEADER$$
0, PORTB will have 1 and so on. Similarly, the second SPI interface (SPI1) of the MCU will probably have an id equal to 1. However, this is not a strict
rule. The implementation of the platform interface might choose to expose only some of the peripherals (components) of the MCU, thus this rule might be
broken. For example, if a board has 3 UARTs, but for some reason the second UART (UART1) is dedicated and can't be touched by <b>eLua</b>, then UART0 will have the id 0 and UART2 will
have the id 1, so UART1 won't ever be accesible to the code. </p>
have the id 1, so UART1 won't ever be accessible to the code. </p>
<p>With some exceptions (most notably the low-level support functions), the different modules supported by the platform interface are
mirrored more or less accurately in separate Lua modules that can be used directly from <b>eLua</b>. Check the reference manual for a
complete description of these modules.</p>

2
doc/en/filesystems.html
View File

@ -5,7 +5,7 @@ $$HEADER$$
<li><b>the ROM file system</b>: a very simple, very low footprint read-only file system that can be included in the <b>eLua</b> binary image. Check <a href="arch_romfs.html">here</a> for details.</li>
<li><b>the FAT file system</b>: a read-write FAT file system implementation (platform independent) that can currently be used with SD/MMC memory cards. Check <a href="fatfs.html">here</a> for
details. <b>(new in 0.7)</b></li>
<li><b>the remote file system (RFS)</b>: a read-write file system that allows eLua to 'share' a directory on a PC, effectively accesing
<li><b>the remote file system (RFS)</b>: a read-write file system that allows eLua to 'share' a directory on a PC, effectively accessing
its contents as if it was a local file system. Check <a href="arch_rfs.html">here</a> for details. <b>(new in 0.8)</b></li>
</ul>
$$FOOTER$$

2
doc/pt/arch_platform.html
View File

@ -9,7 +9,7 @@ $$HEADER$$
0, PORTB will have 1 and so on. Similarly, the second SPI interface (SPI1) of the MCU will probably have an id equal to 1. However, this is not a strict
rule. The implementation of the platform interface might choose to expose only some of the peripherals (components) of the MCU, thus this rule might be
broken. For example, if a board has 3 UARTs, but for some reason the second UART (UART1) is dedicated and can't be touched by <b>eLua</b>, then UART0 will have the id 0 and UART2 will
have the id 1, so UART1 won't ever be accesible to the code.</p>
have the id 1, so UART1 won't ever be accessible to the code.</p>
<p>With some exceptions (most notably the low-level support functions), the different modules supported by the platform interface are
mirrored more or less accurately in separate Lua modules that can be used directly from <b>eLua</b>. Check <a href="refman_gen.html">the reference manual</a> for a
complete description of these modules.</p>