Issue with High Z state

[L10N37]

I tried my hardest not to lodge an issue but this is killing me. I've had these 32pin mini nano style boards for about a year now and they've being of no use on my arduino projects. Everywhere I read says 99% compatible drop in replacement.

Ok, so for some reason, my modchip only works with Nano 328P clones and not 168P, even though only memory should differ between these. Maybe it's the same reason as this not working? I did have plenty of 328P clones and simply switched... but I ran out a long time ago and the prices sky rocketed .

I need to toggle an IO pin between high Z and then back to an output to pull a line low very, very rapidly. 4 miliseconds between the string of bits.

With this board connected, it won't high Z.. Its just killing the consoles (PS1) ability to read discs altogether. I've checked the drive lid sensor pin and, that's ok. I used a process of elimination and I know it's only the pin used to inject these bits (well in high impedance state the console makes the 1's on its own) causing the issue.

I've tried D12 (standard on all versions) and moved to D7.

same deal I should be able to have this connected as a high impedance input (meant to be similar to 10mohm Of resistance at the input pin) and have it not affect the console what ever. Especially since there's a feature to disable the chip altogether by High Z'ing this pin, and that's not working either.

chip disable mode, broken chip actually do it's job , broken

it's the same on the octrobot ones

As for another project, everything works bar SPI stuff to detect controller inputs

[L10N37]

as for the 128P, I'm running low.. but these work perfectly for PSXTAL

[L10N37]

Excuse the typos, and bad punctuation etc my eyes are blurry from the work light, it's 2am and my thumbs are fat :P

[LaZsolt]

Hi Lion!

Try to switch this problematic pin to input state instead of high Z. If you switch a pin to input then this pin's impedance become high. Maybe this will work.

[LaZsolt]

@L10N37

As for another project, everything works bar SPI stuff to detect controller inputs

The LGT8FxP and the ATmega SPI interface is very different so you must use this lgt8f package's SPI library. #include "SPI.h"

[LaZsolt]

On the othe hand I think your problem is not with the high Z state, but with the timing. In the package v1.0.6 the delayMicroseconds() delaying about 30% less than expected. Install the v1.0.7 pre release: https://github.com/dbuezas/lgt8fx/discussions/207 This package contain a lot of corrections.

[L10N37]

High Z / input. same thing. When I refer to High Z this is the same as making the pin an input. As an input, it should be in a high impedance state and not affect what it's connected to.

Timing is absolutely crucial on this, had my logic analyser not started playing up I could delve further in, but at the moment that would be pointless anyway as I know what the issue is by simply connecting / disconnecting the data pin.

[L10N37]

My god, I finally found a fix - but it's not ideal. It should help you with the debug. As long as I don't have the data line connected at boot, it will work.

So i put a switch on the data line, I power the console on, then wait a few seconds, then flick the switch and connect the data line, Voila. I am also using your package for v.1.0.7 but this was probably just a timing thing.

This has driven me absolutely nuts since getting the batches of 168P and the TT-GO-ZI ones and the purple nano style QFP32 LGT's! Now, let me think of what is happening and how can i correct this in software!

[L10N37]

OK, fixed the main issue by moving a delay prior to pin set up. Now I just need to fix the ~7/8 khz not coming out of clock pin D10 which I used a calculator for. It's not outputting this frequency.

[L10N37]

You shouldn't need power.avr in the prime number test sketch. You can use

define F_CPU 32000000UL

And adjust that

[LaZsolt]

Did you know this code generator for timers? https://dbuezas.github.io/arduino-web-timers

[L10N37]

I have being using RTM timer calculator, i have finished making my chip work with this MCU :D I used your release. Thanks. I am about to upload it.

For note, RTM timer calculator you want approx. half the value you are aiming for.

[L10N37]

https://github.com/L10N37/tehUberChip_Another_PSX_Modchip/tree/main/LGT8F328P_PU20_PU22_PU23

Thanks again.

[dwillmore]

I think the previous link is dead because the code got altered a bit. This seems to be the correct link: https://github.com/L10N37/tehUberChip_Another_PSX_Modchip/tree/main/LGT8F328P_PU22_PU23_NTSC-PM41

It's unclear if this bug still exists from L10N37's last comment.

[L10N37]

I've stopped working blind since posting this. I've got a nice scope, replaced my logic analyser that wasn't working around this time. I always code with signal captures now. The code relies heavily on precision delays and this library needs delayMicroseconds of 5150 which is == 4ms.

ive finalised the project with a new library and it's called UberNee.

Anything not relying on delays is fine with this library, but for obvious reasons I'm now just using the one in mention on that repo.

[LaZsolt]

Anything not relying on delays is fine with this library

In the earlier releases of this package the delayMicroseconds() was bad in timing. If you wanted to delay 4000 microseconds then you had to be set 5333. But happens 4 interrupts for measuring millis() in 4000 microsecond, so execution delays of interrupts must be taken out thats why you got the valuse 5150.

Now to reach 4ms delay you need give parameter 3863 approximately for delayMicroseconds() when using the current (2.0.0) release. (By taking account of the 4 interrupts execution time.)

[L10N37]

Hi LaZsolt, you are credited in my flashing guide for UberNee. I use your alpha release from last May off memory. as of a few weeks back it hadn't being updated. Delays are accurate in that.

I use 3970 microsecond delay for bit widths and get exactly 4ms on my scope :)

[dwillmore]

Is it normal to have to compensate for the time the IRQ takes in calculating delay values? For example, is the normal Arduino Atmel library like this?

[LaZsolt]

@L10N37 So no LGT8Fx issue, I will close it.

@dwillmore

Is it normal to have to compensate for the time the IRQ takes in calculating delay values?

This is not an LGT8Fx issue, I will close it.