alvieboy

Simple: you have a PULLUP on an output-only pin, which does not make sense, since it cannot ever go tristate. So just remove pullup from the constraint. Anyway, you can safely ignore the warning.

Are you targeting the same FPGA ? Does that happen all the time ? Can you send me the bit file by email ? (send to alvieboy at alvie dot com)

ruzzmon: Why do you need such speed ? Yes, you can try attaching directly to interrupt vector, but at 1MHz you can only process 96 instructions, add possible icache misses and memory latency... it's rather short. For those speeds, a dedicaded HW controller would be a better approach. Note that you have a direct memory access, so you are not constrained on memory access. Alvie

You have several defines you can use. On all boards, ZPU is defined. On 2.0 boards, ZPU20 is also defined. You can also check for specific boards. Foe example, __ZPUINO_PAPILIO_DUO__ is defined in Papilio DUO boards, and __ZPUINO_PAPILIO_PRO__ in Papilio Pro boards. You can inspect platform.txt and boards.txt for ZPUino, as shipped in DesignLab, for more details: https://github.com/GadgetFactory/DesignLab/blob/master/hardware/zpuino/zpu20/boards.txt https://github.com/GadgetFactory/DesignLab/blob/master/hardware/zpuino/zpu20/platform.txt Alvie

SteveT, thanks for the clarification.

Doesn't ephemeris data change at each message ? It should contain time and location of the GPS satellite, and this needs to be decoded in order to properly decode your posiiton using trilateration, so I don't quite understand "have to download a new copy of the ephemeris after locking on to the signal". It needs to decode that data constantly, not exactly "downloading it". Still, I don't know much about GPS anyway, so I may be mistaken.

Juhizo: are you using the correct serial port ? That "Rx" line does not look like anthing coming from ZPUino bootloader. Or it's just one bit off.. output should be something like 0x7e 0x81 ... 0x7e. Perhaps it's the AVR responding ?

Jack: We need to port that code to 2.0 (i.e., Timer class). Adding a proper "periodicHZ()" call shoud do the trick. Interrupts are now handled internally, and need to follow different rules. Alvie

WTG Jack Any issue with this new release, please let us know.

That should be fixed in 1.0.4. Can you give it a try ? Alvie

What usually takes more space are multiplexers (and incomplete 2^N muxers). And they are so easily declared, that most people forget about that fact. On the other aspect, if you're doing a multi-core, you are surely doing it for performance, so no much sense in using the smaller ZPU, because none of the optional instructions are in HDL (are emulated in firmware).

It has advantages, and disadvantages. The disadvantage is that, if you design an entity that uses another entity, and you want to depict exactly what that other entity is, you should declare your component, to to avoid misunderstandings on the interface. (but this may fail too) The advantage is obvious - less clutter, easier to maintain. I am using that approach in my new designs, despite not using mixed-language. Alvie

Heh, this may help me with my low-power proximity detector Ok, let me read this carefully. But I will assume you will need a proper ADC (which Papilio itself does not have, but there are some ADC wings available). With the ADC, you can do everything in the digital domain. 500Hz or up to 1MHz should be very easy.

Jack, any clues about this one ? Problem seems to be while creating Editor for this file: item = new JMenuItem(_("New DesignLab Library")); item.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { try { String pslPath = Base.getExamplesPath(); File f1 = new File(pslPath+"/Template_DesignLab_Library/edit_library.ino"); Editor newproj = base.handleOpen(f1); newproj.handlesaveAtStart(true); } catch (Exception e1) { e1.printStackTrace(); } } });I guess it's because it cannot find it.

Although TI documentation is far from the best out there Search for 'sprug04a'. Anyway, the implementation will be similar, but not exactly the same. I don't want to do a clone, for obvious reasons. Alvie

Although current ZPUino timers implement a very complex and capable PWM system, we are struggling a bit to integrate PWM and Timer support at same time in ZPUino code. It's rather hard to mix both in a sensible way, because timers can have been claimed for other modules, and PWM may not always be able to map the correct pin, or map the correct timer, and fixing this in software will end up with a bit mess of code and bugs. So, after a quick chat with Jack a few days ago, we concluded that it would be better to have a separate PWM module from now on. But we are not entirely sure of what you users may need/want from such a module. I have spent last couple of days thinking about this, and I have come to a preliminary design which I'd like you to comment on. This design is based on my previous experience with a very PWM-capable generator - the Texas Instruments TMS320F series. I have borrowed some ideas from them, and my plan is roughly to have something like this (I have already implemented most of it, actually): -- Overall Module view - 16-bit counter, 8-bit prescaler. Up to 4 PWM compare/output blocks. - Each output block has 2 outputs. - Sync-in/Sync-out support for cascading more modules (if for example different timebases are needed) and to keep them perfectly synchronized. - Interrupt support. - Clocking block - 8-bit prescaler. Can divide the main clock by anything from 1 to 255. - Only meant to be programmed once. Subsequent programming may lead to glitches. - Per-module clock enable/disable. - Counter block - Three modes: count-up, count-down, and count-up-down - 16-bit period, with shadow register configurable. Phase counter for sync-in. - Compare block (up to 4 blocks per module) - 2 comparators (A and with 16-bit comparator. - Shadowing support - Output module (up to 4 blocks per module) - 2 outputs. - Each output configurable to both A/B comparators, zero or overflow. Can either set, clear, toggle or no-op on output pin. Comments ? Alvie

Ok, it's perfecly wired probably. Can we continue this by email ? Send me your address to alvieboy at alvie dot com. Alvie

You can use this (or a similar approach): library ieee;use ieee.math_real.all;entity mod_m_counter is generic( M: natural := 10; ) --- bla bla end entity;architecture (...) of mod_m_counter is function numbits(width: in natural) return integer is variable r: integer; begin r := integer(ceil(log2(real(width)))); return r; end function; constant N: integer := numbits(M);end (...)

I suspect this may be related to the folder name where you installed DesignLab. It fails while trying to open the example sketch. Can you post: - Full path of DesignLab installation - Does your username in your computer contains spaces or non-ascii characters ? Alvie

Just to clarify: we will support basic "analogWrite()", but will add extra library to control more advanced aspects of PWM generation.

I don't have a clue so far. Can you try installing to the default path and see if it still exhibits the same problem ? Alvie

Hah, forget about ZPUino multi-core... at least in common multi-core sense. It's a long road (if even possible) to get there, due to several reasons: a ) Due to performance issues, the current ZPUino (extreme core) needs a dedicated stack. So all cores will never actually see the same memory, so they cannot behave as SMP. b ) You need a proper interrupt router, and a proper reset controller, as well as software support. c ) There are no memory barriers, nor atomic operations. And no bus-locking mechanism. XTC (XThunderCore) will support SMP, but it's currently under development. It's bigger than ZPU (almost 2x size with medium support like traps, single clock shifter, user/supervisor mode and other modern things [MMU is not ready yet, nor dcache]), but will surely fit nicely on a S6LX25 or larger.

Got some more information on what you're trying to achieve ? Alvie

Can you provide a direct link to the board schematic ? I assume that serial flash is only for the FPGA configuration, and it's a Xilinx one (which can "emulate" JTAG for configuration purposes). I am not sure we can use it, and probably is too small, designed just to hold the FPGA bitfile. Nothing. Just hook the pins in a similar way Papilio does, by changing the UCF file. That should do it. Since you seem to have PMOD connectors, it should be fairly easy. Here're here to help, of course, in case you run into trouble.

So, that board does not have any flash of any kind ? Alvie