Open ychinhan opened 2 months ago
Hello! Looking at the top level design entity (ShiftedSignalGenerator.bdf), it seems that you're correct and there indeed has been a change that is not documented in the pin mappings. I'll update them, thanks for catching it!
Can't recall exactly what the logic behind the change was, I think it might've been the result of a modification to some interfacing hardware between the standalone and chained versions.
To solve your problem, it should be enough to use pin F15 as the generator's uart rx and and D15 as uart tx.
Alternatively (or if you wish to use different pins): go to the aforementioned top level entity. Find the uart_rx block instance, shown in following image:
You'll probably want to bypass the Mux block and directly connect your desired uart RX pin to the rxd port of the uart_rx block (circled in red in image).
You'll need to do the same for the uart's output: find the uart_tx block:
and route the trx port to your desired pin.
The TristateDemux block in the second image lets the signal pass to the output pin selected by the selector input, keeping the other pin in high impedance. This is iirc done to avoid damage if standalone hardware was connected while the generator was in chained mode or vice versa, and should not be relevant for you.
Good luck!
Hey @ychinhan , were you able to get the standalone mode to work?
I'd also love to hear details about whatever it is that you're using the generator for, if you'd like to share :).
Hey! After connecting to the ports you mentioned (F15/D15), I managed to get it working :) However, I think something happened with the pins mapping (it seems to be in a different order than the one mentioned in the mapping table). With a multimeter, I manually obtained the mappings for each channels:
Channel # | GPIO-1 | Channel # | GPIO-0 |
---|---|---|---|
1 | 5 | 33 | 5 |
2 | 7 | 34 | 7 |
3 | 9 | 35 | 9 |
4 | 13 | 36 | 13 |
5 | 15 | 37 | 15 |
6 | 17 | 38 | 17 |
7 | 19 | 39 | 19 |
8 | 21 | 40 | 21 |
9 | 23 | 41 | 23 |
10 | 25 | 42 | 25 |
11 | 27 | 43 | 27 |
12 | 31 | 44 | 31 |
13 | 33 | 45 | 33 |
14 | 35 | 46 | 35 |
15 | 37 | 47 | 37 |
16 | 39 | 48 | 39 |
17 | 38 | 49 | 38 |
18 | 36 | 50 | 36 |
19 | 34 | 51 | 34 |
20 | 32 | 52 | 32 |
21 | 28 | 53 | 28 |
22 | 26 | 54 | 26 |
23 | 24 | 55 | 24 |
24 | 22 | 56 | 22 |
25 | 20 | 57 | 20 |
26 | 18 | 58 | 18 |
27 | 16 | 59 | 16 |
28 | 14 | 60 | 14 |
29 | 10 | 61 | 10 |
30 | 8 | 62 | 8 |
31 | 6 | 63 | 6 |
32 | 4 | 64 | 4 |
I labelled it using the pin arrangement found in the De0-Nano user manual (GPIO-1 (5) corresponds to GPIO_12 which is T14)
I'm currently attempting to use the generator for an acoustic levitation project similar to SonicSurface, but written and controlled mainly using MATLAB instead of Java for the ease of future modifications! It is still in progress, but so far the generator portion works well with the pin layout above :)
Cheers, Shane
Hi, I recognise that this project was completed a few years ago, but I am just trying my luck here :) while trying to replicate this signal generator (Quartus II 13.0.1 Full version on a De0-Nano), in standalone mode, the UART pins A8/D3 as defined in the communication mapping does not respond. Only when Switch 0 is flipped to supposedly chained mode, then the UART is transmitting and replying properly.
Looking at the past commits there was a revision where the title was 'wip on gpio remapping for chained/unchained version switching'. Is there a chance that during standalone mode something has changed? Thank you!