Coding partner sought...

[Peter]

I am thoroughly surprised a 700MHz ARM based SOC sould not read fast enough from GPIO. Someone is not programming it very well... usually bare GPIO (ports) can run at 25+ MHz speed, which is actually enough since once a byte/word is read, the rest of processing works at full speed.

Surprisingly, not a programming issue in case of the RPi. The architecture sucks when it comes to realtime requirements - not a typical microcontroller.

[Peter]

Here's a brief outline on some projects I am working on. The main reason for 'slowly' is because I am not a programmer.

I think none of my machines (and they included so many new peripherals) would have been possible, if I had not written basic software support for all of them myself. I usually did that in C language - good enough to test the hardware and provide the OS authors known-working code as a starting point.

There is some likelihood, it will be faster for you to learn the programming skills you need, than arranging collaboration with a coding partner. Most of us are active in existing QL projects, and lacking time for those projects already. Personally, I'm so far behind with Q68 related projects, that I can not help. I really wish you the best of luck to find a coding partner. But my feeling is, you might have to do it yourself, like me.

Fast, modern serial card:

Just out of curiosity, where would that card plug in? Backplane needed when using (S)GC?

[Dave]

I am thoroughly surprised a 700MHz ARM based SOC sould not read fast enough from GPIO. Someone is not programming it very well... usually bare GPIO (ports) can run at 25+ MHz speed, which is actually enough since once a byte/word is read, the rest of processing works at full speed.

Surprisingly, not a programming issue in case of the RPi. The architecture sucks when it comes to realtime requirements - not a typical microcontroller.

No, but then the only "realtime" component is taken care of us by the videocore, which is just another ARM core running at 400MHz. We don't have to worry about us level timings for anything in the HD video generation - all we need to do is cart updated screen memory into the framebuffer without an unreasonable delay. One nice thing the CM3 has over the Pi is that ALL the GPIOs are brought out. Every pin is available if it is not being used for something else.

Bank 0: 28 GPIOs
Bank 1: 18 GPIOs
CMI: 6 inputs, 6 outputs.

I suspect that its 'jitteryness' comes in large part from it running Linux. The ARM cores themselves just do what they do.

There are better choices, but they're either too expensive, or too complex for me to develop with.

[Dave]

There is some likelihood, it will be faster for you to learn the programming skills you need, than arranging collaboration with a coding partner. Most of us are active in existing QL projects, and lacking time for those projects already. Personally, I'm so far behind with Q68 related projects, that I can not help. I really wish you the best of luck to find a coding partner. But my feeling is, you might have to do it yourself, like me.

That will probably be the case. Mostly, it's the struggle that a lot of the hardware is close to ready, but the firmware/driver support components are missing. This makes the hardware as useful as a car without gas. I am just hoping it will play to someone else's strengths and they'll at least look at the challenge. What they could toss together in a week or two would likely far surpass anything I could produce after years of learning. I used to be a semi-competent programmer in C, BASIC and ARM assembly, but for me that was always hard work.

Also, I appreciate your polite and constructive way of saying you can't help. It's easy to be critical or to just say no but it's a lot harder to say no and I feel your pain, look, I'm in the same boat, and here's some free advice to get you on your way.

Just out of curiosity, where would that card plug in? Backplane needed when using (S)GC?

It likely will require an Issue 6+ motherboard to exist solely in the expansion slot. It would do well on a backplane, but it would likely have a through-connector. If it comes together and works well, it will be built in to replace the 8301/8302/8049 and there will just be an HDMI connector where the RGB DIN used to be.

Someone asked about HDMI license fees. It seems the Raspberry Pi Foundation has paid the HDMI license fees for all Pis, including the CM3. As long as the CM3 card is already installed on the board, I should be in enough of a gray area that I do not have to worry too much. It's not like HDMI Licensing can sue me - I'm judgment proof

[Nasta]

Misunderstanding? Why would a fast serial card have a HDMI connector on it? I don't think it's THAT fast though the number of channels is correct

BTW with a master clock at 48MHz, the top baud rate is 3M, this is compatible with the better FTDI serial to USB bridges, which might come in very useful. 300kbytes a second maximum throughput is a lot in QL terms, and would almost certainly need a faster than 68008 CPU.
The lesser baud rates are a bit odd until you get down to the standard 230400 with a tiny error, which is a division by 13, a nice prime number
All other standard rates below that should be available.

[Dave]

Misunderstanding? Why would a fast serial card have a HDMI connector on it? I don't think it's THAT fast though the number of channels is correct

Two separate projects - serial and video. Really three, as I am also working on the clock retiming method with the 8301. Whichever bears fruit first

BTW with a master clock at 48MHz, the top baud rate is 3M, this is compatible with the better FTDI serial to USB bridges, which might come in very useful. 300kbytes a second maximum throughput is a lot in QL terms, and would almost certainly need a faster than 68008 CPU.
The lesser baud rates are a bit odd until you get down to the standard 230400 with a tiny error, which is a division by 13, a nice prime number
All other standard rates below that should be available.

You're reading my mind

[Peter]

What they could toss together in a week or two would likely far surpass anything I could produce after years of learning. I used to be a semi-competent programmer in C, BASIC and ARM assembly, but for me that was always hard work.

Honestly, I think the time difference would be much smaller. Let's take the serial card as example. A large portion of the work is reading the data sheet of your chip, knowing the hardware registers and their location, initialize them correctly. This requires no programming expertise - I would even say that a hardware developer is closer to understand this part of the work.

Choice of language: I prefer C for hardware-related coding. It requires more memory than assembler, but the speed disadvantage is often close to zero, and for non-experts (like me) the risk of mistakes is so much lower.

In your case, I would just code routines to initialize, read and write the UART chip, and a demo program that transfers a file, all in C language. Gives you the safety to proceed making a small batch. You and others already see that everything works. You'd still need someone for a final SMSQ/E driver - but with tested, working code, the hurdle is so much smaller. This is roughly how things worked for me.

It is very unlikely that Q40, Q60, QL-SD or Q68 would have succeeded, if I only designed the hardware. I always had to provide code myself. Trying to remember what was the last piece of QL hardware, where the designer did not also have to code. Maybe the RomDisq...

[Dave]

Honestly, I think the time difference would be much smaller. Let's take the serial card as example. A large portion of the work is reading the data sheet of your chip, knowing the hardware registers and their location, initialize them correctly. This requires no programming expertise - I would even say that a hardware developer is closer to understand this part of the work.

On another project I worked on a few weeks ago where I had a programming buddy (Commodore WiFi) what I did was condense the datasheet down to a programming model. I actually got the idea from a very nice datasheet (one of the best written I have ever seen). It just had a straightforward "this is how you set it up in software, and this is what operation looks like in software."

I now write those breakdowns for myself. Super handy.

In your case, I would just code routines to initialize, read and write the UART chip, and a demo program that transfers a file, all in C language. Gives you the safety to proceed making a small batch. You and others already see that everything works. You'd still need someone for a final SMSQ/E driver - but with tested, working code, the hurdle is so much smaller. This is roughly how things worked for me.

I can do that.

It is very unlikely that Q40, Q60, QL-SD or Q68 would have succeeded, if I only designed the hardware. I always had to provide code myself. Trying to remember what was the last piece of QL hardware, where the designer did not also have to code. Maybe the RomDisq...

[/quote]

You sort-of released the QL-SD. I saw that Marcel Kilgus made some changes that allowed it to work reliably with SGCs. Has this patch been rolled into the main distribution? (ie: can we treat this like GPL open source software, where improvements and fixes are shared?)

I ask, because I'd like to incorporate the "working SGC" version of QL-SD into something QL-related. It would be very nice to have it integrated instead of be an add-on.

[mk79]

You sort-of released the QL-SD. I saw that Marcel Kilgus made some changes that allowed it to work reliably with SGCs. Has this patch been rolled into the main distribution? (ie: can we treat this like GPL open source software, where improvements and fixes are shared?)

I ask, because I'd like to incorporate the "working SGC" version of QL-SD into something QL-related. It would be very nice to have it integrated instead of be an add-on.

Wouldn't the logical thing then be to ask me?

[Dave]

Wouldn't the logical thing then be to ask me?

The logical thing is to ascertain the status of the code. If Peter doesn't consider it "open" then I don't want to bother you. Asking him where you can see it, you might see there's a demand for it and choose to publish the changes. It's up to him and you, but whether the code is open or not is entirely up to him, so I asked him.