6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Sep 21, 2024 1:16 am

All times are UTC




Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Sat Jul 27, 2024 9:20 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 843
Location: Potsdam, DE
Apart from the 'full' system I showed the 3-d of recently, I've just this morning deleted a lot of it to make a more breadboardable minimal version - the pico should carry the same code in both cases.

A single 32kB ram - because that's what's in the bits box - is mirrored in both halves of the memory space, with a couple of K excluded from 7800-7bff (f800-fbff) to talk to the whole two addresses available on the pico. There is no IO other than via the pico, so testing this might be fun, but that's what breadboards are for.

Attachment:
6502_pico_minimal-Processor and memory.pdf [324 KiB]
Downloaded 24 times


It's raining, so it might get built this morning...

Neil


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Thu Sep 05, 2024 7:38 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 843
Location: Potsdam, DE
So, a minor problem with the simplistic keyboard code: any noise on the clock line offsets the shift register so that subsequent keystrokes are incorrect. I think I need to implement a timeout that resets the bit counter after a millisecond or so (need to measure the timings)...

I think that rather than using the PIO (I don't yet know how much is going to be required for the bus interface) I'll do the same interrupt on falling pin edge that I used with the original Nucleo code; that way I can easily hook a timer to it (or even the system clock microsecond clock: if it's too long since the last interrupt, discard any data and start again).

Beyond that: a simplified prototype is built but not populated beyond the pico at present. There is as yet untested code to IPL the system code for the 65c02, but as that code is basically $4c $00 $02 it's not immediately going to do a lot :mrgreen:

Neil


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Thu Sep 05, 2024 1:13 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8390
Location: Midwestern USA
barnacle wrote:
There is as yet untested code to IPL the system code for the 65c02, but as that code is basically $4c $00 $02 it's not immediately going to do a lot :mrgreen:

Well, there will be a lot of JuMPin’ goin’ on!  :D

Attachment:
ape_at_window.gif
ape_at_window.gif [ 1.98 MiB | Viewed 161 times ]

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Thu Sep 05, 2024 1:38 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 843
Location: Potsdam, DE
:mrgreen:

Well the change to use interrupts instead of the PIO for the keyboard worked, once I worked out the obscure error messages from the compiler. The code resets the bit counter and value (a) if the bit count is 11 and has been read, or (b) if it's more than 160us (nominal cycle time is 80us, so two clocks) since the last interrupt. Doesn't seem to make any change to keyboard use, and I haven't observed it dropping into insanity as it previously did.

We shall see. It overflows in 2^32 microseconds... about 1.2 hours. So that might give a glitch, but then it will correct.

Neil


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Thu Sep 05, 2024 2:13 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1107
Location: Albuquerque NM USA
160uS sounds about right. I used 31khz VGA interrupts to sample PS2. If PS2 clock is high longer than 6 ticks, I reset the state machine. So that’s about 180us.


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Thu Sep 05, 2024 3:14 pm 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 843
Location: Potsdam, DE
Yeah, I got the scope on it and looked for the generic length of the clock pulse, and the period between adjacent pulse trains (in keypresses with multiple sequences).


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Fri Sep 06, 2024 7:26 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 843
Location: Potsdam, DE
As an aside: the new RP2350 has some serious bugs in the IO relating to accidental latchup. Some of this is documented, some is still being investigated, but it looks rather as if new silicon is required. It seems an external IP supplier didn't get the IO pins quite right...

So at the moment, I'm staying clear of that part - though it is in theory a drop-in replacement for both hardware and software for the RP2040.

Neil


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Fri Sep 06, 2024 7:41 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
What I hear is that this concern is overblown - there will be a detailed errata, and most people won't be affected.

That's no great consolation for those few who are, of course.

As I understand it, the problem relates to use of the internal pull-downs. As most designs would use pull-ups, if anything, they won't be affected.


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Fri Sep 06, 2024 7:49 am 
Offline

Joined: Mon Jan 19, 2004 12:49 pm
Posts: 843
Location: Potsdam, DE
I have read that externally applied voltages can cause the issue, too. Wait and see, perhaps?

But it may well be that if pull-up/downs are not required, you're fine.


Last edited by barnacle on Fri Sep 06, 2024 7:50 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Fri Sep 06, 2024 7:50 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
yes we certainly need the facts!


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Fri Sep 06, 2024 1:56 pm 
Offline

Joined: Tue Nov 10, 2015 5:46 am
Posts: 228
Location: Kent, UK
barnacle wrote:
As an aside: the new RP2350 has some serious bugs in the IO relating to accidental latchup. Some of this is documented, some is still being investigated, but it looks rather as if new silicon is required. It seems an external IP supplier didn't get the IO pins quite right...
It happens, and it's frustrating. My company's currently-shipping ASIC had a SPI controller's chip-select signal's polarity inverted at the pad. We chose to just work-around it by using a spare GPIO (not a big deal as it's our ASIC on our boards). So the hardware team had to blue-wire the ASIC bring-up boards, and modify the schematics for the production boards (which wouldn't be released to manufacturing until after bring-up).

It was a screw up by our vendor... From over 1000 pins, different I/O standards, SERDES, clocks... One little error on one of the slowest pins... Irritating, but not worth a spin. Been shipping those boards for two years now.


Top
 Profile  
Reply with quote  
 Post subject: Re: PICO vga/uart/ps/2
PostPosted: Fri Sep 06, 2024 4:48 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10938
Location: England
As of mid afternoon UK time, today (Friday) there's an updated 2350 datasheet with the following erratum (summary being, simple workarounds possible if indeed the application is vulnerable):

Quote:
Reference: RP2350-E9

Summary: Increased leakage current on Bank 0 GPIO when pad input is enabled

Affects: RP2350 A2

Description:

For GPIO pads 0 through 47:
Increased leakage current when Bank 0 GPIO pads are configured as inputs and the pad is somewhere between VIL and VIH (the undefined logic region).
When the pad is set as an input (input enable is enabled and output enable is disabled) and the voltage on the pad is within the undefined logic region, the leakage current exceeds the standard specified IIN leakage level. During this condition the pad can source current (the exact amount is dependent on the chip itself and the exact pad voltage, but typically around 120μA). This leakage will hold the pad at around 2.2 V as that is the effective source voltage of the leakage, and can only be overcome with a suitably low impedance driver / pull.
Note that the pad pull-down (if enabled) is significantly weaker than the leakage current in this state and therefore is not strong enough to pull the pad voltage low.
Driving / pulling the pad input low with a low impedance source of 8.2 kΩ or less will overcome the erroneous leakage and drive the voltage below the level where the leakage current occurrs, so in this case if the pad is driven / pulled low it will stay low.
The erroneous leakage only occurs (and continues to occur) when the pad input enable is enabled; disabling the input enable will reset (remove) the leakage.
The pad pull-up still works. If enabled it will pull the pad to IOVDD as it will pull the input voltage out of the problematic range.
...
In detail, this issue presents under the following conditions, for any GPIO 0 through 47:
1. The voltage on the pad is in the undefined logic region.
2. Input buffer is enabled in GPIO0.IE
3. Output buffer is disabled (e.g. selecting the NULL GPIO function)
4. Isolation is clear in GPIO0.ISO, or the previous were true at the point isolation was set
When all of the above conditions are met, the input leakage of the pad may exceed the specification.
This issue may affect a number of common circuits:
• Relying on floating pins to have a low leakage current
• Relying on the internal pull-down resistor
If the internal pull-up is enabled then any floating signal will be pulled high thus removing increased leakage condition as the excess leakage is only sourcing current. This of course can’t prevent the increased leakage if the pad is fed via a strong source e.g. strong potential divider.
Note that this does not affect the pull-down behaviour of the pads immediately following a PoR or RUN reset, because the input enable field is initially clear. The pull-down resistor functions normally in this state.
This issue does not affect the QSPI pads, which use a different pad macro without the faulty circuitry.
The USB PHY’s pins are also unaffected.
This issue does also affect the SWD pads, which use the same fault-tolerant pad macro as the Bank 0 GPIOs. However, both SWD pads are pull-up by default, so there is no ill effect.

Workaround:

If pad pull-down behaviour is required, clear the pad input enable in GPIO0.IE (for GPIOs 0 through 47) to ensure that the pad pull-down resistor pulls the pad signal low. To read the state of a pad pulled-down GPIO from software, enable the input buffer by setting GPIO0.IE immediately before reading, and then redisable immediately afterwards. Note that if the pad is already a logic-0, re-enabling the input does not disturb the pull-down state.
Alternatively an external pull-down of 8.2 kΩ or less can be used.
Note that PIO programs can’t toggle pad controls and therefore external pulls may be required, depending on your application.
As normal, if ADC channels are being used on a pin, clear the relevant GPIO input enable as stated in Section 12.4.3.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 20 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: