"This page is about how to port or convert existing Delphi or Kylix code to work with the Free Pascal Compiler and Lazarus IDE. "
I think he is now onto COM handling differences, but there is also a menu Lazarus Tools.Convert Delphi Project to Lazarus Project
that automates much of the link above. (see my post above for settings on this tool, for Px)
This patch fixes the (self imposed) COM1..9 limit in Windows :
if (s[1] = '/') then begin
if s[2] = 'P' then FlashMode := True
else if (s[2] in ['1'..'9']) then CommPort := 'COM' + Copy(s,2,3) //COM1..999, tested on COM6 & COM57
else ErrorAbort('Invalid /? parameter.');
end
You're clearly familiar with Pascal. I'm struggling with the scoping and lack of return parameters.
Chip hasn't applied exceptions and I'm not familiar with them either but I think SynaSer pretty much demands they be used. So, I'm feeling a little stuck right now.
Chip hasn't applied exceptions and I'm not familiar with them either but I think SynaSer pretty much demands they be used. So, I'm feeling a little stuck right now.
I've used SynaSer in Windows command line programs without too much sweat.
Seems to default to FRaiseExcept := false;
and I see my code does
ser.RaiseExcept:=True;
but that has little impact on my code itself.
above code uses Synaser handler, and digging, I find another module here that does this :
try
ser.Connect(ComName);
except
on Exception do begin
writeln ('ser.Connect failed !!!: ',ser.LastError, ' ',ser.LastErrorDesc);
KeyHalt;
end;
end; // Try
// This coughs : 2 The system cannot find the file specified.
// when given a bad COM number.
Thanks JMG,
I'm making progress again. The ser.RaiseExcept:=True; made a real difference. I had a stray lock hanging that was blocking me. I had CloseComm() doing nothing because there wasn't any obvious close procedure. I've now got CloseSocket() in there and it seems to be fine.
Got the RX LED to flash on the P123 board! Program is now complaining of not being able to send ...
Damn, it works. Just the one misunderstanding with the read data routine. Wasn't that much work in the end, which figures, just me learning my way around.
Now just need to sort out the string parsing of the comport name ... and then onto PNut.exe ... maybe.
Well, here's the source as it stands. Only bugginess is if it opens a comport but there is no Prop responses then it hangs waiting. There's no timeouts on the receive calls. Other than that I'm happy.
The binary is 16MB with debug symbols. I haven't investigated configuring Lazarus just yet. EDIT: And that's a big kudo to the Lazarus devs too! It just worked and never did a thing unexpected. Unheard of. Better than most commercial products for sure. PS: I'm using Lazarus v1.4.4 with Free Pascal v2.6.4 on Kubuntu 14.04.3
Built PX from your source mods on Mac OS X, but I don't have either of the 123 boards to test it. I do have a DE0-Nano, which uses the .jic files, but not a board that uses the .rbf files.
I had to mod the PXHelp.lfm & PXUnit.lfm files to use different fonts than "MS Sans Serif" & "Nimbus Sans L" as Mac OS X does not include those fonts (I used Arial & Helvetica as replacements)...
Yeah, the executable is 16MB so will not attach it...
Chip, could you update the title of this thread when you update the files in the top post?
So "Prop2 FPGA files!!!" becomes "Prop2 FPGA files update Dec 10!!!" for instance, that way it will a lot easier for us to recognize that new files have posted.
BTW, I've been a bit tied up but I will try to get my P2 SD bootloader finished. It would help however if the serial Flash were implemented anyway. It seems a CLKSET #$100 only puts it back into serial bootloader mode.
I just need to make a new top-level Verilog file to simulate what can be simulated, digitally, in the full-custom I/O pads.
I've been very busy on another project involving 80 props per unit, at least in the prototypes but I am sure I could drag myself away to explore this smartpin feature. One thing I know for certain, and just saying, if I had the P2 already it wouldn't be a question of which CPU to use in the production models. So when it all comes together with the P2 I think there will be so much software ready as well as commercial projects that I can see the P2 spring-boarding into an ocean full of ARMs and making a very big splash almost immediately.
I don't know what you mean, but once you reset it by bringing DIR low and then high, you can read the current count as often you want.
The question really pivots on how many pins can map into one Pin Cell. ?
For Quad you have QA,QB, which is 2 pins.
For generic Counting, you may have ExtCLK and Capture, also 2 pins.
There is a use where you want Quadrature and capture, which means 3 pins. QA,QB,Capt(index)
Another 3 pin use may be 2 triangle PWM out and 1 Current-trip sense in = 3 pins.
I don't know what you mean, but once you reset it by bringing DIR low and then high, you can read the current count as often you want.
The question really pivots on how many pins can map into one Pin Cell. ?
For Quad you have QA,QB, which is 2 pins.
For generic Counting, you may have ExtCLK and Capture, also 2 pins.
There is a use where you want Quadrature and capture, which means 3 pins. QA,QB,Capt(index)
Another 3 pin use may be 2 triangle PWM out and 1 Current-trip sense in = 3 pins.
Right now, each pin has its own smarts, and also access to its neighbor pin's IN and OUT signals (as inputs). This is enough to do quadrature encoding and differential duty and frequency measurements. It's also enough for clock+data SPI.
I've got the smart pins compiling with everything else and they seem to be working.
I do see a bit-position problem with the asynchronous serial transmitter, but that should be simple to fix.
I'm really relieved that the smart pins didn't have some problem that effectively choked off the I/O, causing the Prop2 not to talk to PNut. That could have been a pain to resolve. Fortunately, it played nice on the first compile. Now I'll have to test all the smart pin modes and make sure they are working right.
The problem with Fmax dropping to 30MHz had to do with trying to pass the CLK signal out to an I/O pin. That was a risky proposition, anyway, given constraints that would have been needed, so I got rid of it. Now things just compiled at 95MHz. I'll continue on with this, for now, and maybe revisit it later.
The problem with Fmax dropping to 30MHz had to do with trying to pass the CLK signal out to an I/O pin. That was a risky proposition, anyway, given constraints that would have been needed, so I got rid of it. Now things just compiled at 95MHz. I'll continue on with this, for now, and maybe revisit it later.
The problem with Fmax dropping to 30MHz had to do with trying to pass the CLK signal out to an I/O pin. That was a risky proposition, anyway, given constraints that would have been needed, so I got rid of it. Now things just compiled at 95MHz. I'll continue on with this, for now, and maybe revisit it later.
Jezzh, Chip take a day off.
I know us Moderator can't, but you deserve it.
I feel like I've had a lot of time off over Christmas, and now it's time to get back to work. It takes a lot of energy to get things going again, after a break like this.
The problem with Fmax dropping to 30MHz had to do with trying to pass the CLK signal out to an I/O pin. That was a risky proposition, anyway, given constraints that would have been needed, so I got rid of it. Now things just compiled at 95MHz. I'll continue on with this, for now, and maybe revisit it later.
It is common for vendors to put some MHz limit on actual IO clock speeds, even though the silicon dividers may go above that, the relatively long delays out and back from pins, can mean Tsu and Th dictate practical speeds.
IIRC 50MHz is about the upper Serial speed, and around 100MHz is a round number for 3v3 pin-toggle.
That said, I have just done some speed tests to 200MHz on Clk-In to 3v3 MCUs, so the typicals can go higher.
I'm getting a little closer to having the smart pins done. For that last several days, getting the serial transceiver worked out has been very challenging, as it's all wrapped up in one tight ball to save logic, and it handles both synchronous (SPI/I2C, MSB first) and asynchronous (baud rate, LSB first). By integrating what were four separate blocks (async tx, async rx, sync tx, sync rx) into one, the logic shrank by 20%, which is significant, since this could be replicated 64 times. I'll see what other functions could be melded soon. Anyway, still moving forward.
Comments
Did you see this guide?
"This page is about how to port or convert existing Delphi or Kylix code to work with the Free Pascal Compiler and Lazarus IDE. "
http://wiki.freepascal.org/Code_Conversion_Guide
I think he is now onto COM handling differences, but there is also a menu
Lazarus Tools.Convert Delphi Project to Lazarus Project
that automates much of the link above. (see my post above for settings on this tool, for Px)
Chip hasn't applied exceptions and I'm not familiar with them either but I think SynaSer pretty much demands they be used. So, I'm feeling a little stuck right now.
I've used SynaSer in Windows command line programs without too much sweat.
Seems to default to FRaiseExcept := false;
and I see my code does
ser.RaiseExcept:=True;
but that has little impact on my code itself.
Small code snippet is :
var ser:TBlockSerial; ... ser:=TBlockserial.Create; ser.RaiseExcept:=True; ser.Connect(ComName); writeln ('Ser.Connect: Done'); // procedure Config(baud, bits: integer; parity: char; stop: integer; softflow, hardflow: boolean); ser.Config(BaudR,8,'N', StopL-1, false, false); writeln ('Ser.Config : Done');above code uses Synaser handler, and digging, I find another module here that does this :try ser.Connect(ComName); except on Exception do begin writeln ('ser.Connect failed !!!: ',ser.LastError, ' ',ser.LastErrorDesc); KeyHalt; end; end; // Try // This coughs : 2 The system cannot find the file specified. // when given a bad COM number.I'm making progress again. The ser.RaiseExcept:=True; made a real difference. I had a stray lock hanging that was blocking me. I had CloseComm() doing nothing because there wasn't any obvious close procedure. I've now got CloseSocket() in there and it seems to be fine.
Got the RX LED to flash on the P123 board!
Now just need to sort out the string parsing of the comport name ... and then onto PNut.exe ... maybe.
The binary is 16MB with debug symbols. I haven't investigated configuring Lazarus just yet. EDIT: And that's a big kudo to the Lazarus devs too! It just worked and never did a thing unexpected. Unheard of. Better than most commercial products for sure. PS: I'm using Lazarus v1.4.4 with Free Pascal v2.6.4 on Kubuntu 14.04.3
EDIT: Further Lazarus talk over this way - http://forums.parallax.com/discussion/162989/lazarus-port-of-px
i.e.
finally
Writeln('Free Serial Port');
ser.free;
Writeln('Serial Port closed successfully!');
end;
FYI...
Built PX from your source mods on Mac OS X, but I don't have either of the 123 boards to test it. I do have a DE0-Nano, which uses the .jic files, but not a board that uses the .rbf files.
I had to mod the PXHelp.lfm & PXUnit.lfm files to use different fonts than "MS Sans Serif" & "Nimbus Sans L" as Mac OS X does not include those fonts (I used Arial & Helvetica as replacements)...
Yeah, the executable is 16MB so will not attach it...
dgately
Bob,
I gave ser.free a shot but it died badly.
EDIT: I've turned off the SynaSer exception generation which was casuing errors to abort execution and not cleaning up nicely. I've started a fresh topic - http://forums.parallax.com/discussion/162989/lazarus-port-of-px
So "Prop2 FPGA files!!!" becomes "Prop2 FPGA files update Dec 10!!!" for instance, that way it will a lot easier for us to recognize that new files have posted.
BTW, I've been a bit tied up but I will try to get my P2 SD bootloader finished. It would help however if the serial Flash were implemented anyway. It seems a CLKSET #$100 only puts it back into serial bootloader mode.
I just need to make a new top-level Verilog file to simulate what can be simulated, digitally, in the full-custom I/O pads.
Wahoo...
When running in Quadrature mode, can a 3rd (index) pin capture the counter values ? ie 3 pins (or more?) map to one cell.
I've been very busy on another project involving 80 props per unit, at least in the prototypes but I am sure I could drag myself away to explore this smartpin feature. One thing I know for certain, and just saying, if I had the P2 already it wouldn't be a question of which CPU to use in the production models. So when it all comes together with the P2 I think there will be so much software ready as well as commercial projects that I can see the P2 spring-boarding into an ocean full of ARMs and making a very big splash almost immediately.
Keep up the good work Chip.
I don't know what you mean, but once you reset it by bringing DIR low and then high, you can read the current count as often you want.
If that were to happen... We might get sued, just because.
The question really pivots on how many pins can map into one Pin Cell. ?
For Quad you have QA,QB, which is 2 pins.
For generic Counting, you may have ExtCLK and Capture, also 2 pins.
There is a use where you want Quadrature and capture, which means 3 pins. QA,QB,Capt(index)
Another 3 pin use may be 2 triangle PWM out and 1 Current-trip sense in = 3 pins.
Right now, each pin has its own smarts, and also access to its neighbor pin's IN and OUT signals (as inputs). This is enough to do quadrature encoding and differential duty and frequency measurements. It's also enough for clock+data SPI.
I do see a bit-position problem with the asynchronous serial transmitter, but that should be simple to fix.
I'm really relieved that the smart pins didn't have some problem that effectively choked off the I/O, causing the Prop2 not to talk to PNut. That could have been a pain to resolve. Fortunately, it played nice on the first compile. Now I'll have to test all the smart pin modes and make sure they are working right.
I'm going to sleep now.
FPGA is fuelled up and ready for take-off.
Jezzh, Chip take a day off.
I know us Moderator can't, but you deserve it.
I feel like I've had a lot of time off over Christmas, and now it's time to get back to work. It takes a lot of energy to get things going again, after a break like this.
It is common for vendors to put some MHz limit on actual IO clock speeds, even though the silicon dividers may go above that, the relatively long delays out and back from pins, can mean Tsu and Th dictate practical speeds.
IIRC 50MHz is about the upper Serial speed, and around 100MHz is a round number for 3v3 pin-toggle.
That said, I have just done some speed tests to 200MHz on Clk-In to 3v3 MCUs, so the typicals can go higher.