I started to look at this. It’s not that simple. pysim requires pcscd, which requires a CCID-complient driver. I’ve installed pysim/pcscd/pcsc-tools and the CCID test library. I believe pcscd needs a driver config file (and needs to be running).
Still digging into it…
I’m going to have to start up the debugger. Here is what I have so far.
I created a reader.conf file that has
FRIENDLYNAME "BusPirate"
DEVICENAME /dev/ttyACM1
LIBPATH /usr/lib/pcsc/drivers/serial/libccidtwin.so
CHANNELID 2
I started pcscd in debug mode and there are some errors:
trace.txt (4.3 KB)
(That’s all for today)
I need to hack together a card reader but
./pySim-shell.py --device /dev/buspirate --baud 9600 should do a direct serial interface to a phoenix type reader. I still am happy to be proved wrong.
That was the first thing I tried. But I ended up with
EXCEPTION of type 'NoCardError' occurred with message:
pySIM-shell (no card)>
Here’s the full output
output.txt (3.0 KB)
Half duplex bridge mode:
The latest formal build (forum topic) is 3 days old so I assume this is not in there. And I cannot work out which branch in git it is in.
I have validated my solder together interface and can see the AWR (Awake to reset ) packet but the build in the forum thread does not have the bridge command and the macro m(1) does not work.
Found the correct branch an built it - test_file_updates_2
Had to tweak pySim.
It was using RTS the wrong way.
So added this in pySm-shell.py at 1006
sl = init_reader(opts, proactive_handler = Proact(), rst=‘+rts’) # -rts +rts -dtr +dtr
Also stopped reading atr after part 2
lawrence@dell7520:~/git/pysim$ ./pySim-shell.py -d /dev/buspirate-text -b 9600
No reader/driver specified; falling back to default (Serial reader)
Using reader serial:/dev/buspirate-text
Waiting for card…
+rts 0
atr1.1 0x3b,0x9f,0x95,0x80
atr2.1 0x3b,0x9f,0x95,0x80,0x1f,0x47,0x80,0x31,0xe0,0x73,0xfe,0x21,0x13,0x57,0x4a,0x33,0x5,0x2c,0x32
I had to terminate early as getting garbage afterwards, even with pullups enabled. pySim detects end of atr when it times out waiting for another character…
Good news the concept of using pySim over buspirate appears valid.
RTS works.
Ah! I was using the main branch.
I’m not getting the same thing. I made the changes, but I must have missed a step.
I’m using UART mode, W 3.3, P (pull-ups on)
HDPLXUART uses a clock (G). I tried with and without.
UART bridge mode on
I also tried HDPLXUART bridge mode
I never see “+rts 0”
My apologies, I put some print statements in my copy of pysim in the serial init. So I could see what was happening. I am AFK at present but I can drop my copy of transport/serial into here later. My target this morning was being able to the I initial card message. Will update thread later, there are options in pysim for debug logging.
You can also add debug=True to the init_card call.
I have yet to work out whether I can upload a python file to the forum.
in pysim/transport/serial.py
I added some print statements.
The main useful one for now is
print(“atr1.1”, “,”.join( hex(b) for b in self._atr) )
for i in range(0, t0 & 0xf):
b = self._rx_byte()
self._atr.append(ord(b))
self._dbg_print("Historical = %x" % ord(b))
print("atr2.1", ",".join( hex(b) for b in self._atr) )
in function _reset_card.
I also added a second reset just in case, smartcard spec wants a reset low for minimum time as part of card initialisation before going low again on which case the atr is sent. Note atr is sent whilst rst is low.
.
rst_meth(rst_val)
time.sleep(1.1) # 100 ms
rst_meth(rst_val ^ 1)
rst_meth(rst_val)
print(self._rst_pin, " ", rst_val )
time.sleep(0.1) # 100 ms
self._sl.flushInput()
rst_meth(rst_val ^ 1)
Rad little project, how can I best support ya and order one of these? Just got in the BP Rev10 and learning as fast as I can. 
I’ve been duplicating the tests Ian describes and reporting any problems I encounter. I started with the Tutorials and Device Demos to teach myself how to use the BP. And later on some of the new things Ian has added.
But it depends on your skillset. Some are adding features into the source.
I’m still having trouble. I don’t know what I am doing wrong.
HDPLXUART> bridge
UART bridge. Press Bus Pirate button to exit.Waiting for card...
��
Vout: 3.29
And when I do
This is what happens.
+rts 0
Card initialization (serial:/dev/buspirate-text) failed with an exception:
---------------------8<---------------------
Traceback (most recent call last):
[TRUNCATED]
File "/home/grymoire/.local/lib/python3.10/site-packages/serial/serialposix.py", line 595, in read
raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
---------------------8<---------------------
(you may still try to recover from this manually by using the 'equip' command.)
it should also be noted that some readers may behave strangely when no card
is inserted.)
In addition, when I press the button, nothing happens.
Silly question do you still have minicom or similar connected to the buspirate?
My current state of play is that I am getting extra characters back from the interface.
To try and identify the problem I connected another serial port to the data pin of the buspirate/smartcard so I could see whether there was extra data on the downstream side or whether the data was appearing elsewhere.
The result was that on the smartcard pin I saw just the ATR sequence,
This was putty at 9600/serail with just the data in to the laptop connected.
3b 9f 95 80 1f 47 80 31 e0 73 fe 21 13 57 4a 33 05 2c 32 34 00 3d
From pySim-shell connecting to /dev/buspirate-text my additional print statements gave me the initial ATR and then started returning extra data.
atr2.1
0x3b,0x9f,0x95,0x80,0x1f,0x47,0x80,0x31,0xe0,0x73,0xfe,0x21,0x13,0x57,0x4a, 0x33,0x5,0x2c,0x32
Extra: 34
Extra: 0
Extra: 3d
Extra: 1b
Extra: 37
Extra: 1b
Extra: 5b
Extra: 3f
And on and on.
Looks like it is time to start digging further, possible sources either the python library pyserial has issues, pySim use of the serial library or buspirate is sending some garbage.
@ian I think I have identified the problem of trying to use pySim-shell. and bridge mode
I believe in bridge mode the buspirate is still outputing the updates to the status area on the terminal screen. On a periodic basis.
This would not be a problem if using the terminal as your interface but having configured the buspirate and then attaching something else to the text serial port this is just noise.
UPDATE: I added to hsplxuart.c before line 42/43
system_config.terminal_ansi_statusbar_pause = true;
Depending how you see bridge mode being used, is it intended to be a totally transparent (or is that opaque) once entered, with the buspirate getting off the connection? I know I suggested on another thread that maybe bridge mode should link the binary interface (/dev/buspirate-binary).
Thoughts?
In the meantime if of use to anyone else I have a minimal python program that opens the buspirate and configures it. Save it and change the file extension, you will need pyserial
bp-sim.txt (1.3 KB)
Good point. I had disconnected and reconnected my BP (which terminates my tio program), and instead of ACM0/ACM1 it was grabbing ACM1/ACM2. I bet it was because I had also had pySim-shell running and f it.orgot about
Anyhow - I’m still having problems. I started BP in half-duplex mode, set voltage to 3.3 and executed bridge.
pySimshell says
File “/home/grymoire/.local/lib/python3.10/site-packages/serial/serialposix.py”, line 595, in read
raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
EXCEPTION of type ‘SerialException’ occurred with message: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
pySIM-shell (no card)> equip
So I terminated my tio process with Control-T q to disconnect. Now I get
File “/home/grymoire/Git/pysim/pySim/transport/serial.py”, line 109, in reset_card
raise ProtocolError()
pySim.exceptions.ProtocolError
EXCEPTION of type ‘ProtocolError’ occurred with message:
pySIM-shell (no card)>
Is it possible I implemented RTS backwards?
Sorry, it should have been obvious to me about the toolbar injecting periodic garbage. I’m not sure the best way to handle that. Sometimes it could be a straight terminal, like talking to eg a router. Others (for half duplex especially) is probably going to be like a de-facto binary mode. The toolbar can be disabled from the config menu, but that’s not intuitive. How about adding a flag to the bridge command to specifically “KEEP THE TOOLBAR ON”, with the default behavior turning it off.
Hey @gristleking ! Welcome to the forum. We ran a test production this weekend to check the footprints. It’s untested though. I can send you one of those, I’ll PM for your address. They will probably be generally available end of next week.
Sorry everyone, I feel like I dropped the ball on this one. We were in production of four boards over the weekend and it was a hard bring-up.
The bridge is now on main where it should have been 
Sorry for the confusion.
Both UART bridge commands now support a -t option to explicitly NOT disable the toolbar.
Both CTS and RTS signals are active low.
It looks like a bug on my side, RTS is active low. Fixed that.
