{"head":"eeab1025e2cb5b761fc4bab642317179b9164bda","size":17,"push_id":45030140,"shas":[["22f08c454d65eb25832f73103d965659641dc207","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Fix markup in PWM documentation","Martin Guy"],["5d5443d67e3d1bca29a4a1b17c90c190beacd4d7","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Implement STOP and repeated START condition setup times from I2C spec.\n\nThe code for the bitbanger, taken from wikipedia, in turn taken from\nhttp://www.nctutwt.net/wiki/doku.php?id=wiki:summer2010:i2c\ndoes a STOP condition by raising SCL and immediately raising SDA, but\nin the I2C spec, there is a minimum STOP setup time of 4ms between these\ntransitions (I2C spec, doc UM10204, table 6/figure 27, pp.37-38).\n\nSimilarly, a repeated START has a setup time of minimum 4.7us between\nSCL going high and SDA going low, which the code did not contain.\n\nThis patch inserts these delays to conform better to the I2C spec,\neven though all tested devices \"seemed to work\" without them.","Martin Guy"],["30b4f7a6dd3b67c37f55f859bfcff38ef64f4a16","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Insert setup delay for repeated START condition (missed from last commit)","Martin Guy"],["f6783e40cefa370adf1d58ef94583f2a6c924b30","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Add math.floor() and math.ceil() identity functions to integral mathlib\n\nIn integer math, floor() and ceil() give the same value, but\nhaving them included in the integer library as functions that return\ntheir argument allows you more easily to write code that works unchanged\nin both integer and floating point versions of Lua.","Martin Guy"],["99f696451c87be41c6888e05768eb9fcf268fce7","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Add BUILD_LUA_INT_HANDLERS to Mizar32 default build","Martin Guy"],["a05c209ab2e14e7879f8f5f49064f5b87fa7367e","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Remove documentation for non-existent str9.rtc module","Martin Guy"],["f048bece4bd21810b6766e9ccbe3406e59062626","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Change LCD I2C slave addresses to 7C-7F\n\nThe old slave addresses, F2, F3, F6, F7 are reserved for 10-bit\nI2C addressing.  This changes them to values that are least likely\nto conflist with other devices: 7C-7F are registered to two LCD display\ndevices.","Martin Guy"],["a9c7041af7adc32bb30d12b33b83cd7cc0845eec","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Use new hard reset command to reset LCD module.\n\nWe just changed LCD command 0 from a no-op to a speciall-recognized\nhardware reset. This is essential because the LCD controller's reset line\nis not connected to the AVR32's reset line, so if the AVR32 is reset,\nthe LCD is left in an unknown, possible unusable, state.","Martin Guy"],["2c7d3a37437d4e87530dd6ea3db80f8641ced450","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","Increase LCD I2C bus frequency to fit with new LCD module firmware.\n\nThe new firmware can run at up to 68kHz, so increase the I2C bus speed\nto 60000Hz","Martin Guy"],["121a70b8b11ebab38964ac92d0ff4b46b374e814","1707e15e9766e69023bc0cd1bc9fd9dbf96ce96d@gmail.com","New firmware works with no delays and max speed of 50000Hz\n\nThe new LCD firmware doesn't need the caller to wait after each command:\nit stretches the clock instead. Actually, it works at 68kHz too, but\nthere is a non-working range from 55 to 66kHz.\nWe set it to 50000Hz to have reliable operation and allow for clock drift.","Martin Guy"],["60d62078b7048e1f5f59f95dbaaa63e180749362","9474f3f1273a481bc9896148565277359222fee4@gmail.com","Remove separate dependency step from Lua build system\n\nThe separate dependency generation step from the Lua build system\nwas not needed, now the dependencies are generated at the same time\nas the object files.","Bogdan Marinescu"],["8839e93c16ded79e06d8a980752cc2f7e3bcc119","9474f3f1273a481bc9896148565277359222fee4@gmail.com","Merge branch 'master' of github.com:elua/elua","Bogdan Marinescu"],["fa335c481e972e38e7267f2997ed062d9e1ff957","bfc95e50f828f0aecd632c939fd45c1bf5272127@dearriba.com","lc-switch.h has typo in head protection macros\n\nAnother think: the LC-SWITCH.C has this two lines that are wrong:\n\nOf course its a typo on the second one.\n\nhttp://article.gmane.org/gmane.network.uip.user/15","Pablo Cossutta"],["2d484e1eadf3fe7c5feba43800745eca3b20ad75","da2ea5bee82302925a2874f529684e980c179d70@harbaum.org","Fix missing UDP stats for sent/received packets\n\ni just saw that the stats taking in uip is missing entries for udp\nreceive and\ntransmit.\n\nTo fix this insert a UIP_STAT after the udp_found label:\n\n udp_found:\n +  UIP_STAT(++uip_stat.udp.recv);\n\n And a UIP_STAT before the goto ip_send_nolen instruction:\n\n +  UIP_STAT(++uip_stat.udp.sent);\n   goto ip_send_nolen;","Till Harbaum"],["7fbfc2c229faa471c48eb75e4216d6261f705861","ec831e33fb459bda7dc8930e1ab2edaa44c33777@colorado.edu","UDP packet data pointed at wrong location\n\nI have been working on implementing a port to the atmel\nATMega128 and I have noticed that sending UDP packets does not\nwork (the transferred data is always 0).\n\nA look into the code reveals that in uip.c, the address of\nuip_appdata gets set incorrectly.\n\nSomewhere around line 1159 the code needs to be changed:\n\n--- uip_appdata = &uip_buf[UIP_LLH_LEN + UIP_IPTCPH_LEN];\n+++ uip_appdata = &uip_buf[UIP_LLH_LEN + UIP_IPUDPH_LEN];\n\nhttp://article.gmane.org/gmane.network.uip.user/68","Jack Elston"],["c388c3f3b30e762e148819f946df75de09947218","e3579b1e47f273529f0f929453e939a68ede9fd1@aeruder.net","TCP polling code can send stale/duplicate data\n\nHere's the content of the patch (so it can be more easily\ndiscussed if need be).  What basically happens is uip_len and\nuip_slen never get reset to 0 when calling the poll handler.\nHere's an example of how things go wrong:\n\nLet's say you get some new incoming data (uip_newdata()), your\napplication handler processes the new data and sends something\nout (thus setting uip_slen).  Back in the main loop again, you\npoll a connection.  uip_slen is still set from the last send and\nif your poll handler doesn't send out something new, uip ends up\njust sending out the exact same data on the now polled\nconnection.  In every other applicable case, uip_len and\nuip_slen get reset, but for whatever reason this one just got\nmissed...\n\nhttp://article.gmane.org/gmane.network.uip.user/1312","Andrew Ruder"],["eeab1025e2cb5b761fc4bab642317179b9164bda","d8e08eeaf716f6ef9206fbae6b411b2d84f6bf0b@cs.rwth-aachen.de","Lost SYNACK causes connection reset\n\n==================\nFrom: Raimondas Sasnauskas <raimondas.sasnauskas@cs.rwth-aachen.de>\nDate: Sun, Sep 20, 2009 at 1:29 PM\nSubject: Re: RE: Re: RE: Re: Re: RE: Bug (?) in uip TCP/IP stack: lost SYNACK causes connection reset\n\nOK, here I'm proposing the following patch (see git diff attached).\n\nAgain the problem we face here is the subsequent SYN arriving in\nUIP_SYN_RCVD state after the SYNACK packet was lost.  First, to avoid\nother issues,  suggest to reset any _active_ connection where a SYN\narrives in a state != UIP_SYN_RCVD.\n\n==================\n\nThis is a combination of the patch submitted by Raimondas Sasnauskas and\nthe patch applied by Oliver Schmidt to Contiki\n\n===================\nOriginal bug report\n===================\n\n From: Raimondas Sasnauskas\n       <raimondas.sasnauskas@cs.rwth-aachen.de>\n Subject: Bug (?) in uip TCP/IP stack: lost SYNACK causes\n          connection reset\n Date: 2009-09-02 19:07:51 GMT\n\n Hi all,\n\n I've found the following issue in the TCP (UIP_ACTIVE_OPEN)\n connection establishment phase leading to connection failure.\n This happens whe the SYNACK packet gets lost during the TCP\n 3-way handshake.\n\n Client: SYN\n Server: SYNACK (this packet gets lost)\n Client: SYN (retransmission)\n Server: ACK (<-- server thinks it's data?)\n Client: RESET (correct, no SYNACK received yet)\n Server: ABORT (got reset, aborting connection)\n\n I do not have a patch/workaround yet, but I think that\n correctly handling incoming TCP_SYN packets in UIP_SYN_RCVD\n state would fix this issue.\n\n http://article.gmane.org/gmane.network.uip.user/1506","Raimondas Sasnauskas"]],"ref":"refs/heads/master"}