News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_PulkoMandy

Albireo - USB/SD/Serial interface for CPC

Started by PulkoMandy, 15:54, 18 October 15

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

CloudStrife

I really don't think it's on the PC side, 0xFF are correctly transmitted (if we don't make mistake on the measure after the usb->serial adapter), but it can be on the CPC, maybe I am really an idiot and make an horrible mistake, or I am a bit less idiot and don't correctly understand a strange mode of the serial controller :)

For the workaround, the problem is not the serial speed... But the Z80 speed... You need at least 5 more NOP per octet to do the test...
For the current simple I use it mean going from a theoretical 45.4ko/s to 37ko/s. But it's make some optimization more difficult: one of my idea was to do burst transfer from the FIFO, still doesn't know if it's really work but the theoretical speed was something around 8µs per octet... So 5 more is a lot AND because you don't get the same number of serial read and memory write it's make the code around a bit more complex.

And for me the worst part... It's mean we need to do specific protocol for the Albireo :/ Really does'nt like the idea :(

TFM

Ok, let's prohibit &FF in CPC world.  ;D


Seriously, best is sometimes to leave it for a couple of days and then (later) return to it. Sometime one is to close to the bug to see it. At least it helped me couple of times.  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

I am helping CloudStrife as much as I can, but my simple 2-channel oscilloscope is a bit limited. The 0xFF looks correct to me (I see only a start bit at 0V, and then the line stays high for some time), but I could have missed something. I'll run some more tests until I can be sure.


Except for this issue, if there are other problems on some boards, I can replace them. I hope it will not be the case. I tested the software I had before sending the boards, but for the first few ones I didn't have the serial port testing in place yet. This is only 4 lines on the PCB but they are between the two chips with very small pins, which makes it a bit difficult to fix and even see problems.

gerald

Quote from: PulkoMandy on 10:33, 25 September 16
I am helping CloudStrife as much as I can, but my simple 2-channel oscilloscope is a bit limited. The 0xFF looks correct to me (I see only a start bit at 0V, and then the line stays high for some time), but I could have missed something. I'll run some more tests until I can be sure.
What is the reference clock for sender and receiver ?
Can you compare the low level timing of both side sending a 0xFF. If the timing is different, you may have a clock precision/configuration problem.

PulkoMandy

The reference clock is generated by the FT231X. It uses a 48MHz clock internally for both the USB and serial sides. It outputs a 24MHz clock to the TL16C550D which further divides it to generate its baudrate clock. It also outputs a 12MHz version to the chip handling the USB-host things, but that should not be relevant here.


The baudrate generators on either side are similar. At 115200 bauds, they should both be set to divide-by-13 if I get my math right (24MHz/16/115200). The exact value is 13.020833... so the FTDI fractional divider should not be used (it can do 1/4 or 1/8 precision only, so 13 is the closest it can do).


The fact that they share the same clock source means they should run in exact sync. That was the point of putting the FTDI chip directly on the board instead of using a TTL-level serial port output or adding in a MAX232.


The problem could be a different choice of dividers in either side. I don't know what windows and linux drivers for the FTDI chip are doing, and I don't know what CloudStrife code is doing either. But, all other chars seem to pass properly, so I'm surprised to see a problem.


I was also wondering if adding an extra parity byte for even parity could help. That would force a 0 bit to be sent after the 0xFF, maybe helping things to synchronize at the low-level side (and provide a little mode error detection, at least). But it will also reduce the transfer speed by 10%.

gerald

Both using the same clock may be part of the problem.
When it's said that the 0xFF is not reliable, what is the missing rate ? Is it from FT to TL, TL to FT or both ?
The 0xFF case is quite specific as you only have a start bit. If the start bit from the FT is too short, it my just be ignored by the TL (which surely has input filtering).

PulkoMandy

#356
The missing rate is close to 100% when sending a random string of characters. The presence of a 0xFF tends to corrupt the next char as well (but that may be a software problem). when sending only 0xFF bytes, I think about half of them get through on my setup, but I'll have to check to make sure.


This happens from FT to TL (PC to CPC), we have not tested the other way yet as the test program on CPC can only send what you type on the keyboard and there is no key that sends 0xFF.


The start bit looked about right, with the limited precision of my scope. But right, if both chips run on exactly the same clock, and with slightly different dividers, that could explain it (and yes, there is some input filtering but I didn't find any docs on how many times the input is sampled before making a decision).


I measured the start bit (and other bits) at 8.4us (but that's not a very precise measurement with my analogue scope). That would be a baudrate of 119047 instead of 115200, so, quite a bit off the mark. But I'd think it's a problem with the way I'm doing the measurement, as it would be surprising for FTDI's drivers to be this far off? I have also tried to set a custom baudrate of 110000 bauds, and RealTerm crashed  :D

TFM

Quote from: PulkoMandy on 12:42, 25 September 16
This happens from FT to TL (PC to CPC), we have not tested the other way yet as the test program on CPC can only send what you type on the keyboard and there is no key that sends 0xFF.

Add the BASIC line:[nb]Sorry for that[/nb]

key 0,chr$(255)

Now pressing the F0 key will create &FF
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

CloudStrife

@TFM Yep, not complicate, just that does'nt made the test yet, I initially concentrate on the PC->CPC side and verification of my reception code. My apartment make difficult to have a permanent setup of my CPC, so can't do quick test, so I need to take a full afternoon on it if I want to do something interesting.
(by the way, I am pretty sure that your line will work, all my softs use the system or are compatible with it)

For information I made my tests at 1.5Mbaud, 115200 baud and as slow as 9600 baud... with the same results each time...

TFM

Ok, one super stupid idea from my side... telling already sorry about it... but... could it help to hook up two CPCs with two Albireo cards and let them communicate? The reason would be to check if the error is still there, then it's a problem of the Albireo. If not it may be a timing problem or a PC problem.


Anybody our there having two Albireo cards set up?
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

You can't do that, because the USB conversion is made directly on the Albireo board. So you have two USB devices, and there are no way to plug them together (only plug them to a computer which is an USB host).


We have reproduced the problem on two completely different setups: my computers and CloudStrife's ones. The OS changes (I used Windows for this test, he used Linux), the Albireo board changes (serial mnumbers 18 and 19), the USB cable changes, everything changes. But the results are the same.


So, it's either a design error on the board, or a bug in the test program.

TFM

Or a timing error, because the PC hardware (both the same in your setups) has different timings. I know nothing about USB, but is there a chance to alter some kind of "configuration"? (Just try to help).  :)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

PulkoMandy

The strictly USB side is fine (I think). The problematic signals are on the Albireo board. It is setup like this:


PC <--USB-->FT231X<--RS232-->TL16C550D<--EXP port-->CPC


The USB protocol has pleinty of checksums and modern features, so if the problem was there, the OS would loudly complain. Also, the FT231X is handling this, is used in many other products without any problems.

The expansion port, well, we all know how it works  :laugh:.

This leaves us with the "RS232" serial link between the two chips on the albireo board. It is possible to set the baudrate on both side (the PC can set the FT231X baud rate, and the CPC can set the TL16C550D). The timings look "about correct" (that's the best I can do with my tools), which means the 0xFF byte got through the USB link and is being sent on the RS232 wires.

Also, I tried the "key 0" redefinition, but it doesn't work. Entering the test program (both with load and call) resets the key to sending "0".

Prodatron

First test of the new Albireo USB mouse driver in SymbOS CPC  :D


https://www.youtube.com/watch?v=2kIjcEHsflI

It's nearly fully working including the mouse wheel, there is only sometimes an issue with the mouse buttons, which I try to fix now. Currently you need a simple USB mouse, I couldn't activate my gaming mouses with the Albireo in general yet. Maybe we have to init them in another way.
Maybe it's possible to have a public beta release of SymbOS CPC 3.0 tomorrow or monday with Albireo and M4Board support :)

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

robcfg


CraigsBar

Quote from: Prodatron on 17:02, 08 October 16
First test of the new Albireo USB mouse driver in SymbOS CPC  :D


https://www.youtube.com/watch?v=2kIjcEHsflI

It's nearly fully working including the mouse wheel, there is only sometimes an issue with the mouse buttons, which I try to fix now. Currently you need a simple USB mouse, I couldn't activate my gaming mouses with the Albireo in general yet. Maybe we have to init them in another way.
Maybe it's possible to have a public beta release of SymbOS CPC 3.0 tomorrow or monday with Albireo and M4Board support :)
Hell yeah! This Monday will feature..... New games, jean michel jarre, new symbos and I am collecting a retro haul containing a speccy +3 and an N64.
IRC:  #Retro4All on Freenode

PulkoMandy

Ok, so after Prodatron implemented the mouse with some actual use besides my little demo program, he noticed that something wasn't working quite right, often mouse clicks would be missed.


I made some research on WCH forums (WCH is the chinese manufacturer of the main USB chip on the Albireo). And I found the explanation there after some Google Translate and experimentations to confirm my understanding of translated chinese.


Anyway, the important part is that I understood and fixed the problem, and before I forget about it again, I wrote a detailed write-up of how this all works. If you are interested in adding support for USB mouses in your programs (Imperial Mah Jong? Perfect Pix? OCP Art Studio? IMPDraw?), here are the instructions for writing a simple mouse driver: http://pulko.mandy.pagesperso-orange.fr/shinra/albireo.shtml#heading_toc_j_35

It gives you an idea how simple USB can be. It opens some other possibilities as well: MIDI keyboards and other devices, gamepads, webcams, printers...

Of course I'm available if you need help and support with this.

Prodatron

Fantastic news!! Thanks so much for your researches, I will implement it as soon as possible! :)

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

CraigsBar

IRC:  #Retro4All on Freenode

HAL6128

@PulkoMandy ...do you still produce the Albireo boards?
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

PulkoMandy

Yes, but I have stopped assembling them until we can figure out the problems with the serial port, as I'm still not sure if there is an hardware problem there.
If people are not interested in the serial port and only want USB and SD card, I can ship boards with non-working serial ports, but I'd prefer getting them completely working.

CraigsBar

Will there be an chargeable upgrade 'upgrade' service once the problem is fixed? Presumably any PCB changes will incur costs to you.
IRC:  #Retro4All on Freenode

PulkoMandy

Yes, if we find out that PCB changes are indeed required, I will provide information about how to patch the boards (if possible), and patch/replace the existing boards. As usual, my problem with building too many boards at once to save costs and not writing enough software to test them...


We'll see, at this point it is also quite possible that the problem is on the software side. I've shipped a board to Gerald as he probably has better tools than me to investigate the problem. Now that the HID mouse is working well, I will also try to write my own test software to see if I get different results (as there is currently only one implementation of the driver, it's hard to tell wether there is an hardware problem, or if it's only software).


Note that this only affects the serial link with PC - as far as I know, the USB and SD ports are working without any problems on all shipped boards. And even if the problems ends up being in the hardware design, there may be software workarounds for it - I need to experiment a little and see what I can come up with.

Prodatron

The Albireo USB mouse driver is now 100% working in SymbOS including the buttons! :) (at least with the mouse I am using)
Thanks again, PulkoMandy! I will update the preview package soon!

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

PulkoMandy

#374
I'm interested in compatibility reports from other people with this driver. I will see if it's possible to improve compatibility with more mouses.


And, thanks again for supporting the board in SymbOS :)

Powered by SMFPacks Menu Editor Mod