tlogic

im on 3.7 too i don't mind helping out either.

__________________
http://i34.tinypic.com/2hnz9t2.gif

Pimped

Me as well, I can't take out time to go through the coding, so I'm available to help on testing mate. PM me when you need me

__________________
Wars come and go but my soldiers stay eternal

jasperconran

anyone know where i can find stunt guys faq pld..?

Satch

This what your after jasper Here

jasperconran

that is it cheers, ive looked all over and its under my nose

grooster

After reading hbc's post earlier I read around elsewhere and found this but still can't workout if this is anything to do with the problem.
* CLK

The actual frequency, delivered by the interface device on CLK, is designated either by fi the initial frequency during the answer to reset, or by fs the subsequent frequency during subsequent transmission.

Duty cycle for asynchronous operations shall be between 45% and 55% of the period during stable operation. Care shall be taken when switching frequencies (from fi to fs) to ensure that no pulse is shorter than 45% of the shorter period.


Edit:
After reading more and looking at the difference between the working rst code and the non working code is the problem around the fact that the funcards stack is being loaded and not cleared therefore the stb can't send info due to the "floating posotive" method of comunicating. if either stb or card is at zero that is seen.

Could anyone say if I'm on the right line with this.

madbrumie

your kind of right! what u have to think about is how the card recieves info and sends it, also the same from the box. so box sends something the card has to reply, then go low so the box can send more info and back to card again. remeber the box has good control over its send/recieve data but the card has to be programmed by us to work in the same way as a mosc/tit etc would. think cycles, that will help a great deal in this, as u know its timing!

MB

hnj

heres an idea i got:

http://www.digitalworldz.co.uk/22199...d-fix-way.html

hope it goes through well!

hnj

__________________
IF I HAVE HELPED YOU HIT REPUTATION BUTTON!

cg010169

perfer this way, as then I don't have to rely on others. Im enjoying the learning process with this all and over the past view weeks have took alot on board.

Few questions

have been reading and read, on some other forums as well, that there is more than one way to skin a cat when it comes to fixing the issue. Some are using different method but getting the same result. that is how it has became confusing as you hear different things and then get lost.

how i am seeing it so far ( took from another forum but puts it more clearly than i would with my brain like cheese today)

3.7 is a lot tighter on the command responses from the card (it will reset the card if incorrect or corrupt responses are recieved)

We have a timing issue with the fun/atmega cards which make them fail but MOSC/TIT/OPUS cards still work.

After start up the data is sent to the card following the ISO 7816 std which im sure has been stated means that the serial data is available on the input pin for 32 clock (or instruction) cycles. The data line is held high when no data is being sent, a start bit (data line pulled low) is sent before each byte of data and there is a wait or guard time between each byte of data sent.

MOSC/TIT/OPUS card use a UART to handle the serial data comms to/from the IRD (Which means the software can ignore the handling of the comms data as the UART will tell the card it has data to be recieved)

The fun/atmega don't have a UART to recieve the data so have to try to emulate that function is software. (It uses a timer to interrupt the main software at regular intervals to check for a start bit/data)

So if the values used by the timer or the code used to check for the data use to little or to many clock cycles maybe we miss the start bit and start reading the data in the wrong place or not at all.


with that I am thinkin that this code is wrong

RX_IRD: sbis IO_PIN, IO_PIN_IRD ; wait for RX to go high = line idle
rjmp RX_IRD

As the start bit should be low instead, so would be this so that the start bit is detected

RX_IRD:sbis IO_PORT, IO_PIN_IRD


any info would be helpful, while my brain has a rest for a while

__________________

TBC

It would appear then that there is a bit timing error which was always there, logically if this worked prior to this update then you have to assume some kind of phase discrepency in the i/o routines. If the request was previosly resent when there was a failure with out cardwide reset then stands to reason eventually the comms would work. Thus this card was working on 3.6 then not on 3.7!

I assume card operations are structured around this area so the card is doing something useful between bit times? Would explain simply enough why there have been a few ways of getting it working!!

What with whats in this thread and stuff i read in other places this has got to be an easy fix

BTW i have deduced this from the post above and some other posts out there, i still no nothing about funcards at all