Jan 2018 Semester Group Project

The place to share and discuss your Ultibo projects.
mark
Posts: 1325
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Jan 2018 Semester Group Project

Postby mark » Mon Feb 12, 2018 1:04 pm

mark wrote:A lot of the underlying work for the semester project is going to occur in ultibo-users-demo for a few weeks. Mark.

FYI The semester project has these distinctive features, which are not part of ultibo-users-demo:
  • specification
  • zero-defect policy
  • schedule
  • delivery and closure
captbill
Posts: 70
Joined: Tue Aug 16, 2016 5:47 am

Re: Jan 2018 Semester Group Project

Postby captbill » Wed Feb 14, 2018 9:12 pm

I would like to propose as my project a hardware based implementation of a "RAD hardware reference design". The idea is to break the barrier between the Pc world and the MCU world and bring a more RAD like experience by providing a mediator layer to manage the intercommunication between pc and mcu.

The hardware design should use the simplest hardware of the lowest level with no heavy protocols/standards in between. The last protocol on the Pc side, the fence, is USB. From here we must manage the 'dimensional shift' from Pc/Master application--->Hexadecimal transformation---> SPI or UART---> MCU slave application, and back to the Master/Pc. Success would equal a piece of hardware that is barely distinguishable from a Lazarus component, including a simple interrupt based 'event model'.

Here is the hardware reference design I am thinking about for starters:

Master- PIC16f84(program data)---> NRF24l01 RF based wireless transceiver (all communication)

Slave- 'The project hardware'---->PIC16f84(program data)---->NRF24l01

So think of the 'Master' as the 'modem for objects/components' and the 'Slave' as the 'component/wrapper of actual hardware' with networking back to the master seamless and transparent over RF.

The workflow would look something like this. You want to make a 'RAD videocam' based upon a raw SPI based camera. You start by using the 'slave reference design', wire the SPI from the camera, write the MCU code following the 'RAD protocol' that we must establish (which will be hard wired into the master/modem reference design). Success means at the end of the day, you have a hardware camera that looks and behaves like a Lazarus component... and wirelessly.

https://i.ytimg.com/vi/OWyHnAlJhpw/hqdefault.jpg

https://www.zigobot.ch/images/stories/v ... mini-1.jpg
mark
Posts: 1325
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Jan 2018 Semester Group Project

Postby mark » Wed Feb 14, 2018 11:31 pm

For the semester the idea is to have one (or more) ultibo devices that we work on as a group study. Your idea seems to be a device maker not a device but your example usage is a device. I think the master or the slave or both needs to be ultibo/pi to fit the semester project. Also at this time ultibo/lazarus does not include a forms designer or a block diagram designer. What part of your proposal could be upstream or downstream from an ultibo device? I'll check those part numbers to catch up to your thinking. Are you utilizing USB or replacing it?
Mark.
captbill wrote:I would like to propose as my project a hardware based implementation of a "RAD hardware reference design". The idea is to break the barrier between the Pc world and the MCU world and bring a more RAD like experience by providing a mediator layer to manage the intercommunication between pc and mcu.

The hardware design should use the simplest hardware of the lowest level with no heavy protocols/standards in between. The last protocol on the Pc side, the fence, is USB. From here we must manage the 'dimensional shift' from Pc/Master application--->Hexadecimal transformation---> SPI or UART---> MCU slave application, and back to the Master/Pc. Success would equal a piece of hardware that is barely distinguishable from a Lazarus component, including a simple interrupt based 'event model'.

Here is the hardware reference design I am thinking about for starters:

Master- PIC16f84(program data)---> NRF24l01 RF based wireless transceiver (all communication)

Slave- 'The project hardware'---->PIC16f84(program data)---->NRF24l01

So think of the 'Master' as the 'modem for objects/components' and the 'Slave' as the 'component/wrapper of actual hardware' with networking back to the master seamless and transparent over RF.

The workflow would look something like this. You want to make a 'RAD videocam' based upon a raw SPI based camera. You start by using the 'slave reference design', wire the SPI from the camera, write the MCU code following the 'RAD protocol' that we must establish (which will be hard wired into the master/modem reference design). Success means at the end of the day, you have a hardware camera that looks and behaves like a Lazarus component... and wirelessly.

https://i.ytimg.com/vi/OWyHnAlJhpw/hqdefault.jpg

https://www.zigobot.ch/images/stories/v ... mini-1.jpg
mark
Posts: 1325
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Jan 2018 Semester Group Project

Postby mark » Wed Feb 14, 2018 11:38 pm

Bill - do these part suggestions change your plans?

http://www.microchip.com/wwwproducts/en/PIC16F84
PIC16F84
Not Recommended for new designs
Please consider this device PIC16F84A

http://www.nordicsemi.com/eng/Products/ ... F/nRF24L01
This product is not recommended for new designs. Nordic recommends its drop-in compatible nRF24L01+ or for a System-on-Chip solution the Nordic nRF24LE1 or nRF24LU1+.

Mark
mark
Posts: 1325
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Jan 2018 Semester Group Project

Postby mark » Thu Feb 15, 2018 12:06 am

Is PIC16F84 programmable (low voltage) using pi gpio?
captbill
Posts: 70
Joined: Tue Aug 16, 2016 5:47 am

Re: Jan 2018 Semester Group Project

Postby captbill » Thu Feb 15, 2018 5:09 am

mark wrote:Bill - do these part suggestions change your plans?

http://www.microchip.com/wwwproducts/en/PIC16F84
PIC16F84
Not Recommended for new designs
Please consider this device PIC16F84A

http://www.nordicsemi.com/eng/Products/ ... F/nRF24L01
This product is not recommended for new designs. Nordic recommends its drop-in compatible nRF24L01+ or for a System-on-Chip solution the Nordic nRF24LE1 or nRF24LU1+.

Mark


I was thinking in rather generic terms concerning the hardware, hoping to define a simple 'base reference design' (master and slave) to base our discussion/brainstorming around. The actual hardware may need to change to accommodate whatever we find along the way. I definitely feel that the PIC16xxx line of uC's could serve as the 'bare minimum implementation' and will be a good choice to force us to keep things tightly focused on highly efficient code. More likely, 'master' will be better served by a PIC with more available pins, realistically.

I definitely forgot to mention the big 'why' I think that the PIC's look so promising... we have a fantastic new open source compiler/IDE/debugger/emulator addition to the Pascal family...

https://github.com/t-edson/PicPas

This will serve as the 'hardware component developers IDE/design toolkit'. It is looking like a fantastic piece of work. You guys have to give this one a look. There is already a full implementation of a UART in the examples that could give us a running start. Actually, my idea with the NRF24l01xx interfacing will involve SPI, but it's enough to wet the appetite. If we could all play around with some ideas and simply come up with an SPI based "Hello World", much like the UART example, I think we will be well on our way.

I think a good focused goal could be just that... an SPI based 'project framework' which would be not much more than the UART 'Hello World' example. I think this simple thing could get some ideas flowing.

Please discuss!
mark
Posts: 1325
Joined: Mon Oct 03, 2016 2:12 am
Location: Indianapolis, US

Re: Jan 2018 Semester Group Project

Postby mark » Thu Feb 15, 2018 12:18 pm

mark wrote:Is PIC16F84 programmable (low voltage) using pi gpio?

It would be quite convenient if it is.

What are some of the ultibo spi projects that are notable?

Mark
captbill
Posts: 70
Joined: Tue Aug 16, 2016 5:47 am

Re: Jan 2018 Semester Group Project

Postby captbill » Thu Feb 15, 2018 4:51 pm

mark wrote:
mark wrote:Is PIC16F84 programmable (low voltage) using pi gpio?

It would be quite convenient if it is.

What are some of the ultibo spi projects that are notable?

Mark


I appears as if, at first glance, using GPIO directly for programming the PIC's is not that simple. I see many DIY boards but none directly to GPIO. The PIC's look to need a voltage pullup to put them into programming mode. I think this is how they manage to save an extra pin.
captbill
Posts: 70
Joined: Tue Aug 16, 2016 5:47 am

Re: Jan 2018 Semester Group Project

Postby captbill » Thu Feb 15, 2018 6:36 pm

mark wrote:What are some of the ultibo spi projects that are notable?
Mark


What about the issue with the SDCard? If we use the PIC as the SDCard 'controller', that we manage the uploading with, it would simply be a matter of switching a couple of pins to redirect the data flow to either the Pi or the PIC controller.

How about a PIC programmer as a 'wireless Ultibo component'? How cool would that be?!!
http://pic-microcontroller.com/simple-jdm-pic-programmer-using-pic16f84a-microcontroller/
captbill
Posts: 70
Joined: Tue Aug 16, 2016 5:47 am

Re: Jan 2018 Semester Group Project

Postby captbill » Fri Feb 16, 2018 7:28 am

For the semester the idea is to have one (or more) ultibo devices that we work on as a group study. Your idea seems to be a device maker not a device but your example usage is a device. I think the master or the slave or both needs to be ultibo/pi to fit the semester project. Also at this time ultibo/lazarus does not include a forms designer or a block diagram designer. What part of your proposal could be upstream or downstream from an ultibo device? I'll check those part numbers to catch up to your thinking. Are you utilizing USB or replacing it?
Mark.


Forgive my overlooking this post. I totally missed it! :oops:

I think you may have a good point that my project submission may be too hard to 'pin down' in this class forum. How about if I simplify my project submission to simply 'NRF24l01+ Rf network driver library'. This will require utilizing the Rpi GPIO's to drive the NRF24l01+ (it is three pin SPI).

This PIC route is to confusing and doing a direct GPIO based library for the NRF24l01+ will be quite useful as well. I will keep the PIC ideas over in the discussion forum, if you prefer.

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 2 guests