Charles, Does the Clock rate specified in the pinfile for the module instance relate to the clock rate as it's set in the "card" file? Like I said the example I came across in MKSOCFPGA specified "ClockLowTag" for SS so that is what I used. I later tried building it with ClockMedTag for giggles but it failed, I forget the error, something not found. The DE10 projects seem to be built with a different structure, I don't see a VHD that looks like the card file you linked to. There are SystemVerilog files that look like they pertain to the same things you are describing:
The "card" file? https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/hm2/config/DExx_Nano_xxx_Cramps/atlas_3x24_cap_enc.sv#L7 Similar to the "HPS PLL"? https://github.com/machinekit/mksocfpga/blob/fdc9ddc3a42cc2b6f4a1302ef8e6ca8fc23a4bc0/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv#L297 The sure way to check is capture a few bytes being sent over the > serial port when the driver starts up. That will tell you the *REAL* > baud rate. > That's what I was trying to do. I breadboarded a differential reciever IC and connected the input to a Tx driver on my board and the output to an RS232-USB adapter Rx pin. I used Moserial to try to capture a transmission when MK was starting up. I only got a hex value of all 0's at some random baud rate but the max baud rate in moserial is 2mbps. So I scoped the Tx+ line of the board and only found a single short pull down when starting MK On Tuesday, July 23, 2019 at 10:51:31 AM UTC-4, Charles Steinkuehler wrote: > > On 7/22/2019 1:01 AM, justin White wrote: > > > > For the Sserial thing, I did eventually get MK to dump a logfile that > > showed HM2 come up. SSerial is being initiated as far as that goes, it > does > > print the version. I tried rigging up a Serial cable and sniffing the > > transmit line but the 2.5m baud rate that sserial claims is too high for > > anything I'm using to catch. With a scope I can catch the transmit line > get > > pulled low for a very short period. PCW did mention this: > > > > I still suspect a wiring error as the most like cause of non-detection > of > >> SSerial remotes, > >> but another possibility is an incorrect CLKMED value in the firmware > source > >> (The baud rate calculations that the SSerial processor does depend on > this > >> constant > >> matching the actual CLKMED clock rate) > > > > I've checked the wiring, and double checked the PCB traces against the > > datasheets and continuity to every solder joint everything looks fine. > > Later in the week I'll be able to test a better circuit but I'm not sure > > what to do about checking the clock rate. > > The sure way to check is capture a few bytes being sent over the > serial port when the driver starts up. That will tell you the *REAL* > baud rate. > > The "medium" clock rate is typically defined in the "card" VHDL file. > I'm not sure if there's one specifically for the DE10 or if it uses > the one for the DE0_Nano: > > > https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/DE0_Nano_SoC_DB25/DE0_Nano_SoC_DB25_card.vhd#L73 > > > The clock source also needs to match the frequency specified in the > above file. For the DE0_Nano, the 100 MHz medium clock is generated > by an HPS PLL: > > > https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE0_Nano_SoC_DB25/DE0_Nano_SoC_DB25.vhd#L277 > > > -- > Charles Steinkuehler > cha...@steinkuehler.net <javascript:> > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/168f575c-fe3d-48a3-adc9-8ee24ff97016%40googlegroups.com.
