Emperor Napoleon

Members
  • Content count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Emperor Napoleon

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. Emperor Napoleon

    My Papilio One Makes Noise

    Update: Now i have the replacement board side by side with the one from sparkfun. Flashed identically. Same ZPU program. The two boards behave quite differently when talking to the host PC over serial. The replacement is mostly fine, the sparkfun has many bad errors. Near as I can tell, the errors are basically chunks of missing bytes on TX and RX. But maybe I am missing something. Now maybe I am using the serial port is some dangerous manner. I can't think of what that would be. If anyone is really interested I can post some monster (large and ugly) ZPU code and host Perl program. But what is clear at this point is the two boards, are not behaving logically equivalent. Clearly the serial is working under some conditions, otherwise how would I be able to flash it, and upload ZPU code. Maybe it only affects half of the dual serial. Or something. Ugh.
  2. Emperor Napoleon

    My Papilio One Makes Noise

    Thanks. It's interesting to note the 32mhz oscillator is of a completely different brand between the two boards.
  3. Emperor Napoleon

    My Papilio One Makes Noise

    Update: Replacement board worked well and did not make noise, made good progress on a project. That board is now fried, a couple days ago. Ordered a new one on sparkfun, guess what, it makes hissing noises. It has intermittent usb serial communication errors with both RX and TX. While it's possible something else has changed that is causing errors, It might also be related to some defect that is causing noise. I think there are also pretty bad issues with usb connector quality. Tried 3 different cables of different brands, they all have intermittent connections when the plug is slightly wiggled in its socket. This is true for every papilo board i have tried. Can I have a new non hissing board please? Thanks
  4. Emperor Napoleon

    Bad USB cable for the Papilio.

    I second this motion. There was actually a visibly missing wire in the connector.
  5. Emperor Napoleon

    Am I Doing This Right?

    Not that it really matters but I think "sr" is longer than it needs to be.. Right?
  6. Emperor Napoleon

    Am I Doing This Right?

    Thanks hamster, I have read your comments several times now, I think it makes sense. If I understand right, the only thing missing is that reading the inputs should be synchronized, latched, and then processed in the next clock cycle. I'm not particularly concerned about the case when both input signals change in the same cycle, it would seem to indicate the encoder is either spinning too fast (not really possible) or falling apart. Yeah, the decoding the "gray code" into an int is just what made sense to me
  7. Emperor Napoleon

    Am I Doing This Right?

    Ok let me explain. So quadrature is like a 2 bit gray code. Function gray() decodes the gray code into an int. Thus decoded values 0,1,2,3 correspond to sequential phases in the progression of a quadrature signal. Every clock cycle I read the value of the 2 quadrature signals. I set "quad" to the decoded current value. Then I set "lastQuad" to the value of "quad" on the previous cycle. By comparing the current value to the last value, i can see if the quadrature signal has progressed forward or backward. If quad = lastQuad+1, then it has moved forward If quad = lastQuad-1 then if has moved backward I don't think debouncing is necessary since I only read the signal values once a clock cycle. Will this really buffer the output a single clock cycle? I thought within a process any values written are immediately visible to following statements? thanks...
  8. Emperor Napoleon

    Am I Doing This Right?

    I wanted to decode a quadrature rotary signal, so I started with the quadrature decoder code from opencores http://opencores.org/project,quadraturecount I was never able to get that code to count, even after ruling out other sources of problems So I modified the code in a way that made sense to myself, it turned out much shorter then the original and best of all it works correctly Yes, It's not enough that it works, I need outside confirmation that I did not do something bad. My question is, did I get lucky, and am I ignoring possible timing issues, race conditions? Under what conditions can I know that writing to a signal visible to outside circuits is safe? My head kind of hurts from thinking about it. Code follows, thanks library IEEE;use IEEE.STD_LOGIC_1164.ALL;use IEEE.STD_LOGIC_ARITH.ALL;use IEEE.STD_LOGIC_SIGNED.ALL;library work;--How we 'talk' to the outside world:entity QuadratureCounterPorts is Port ( clock : in std_logic; --system clock, i.e. 10MHz oscillator QuadA : in std_logic; --first input from quadrature device (i.e. optical disk encoder) QuadB : in std_logic; --second input from quadrature device (i.e. optical disk encoder) CounterValue : out std_logic_vector(23 downto 0); --just an example debuggin output setCount : in std_logic_vector(23 downto 0); writeEnable : in std_logic );end QuadratureCounterPorts;--What we 'do':architecture behave of QuadratureCounterPorts is signal Count : unsigned(23 downto 0); signal clockD : std_logic; signal Quad : std_logic_vector(1 downto 0); signal lastQuad : std_logic_vector(1 downto 0); function gray(a:std_logic_vector) return std_logic_vector isbegin if a="00" then return "00"; elsif a="10" then return "01"; elsif a="11" then return "10"; elsif a="01" then return "11"; end if; return "11";end function; begin --architecture QuadratureCounter -- do our actual work every clock cycle process(clock) begin --keep track of the counter if ( rising_edge(clock) ) then lastQuad <= Quad; Quad <= gray((0=>QuadA,1=>QuadB)); if((unsigned(Quad) = unsigned(lastQuad)+1)) then Count <= Count + 1; end if; if((unsigned(Quad) = unsigned(lastQuad)-1)) then Count <= Count - 1; end if; if(writeEnable = '1') then --Count <= unsigned(setCount); end if; end if; --clock'event CounterValue <= std_logic_vector(Count); end process; --(clock) end behave;
  9. Emperor Napoleon

    Does the ZPUino support unaligned pointer access?

    Sweet, thanks. Makes sense. I guess a compiler cant know ahead of time when a pointer would become unaligned and emit the code for such an acces.
  10. From a little googling I have learned that the ZPU in general does not support unaligned memory accesses. My question is, will the ZPUino compiler generate the correct code to access the data pointed here correctly? I suspect it does not... would that be considered a bug? The reason for this is I am doing some data structure packing/unpacking. Im porting this code from an ARM and it seemed ok there! Thanks, and please let the emperor know if he is really just losing his mind. uint8_t output_buf [64]; uint8_t * buf_ptr= output_buf; *buf_ptr = '1'; buf_ptr++; *(unsigned *)buf_ptr = 0;//Unaligned access.
  11. Emperor Napoleon

    How to modify the timers to buffer the compare value?

    I have decided I will probably just change the comparison between cnt and cmp to ">=" instead of "=". Keeping it simple!
  12. Emperor Napoleon

    How to modify the timers to buffer the compare value?

    Right, I have some logic in C that enables the buffering only if the last period set is below some threshold.
  13. Hi, the emperor would like to ask for your thoughts on how best to buffer the ZPUino's compare values (prescaler too but less critical). Yes, I am a VHDL n00b. The idea is that any compare value settings would not take effect until the next overflow event. This is helpful when changing the frequency of the timer to avoid unnatural states. Below is a diff on how to turn a "timer" into a "timer2", the difference being, a "timer2" should buffer its prescaler and compare registers (just like the PWM channels). I am not sure if anything is wrong with the below code, although i have run into an apparent issue where I hear audio pops when i listen to PWM output and I make little changes to the timer frequency. * Not actually an audio project, this is just how I debug. * It doesn't happen when buffering is disabled, or when I set the update mode to "NOW", or when I just swap in the "timer" for the "timer2" * I still think buffering is important for smooth frequency adjustments without occasional glitches ..... is this true? That is unfortunately all I know... I don't know how to simulate anything and I don't know whats going on inside the fpga's head. Nothing helpful to be seen on the scope because the pops are too brief. The emperor would like to thank you for any insights, advice, or harsh criticism. library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; use ieee.numeric_std.all; library work; use work.zpu_config.all; use work.zpupkg.all; use work.zpuinopkg.all; -entity timer is+entity timer2 is generic ( TSCENABLED: boolean := false; PWMCOUNT: integer range 1 to 8 := 2; WIDTH: integer range 1 to 32 := 16; PRESCALER_ENABLED: boolean := true; BUFFERS: boolean := true ); port ( wb_clk_i: in std_logic; wb_rst_i: in std_logic;@@ -59,23 +59,23 @@ wb_adr_i: in std_logic_vector(5 downto 0); wb_we_i: in std_logic; wb_cyc_i: in std_logic; wb_stb_i: in std_logic; wb_ack_o: out std_logic; wb_inta_o: out std_logic; pwm_out: out std_logic_vector(PWMCOUNT-1 downto 0) );-end entity timer;+end entity timer2; -architecture behave of timer is+architecture behave of timer2 is component prescaler is port ( clk: in std_logic; rst: in std_logic; prescale: in std_logic_vector(2 downto 0); event: out std_logic ); end component prescaler; @@ -93,20 +93,22 @@ ccm: std_logic; -- clear on compare match en: std_logic; -- enable dir: std_logic; -- direction ien: std_logic; -- interrupt enable intr: std_logic; -- interrupt pres: std_logic_vector(2 downto 0); -- Prescaler updp: std_logic_vector(1 downto 0); presrst: std_logic; pwmr: pwmregs; pwmrb:pwmregs;+ cmpb: unsigned(WIDTH-1 downto 0);+ presb: std_logic_vector(2 downto 0); end record; constant UPDATE_NOW: std_logic_vector(1 downto 0) := "00"; constant UPDATE_ZERO_SYNC: std_logic_vector(1 downto 0) := "01"; constant UPDATE_LATER: std_logic_vector(1 downto 0) := "10"; signal tmr0_prescale_rst: std_logic; --signal tmr0_prescale: std_logic_vector(2 downto 0); signal tmr0_prescale_event: std_logic;@@ -214,50 +216,58 @@ do_interrupt <= '0'; if wb_rst_i='1' then w.en := '0'; w.ccm := '0'; w.dir := '0'; w.ien := '0'; w.pres := (others => '0'); w.presrst := '1';- w.updp := UPDATE_ZERO_SYNC;+ w.updp := UPDATE_NOW; for i in 0 to PWMCOUNT-1 loop w.pwmrb(i).en :='0'; w.pwmr(i).en :='0'; end loop; else if do_interrupt='1' then w.intr := '1'; end if; w.presrst := '0'; -- Wishbone access if write_ctrl='1' then w.en := wb_dat_i(0); w.ccm := wb_dat_i(1); w.dir := wb_dat_i(2); w.ien := wb_dat_i(3);+ if BUFFERS then+ w.presb:= wb_dat_i(6 downto 4);+ else w.pres:= wb_dat_i(6 downto 4);+ end if; w.updp := wb_dat_i(10 downto 9); if wb_dat_i(7)='0' then w.intr:='0'; end if; end if; if write_cmp='1' then+ if BUFFERS then+ w.cmpb := unsigned(wb_dat_i(WIDTH-1 downto 0));+ else w.cmp := unsigned(wb_dat_i(WIDTH-1 downto 0)); end if;+ end if; if write_cnt='1' then w.cnt := unsigned(wb_dat_i(WIDTH-1 downto 0)); else if tmrr.en='1' and tmr0_prescale_event='1' then -- If output matches, set interrupt if ovf='1' then if tmrr.ien='1' then do_interrupt<='1'; end if;@@ -313,23 +323,27 @@ end if; end if; end loop; end if; if BUFFERS then for i in 0 to PWMCOUNT-1 loop case tmrr.updp is when UPDATE_NOW => w.pwmr(i) := tmrr.pwmrb(i);+ w.cmp := w.cmpb;+ w.pres := w.presb; when UPDATE_ZERO_SYNC => if ovf='1' then w.pwmr(i) := tmrr.pwmrb(i);+ w.cmp := w.cmpb;+ w.pres := w.presb; end if; when UPDATE_LATER => --if wb_adr_i(3 downto 2) = std_logic_vector(to_unsigned(i,2)) then -- if wb_adr_i(1 downto 0)="11" then -- w.pwmr(i) := tmrr.pwmrb(i); -- end if; -- end if; when others => --w.pwmr(i) := tmrr.pwmrb(i);
  14. Emperor Napoleon

    My Papilio One Makes Noise

    Yep, I'm completely sure it's coming from the board itself. Other things I've noticed: Sometimes the hissing abruptly starts or stops, although generally it will be hissing. It's the board with the linear regulators (papilio one). They do get warm indeed. I kind of don't want to have to send it back, I already flashed it with ZPUino and it looks to be working fine. I'm having too much fun with it already! The board looks completely flawless in every way. Thanks for your thoughts.
  15. Emperor Napoleon

    My Papilio One Makes Noise

    I just got my papilio today and when I plug it in I can hear a wee bit of hissing coming out of it. Not a problem, I am just wondering why this is happening and what part is causing this. I don't see any moving parts or inductors. My best guess is the crystal resonator but i have never heard one of those making sound before. thanks!