🚀 go-pugleaf

On Sun, 2 Sep 2001 22:35:05 +0200, Bart.Vanhauwaert@nowhere.be wrote:

>a183824 <erno@freegates.be> wrote:
>> Als C-newbie heb ik vooral problemen met de syntax van C (ik ga nog
>> altijd op assembly-niveau kijken wat 'm er van bakt om te weten of de
>> C-code juist is).
>> Een van de varianten die -net als de andere- niet goed werkt:
>
>>           TypePointer += *((INT8U*) ((&TypFixSize) + type)));
>
>TypePointer = (INT8U*)(&TypFixSize) + type;
>
>(Ik veronderstel dat die += een = moet zijn)

1. char is in mijn geval wel degelijk byte, 8-bit.  Ik heb ondertussen
een oplossing maar ga toch de tips verder bekijken (alvast iedereen
bedankt).  Hier zie je direct mijn probleem: ik ben assembly gewoon,
en daar pass je de pointer en maakt het geen ** uit waarnaar je point.
Ik erger me dus vaak aan het - overigens terechte- feit dat de
compiler dit allemaal controlleerd.  Ik raak het maar moeizaam gewoon
dat iets over mijn schouder ligt te loeren terwijl ik datzelfde iets
soms vrij slecht kan duidelijk maken wat ik wil hebben.
Btw: de processor is uit de FFMCS 16LX familie, de manuals zijn
vertaald door een aziaat.  Dus "Frame" staat daar letterlijk als
"Flame".  Verder blinkt de manual uit door fouten en -het ergst-
onvolledigheid.  Dat terwijl het een prachtige chip is (ik heb tot nu
altijd Motorola MC68xxx de superieure CISK gevonden, maar aangaande
peripherals en code vind ik dit nog stukken beter.  Enige nadeel is
dat het user/system model geen hardware-protectie omvat).

2. Neen, het is wel degelijk += als bedoeling.  Volgende code werkt,
en ik zou eigenlijk wel eens willen weten of dit op andere platforms
ook zo is:

  INT16U c;
  INT16U d;

          c = (INT16U) &TypFixSize;
/* Zet de pointer van "descriptor-lengte"-tabel om naar int */

          c += type;
/* Tel hierbij  type-nummer op als byte */

          d = * (INT8U*) c;
/* Lees de byte-geheugeninhoud, bepaald door de waarde van c.  Dit
lijkt me nogal walgelijke omschrijving, maar het werkt perfect */

          TypePointer += d;
/* En tel dat bij op de pointer */

Mooie is: de compiler blijkt snugger genoeg om te zien dat de
variabelen c en d verder niet gebruikt worden, en verwerkt ze dan ook
direct in de gegenereerde code (iets minder optimaal dan directe
assembly, maar aanvaardbaar).  Daarbij is het raar dat het in 1
statement (dus zonder gebruik van c en d) het niet meer juist
compileert, zelfs niet met een batterij "parentheses".  In 1 regel
geplaatst wordt de waarde van type als een address genomen, verlaagd
met een constante waarvan ik niet weet waarom de compiler die
genereerd en hoe hij bij die 16-bit offset (-$57AF) komt.

Volgende is ongeveer een voorstelling (hoop dat het goed overkomt):
+--------------------------------------------------------------------------+
| 16-byte mask (werkt als enable voor de pointer |
|  die naar descriptor wijst)                                    |
+--------------------------------------------------------------------------+
       |     Pointer                            
       |      /   \      +--------------------------------+
        `--> |  +  ---> | ???-bytes descriptor |
              \__/    +--------------------------------+
                ^         /                    
                |        /       +---------------------------------+

                |         |---->  | Hardware pin /          |
                |         |        |         alternate option |

                |         |       +----------------------------------+

                |         \ 
                |           \   |----------------------------------+
                |            -> | - Descriptor lengte.    |
                |                | - De benodigde RAM | \
                |                |       voor pin-beheer   |  |
                |               +----------------------------------+ |
                \__________________________/


- De lengte van de descriptor zit in Flash: daarvan heb ik heel wat
meer ter beschikking, dus dat stoort niet.  Die lengte moet bijgeteld
op de pointer waarmee ik door die tabel wijs.  Ook de RAM size wordt
aanvaardbaar laag gehouden (typical 2-4bytes/pin).
- De pin-descriptor (???-bytes) en 16-byte mask zitten in externe
EEPROM: die is zeer beperkt in opslagruimte,  vandaar variable in
functie van de descriptor zelf.  Er zijn eigenlijk twee zulke
tabellen: die voor het main-board zit nl ook nog in de Flash.
=> In de nabije toekomst komen er nog 192 externe I/O's bij, dus wordt
het behoorlijk drummen in EEPROM.  Aangezien er nu al voor 256 pins
plaats gereserveerd is, en er nog 192 kunnen bijkomen, zou het maken
van een NOP-type mij al (256 + 192) * 2(bytes) = ~900 bytes EEPROM
kosten.  Dat op zich kan nog, maar omwille van access-snelheid
(seriele EEPROM) moet ik dat hele zootje in RAM copieren en bijhouden.
En 900 bytes RAM kan ik echt niet missen (dat is inclusief stack area
10% van het geheel).

Wat gebeurt er:
- Lees het mask.  0 geeft aan dat er geen descriptor is: een unused
I/O pin kost mij dus 1 bit.
- Als het bit 1 leest, wordt de descriptor gelezen.  Het eerste word
geeft pin-type en kanaalnummer weer.
  Dan volgt set-up data specifiek voor de pin-type, maar de eerste
keer wordt enkel gezocht naar het hoogste kanaalnummer om de
RAM-pointers voor het beheerssysteem te kunnen bereken.  Die extra
data moet ik dus kunnen overslaan.  Het aantal kanalen per pin-type is
variabel (in functie van een opsteekprintplaat waarvan het grootste
gedeelte ooit nog ontworpen moet worden.  Wat we wel zeker weten is
dat bij die printen 95% van de pin-types al bekend zijn).
- De RAM kan gealloceerd eens gekend is hoeveel kanalen er zijn per
type: #kanalen * (size_per_kanaal_voor_dit_type).
  Er is een abort als pin-types gemeld worden die niet door het O.S.
herkend worden (dan is OS flash nodig).   
Een semi-dynamische RAM-allocatie start.  C-libraries worden immers
niet ingelinked omdat er geen plaats is.  Het betreft pointers die
opgezet worden, en bij verandering (een insteekprint verander je niet
zo vaak) worden alle geheugenblokken verschoven op de nieuwe situatie
(met inbegrip van aanpassen v.d. pointers).
- De interne script-taal werkt op virtuele I/O, (bijna) nooit op
fysieke (tenzij het omwille v.d. snelheid niet anders kan).  Vb: een
UART-interrupt handler is altijd in Flash-code beschikbaar.  Wordt de
UART optie niet gebruikt, stelt de intialiser die in op het gewenste
(andere) pin-type.  De UART-interrupt blijft disabled en bijgevolg is
deze driver automatisch uitgeschakeld.  Het programma is dus een heel
gedoe, want de micro- controller heeft zes seriele I/O's, 2 PPG's, 2
D/A en 8 A/D ingangen,...  Elke alternatieve hardware-optie moet
  dus door de initialiser gekend zijn, elke interrupt-handler moet in
Flash code aanwezig zijn, zelfs als je 'm niet nodig hebt voor de
actuele opsteekprint.  En dan moet al die zooi nog eens correct
gekoppeld aan de script.
- Regelmatig worden de discriptortabellen afgescanned en I/O met RAM
ge-update.  Enkel in gevallen zoals seriele poorten, wordt de handling
direct overgenomen door de IRQ-handler.  Descriptor data die snel
toegankelijk moet zijn, wordt dan via aparte pointer of data-duplicaat
rechtstreeks accessed (dus niet relatief gezocht in de gehele tabel),
want de hardware pinnummer v.d. UART zit ergens rond #32.
- Eigenlijk is e.e.a. vergelijkbaar met het lezen van bijvoorbeeld een
word-document: je weet vooraf gewoon niet wat er in staat.   En je
dient dus alle troep (zoals onderlijnen, ...) op het moment zelf te
detecteren.  Stel dat je die info moet overslaan omdat ze op dat
moment niet op het scherm komt.  Overslaan is sneller dan het virtueel
op te bouwen en dan te discarden.  
Opm: enige probleem is dat ik geen enkele C-lib kan inlinken: daar is
geen geheugen voor vrij.  Het moet dus met de C-basis.