*** tpb has joined #timvideos | 00:00 | |
*** sab_123 has joined #timvideos | 00:51 | |
sab_123 | mithro, I have one question. I understand that UART needs code in the ISR because it has no clock. But since MPSSE allows only master mode, can I have all my I2C routines running on a main while() loop instead of an ISR? Otherwise code wise the ISR will become extremely long | 00:53 |
---|---|---|
*** springermac_ has joined #timvideos | 00:56 | |
*** springermac is now known as Guest91071 | 00:56 | |
*** springermac_ is now known as springermac | 00:56 | |
*** Guest91071 has quit IRC | 00:57 | |
mithro | sab_123: If your ISR routines are more then a couple of instructions you are doing something wrong | 02:45 |
sab_123 | mithro, I decided not to use the ISR for I2C | 02:46 |
mithro | sab_123: you should be using the ISR for doing the actual shifting | 02:46 |
sab_123 | mithro, I have tried that out | 02:47 |
sab_123 | mithro, it becomes pretty complex | 02:47 |
sab_123 | I need to have about 10 states | 02:47 |
mithro | sab_123: then you are doing something wrong | 02:47 |
sab_123 | mithro, the problem is this. If you plan to shift data out in the ISR, then you need to have data ready in the buffer. Different I2C devices have different number of bytes which need to be sent as address. For example the eeprom that I am working on has a 3 byte address | 02:48 |
sab_123 | mithro, not only this you need to change the state also in the ISR | 02:48 |
sab_123 | mithro, my second attempt | 02:49 |
mithro | sab_123: your ISR shouldn't understand I2C, it should be a simple shifter | 02:49 |
sab_123 | mithro, take a look at this | 02:49 |
sab_123 | please note code isnt formatted | 02:50 |
sab_123 | I am redoing the architecture now fully | 02:50 |
sab_123 | because I believe using the ISR is not a good way to proceed( I may be wrong here) | 02:50 |
mithro | sab_123: I'm not looking at any code which isn't formatted | 02:51 |
sab_123 | :-) | 02:51 |
mithro | sab_123: no seriously, if you aren't formatting your code correctly then you are wasting a huge amount of time | 02:53 |
sab_123 | mithro, http://pastebin.com/aWzAYRTZ | 02:54 |
tpb | Title: [C] if ( my_i2c_states == start ) { //Send the start bit. Need to sen - Pastebin.com (at pastebin.com) | 02:54 |
mithro | sab_123: formatting is broken | 02:54 |
sab_123 | mithro, I ran it through astyle | 02:54 |
sab_123 | Which line is broken | 02:55 |
mithro | Look at line 39 and below | 02:59 |
sab_123 | mithro, I did that | 02:59 |
sab_123 | It makes it easier to understand where the jumps are | 02:59 |
sab_123 | in asm there is no bracket | 03:00 |
sab_123 | so i was getting confused as to where the jumps end | 03:00 |
sab_123 | If you need to shift bits out in ISR, then you need to shift bits in also in the same ISR for the read part | 03:01 |
sab_123 | Then you need to put these into a buffer | 03:01 |
sab_123 | do you want me to proceed like that? | 03:02 |
sab_123 | Have a read and write block in ISR, once it is done put it into the buffer and have states which the ISR sets to understand what the data is? | 03:02 |
mithro | sab_123: As I mentioned above the ISR should be something as simple was "rotate BUF, mov C->Y, mov Z->C, rotate BUF" | 03:05 |
mithro | sab_123: then your other code should put the right data into BUF | 03:06 |
mithro | sab_123: maybe you want BUF to be double buffered | 03:06 |
sab_123 | mithro, I should have atleast a CJNE to know if it is write or read | 03:07 |
sab_123 | a counter to count | 03:07 |
sab_123 | both in ISR | 03:07 |
sab_123 | It adds up pretty quickly | 03:07 |
mithro | sab_123: not really, the ISR just shouldn't be running when there is nothing to shift in/out | 03:07 |
sab_123 | it needs a count to know how many bits have been shifted out correct? | 03:08 |
sab_123 | Anyway I will give it another try and write it again | 03:08 |
mithro | sab_123: and like literally the above are the ASM commands | 03:08 |
sab_123 | Line 58-76 | 03:09 |
sab_123 | Line 80-97 | 03:10 |
sab_123 | Inside ISR | 03:10 |
sab_123 | mithro, I will try to make it shorter | 03:11 |
sab_123 | and then commit and ping you back | 03:11 |
mithro | sab_123: As I said, the ISR should *not* understand I2C, it is simply something which shifts data in/out | 03:12 |
sab_123 | understood | 03:12 |
mithro | sab_123: If your ISR is longer then 8 ASM instructions, you are doing something wrong | 03:12 |
sab_123 | 8 cycles is going to be pretty hard to achive | 03:15 |
sab_123 | achieve | 03:15 |
sab_123 | I will give it a shot | 03:15 |
mithro | sab_123: I think you can do it in 5 | 03:15 |
sab_123 | Shift + toggle SCL yes | 03:15 |
sab_123 | but how does ISR know read/write | 03:16 |
sab_123 | so CJNE 3 | 03:16 |
sab_123 | But CJNE with what? You need to do a mov to do CJNE | 03:16 |
sab_123 | So thats another 2 cycles | 03:16 |
sab_123 | typically you also want to store the ACK/NAK | 03:17 |
mithro | sab_123: the ISR you setup to be called is different depend on read, read/write or write | 03:17 |
sab_123 | oh | 03:18 |
sab_123 | There are only 3 timer ISR's | 03:18 |
sab_123 | Timer 0 is being used | 03:18 |
sab_123 | for UART | 03:18 |
sab_123 | Timer 1 is also being used for callbacks | 03:18 |
sab_123 | I can use Timer 2 for 1 | 03:18 |
mithro | sab_123: patch the jump instruction | 03:19 |
sab_123 | I did not understand | 03:19 |
mithro | sab_123: when the interrupt is called, the code jumps to a given location in memory | 03:20 |
sab_123 | yes | 03:20 |
mithro | sab_123: that location in memory will be a jump instruction to your ISR routine | 03:20 |
sab_123 | Yes | 03:20 |
mithro | sab_123: so if you change the contents of that location in memory you will jump to a different ISR routine | 03:20 |
sab_123 | https://github.com/RacingTornado/fx2lib_serial_uart/blob/master/lib/usbav.a51 | 03:22 |
tpb | Title: fx2lib_serial_uart/usbav.a51 at master · RacingTornado/fx2lib_serial_uart · GitHub (at github.com) | 03:22 |
mithro | sab_123: or make the jump instruction a computed jump based on another value | 03:22 |
sab_123 | well jump cycles arent free either | 03:22 |
mithro | sab_123: yes? | 03:22 |
sab_123 | AJMP is 3 cycles | 03:24 |
sab_123 | LJMP 4 | 03:24 |
mithro | sab_123: sure | 03:24 |
sab_123 | so its going to add up pretty quickly right | 03:24 |
sab_123 | CJNE is 4 too | 03:25 |
sab_123 | so a CJNE+MOV to jump is 6 cycles | 03:25 |
sab_123 | Then about 5 for shifting | 03:25 |
sab_123 | maybe 11 cycles | 03:25 |
mithro | sab_123: I'm pretty sure I said 8 ASM instructions, not 8 cycles | 03:25 |
sab_123 | Ah | 03:25 |
sab_123 | :-) | 03:25 |
sab_123 | My bad | 03:26 |
sab_123 | Another thing we arent thinking of is the ACK/NAK bit | 03:26 |
sab_123 | If you want to store in an extra buffer | 03:26 |
sab_123 | it is the 9th bit | 03:26 |
mithro | sab_123: the ACK/NAK bit is higher level | 03:26 |
sab_123 | So 8 bits isnt enough | 03:26 |
sab_123 | for shifting | 03:27 |
mithro | sab_123: How many times do I have to repeat that the ISR knows nothing about I2C? | 03:27 |
sab_123 | I completely agree | 03:27 |
sab_123 | I dont deny it | 03:27 |
mithro | sab_123: The I2C code will just have to load the ACK/NAK bit into the buffer and cause one more shift to occur | 03:27 |
sab_123 | What I am trying to say is shifting happens on an unsigned char | 03:28 |
sab_123 | This is 8 bits long | 03:28 |
sab_123 | If you try to shift the ACk/NAK into the same buffer | 03:28 |
sab_123 | There is going to be an overrun | 03:28 |
sab_123 | We need extra logic within the ISR to handle this | 03:28 |
mithro | sab_123: no you don't | 03:29 |
mithro | sab_123: 9 bits can be divided into 8 bits and 1 bit | 03:29 |
mithro | sab_123: so you do your 8 bits, then you update the ISR, then you do your final bit, then you update the ISR | 03:30 |
sab_123 | ok | 03:31 |
mithro | sab_123: think of it like this way, how would you write I2C support if you had 8 bit shift register? | 03:32 |
sab_123 | I understand what you are saying. | 03:32 |
sab_123 | I just think we will end up with a couple of more instruction cycles | 03:32 |
sab_123 | Let me give it a 3rd try | 03:33 |
sab_123 | :-) | 03:33 |
sab_123 | like for example | 03:34 |
sab_123 | We will have to signal ISR has finished trasmitting the 8 bits | 03:34 |
sab_123 | or receiving the 8 bits | 03:34 |
sab_123 | So the main cal clear or read out the current buffer and put in a new one | 03:35 |
mithro | sab_123: I might give you that one - but I'm not confident it is needed yet | 03:35 |
sab_123 | mithro, okay let me get started then | 03:36 |
*** Bertl_oO is now known as Bertl_zZ | 04:40 | |
mithro | sab_123: lots of comments on your pull request | 05:09 |
sab_123 | mithro, okay | 05:10 |
*** CarlFK has quit IRC | 05:14 | |
sab_123 | mithro, just one things | 05:19 |
sab_123 | thing | 05:19 |
sab_123 | Regarding testing | 05:19 |
sab_123 | The information is on the pull request comment | 05:19 |
sab_123 | mithro, in the features section | 05:20 |
mithro | sab_123: No it isn't, there isn't a set of instructions like "Do X, Do Y, See result Z, Do A, See result B" | 05:20 |
sab_123 | Ah, okay | 05:21 |
sab_123 | Most of what you said can be cleaned up | 05:21 |
sab_123 | mithro, will ping you once it is done | 05:22 |
*** CarlFK has joined #timvideos | 05:22 | |
*** ChanServ sets mode: +v CarlFK | 05:22 | |
sab_123 | mithro, is it okay if I combine the timer based UART and fast uart | 05:55 |
sab_123 | fastuart is only 1 function | 05:55 |
mithro | sab_123: then it should be a really simple pull request | 05:55 |
sab_123 | mithro, yes | 05:55 |
mithro | and I'll be able to press "Merge" after like 30 seconds of looking at it | 05:55 |
sab_123 | :-) | 05:55 |
mithro | which is good for everyone | 05:55 |
sab_123 | well I am adding a lot of code | 05:55 |
sab_123 | for timerbased uart | 05:56 |
sab_123 | it is tested | 05:56 |
sab_123 | both work together. I thought I needed to combine them and send it in | 05:56 |
mithro | sab_123: you want a pull request to be the *smallest* amount of changes that get the effect you are after | 05:56 |
sab_123 | So you want me to add fast_uart first? | 05:57 |
sab_123 | Thats basically like 20 - 30 lines | 05:57 |
sab_123 | I will do that then | 05:58 |
*** se6astian|away is now known as se6astian | 06:44 | |
*** aom has joined #timvideos | 07:12 | |
*** panther has joined #timvideos | 07:54 | |
*** sab_123 has quit IRC | 07:54 | |
*** panther is now known as sab_123 | 08:13 | |
sab_123 | mithro, still working on it. Modifying the makefile seems to give me memory overlap errors for the DSCR_AREA, so still trying to find the issue | 08:13 |
*** se6astian is now known as se6astian|away | 09:27 | |
sab_123 | mithro, sent it in | 10:09 |
mithro | _florent_: ping? | 10:45 |
*** Bertl_zZ is now known as Bertl | 11:00 | |
mithro | sab_123: why are you opening and closing so many pull requests? | 11:01 |
mithro | sab_123: you can see what ends up in a pull request before you click the button | 11:13 |
sab_123 | mithro, I realized that now | 11:13 |
sab_123 | mithro, its just that going back is kind of hard because I have so many things added | 11:14 |
sab_123 | mithro, I am going to get back to I2C now | 11:15 |
sab_123 | :-) | 11:15 |
mithro | sab_123: remember you should be writing small independent modular chunks that can be added together | 11:19 |
sab_123 | mithro, I agree | 11:20 |
mithro | sab_123: that should be easy to send pull requests for each small part then | 11:20 |
sab_123 | mithro, I wanted to test how they work together | 11:21 |
mithro | sab_123: sure, that should be additional work on the of the small parts | 11:22 |
sab_123 | ok | 11:22 |
mithro | if you made your modular bits correctly, they shouldn't have to change at all to test them together | 11:24 |
sab_123 | ok | 11:26 |
mithro | sab_123: you should aim to try and get stuff reviewed as early as you can | 11:29 |
sab_123 | mithro, okay | 11:29 |
*** se6astian|away is now known as se6astian | 11:49 | |
*** panther_ has joined #timvideos | 12:16 | |
*** sab_123 has quit IRC | 12:16 | |
*** Bertl is now known as Bertl_oO | 12:28 | |
*** ssk1328 has joined #timvideos | 13:50 | |
*** panther_ has quit IRC | 15:45 | |
*** ssk1328 has quit IRC | 16:24 | |
*** se6astian is now known as se6astian|away | 16:41 | |
*** ssk1328 has joined #timvideos | 17:37 | |
*** se6astian|away is now known as se6astian | 19:22 | |
*** ssk1328 has quit IRC | 20:44 | |
*** thaytan_ has joined #timvideos | 20:57 | |
*** thaytan has quit IRC | 21:00 | |
*** se6astian is now known as se6astian|away | 21:37 | |
*** springermac_ has joined #timvideos | 22:35 | |
*** springermac is now known as Guest12700 | 22:35 | |
*** springermac_ is now known as springermac | 22:36 | |
*** Guest12700 has quit IRC | 22:38 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!