[elektro] STM32L1 - gcc - -O2,3

uprogc . uprogc at gmail.com
Thu Feb 9 09:17:47 CET 2017


Szia.

Van egy driver.c es driver.h, a .h-ban van a struktura tipus definialva,
.c-ben a info_ublox_u27_get_http_response es a tobbi valtozo letrehozva.
Itt vannak a hozza tartozo fuggvenyek is.

Ugyanezzel a tipussal [mas valtozo] dolgozik meg nehany fuggveny. A tobbi
fuggveny is egy struktura cimevel ter vissza.

Ezen a valtozon: info_ublox_u27_get_http_response csak ez az egyetlen
fuggveny dolgozik, es a pointert [  state_read_content_info_p ] sem
modositja semmi, a cimzett strukturat sem, ezek az adatok csak olvasva
vannak:

if( ret != STATE_END )
{
    state_read_content_info_p = ublox_u27_get_http_response( ); //@NOTE non
blocking state machine
    ret = state_read_content_info_p->ret; //@NOTE struct address error with
-O1,2,3 !
}
else if( ret == STATE_END )
{
  .....
}

Udv.
Szabi

On Thu, Feb 9, 2017 at 9:52 AM, SZIGETI Szabolcs <szigiszabolcs at gmail.com>
wrote:

> Hali!
>
> A info_ublox_u27_get_http_response -t ki és hol definiálja?
>
> Szabolcs
>
>
> 2017. február 7. 17:49 uprogc . írta, <uprogc at gmail.com>:
>
> > ui:
> >
> > Meg annyit hogy a struktura mezoi mind enum tipusuak, negy mezo egyforma
> ,
> > egy mezo pedig egy masik enum tipusu.
> >
> > 2017-02-07 18:47 GMT+02:00 uprogc . <uprogc at gmail.com>:
> >
> > > Valamit elkever mar a fuggvenyben. Van a strukturanak egy .ret mezoje,
> ez
> > > enum tipusu. Ez be van allitva STATE_END-re a fuggvenyben.
> > > Amikor visszater a fv. struktura cimevel, akkor ki kellene a ->ret-et
> > > ertekelni es kilepni a hivasbol [ non blocking state machine a fuggveny
> > > felepitese ] de ekkor mar a pointer cime sem a strukturara mutat es
> > nyilvan
> > > a ->ret erteke sem jo.
> > >
> > > Banalisan egyszeru kodreszletrol van szo, ezert is fura.
> > >
> > > Udv.
> > > Szabi
> > >
> > > 2017-02-07 18:43 GMT+02:00 uprogc . <uprogc at gmail.com>:
> > >
> > >> Nincs IT hasznalva ezzel kapcsolatosan. Mainbol loopbol hivodik.
> > >>
> > >> Udv.
> > >> Szabi
> > >>
> > >> On Tue, Feb 7, 2017 at 6:37 PM, Bali Zoltan <eltexto at freemail.hu>
> > wrote:
> > >>
> > >>> volatile-ek rendben?
> > >>>
> > >>> Üdv.  Zoli
> > >>>
> > >>>
> > >>> 2017.02.07. 17:29 keltezéssel, uprogc . írta:
> > >>>
> > >>>> Azt hiszem ugy van a stack es a heap config hogy a megmaradt RAMot
> > >>>> hasznalja erre a celra, de lehet hogy tevedek.
> > >>>>
> > >>>> Amugy meg van RAM boven szabadon,
> > >>>> Es -O0 optimalizacioval tokeletesen mukodik.
> > >>>>
> > >>>> Udv.
> > >>>> Szabi
> > >>>>
> > >>>> On Tue, Feb 7, 2017 at 5:47 PM, Lajos Rancz <lajos.rancz at gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>> Hi!
> > >>>>>
> > >>>>> Nem lehet stack vagy heap atiras?
> > >>>>>
> > >>>>> Udv
> > >>>>>
> > >>>>> 2017. febr. 7. 14:37 ezt írta ("uprogc ." <uprogc at gmail.com>):
> > >>>>>
> > >>>>> Nem,
> > >>>>>>
> > >>>>>> Valamit elkever. ha strukturaval terek vissza akkor sem jok a
> mezok
> > >>>>>> ertekei.
> > >>>>>>
> > >>>>>> Ugyanezzel az enummal es strukturaval, pontosan ezzel a modszerrel
> > >>>>>> tobb
> > >>>>>> masik non-blocking state machine mukodik a projektben.
> > >>>>>> Megneztem a map-ben hogy hol van a pointer es a struktura cime,
> > nem-e
> > >>>>>>
> > >>>>> irja
> > >>>>>
> > >>>>>> felul valami, de nem talaltam ilyesmire utalo nyomot.
> > >>>>>>
> > >>>>>> Udv.
> > >>>>>> Szabi
> > >>>>>>
> > >>>>>> On Tue, Feb 7, 2017 at 3:31 PM, Bakcsa Zoltán <bakcsa at gmail.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>> Sikerült rájönni a hiba okára?
> > >>>>>>>
> > >>>>>>> Üdv:
> > >>>>>>> Zoli
> > >>>>>>>
> > >>>>>>> On Mon, Feb 6, 2017 at 12:27 PM, uprogc . <uprogc at gmail.com>
> > wrote:
> > >>>>>>>
> > >>>>>>> ui:
> > >>>>>>>>
> > >>>>>>>> ublox_u27_init_states_t    egy enum{} 0-tol,....
> > >>>>>>>> state_info_t    egy struktura.
> > >>>>>>>> -----------------------------------------
> > >>>>>>>>            elektro[-flame|-etc]
> > >>>>>>>>
> > >>>>>>>> -----------------------------------------
> > >>>>>>>            elektro[-flame|-etc]
> > >>>>>>>
> > >>>>>> -----------------------------------------
> > >>>>>>            elektro[-flame|-etc]
> > >>>>>>
> > >>>>> -----------------------------------------
> > >>>>>            elektro[-flame|-etc]
> > >>>>>
> > >>>>> -----------------------------------------
> > >>>>            elektro[-flame|-etc]
> > >>>>
> > >>>
> > >>>
> > >>> -----------------------------------------
> > >>>          elektro[-flame|-etc]
> > >>>
> > >>
> > >>
> > >
> > -----------------------------------------
> >           elektro[-flame|-etc]
> >
> -----------------------------------------
>           elektro[-flame|-etc]
>


More information about the Elektro mailing list